Claims:9. CLAIM

The subject matter has been described as a system having ability and features to monitor call drops with probable cause of call drops for users based on network parameters that can be captured in Android O.S. along with user behavior (from call state) captured in Android

Claim 1: A Method to accurately estimate if a call of a user, using an Android based phone has been disconnected owing to bad network / audio quality
Claim 2: The method provided in the application analyses the data to find out the reason for the change in call status in last 4 seconds of call. If the call state change from ringing/off-hook to idle and technology has not been either 2G/ 3G/ VoLTE for the last 4 seconds, then there has been a call block / call drop owing to improper change in technology and needs no further analyses.
Claim 3: This application will measure the technical parameters in android operating system of the user like RxQual and/or RxLEV in case of 2G / EcNo and/ or RSCP in case of 3G / RSRQ and/or RSRP and SINR in case of 4G(VoLTE). If determines that the said parameter are/are not within a particular limit for a prescribed time period as described in the above figure and accordingly do the further analyses of data and figure out the reasons of call drop.
Claim 4: The application can identify the reason for call drop like due to improper change in technology, Bad quality of network, poor coverage by network provider, interference from other cells/ pilot pollution / no handover to dominant cell / overshooting.
Claim 5 : The method combines user behavior with technical network parameters available with open APIs in Android (version 4.4 and later), to accurately estimate call drops of calls which a general user initiates / receives during their day to day course.
Claim 6, The application further comprising analysis of information as to type of user device, a device location, a user problem, or an access technology.
Claim 7 : The method combines user behavior with technical network parameters available with open APIs in Android (version 4.4 and later), to accurately estimate call drops of calls which a general user initiates / receives during their day to day course and provide the relevant causes along with other network statistics of Coverage (RxLev, RSCP, RSRP), Quality (RxQual, EcIo, RSRQ, SINR) as well as location and user identification parameters to the telecom network provider so that the telecom network provider can take corrective action as well as compensate the user for benefiting the user perception of the telecom network provider.
Claim 8: The method combines device screen behavior(screen on/off) with call state change from off hook to idle at the end of call and technical network parameters available with open APIs in Android (version 4.4 and later), to accurately estimate call drops of calls which a general user initiates / receives during their day to day course.
Claim 9 : The method provided in the application determines whether user has experienced call drop based on the audio decibel level, call state change from off hook to idle and technical network parameters available with open APIs in Android (version 4.4 and later) like Coverage (RxLev, RSCP, RSRP), Quality (RxQual, EcIo, RSRQ, SINR, tower ID).
Claim 10: The method provided in the application provides speech quality experienced by user during a call, based on the audio decibel level during the call and technical network parameters available with open APIs in Android (version 4.4 and later) like Coverage (RxLev, RSCP, RSRP), Quality (RxQual, EcIo, RSRQ, SINR, tower ID).
, Description:PATENT COMPLETE SPECIFICATION ON
INTELLIGENT PASSIVE CALL COMPLETION APPLICATION

