Abstract: ABSTRACT A SYSTEM AND METHOD FOR MITIGATING MUTING OF A CALL IDENTIFIED IN A CELLULAR NETWORK Embodiments of the present disclosure relate to mitigating the muting of a call identified in a cellular network by performing one or more mitigating action to mitigate the muting of the call based on a muting category determined. In an embodiment, the system [700] receives a plurality of parameters such as network parameters, user device parameters and muting parameters. Based on the muting parameters, the system [700] identifies a candidate cell [for e.g. 104A] (experiencing muting of the call) from a plurality of serving cell [104A-104E] in the network. Subsequently, the system [700] analyses network parameters and user device parameters for said candidate cell [for e.g. 104A]. Based on the said analysis, one or muting category is determined by the system [700] basis to which the system [700] mitigates the muting of the call for each of the muting category being identified.
FORM 2
THE PATENTS ACT, 1970
(39 OF 1970)
AND
THE PATENT RULES, 2003
COMPLETE SPECIFICATION
(See section 10 and rule 13)
“A SYSTEM AND METHOD FOR MITIGATING MUTING OF A CALL IDENTIFIED IN A CELLULAR NETWORK”
We, RELIANCE JIO INFOCOMM LIMITED, an Indian National, of, 3rd Floor, Maker Chamber-IV, 222, Nariman Point, Mumbai- 400021, Maharashtra, India.
The following specification particularly describes the invention and the manner in which it is to be performed.
TECHNICAL FIELD
Embodiments of the present disclosure generally relate to wireless communication networks. More particularly, the embodiments of the present disclosure relate to a system and method for mitigating a muting of a call in a cellular network for enhanced call connectivity and user experience.
BACKGROUND
With the recent advancements in wireless communications (technologies such as GMS, EDGE, HSPA, LTE, etc.), wireless networks are widely deployed to provide various communication services such as voice, video, data, advertisement, content, messaging, broadcasts, etc. Additionally, said wireless networks comprise various access points/network for supporting communications for multiple users by sharing the available network resources. One such network is a UMTS network, a successor to GSM technologies. The UMTS networks currently support not only various air interface standards such as Wideband-Code Division Multiple Access (W-CDMA), Time Division-Code Division Multiple Access (TD-CDMA), and Time Division-Synchronous Code Division Multiple Access (TD-SCDMA) but also supports various enhanced 3G data communications protocols, such as High-Speed Packet Access (HSPA) for providing higher data transfer speeds. However, due to various limitations possessed by the UMTS network, an Evolved Universal Terrestrial Radio Access (E-UTRA) with advanced features including higher data rates and lower latency is considered as a replacement of the UMTS and HSDPA/HSUPA technologies as specified in the 3GPP releases 5 and beyond.
Further, in lieu of increasing demand in data traffic, various service providers nowadays have rolled out the network on complete IP Platform to support LTE as well as 5G Technologies. While most of the LTE operators facilitate voice calls via circuit-switched fall back (CSFB) mechanism, a few service operators are shifting to Voice over LTE (VoLTE), thereby providing a carrier upgrade Voice over IP (VoIP) solution built on IP-Multimedia Sub System (IMS) architecture. The VoLTE technology provides numerous benefits to the service operator as well as end-users by enhancing LTE radio spectral efficiency and offering High Definition (HD) voice
quality. Also, VoLTE enables faster call set up with enhanced voice quality. However, since VoLTE is a real-time phenomenon, any packet delay may lead to depreciated user experience.
Further, it is observed that few service operators have developed network where voice and data is fully supported by IP Multimedia Service (IMS), wherein the data transmitted over said wireless network is classified as either real-time (RT) data or non-real-time (NRT) data. For example, voice communication between users is real-time data, while the text communication between the users is non-real data. The voice communication (real-time data) is considered as vital functionality in 3GPP LTE and is carried as voice-over-internet-protocol (VoIP) transmissions. Although the call connectivity in the IP network is faster for setting the call, the IP network still experiences call muting (gap in voice packets/real-time packet (RTP) perceived by human ears as a blank voice).
The typical VoIP session has a periodic small VoIP data packet and periodic silence indication (SID) packets at fixed intervals. Accordingly, there are two periods/intervals in the VoIP transmission: (i) talk-spurt periods during which VoIP packets are transmitted, and (ii) silence periods during which SID packets are transmitted. It is necessary to identify the time gaps in between the intervals during the communications. In case said time gap of the real-time packets (RTP) is not identified, there is a possibility of the muting of the call. For preventing call failures and call drops which lead to bad user experience, there is a need to identify the call muting from the related changes perceived in the KPIs which effect to the cause of the degradation of the call and the user experiences. The call muting can occur in various instances and locations such as at device side, at the network side, in between the communication channels. The existing/conventional technologies lack identification of the cause and reason behind the muting, i.e. the existing technologies fail to identify muting in different scenarios such as uplink coverage, downlink coverage, mobility scenario, user device, backhaul network, etc. Also, the existing technologies, due to lack of identification of different scenarios of the muting, fail to perform appropriate actions for mitigating/eliminating the call muting
efficiently and correctly. In particular, the existing technologies are unable to perform suitable mitigation steps for mitigating the call muting based on the different scenarios of the call muting.
Accordingly, in order to overcome the aforementioned problems inherent in the existing/outgoing solutions, there exists a need of an efficient mechanism for determining different possible scenarios/categories/instances of muting of the call, and accordingly mitigate the muting of the call based on said determined categories. Also, there is a need to mitigate the call muting in the network and devices in an IP network.
SUMMARY
This section is provided to introduce certain objects and 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.
Embodiments of the present disclosure relate to a method for mitigating muting of a call in a cellular network comprising a plurality of serving cells. The method comprising: receiving, for each of the plurality of serving cells, at least one network parameter, at least one user device parameter and at least one muting parameter, wherein the at least one user device parameter is associated with at least one user device served by each of the plurality of serving cells; identifying a candidate cell, from the plurality of serving cells, experiencing the muting of the call, the identification being based on the at least one muting parameter; analysing the at least one network parameter and the at least one user device parameter for the candidate cell; determining at least one muting category based on said analysis of the at least one network parameter and the at least one user device parameter, wherein each of the at least one muting category has an associated identification criteria, and the at least one muting category is at least one of an uplink muting, a downlink muting, a user device muting, a mobility muting and a backhaul muting; and mitigating the muting of the call by performing one or more mitigating action for each of the at least one muting category.
Further, the embodiments of the present disclosure encompass a system for mitigating muting of a call in a cellular network comprising a plurality of serving cells. The system comprising: a transceiver unit configured to receive, for each of the plurality of serving cells, at least one network parameter, at least one user device parameter and at least one muting parameter, wherein the at least one user device parameter is associated with at least one user device served by each of the plurality of serving cells; and a processor configured to: identify a candidate cell, from the plurality of serving cells, experiencing the muting of the call, the identification being based on the at least one muting parameter, analyse the at least one network parameter and the at least one user device parameter for the candidate cell, determine at least one muting category based on said analysis of the at least one network parameter and the at least one user device parameter, wherein each of the at least one muting category has an associated identification criteria, and the at least one muting category is at least one of an uplink muting, a downlink muting, a user device muting, a mobility muting and a backhaul muting, and mitigate the muting of the call by performing one or more mitigating action for each of the at least one muting category.
BRIEF DESCRIPTION OF THE DRAWINGS
The accompanying drawings, which are incorporated herein, and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems in which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Some drawings may indicate the components using block diagrams and may not represent the internal circuitry of each component. It will be appreciated by those skilled in the art that disclosure of such drawings includes disclosure of electrical components or circuitry commonly used to implement such components.
FIG.1 illustrates an exemplary cellular network [100] having a plurality of serving cells [104A, 104B, 104C, 104D, 104E] and user devices [102A, 102B, 102C, 102D]
served by the plurality of the serving cells [104A, 104B, 104C, 104D, 104E], in accordance with an embodiment of the present disclosure.
FIG.2 (FIG.2A and FIG.2B) illustrates an exemplary scenario demonstrating the muting of the call, in accordance with an embodiment of the present disclosure.
FIG.3, FIG.4 and FIG.5 illustrate exemplary scenarios demonstrating the muting of the call caused in events of a late handover, an early handover and a wrong handover respectively, in accordance with embodiments of the present disclosure.
FIG.6 illustrates an exemplary scenario demonstrating the muting of the call caused in an event of PCI confusion and PCI detection, in accordance with an embodiment of the present disclosure.
FIG.7 illustrates a system architecture [700] for mitigating muting of a call identified in a cellular network, in accordance with an embodiment of the present disclosure.
FIG.8 illustrates an exemplary method flow diagram [800] comprising the method for mitigating muting of a call identified in a cellular network, in accordance with an embodiment of the present disclosure.
DETAILED DESCRIPTION
In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features. An individual feature may not address any of the problems discussed above or might address only one of the problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein. Example embodiments of the present disclosure are described below, as illustrated in various drawings in which like reference numerals refer to the same parts throughout the different drawings.
Embodiments of the present disclosure may relate to a system and a method for mitigating the call muting of a call in a cellular network. The system receives a
plurality of parameters for each serving cell of the network, wherein the parameters include, but not limited to, network parameters, muting parameters and user device (UE) parameters. Based on said received parameters, the system identifies a candidate cell among a plurality of serving cells in a cellular network based on the muting parameters such as mute call rate and mute call count, wherein the candidate cell corresponds to a serving cell facing maximum muting. Subsequently, the system analyses the network parameters and user device parameters for the candidate cell to determine one or more muting category. Once the muting category is determined, the system mitigates the muting of the call by performing one or more mitigating action based on the determined one or more muting category. Further, the system may be implemented at a network level or user device level. In an event the system is implemented at the network level, a network entity may be configured to perform functions/steps in accordance with the present disclosure.
The cellular network, as used herein, may refer to a mobile network comprising a network entity and a plurality of serving cells for providing services to one or more user device present inside the network. FIG. 1 illustrates an exemplary cellular network [100] having a plurality of serving cells [104A, 104B, 104C, 104D, 104E] and user devices [102A, 102B, 102C, 102D] served by the plurality of the serving cells [104A, 104B, 104C, 104D, 104E]. The at least one serving cell [104A, 104B, 104C, 104D, 104E] as used herein may refer to one or more cells which provide network coverage to a geographic coverage area. The candidate cell [for e.g. 104A] as used herein may refer to a serving cell where maximum muting is observed based on various parameters such as mute call rate and mute call count.
The user device as used herein may include, but not limited to, a smartphone, a feature phone, a tablet, a phablet and any such device obvious to a person skilled in the art. Further, the user device may have the capability to perform the steps of mitigating the muting of the call in the cellular network, in accordance with the present disclosure. Furthermore, the user device may comprise an input means such as a keyboard, an operating system, a memory unit, a display interface, etc.
The network entity as used herein may refer to one of an eNodeB, a Base Transceiver Station (BTS), Base Station Controller (BSC), a Radio Network Controller (RNC) and a server. Further, the network entity may be present in the cellular network and may comprise of one or more components of an IMS network, wherein said components may include, but not limited to, a transceiver unit, a processor and a storage unit. Further, the network entity may be configured to communicate to the user device through the wireless LAN network. Also, the network entity may be configured to serve the plurality of serving cells present in the network.
The transceiver unit, as used herein, may refer to a device comprising a transmitter and a receiver configured to transmit and receive data/information. For example, in LTE eNB, the transceiver unit may comprise of RRH (Remote Radio Head), where such RRHs may be configured to have operation and management processing capabilities. The RRHs may further comprise of a standardized optical interface to connect to the rest of the base station.
The processor as used herein may include one or more processors, wherein the processor may refer to any logic circuitry for processing instructions. Said processor might be a general-purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, a controller and a microcontroller. For example, an LTE eNodeB may comprise of one or more processors which may reside in the base band unit (BBU), like a UAMA and a channel card processor. The UAMA may be configured to performs functions, including but not limited to, relating to network and external interfacing, reset, clock generation/distribution, etc. The channel card processor may be configured to perform functions, including but not limited to, relating to subscriber channel processing, and also act as a CPRI Interface.
The storage unit, as used herein, may refer to any non-transitory media configured to store data and/or instructions. Further, said storage unit may be a volatile memory or a non-volatile memory, wherein said memory may be single or multiple, coupled or independent, and may be positioned at the device level or network level.
The network parameters as used herein may refer to network information/data for each of the plurality of serving cells in the cellular network. Further, the network parameters may include, but not limited to, a basic service set identifier (BSSID), a RF coverage power (RSRP), a Reference Signal (RS) strength, an uplink SINR, a downlink SINR, a MCS, a call drop rate, a handover success rate, a number of handovers, type of handovers (late handover, early handover and wrong handover), a handover delay, a QoS of the at least one serving cell, uplink Volte residual block error rate (BLER), an interference over thermal (IoT), a RRC connection re-establishment (RRE) attempt, a GTP loss rate, PDCP packet loss rate, packet loss in TWAMP, downlink Volte, uplink Volte, Volte HARQ fail rate, packet loss rate at network, PCI collision, PCI confusion, downlink Volte channel quality indicator (DL Volte CQI), an overshooting cell, a radio link failure (RLF) count, ping pong, Cell Individual Offset (CIO).
The user device parameters, as used herein, may refer to user device information/data for each user device served by the plurality of serving cells in the cellular network. Further, the user device parameter may include, but not limited to, an international mobile subscriber identity (IMSI) facing frequent muting, a user density, user throughput, packet loss at the user device and a percentage of ROHC de-compression failures.
The muting parameters, as used herein, may refer to the performance characteristics of the call established between at least two user devices. Further, the muting parameters may include, but not limited to, mute call rate and mute call count. In an embodiment, the muting parameters may refer to the percentage and frequency of calls getting muted at network or user device.
The following table (Table 1) illustrates the definitions of various parameters such as network parameters, muting parameters and user device parameters, in accordance with wireless communication networks based on the IEEE 802.16 and IEEE 802.11 standards:
Parameter Full-Form Definition
PDCP Packet Packet data PDCP implements Robust Header Compression
Loss Rate convergence (RoHC) in the PDCP layer and sends the data to the
protocol layer Radio Link Control (RLC) Layer. While transmitting, any data loss in the uplink PDCP layer refers to PDCP Packet Loss.
UL VoLTE Uplink VoLTE It refers to a failure rate for initial transmission.
Residual BLER (Voice over Also, it refers to a ratio of the number of times the
LTE) residual first re-transmission was carried out to the number
Block Error Rate of times the initial transmission was carried out.
UL SINR Uplink Signal It refers to the power of a signal of interest divided
to by the sum of the interference power and the
Interference Noise Ratio power of the background noise.
IOT Interference It refers to any interference in a cell when there is
over Thermal no user attached, wherein said interference is caused by an external source in a radiating spectrum.
RSRP RF coverage It refers to a power of the LTE reference signals
power spread over the full bandwidth and narrow band.
DL VoLTE CQI Downlink It refers to an indicator carrying the information
VoLTE Channel Quality Indicator relating to how good/bad the channel quality is.
Overshooting N.A. A cell is considered as an overshooting cell if the
cell cell is serving higher than the inter-site distance of 1.5 times such that percentage of samples is more than 40% and PRB utilization is higher than 40%.
GTP Loss Rate GPRS It refers to an IP/UDP based protocol used in GSM,
Tunneling UMTS and LTE core networks. Also, it helps in
Protocol encapsulation of user data when passing through the core network. It also carries bearer specific signalling traffic between various core network entities. The GTP loss rate is calculated between SAE-GW and eNB in Downlink direction.
TWAMP Two-Way TWAMP creates a session from EPC location to
Active each type of routers (i.e. SAR, AG3, AG2, AG1 and
Measurement CSS) and eNodeBs (network entity), where the
Protocol routers and eNodeBs act as TWAMP Reflector. Further, each session carries synthetic TWAMP packets to measure bidirectional packet loss, latency and jitter between each router and the end nodes.
Packet Loss in Packet Loss in The TWAMP measures packet loss between the
TWAMP Two-Way nodes from eNodeB to EPC (Evolved Packet Core).
Active In an event the packet loss is higher than 1%
Measurement between any nodes, the flow of Real-Time Packets
Protocol (RTP) from receiver to transmitter end and vice versa are affected.
Handover N.A. The handover duration may start from the time a
delay Handover Response Message is sent from a target eNB to a source eNB and end at the time a RRC Connection re-configuration complete message is received at the target eNB from the user device. Further, the handover process is subdivided into three phases: preparation, execution and completion, wherein the execution phase is most critical since the UE is completely detached from the network during this time. This time interval experienced by the RRC message refers to the delay time or the handover delay.
RLF Radio Link In an embodiment, radio link failure occurs at the
Failure user device in one of the following situations:
(i) RSRP is less than the required value, or (ii) user
device is unable to decode the control channel
(PDCCH) or data channel (PDSCH) due to power
signal quality.
In another embodiment, radio link failure occurs at
eNodeB in one of the following situations:
(i) uplink SINR of the user device is lower than the
SINR of eNodeB; or (ii) eNodeB is unable to detect
any acknowledgement response from the user
device for the data channel (PDSCH).
Other reasons behind the radio link failures may be
based on the type of handover, i.e. late handover,
early handover and wrong handover
RLF Count Radio Link It refers to a number of breaks in the call
Failure count connectivity for some duration.
PCI Collision Physical Cell PCI may be used for signal synchronization and
Identity random access. Each evolved universal terrestrial
collision radio access network (E-UTRAN) cell is allocated a PCI. Further, the PCI refers to a configuration of cell identity used to regulate the neighbouring system of each cell corresponding to a unique combination of PSS (Primary Synchronization Signals) and SSS (Secondary Synchronization Signals).
A PCI collision occurs between two intra-frequency cells using an identical PCI.
Ping Pong Ping refers to the transmission of data packets sent to an opposite computer, while Pong refers to the response from the other computer. Further, during the ping pong mechanism, a handover of the user device to a target cell is performed. However, in an event, the user device returns to the original cell within a short time, the ping handover results in the muting of the call.
RRC Re- When RLF occurs, the RRC Re-establishment
establishment attempt takes place and cause delay resulting in
attempt muting.
ROHC De- Robust In VoIP packets, the size of headers (IP/UDP/RTP) is
compression Header larger than the data itself, and thus, compressing is
failures Compression required. Compressing such protocol headers over
Decompressio end to end (user to user) connection is not feasible
n failure since the headers play an essential role. However, compressing these protocol headers over the air interface, i.e. between the user device and eNB/NB/BTS etc. is possible. Pursuant to compression, decompression is required, and any failure during the process of de-compression at user device end may lead to muting.
Repeated N.A. It refers to the IMSI of the user device facing
muting for repeated issues for connection and said issue might
same IMSI be faced by several eNodeB which may be due to misbehaviour of the user device.
Table 1
The muting of the call as used herein may refer to one of a call drop and a call failure in an event of a gap in voice packets, and/or real-time packets (RTP) perceived as a blank voice. For instance, call muting may refer to a phenomenon where users hear no voice during the attempts made by the network for re-setting up the call established between the users. Thus, muting can be understood as a gap between voice/RTP packets, excluding the silent packets (SID). For example, in LTE technology, say if the periodicity of voice/RTP is 20 ms and periodicity of SID packets is 160 ms, in an event 20 consecutive RTP packets (20 *20ms = 400 ms) are missed then that call may be considered as a mute call.
FIG.2 (FIG.2A and FIG.2B) illustrates an exemplary scenario of the muting of the call.
Further, as illustrated in FIG.2A, in a downlink communication, downlink RTP packets
may comprise a plurality of voice packets and one or more silence indicator packets,
wherein said one or more silence indicator packets are present on a user plane path
from the network to the user device. The voice packets and the silence indicators
are transmitted at a fixed interval, and therefore, there may be a need to identify
the time gaps (downlink acknowledgement time) in between the intervals during the
communications. In the event of silence indicators on the path, there is a possibility
that the user device may detect only silence indicator packets. In such event, there
may be a gap/silence period (downlink acknowledgement time) while receiving the
voice packets due to the presence of silence indicators that may create a silence/gap
(particularly illustrated in FIG.2B) between the voice packets. In such event, the
silence indicator packets may not be counted and may be ignored while calculating
the muting parameters. Further, the phrase ‘muting of the call’ and ‘call muting’
have a similar meaning and may be interchangeably used throughout the disclosure.
The muting category, as used herein, may refer to a category/type of the muting occurred at the network or the user device. In particular, the muting category may be one of an uplink muting, a downlink muting, a backhaul muting, a user device muting and a mobility muting. Each of the muting categories has associated identification criteria of detecting which the type of muting, wherein said associated criteria might be defined by the system.
The uplink muting may be determined in an event the muting occurs between the user device and eNodeB (i.e. network entity). In an embodiment, the uplink muting may occur in an event the user device is in a poor coverage area during the transmission to the eNodeB, and faces connection issue during the communication due to high RSSI among the cells of the network. Further, the uplink muting may be determined based on the uplink SINR, the PDCP packet loss rate, the BLER and the IOT.
The downlink muting may be determined in an event the muting occurs between the eNodeB and the user device. In an embodiment, the downlink muting may occur in an event the user device is in a poor coverage area during the transmission from the eNodeB. Further, the downlink muting may be determined based on the RSRP, the CQI and the Volte HARQ fail rate.
The backhaul muting may be determined in an event the muting occurs beyond the serving cells (served by the network), i.e. the backhaul muting may occur due to intermediate links between the core network and small subnetworks at the edge of the network. The backhaul muting may occur in an event of packet loss in the backhaul path, i.e. path through which data is transmitted from eNodeB to core of the network. Further, the backhaul muting may be determined based on the GTP loss rate, the packet loss at the network and the packet loss at the user device.
The user device muting may be determined in an event the muting occurs due to incompatibility of the user device to avail services and frequently facing failure issues. Further, the user device muting may be determined based on the percentage of ROHC de-compression failures and the IMSI of the user device. Further, the user device muting may be determined if the same IMSI is getting repeated for the user device.
The mobility muting may be determined in an event the user device is travelling from one network to another, thereby requiring a need of handover, i.e. the mobility muting may occur due to failure of RRC re-establishment during the handover. The mobility muting may occur in an event the user device is attempting to re-select from one serving cell to another serving cell. Further, the mobility muting may be
determined based on the handover success rate, the number of handovers, the handover delay, the type of handover, the RLF count, the RRE attempt and the PCI collision.
Further, in an embodiment, FIG.3 illustrates a scenario depicting the muting of the call caused in an event of late handover. As illustrated in FIG.3, if the user device [for e.g. 102A] remains connected to original serving cell [for e.g. 104A] in the network, in spite of the target serving cell [for e.g. 104B] having more signal strength, the user device [for e.g. 102A] experiences radio link failure with the original serving cell [for e.g. 104A]. Further, on detection of the RLF, the user device [for e.g. 102A] transmits the RRC re-establishment message (comprising ID of the serving cell and RLF information such as C-RNTI of previous serving cell, UE Identity, Physical Cell ID, Short MAC-I, Re-establishment Cause being one of a RRC Re-configuration Failure or a Handover Failure or a Radio Link Failure, RLC indicate reaches the Maximum re-transmission, etc. ) to the target cell [for e.g. 104B] which further relays the RLF information to the serving cell [for e.g. 104A] over an X2 interface. This sequence of events is considered as late handover, and the mobility muting occurs in an event of repetitive handover event such that handover success rate is lower than the threshold.
In another embodiment, FIG.4 illustrates a scenario depicting muting of the call caused in an event of early handover. As illustrated in FIG.4, RLF occurs when the user device [for e.g. 102A] after the handover to target cell [for e.g. 104B], returns to original serving cell [for e.g. 104A]. Further, on detection of the RLF, the user device [for e.g. 102A] transmits the RRC re-establishment message (comprising ID of the original serving cell [for e.g. 104A] and RLF information such as C-RNTI of previous serving cell, UE Identity, Physical Cell ID, Short MAC-I, Re-establishment Cause being one of a RRC Re-configuration Failure or a Handover Failure or a Radio Link Failure, RLC indicate reaches the Maximum re-transmission, etc. ) received by said original serving cell [for e.g. 104A]. However, said RLF information is relayed by the original serving cell [for e.g. 104A] to the target serving cell [for e.g. 104B] over an X2 interface as a result of which the target cell [for e.g. 104B] transmits a handover
report message to the original cell [for e.g. 104A]. This sequence of events is
considered as early handover, and the mobility muting occurs in an event of
repetitive handover event such that handover success rate is lower than the
threshold.
In yet another embodiment, FIG.5 illustrates a scenario depicting muting of the call caused in an event of the wrong handover. As illustrated in FIG.5, RLF occurs when the handover of the user device [for e.g. 102A] is performed to a wrong serving cell [for e.g. 104C] instead of the target serving cell [for e.g. 104B]. Thereafter, the user device [for e.g. 102A] immediately returns to original serving cell [for e.g. 104A]. Further, on detection of the RLF, the user device [for e.g. 102A] transmits the RRC re-establishment message (received by the original serving cell [for e.g. 104A], (comprising ID of the serving cell and RLF information such as C-RNTI of previous serving cell, UE Identity, Physical Cell ID, Short MAC-I, Re-establishment Cause being one of a RRC Re-configuration Failure or a Handover Failure or a Radio Link Failure, RLC indicate reaches the Maximum re-transmission, etc.) to the target serving cell [for e.g. 104B]. However, said RLF information is relayed by the original serving cell [for e.g. 104A] to the target serving cell [for e.g. 104B] over an X2 interface as a result of which the wrong serving cell [for e.g. 104C] transmits a handover report message to the original serving cell [for e.g. 104A]. This sequence of events is considered as the wrong handover, and the mobility muting occurs in an event of repetitive handover event such that the handover success rate is lower than the threshold.
Further, in an embodiment, FIG.6 illustrates a scenario depicting muting of the call caused in an event of PCI collision. As illustrated in FIG.6, the neighbouring serving cells [for e.g. 104A, 104B] have the same Physical Cell Identity/Root Sequence Index (PCI/RSI). Further, when a first (neighbouring) cell [for e.g. 104B] present in eNodeB1, transmits a message (eNodeB configuration update comprising PCI, RSI, etc.) to a second serving cell [for e.g. 104A], said second serving cell [for e.g. 104A] detects PCI collision based on the message. The PCI collision is detected when said neighbouring serving cells [for e.g. 104A, 104B] have the same frequency and PCI.
Thereafter, said second serving cell [for e.g. 104A] reports the PCI collision to an Element Management System (EMS) [610], wherein the EMS may consist of various components and applications for managing network elements. The EMS [610] then performs PCI re-configuration by assigning new PCI to said second serving cell [for e.g. 104B]. Furthermore, when the user device [for e.g. 102A] travels from the second serving cell [for e.g. 104B] to the first serving cell [for e.g. 104A], the user device [for e.g. 102A] creates an ANR between the first serving cell [for e.g. 104A] and the second serving cell [for e.g. 104B] and shares configuration update (along with PCI) to the second serving cell [for e.g. 104B]. Likewise, PCI confusion is created in the second serving cell [for e.g. 104B], since the second serving cell [for e.g. 104B] was already a neighbour of the first serving cell [for e.g. 104A] with the same PCI. Pursuant to the PCI confusion, EMS [610] resolves the conflict by determining new PCI.
The mitigating action as used herein may refer to an action performed for mitigating the call muting based on the muting category. In particular, the mitigating action for each muting category is pre-defined by the system.
FIG.7 illustrates a system architecture [700] for mitigating muting of a call identified in a cellular network, in accordance with an embodiment of the present disclosure. As illustrated in the FIG.7, the system architecture [700] may comprise a transceiver unit [720], a processor [730] and a storage unit [740]. Further, the transceiver unit [720], the processor unit [730], the storage unit [740] and the sub-components therein may be configured to work in conjunction and provide respective functionalities in order to achieve the objective of the present disclosure. Further, the system [700] may be implemented at one of the user device [102A-102D] level and the network level.
The transceiver unit [720] may be configured to receive the at least one network parameter, the at least one user device parameter and the at least one muting parameter (as explained above) for each of the plurality of the serving cells [104A-104E] in the cellular network, wherein the at least one network parameter and the at least one muting parameter may be received from a network database [710A],
and the at least one user device parameter may be received from a user device database [710B]. In an embodiment, the network database [710A] and the user device database [710B] may be located at one of the user device [102A-102D] level and the network level. The present invention encompasses receiving of said parameters through one of an automatic update and a manual update in the system [700].
Further, the transceiver unit [720] may be configured to transmit the at least one network parameter, the at least one user device parameter and the at least one muting parameter to the processor [730] of the system [700]. Thereafter, the processor [730] may be configured to identify a candidate cell [for e.g. 104A] among the plurality of the serving cells [104A-104E]. Further, the candidate cell [for e.g. 104A], experiencing the muting of the call, may be identified based on the at least one muting parameter such as mute call rate and the mute call count i.e. the serving cell meeting a muting criteria may be identified as a candidate cell [for e.g. 104A], wherein the muting criteria may be pre-defined by the system [700]. Further, the mute call count and the mute call rate may be configurable at the system [700]. In an exemplary embodiment, the candidate cell [for e.g. 104A] may be identified based on the following criteria of the at least one muting parameter, i.e. if the mute call rate and the mute call count of a serving cell meet the below criteria, the serving cell may be identified as a candidate cell, if say for example,: Mute call count > 50
Mute call rate>3
Further, the processor [730] may be configured to analyse the at least one network parameter and the at least one user device parameter of the candidate cell [for e.g. 104A] being identified. In an embodiment, the processor [730] may be configured to analyse the at least one network parameter and the at least user device parameter to determine the at least one muting category having the pre-defined associated identification criteria. In a preferred embodiment, the associated identification criteria for each of the at least one muting category may be as follows:
Uplink Muting:
PDCP Packet Loss Rate > 1% UL VOLTE residual BLER > 1% UL SINR < 0dB
IOT > -105dbm
Downlink Muting:
RSRP <-110dBm DL Volte CQI < 7 VOLTE HARQ Fail Rate > 1%
Overshooting cell>40%
Backhaul Muting:
GTP Loss Rate > 1%
Packet Loss in TWAMP>1%
User Device Muting:
ROHC De-compression failure
Frequent muting for same IMSI
Mobility Muting:
Handover Delay > 1000ms
RLF Count (handover (early/ Late/Wrong cell)) > 1000
PCI Collision
Ping Pongs > 1000
RRC Re-establishment attempt > 1000
Further, pursuant to determining of the at least one muting category, the processor [730] may be configured to mitigate the muting of the call by performing the one or more mitigating action for each of the at least one muting category. In an embodiment, said one or more mitigating action may be pre-defined by the system [700] for each of the at least one muting category. In an event two muting categories are determined, the processor [730] may be configured to mitigate the
muting of the call by performing the one or more mitigating action for each of the two muting categories determined. In a preferred embodiment, the one or more mitigating action for mitigating process for each of the at least one muting category is as follows:
Mitigating Action for Uplink Muting:
1. Performing physical optimisation by up-tilting to E-Tilt/M-Tilt and Re-azimuth; and
2. Creating new cell sites by splitting the sector of the cellular network to improve cell edge coverage and capacity of the cell;
Mitigating Action for Downlink Muting:
1. Performing coverage optimisation by up-tilting to E-Tilt/M-Tilt and Re-azimuth;
2. Performing overshooting optimisation by down-tilting to E-Tilt/M-Tilt; and
3. Creating new cell sites by splitting the sector of the cellular network; and Identifying a serving cell.
Mitigating Action for Backhaul Muting:
1. Identifying at least one fault creating the packet loss at TWAMP. In an event, the packet loss is higher than a predefined criteria, rectify high packet loss issue by improving the link stability.
Mitigating Action for User Device Muting
1. Identifying at least one user device having the IMSI facing frequent muting and failure issues.
2. Optionally, the identified user devices with such IMSI may be communicated to the device vendor.
Mitigating Action for Mobility Muting:
1. Performing handover optimisation based on the type of handover, the handover success rate, the number of handovers and the handover delay. Further, the handover parameters may be tuned based on the current network and muting parameters. In an embodiment, the CIO and the triggering time may be
decremented by 1db in an event of fast handover, while the CIO and the triggering time may be incremented by 1db in an event of slower handover.
Thus, as illustrated in the below table (Table 2), the processor [730] may be configured to perform the at least one action based on the at least one muting category determined:
Muting Category Associated Identification Mitigating Action to be
Criteria performed
Uplink Muting PDCP Packet Loss Rate > 1% 1. Performing physical
UL VOLTE residual BLER > 1% optimisation;
UL SINR < 0dB 2. Creating new cell sites by
IOT > -105dbm splitting the sector of the cellular network; and
Downlink Muting RSRP <-110dBm 1. Performing coverage
DL Volte CQI < 7 optimisation;
VOLTE HARQ Fail Rate > 1% 2. Performing overshooting
Overshooting cell>40% optimisation;
3. Creating new cell sites by splitting the sector of the cellular network; and
Backhaul Muting: GTP Loss Rate > 1% Identifying at least one fault
Packet Loss in TWAMP>1% creating the packet loss at TWAMP
User Device ROHC De-compression failure Identifying at least one user
Muting: Frequent muting for same IMSI device having the IMSI facing frequent muting and failure issues
Mobility Muting: Handover Delay > 1000ms Performing handover
RLF Count( handover (early/ optimisation based on the
Late/Wrong cell) > 1000 type of handover, the
PCI Collision handover success rate, the
Ping Pongs > 1000 number of handovers and
RRC Re-establishment attempt > 1000 the handover delay.
Table 2
Further, the storage unit [740] may be internally connected with the transceiver unit [720] and the processor [730] for storing the at least one of the muting criteria, the muting category, the associated identification criteria, the at least one action corresponding to each muting category. The present disclosure also encompasses self-evaluating said information stored in the storage unit [740] and automatically performing the one or more mitigating action based on a feedback mechanism and information stored in the storage unit [740] of the system [700].
As illustrated in FIG.8, the present disclosure encompasses an exemplary method [800] for mitigating muting of the call identified in the cellular network, in accordance with an embodiment of the present disclosure. The following method [800] may be implemented at one of the network level or the user device [102A-102D] level. Said method includes detailed steps involved in mitigating muting of the call in the cellular network, wherein the method [800] may initiate at step 802 where the muting of the call is identified.
At step 804, the transceiver unit [720] may receive the at least one network parameter, the at least one user device parameters and the at least one muting parameter for each of the plurality of the serving cells [104A-104E] in the cellular network. The present invention encompasses receiving of said parameters through one of an automatic update and a manual update in the system [700]. Further, the transceiver unit [720] may internally communicate with the processor [730] of the system [700] to transmit the at least one network parameter, the at least one user device parameter and the at least one muting parameter.
At step 806, on receiving said parameters, the processor [730] may identify the candidate cell [for e.g. 104A] among the plurality of the serving cells [104A-104E]. Further, the candidate cell [for e.g. 104A], experiencing the muting of the call, may be identified based on the at least one muting parameter such as mute call rate and the mute call count. In an exemplary embodiment, the candidate cell [for e.g. 104A] may be identified based on the following criteria of the at least one muting parameter, i.e. if the mute call rate and the mute call count of the serving cell meet the below criteria, the serving cell is identified as a candidate cell:
Mute call count > 50
Mute call rate>3
At step 808, Further, the processor [730] may analyse the at least one network parameter and the at least one user device parameter of the candidate cell [for e.g. 104A] being identified in the above step (step 806). In an embodiment, the processor [730] may analyse the at least one network parameter and the at least user device parameter.
At step 810, based on the said analysis performed in step 808, the processor [730] may determine the at least one muting category having the pre-defined associated identification criteria. In a preferred embodiment, the associated identification criteria for each of the at least one muting category is illustrated in the Table 2.
At step 812, and pursuant to the accomplishment of step 808, the processor [730] may mitigate the muting of the call by performing the one or more mitigating action for each of the at least one muting category. In an instance, two muting categories are determined, the processor [730] may mitigate the muting of the call by performing the one or more mitigating action for each of the two muting categories determined. In a preferred embodiment, the one or more mitigating action for the mitigating process is illustrated in the Table 2. The method [800] may then terminate at step 814.
Therefore, the present disclosure encompasses a mechanism for mitigating the muting of the call identified in the cellular network. Further, the present disclosure encompasses determining the at least one muting category to appropriately perform one or more mitigating action to mitigate the muting of the call based on said muting category. Furthermore, the present disclosure encompasses automatic mitigating of the call muting based on a feedback mechanism and information stored in the storage unit [740] of the system [700] by self-evaluation.
Though a limited number of the at least one user device [102A-102D], the at least one serving cell [104A-104E], the system [700] and the subcomponents therein have been shown in the figures; however, it will be appreciated by those skilled in the art
that the system [700] of the present disclosure encompasses any number and varied types of the components/modules and other components/subsystems as may be obvious to person skilled in the art.
While considerable emphasis has been placed herein on the disclosed embodiments and also, the present disclosure has been described for VoIP which has a traffic pattern characterized by periodic packets, it will be appreciated that many embodiments can be made for applications other than VoIP (where the traffic patterns are characterized by small periodic packets) 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 [800] for mitigating muting of a call in a cellular network comprising a
plurality of serving cells [104A-104E], the method [800] comprising:
- receiving, for each of the plurality of serving cells [104A-104E], at least one network parameter, at least one user device parameter and at least one muting parameter, wherein the at least one user device parameter is associated with at least one user device [102A-102D] served by each of the plurality of serving cells [104A-104E];
- identifying a candidate cell [for e.g. 104A], from the plurality of serving cells [104A-104E], experiencing the muting of the call, the identification being based on the at least one muting parameter;
- analysing the at least one network parameter and the at least one user device parameter for the candidate cell [for e.g. 104A];
- determining at least one muting category based on said analysis of the at least one network parameter and the at least one user device parameter, wherein
each of the at least one muting category has an associated identification criteria; and
- mitigating the muting of the call by performing one or more mitigating
action for each of the at least one muting category.
2. The method [800] as claimed in claim 1, wherein the at least one muting category is at least one of an uplink muting, a downlink muting, a user device muting, a mobility muting and a backhaul muting.
3. The method [800] as claimed in claim 1, wherein the method [800] is performed by at a network level or a user device level.
4. The method [800] as claimed in claim 1, wherein the muting of the call represents one of a call drop and a call failure in an event of a gap in voice packets and real-time packets (RTP) perceived as a blank voice.
5. The method [800] as claimed in claim 1, wherein the at least one muting parameter is a mute call rate and a mute call count.
6. The method [800] as claimed in claim 1, wherein the at least one network parameter is at least one of a basic service set identifier (BSSID), a RF coverage power (RSRP), a Reference Signal (RS) strength, an uplink SINR, a downlink SINR, a MCS, a call drop rate, a handover success rate, a number of handovers, type of handovers, a handover delay, a QoS of the at least one serving cell, uplink Volte residual block error rate (BLER), an interference over thermal (IoT), a RRC connection re-establishment (RRE) attempt, a GTP loss rate, PDCP packet loss rate, packet loss in TWAMP, a downlink Volte, an uplink Volte, a Volte HARQ fail rate, a packet loss rate at network, a PCI collision, a PCI confusion, a downlink Volte channel quality indicator (DL Volte CQI), an overshooting cell, a radio link failure (RLF) count, a ping pong and a Cell Individual Offset (CIO).
7. The method [800] as claimed in claim 1, wherein the at least one user device
parameter is at least one of an international mobile subscriber identity (IMSI)
facing frequent muting, a user density, a user throughput, a packet loss at user
device and a percentage of ROHC de-compression failures.
8. The method [800] as claimed in claim 1, wherein the uplink muting is determined based on the uplink SINR, the PDCP packet loss rate, the UPLINK Volte BLER and the IOT.
9. The method [800] as claimed in claim 1, wherein the downlink muting is determined based on the RSRP, the CQI, the Volte HARQ fail rate and the overshooting cell.
10. The method [800] as claimed in claim 1, wherein the user device muting is determined based on the percentage of ROHC de-compression failures and the IMSI.
11. The method [800] as claimed in claim 1, wherein the backhaul muting is determined based on the GTP loss rate, the packet loss at the network and the packet loss at the user device.
12. The method [800] as claimed in claim 1, wherein the mobility muting is determined based on the handover success rate, the number of handovers, the handover delay, the RLF count, the RRE attempt, the PCI collision, the RRC connection re-establishment (RRE) attempt, the ping pongs and the type of handovers.
13. The method [800] as claimed in claim 1, wherein the mitigating the muting of the call, in an event of the uplink muting, comprises at least one of performing a physical optimisation and identifying a serving cell having a lower frequency.
14. The method [800] as claimed in claim 1, wherein the mitigating the muting of the call, in an event of the downlink muting, comprises at least one of performing a downlink optimisation, a coverage optimisation and identifying a serving cell having a lower frequency.
15. The method [800] as claimed in claim 1, wherein the mitigating the muting of the call, in an event of the user device muting, comprises identifying a user device based on the IMSI facing frequent muting.
16. The method [800] as claimed in claim 1, wherein the mitigating the muting of the call, in an event of the backhaul muting, comprises identifying at least one fault resulting in the packet loss at the user device and the network.
17. The method [800] as claimed in claim 1, wherein the mitigating the muting of the call, in an event of the mobility muting, comprises performing handover optimisation based on the type of handovers, the handover success rate, the number of handovers and the handover delay.
18. A system [700] for mitigating muting of a call in a cellular network comprising a plurality of serving cells [104A-104E], the system comprising [700]:
- a transceiver unit [720] configured to receive, for each of the plurality of serving cells [104A-104E], at least one network parameter, at least one user device parameter and at least one muting parameter, wherein the at least one user device parameter is associated with at least one user device
[102A-102D] served by each of the plurality of serving cells [104A-104E]; and
- a processor [730] configured to:
identify a candidate cell [for e.g. 104A], from the plurality of serving cells [104A-104E], experiencing the muting of the call, the identification being based on the at least one muting parameter,
analyse the at least one network parameter and the at least one user device parameter for the candidate cell [for e.g.104A],
determine at least one muting category based on said analysis of the at least one network parameter and the at least one user device parameter, wherein
each of the at least one muting category has an associated identification criteria, and
the at least one muting category is at least one of an uplink muting, a downlink muting, a user device muting, a mobility muting and a backhaul muting, and
mitigate the muting of the call by performing one or more mitigating action for each of the at least one muting category.
19. The system [700] as claimed in claim 18, wherein the system [700] is implemented at a network level or a user device level.
| Section | Controller | Decision Date |
|---|---|---|
| # | Name | Date |
|---|---|---|
| 1 | 201821028250-Response to office action [04-11-2024(online)].pdf | 2024-11-04 |
| 1 | 201821028250-STATEMENT OF UNDERTAKING (FORM 3) [27-07-2018(online)].pdf | 2018-07-27 |
| 2 | 201821028250-IntimationOfGrant28-10-2024.pdf | 2024-10-28 |
| 2 | 201821028250-PROVISIONAL SPECIFICATION [27-07-2018(online)].pdf | 2018-07-27 |
| 3 | 201821028250-PatentCertificate28-10-2024.pdf | 2024-10-28 |
| 3 | 201821028250-FORM 1 [27-07-2018(online)].pdf | 2018-07-27 |
| 4 | 201821028250-ORIGINAL UR 6(1A) FORM 1-050424.pdf | 2024-04-15 |
| 4 | 201821028250-FIGURE OF ABSTRACT [27-07-2018(online)].pdf | 2018-07-27 |
| 5 | 201821028250-Proof of Right (MANDATORY) [26-09-2018(online)].pdf | 2018-09-26 |
| 5 | 201821028250-ORIGINAL UR 6(1A) FORM 26-050424.pdf | 2024-04-15 |
| 6 | 201821028250-PETITION UNDER RULE 137 [22-02-2024(online)].pdf | 2024-02-22 |
| 6 | 201821028250-FORM-26 [26-09-2018(online)].pdf | 2018-09-26 |
| 7 | 201821028250-Written submissions and relevant documents [22-02-2024(online)].pdf | 2024-02-22 |
| 7 | 201821028250-ORIGINAL UR 6(1A) FORM 1 & FORM 26-011018.pdf | 2019-02-12 |
| 8 | 201821028250-ENDORSEMENT BY INVENTORS [24-07-2019(online)].pdf | 2019-07-24 |
| 8 | 201821028250-Correspondence to notify the Controller [31-01-2024(online)].pdf | 2024-01-31 |
| 9 | 201821028250-DRAWING [24-07-2019(online)].pdf | 2019-07-24 |
| 9 | 201821028250-FORM-26 [31-01-2024(online)].pdf | 2024-01-31 |
| 10 | 201821028250-COMPLETE SPECIFICATION [24-07-2019(online)].pdf | 2019-07-24 |
| 10 | 201821028250-US(14)-HearingNotice-(HearingDate-12-02-2024).pdf | 2024-01-18 |
| 11 | 201821028250-AMENDED DOCUMENTS [05-04-2022(online)].pdf | 2022-04-05 |
| 11 | 201821028250-FORM 18 [25-07-2019(online)].pdf | 2019-07-25 |
| 12 | 201821028250-FORM 13 [05-04-2022(online)].pdf | 2022-04-05 |
| 12 | Abstract1.jpg | 2019-09-12 |
| 13 | 201821028250-8(i)-Substitution-Change Of Applicant - Form 6 [22-02-2022(online)].pdf | 2022-02-22 |
| 13 | 201821028250-FER_SER_REPLY [16-07-2021(online)].pdf | 2021-07-16 |
| 14 | 201821028250-ASSIGNMENT DOCUMENTS [22-02-2022(online)].pdf | 2022-02-22 |
| 14 | 201821028250-FER.pdf | 2021-10-18 |
| 15 | 201821028250-PA [22-02-2022(online)].pdf | 2022-02-22 |
| 16 | 201821028250-ASSIGNMENT DOCUMENTS [22-02-2022(online)].pdf | 2022-02-22 |
| 16 | 201821028250-FER.pdf | 2021-10-18 |
| 17 | 201821028250-FER_SER_REPLY [16-07-2021(online)].pdf | 2021-07-16 |
| 17 | 201821028250-8(i)-Substitution-Change Of Applicant - Form 6 [22-02-2022(online)].pdf | 2022-02-22 |
| 18 | Abstract1.jpg | 2019-09-12 |
| 18 | 201821028250-FORM 13 [05-04-2022(online)].pdf | 2022-04-05 |
| 19 | 201821028250-AMENDED DOCUMENTS [05-04-2022(online)].pdf | 2022-04-05 |
| 19 | 201821028250-FORM 18 [25-07-2019(online)].pdf | 2019-07-25 |
| 20 | 201821028250-COMPLETE SPECIFICATION [24-07-2019(online)].pdf | 2019-07-24 |
| 20 | 201821028250-US(14)-HearingNotice-(HearingDate-12-02-2024).pdf | 2024-01-18 |
| 21 | 201821028250-DRAWING [24-07-2019(online)].pdf | 2019-07-24 |
| 21 | 201821028250-FORM-26 [31-01-2024(online)].pdf | 2024-01-31 |
| 22 | 201821028250-Correspondence to notify the Controller [31-01-2024(online)].pdf | 2024-01-31 |
| 22 | 201821028250-ENDORSEMENT BY INVENTORS [24-07-2019(online)].pdf | 2019-07-24 |
| 23 | 201821028250-ORIGINAL UR 6(1A) FORM 1 & FORM 26-011018.pdf | 2019-02-12 |
| 23 | 201821028250-Written submissions and relevant documents [22-02-2024(online)].pdf | 2024-02-22 |
| 24 | 201821028250-FORM-26 [26-09-2018(online)].pdf | 2018-09-26 |
| 24 | 201821028250-PETITION UNDER RULE 137 [22-02-2024(online)].pdf | 2024-02-22 |
| 25 | 201821028250-Proof of Right (MANDATORY) [26-09-2018(online)].pdf | 2018-09-26 |
| 25 | 201821028250-ORIGINAL UR 6(1A) FORM 26-050424.pdf | 2024-04-15 |
| 26 | 201821028250-ORIGINAL UR 6(1A) FORM 1-050424.pdf | 2024-04-15 |
| 26 | 201821028250-FIGURE OF ABSTRACT [27-07-2018(online)].pdf | 2018-07-27 |
| 27 | 201821028250-PatentCertificate28-10-2024.pdf | 2024-10-28 |
| 27 | 201821028250-FORM 1 [27-07-2018(online)].pdf | 2018-07-27 |
| 28 | 201821028250-PROVISIONAL SPECIFICATION [27-07-2018(online)].pdf | 2018-07-27 |
| 28 | 201821028250-IntimationOfGrant28-10-2024.pdf | 2024-10-28 |
| 29 | 201821028250-STATEMENT OF UNDERTAKING (FORM 3) [27-07-2018(online)].pdf | 2018-07-27 |
| 29 | 201821028250-Response to office action [04-11-2024(online)].pdf | 2024-11-04 |
| 1 | 2021-01-1413-20-05E_14-01-2021.pdf |