1. TITLE OF INVENTION:
Intelligent passive call completion application.
2. FIELD OF INVENTION:
The invention relates to the field of digital mobile media delivery by providing information on user experience of various networks and reason for call drops. The android application is based on network parameters combined with user behavior, the application accurately identifies calls those were either dropped due to poor mobile network or closed by the user owing to bad quality in an Android phone.
3. BACKGROUND OF INVENTION & PRIOR ART:
• Technical Field of the Invention
The present invention of android application relates in general to call connections in a telecommunications network, and in particular to saving dropped calls in the mobile telecommunications environment.
• Description of Related Art
In the past under the patent application number US6580906B2, the cellular telecommunications systems rely upon a radio interface for communications between a fixed base station and a mobile subscriber, failures or interruptions in the radio path between the base station and the mobile subscriber frequently result in dropped calls, wherein an ongoing call connection is eventually terminated because of an inability of the base station and mobile station to communicate with one another. In particular, if an ongoing call experiences a semi-permanent radio path failure (i.e., a radio path failure in which radio communications are interrupted for more than an inconsequential period of time), the mobile station and/or the cellular system will generally terminate the call connection. Such radio path failures can be due to, for example, broken base station equipment, a base station power outage, a transport network outage, software faults in the radio base station, or radio path disturbances. One of the primary problems with dropped calls is that they inconvenience subscribers by requiring them to set up the call again, which can result in subscriber dissatisfaction. Furthermore, if dropped calls occur frequently enough, subscribers may be more reluctant to use their mobile telephones, effectively reducing the amount of revenues that network detects that the connection to the mobile station has been lost, the network will have to wait until the mobile station becomes idle and returns to the control channel (i.e., when the subscriber pushes the "on-hook" button on the mobile station) before it can initiate the call back procedure. Then, the mobile station can be paged as a normal terminating call, and the subscriber will receive a ring tone and have to manually answer the new call. An additional drawback of this proposed solution is that, if the mobile station is no longer within the same coverage area, the network probably will not be able to locate the mobile station to place the new call. There is a need, therefore, for a method and system for reconnecting dropped calls in a mobile telecommunications network. Such a method and system would preferably allow a call connection to be reestablished promptly and without the need to manually initiate a new call. Furthermore, the method and system would allow for reconnection in cases where the mobile station has moved from one coverage area to another.
In the patent application US20070288599A1 it was stated that to curb the issue, the population of mobile users, particularly among those using systems such as CDMA (Code Division Multiple Access), PCS (Personal Communication System), and GSM (Global System for Mobile communication), has grown at a rapid rate. Also, the demand has increased for multimedia applications requiring high bandwidth, such as high quality video. Therefore, the current trend in wireless networks is to decrease cell sizes (into micro-cells or pico-cells) to provide higher capacity and accommodate more users in a given area. However, smaller cell sizes increase the frequency of handoffs, which results in rapid changes in the conditions of the network traffic. Thus, the QoS provisioning in wireless networks becomes more difficult to achieve.
In the patent application number US6745031B2 it was invented that there is provided a method of reconnecting a communication link terminated by a service impediment during a service between a mobile station (MS) subscriber and the other party communicating with the MS subscriber through a mobile communication system having a plurality of mobile switching centers (MSCs) connected to one another, each MSC being connected to a plurality of base stations (BSs). When the service impediment lasts for at least a predetermined first time period, the MS subscriber sends a reconnection request signal. Then, the service is reinitiated between the MS subscriber and the other party through one of the plurality of BSs and one of MSCs connected to the BS in response to the reconnection request signal.
The patent application having application number US 2011/0201364 A1 relates to a computer-implemented method, a computer program product and a system for measuring Quality of Service (QoS) in a mobile network. QoS in a mobile network may be measured from the perspective of an expert, such as a tele traffic engineer. This may involve assessing the network to see if it delivers the quality that a network planner intended to target. Certain tools and methods including protocol analysers, drive tests, and operation and maintenance measurements can be used for QoS measurement. Because of the size of some mobile networks and the sophistication and expense of some of the measurement instruments, fully distributed measurement can be difficult.
Android applications available in the market today, only have capability of capturing various network parameters. Based on unique programme, our application is developed to identify possible call drop conditions which can be coupled with user behavior pattern to determine if, a user experienced a call drop / bad call quality, owing to which the user disconnected the call. This application not only captures calls dropped by the network, but also calls terminated by user owing to in-audible voice quality.
The prior art used servers to analyses the call drop due to network problems and limitations whereas in the present invention the analysis for the call drop is carried out in the mobile device itself. The present application in order to analyse the reason for call drop not only takes into account the network parameters but also the user behavior. It does not require any input or initiation from the user. User calls are monitored in the backend to obtain call drop based on smart algorithm.
Out of the cited prior arts the patent application number US6745031B2 was working under a system which is entirely different from environment and assumptions in which current application is working. The applicant has differentiated the other patent application no (US 2011/0201364 A1), which is cited as prior art , with the present application in a tabular form which is as under:

Difference between current application & prior art of patent US 2011/0201364 A1¬¬¬¬¬¬¬
Sr. No. Prior art (US 2011/0201364 A1) Current application
1 Uses Server based model for analysis All analysis is done on the mobile device itself
2 Requires user initiated test calls and configruation to make calls to specific server to capture quality and call drops No user initiated test calls required.
3 User input required to for passive tracking to understand call drop and other Qos parameters. No user input is required. User calls are monitored in the backend to obtain call drop based on smart algorithm
4 Probable causes of call drop are not availbale Probable causes of call drop is available owing to unique smart algorithm which runs on different KPIs
5 User behaviour is not monitored to anaylse call drop User behaviour is analysed in conjuction with network parameters to analyse call drops
6 No variables / network parameter thresholds are used to analyse call drops. Variables / network parameter thresholds of unique smart algorithm are based on extensive tests of over 1 million calls done over 60,000 kms (37,500 miles) of roadways and railways)
7 QoS of VoLTE calls are not monitored Call drops and parameters for VoLTE calls are also included such as SINR, RSRP, RSRQ

4. OBJECT OF INVENTION:
The objective of the present invention of an android application is to accurately capture call drops of a network that a user faces, which in today's day and age has become a recurrent problem in India as well as other markets globally. Not only do call drops lead to extra costs for users, but also mental tension, agony and frustration if the user is on an important call. This application not only captures calls dropped by the network, but also calls terminated by user owing to in-audible voice quality.
A mobile network may be very large in terms of the number of components, geographic extent, and the number of users. Measuring Quality of call (QoC) in a mobile network may facilitate understanding and analysis of the network and allow better network planning, better user experience, and continuous optimization of mobile network by network service provider.
QoS in a mobile network may be measured from the perspective of users. This may involve assessing the network to see if it delivers the quality that a network planner intended to target.

5. STATEMENT OF INVENTION:
The present invention of android application states the relation to call connections in a telecommunications network, and in particular to saving dropped calls in the mobile telecommunications environment which user faces, In the current scenario and call droppage has become a recurrent problem in India as well as other markets globally. Not only do call drops lead to extra costs for users, but also mental tension, agony and frustration if the user is on an important call. This application not only captures calls dropped by the network, but also calls terminated by user owing to in-audible voice quality.
6. SUMMARY OF THE INVENTION
The application not only captures calls dropped by the network and calls terminated by user owing to in-audible voice quality as well as identifies the reason of such call dropped/terminated, thus, facilitate understanding and analysis of the network and allow better network planning, better user experience, and continuous optimization of mobile network by network service provider.

7. BRIEF DESCRITION OF THE ACCOMPANYING DRAWING
For the purpose of, illustrating the invention, the drawings show a form of the invention that is presently preferred. However, it should be understood that this invention is not limited to the precise arrangements and instrumentalities shown in the drawings.

FIG. 1 schematically depicts android operating system and its alternates according to the present invention for transmitting information and data by using the Application and analysis the same for desired result

8. DETAILED DESCRITION OF THE INVENTION WITH THE DRAWING/EXAMPLES
Owing to limitations in the Android Operating System and available APIs that Android provides for call state, viz
I. Idle- It means call terminated either by the user or owing to network condition.

II. Off hook- The state of a telephone line that allows dialing and transmission but prohibits incoming calls from being answered. The phone is off-hook when the handset is lifted off the base of a stationary phone or when Talk is pressed on a portable phone. The term stems from the days when the handset rested on an actual hook.

III. Ringing- It means a state where the user device has received an incoming call and the user device (phone) is ringing.
It is difficult to ascertain from the above if there was a blocked/dropped call - a connection went from off hook (call state) to Idle (call terminated) - owing to a undesirable network condition or was initiated by the user.
The present application is programmed in a manner to captures those calls which have been blocked / terminated by network or by the user owing to bad Radio Frequency conditions in android operating system.
To attain this, it identify certain technical parameters that can be obtained from Android operating system having 3G/2G/ VoLTE Technology. These are
1) Technology in use on the android mobile device
2) EcNo (For 3G technology)
3) RSCP (For 3G technology)
4) RxLev (For 2G technology)
5) RxQual (For 2G technology
6) RSRP (For VoLTE technology)
7) RSRQ (For VoLTE technology)
8) SINR (For VoLTE Technology)
The above are the technical parameter levels that govern each voice call for the different types of technologies (2G, 3G and 4G – VoLTE) available. Based on a drop in the levels of the aforementioned parameters, the ability to make a call / quality of the voice calls in progress degrades. If the quality of the voice calls in progress degrades to a very low level, the network drop the call based on the aforementioned technical parameters so that a new connection is made which will help the user be able to have a conversation that can be deciphered.
However, each network will set these levels differently based on different ideologies of the network team.
During the development of this application several test of voice calls were made based on tests of voice calls and their parameters along with the voice MOS (POLQA Mean Opinion Score – ITU-T standard Rec. P.863) that is obtained during such voice calls, it was observed , inferred and concluded that even if the network doesn’t drop the call, once the value of the aforementioned technical parameters drops beyond a specific level, the quality of voice becomes either un-audible / un decipherable by the calling / called party.
To arrive at the above conclusion, over 1 million calls in different networks (2G, 3G and 4G – VoLTE) over 60,000 kms. of roadways and railways were made and the results were analysed and studied, by analyzing the data obtained with specific Layer 3 handsets that are rooted handsets that capture the aforementioned parameters along with MOS score and the relevant handshake signals from Base stations for network based call blocks and drops .
Hence, with the use of this data analytics and its results as well as user behavior, the application can accurately capture the occurrences of call blocks (only due to adverse Radio frequency conditions) and call drops (due to adverse Radio frequency conditions) as well as probable cause (what Radio frequency condition was degraded) of such call blocks and call drops which can aid the operator in doing root cause analysis and rectifying their network.
Since there are only 3 call state conditions, (as given above), the user behavior can only be captured based on these parameters.
To begin with the only information that the application can get from Android Operating system is, when a call state changes from off-hook (in use) to idle (not in-use) or ringing to idle (for incoming calls). However, the application is programmed to eradicate all other possible reasons for such call terminations to ensure that our algorithm only captures those calls which have been blocked / terminated by network or by the user owing to bad Radio Frequency conditions.
This application does not measure call blocks/ drops which are owing to force majeure events such as broken base station, power outage, transport network outage, software faults etc. or owing to backend issues such as backhaul, core network or congestion. Such events trigger relevant alarms at the operators NoC (National operating Centre), which the operator can rectify.
This application captures call blocks and call drops that have occurred owing to Radio Frequency (RF) issues such as coverage, quality, interference, which would happen on a recurring basis and may go undetected by operators unless rectified by the telecom operator.
Since the application captures call drops owing to drop in RF conditions (without any factor of force majeure), any degradation of aforementioned technical parameters would be gradual and not sudden.
Hence, the first step would be to log the technical parameters continuously to understand the state of the network.
Based on the data analysis of over 1 million calls across over 60,000 kms of roadways and railways, it is concluded that the network starts to degrade about 4 seconds before the actual call drops / call quality becomes inaudible / un-decipherable.
The primary trigger condition for a call block / call drop is when the call state goes from ringing or off-hook to idle state. The application analyses the various user behavior pattern along with technical parameters obtained from the Android Operating system at that instant as well as during the previous 4 seconds to accurately estimate a call block / call drop. The various steps as depicted in the figure above to detect the reason of call drop is explained as below :
I. If the call state has gone from idle/ringing to off hook in the last 4 seconds, then trigger the technical parameter the application will check reason for call block as per the flow chart depicted in Figure above.
II. If the call state has not gone from idel/ringing to off hook in the last 4 seconds, then trigger the application will technical parameter and will check reason for call drop as per the flow chart depicted in Figure above.
Since calls be initiated in various technologies, each having different technical parameters, the programme to estimate network based call blocks / call drops for each type of technology would be different and are as given below :
A. If the technology at the time of call state change from ringing/off-hook to idle is 2G then :
I. If the technology has not been 2G for the last 4 seconds, then there has been a call block / call drop owing to improper inter-technology handover.
II. If RxQual value is not between 0 and 7, then there is a problem with the Android Operating System returned value, hence, the application will skip the RxQual technical parameter test and do only the RxLev technical parameter test.
III. If technology has not changed in the last 4 seconds and the level of RxQual has been greater than 5 for the last 4 seconds, then the call has been blocked / dropped owing to bad quality of 2G network
IV. If technology has not changed in the last 4 seconds and the level of RxQual has been below 5 for the last 4 seconds, then if RxLev is less than -100 for the last 2 seconds, then the call has been blocked / dropped owing to poor coverage
V. If technology has not changed in the last 4 seconds and the level of RxQual has been below 5 for the last 4 seconds and RxLev is greater than -100 for the last 2 seconds, then is RxLev of any of the neighbouring cells more than 6 dBm greater than RxLev of serving cell, then call drop has happened owing to interference / overshooting / no handover to dominant tower.
B. If the technology at the time of call state change from ringing/off-hook to idle is 3G then :
I. If the technology has not been 3G for the last 4 seconds, then there has been a call block / call drop owing to improper inter-technology handover.
II. If EcNo value is not between -32 and 0, then there is a problem with the Android Operating System returned value, hence skip the EcNo technical parameter test and do only the RSCP technical parameter test.
III. If technology has not changed in the last 4 seconds and the level of EcNo has been less than -15 for the last 3 seconds, then the call has been dropped owing to bad quality of 3G network
IV. If technology has not changed in the last 4 seconds and the level of EcNo has been above -15 for any one of the last 3 seconds, then if RSCP is less than -106 for the last 2 seconds, then the call has been blocked / dropped owing to poor coverage
V. If technology has not changed in the last 4 seconds and the level of EcNo has been above -15 for any one of the last 3 seconds and RSCP is greater than -106 for the last 2 seconds, then
a) Let N1 be the number of neighboring cells whose RSCP is greater than RSCP of serving cell
b) Let N2 be the number of neighboring cells whose RSCP is more than 5 dBM less than RSCP of serving cell
c) If N1 + N2 is greater than 2 then call has been dropped owing to interference from other cells / pilot pollution.
C. If the technology at the time of call state change from ringing/off-hook to idle is 4G (VoLTE) then :
I. If the technology has not been 4G for the last 4 seconds, then there has been a call block / call drop owing to improper change in technology handover.
II. If RSRQ value is not between -3 and -20, then there is a problem with the Android Operating System returned value, hence skip the RSRQ technical parameter test and do only the RSRP and SINR technical parameter test.
III. If technology has not changed in the last 4 seconds and the level of RSRQ has been lesser than -15 for the last 4 seconds, then the call has been blocked / dropped owing to bad quality of 4G network
IV. If technology has not changed in the last 4 seconds and the level of RSRQ has been above -15 for any one of the the last 4 seconds, then if RSRP is less than -112 for the last 2 seconds, then the call has been blocked / dropped owing to poor coverage
V. If technology has not changed in the last 4 seconds and the level of RSRQ has been above -15 for the any one of the last 4 seconds and RSRP is greater than -112 for the last 2 seconds, then if SINR is less than 5, then call has been dropped owing to interference.