CLIAMS:We claim:

1. A method of triggering network specific data recovery in a telecommunication network, said method comprising:
identifying a delayed response to at least one data packet transmitted from a User Equipment (UE) to at least one mobile network, by a data stall identification and recovery module;
checking severity of said identified delay, by said data stall identification and recovery module;
triggering at least one data recovery process by said data stall identification and recovery module, to recover at least one data if said severity indicates that said delay is a critical delay, wherein said critical delay represents occurrence of a data stalling event;
monitoring said at least one recovered data for verifying stability of said at least one recovered data, by said data stall identification and recovery module; and
triggering at least one other data recovery process if said at least one recovered data is found to be unstable, by said data stall identification and recovery module.
2. The method as claimed in claim 1, wherein identifying said delayed response further comprises:
monitoring a plurality of data packets sent from said UE to at least one Access Point Name (APN) in a mobile network, by said data stall identification and recovery module;
measuring a response time corresponding to each of said plurality of data packets, by said data stall identification and recovery module; and
comparing said measured response time with a reference time, by said data stall identification and recovery module.
3. The method as claimed in claim 1, wherein said severity of said identified delay is checked based on data from at least one of a Data-Stall-Profile (DSP) database and a Quality of Network (QoN) database.
4. The method as claimed in claim 1, wherein triggering said data recovery process comprises triggering a smart recovery process by said data stall identification and recovery module, wherein said smart recovery process further comprises:
comparing said identified delay with data in a Data-Stall-Profile (DSP) database;
identifying at least one match for said identified delay in said DSP database by said data stall identification and recovery module, wherein said at least one match is at least one of a similar delay occurred in the past;
identifying at least one data recovery process corresponding to said identified match, by said data stall identification and recovery module; and
triggering said identified at least one data recovery process, by said data stall identification and recovery module.
5. The method as claimed in claim 4, wherein said identified data recovery process is at least one of an Access Point Name (APN)-offloading, Radio Access Technology (RAT)-offloading, and a Data – Tech – Type – offloading.
6. The method as claimed in claim 1, wherein triggering said data recovery process comprises triggering a normal recovery process by said data stall identification and recovery module, wherein said normal recovery process comprises triggering at least one of an Access Point Name (APN)-offloading, Radio Access Technology (RAT)-offloading, and a Data – Tech – Type – offloading.
7. A User Equipment (UE) for triggering network specific data recovery in a telecommunication network, said UE comprising:
a hardware processor; and
a non-volatile memory comprising instructions, said instructions configured to cause said hardware processor to:
identify a delayed response to at least one data packet transmitted from said UE to at least one mobile network, by a data stall identification and recovery module;
check severity of said identified delay, by said data stall identification and recovery module;
trigger at least one data recovery process to recover at least one data if said severity indicates that said delay is a critical delay, by said data stall identification and recovery module, wherein said critical delay represents occurrence of a data stalling event;
monitor said at least one recovered data for verifying stability of said at least one recovered data, by said data stall identification and recovery module; and
trigger at least one other data recovery process if said at least one recovered data is found to be unstable, by said data stall identification and recovery module.
8. The UE as claimed in claim 7, wherein said data stall identification and recovery module is further configured to identify said delayed response by:
monitoring a plurality of data packets sent from said UE to at least one Access Point Name (APN) in a mobile network, by a data monitoring module in said data stall identification and recovery module;
measuring a response time corresponding to each of said plurality of data packets, by a delay measurement module in said data stall identification and recovery module; and
comparing said measured response time with a reference time, by said delay measurement module.
9. The UE as claimed in claim 7, wherein said data stall identification and recovery module is further configured to check severity of said identified delay based on data from at least one of a Data-Stall-Profile database and a Quality of Network (QoN) database.
10. The UE as claimed in claim 7, wherein said data stall identification and recovery module is further configured to trigger said data recovery process by triggering a smart recovery process, wherein said data stall identification and recovery module is further configured to trigger said smart recovery process by:
comparing said identified delay with data in a Data-Stall-Profile (DSP) database;
identifying at least one match for said identified delay in said DSP database, wherein said at least one match is at least one of a similar delay occurred in the past;
identifying at least one data recovery process corresponding to said identified match; and
triggering said identified at least one data recovery process.
11. The UE as claimed in claim 7, wherein said data stall identification and recovery module is further configured to execute at least one of an Access Point Name (APN)-offloading, Radio Access Technology (RAT)-offloading, and a Data – Tech – Type – offloading as said smart recovery process.
12. The UE as claimed in claim 7, wherein said data stall identification and recovery module is further configured to trigger said data recovery process by triggering a normal recovery process, wherein said data stall identification and recovery module is further configured to trigger said normal recovery process by triggering at least one of an Access Point Name (APN)-offloading, Radio Access Technology (RAT)-offloading, and a Data – Tech – Type – offloading.
13. Date: 16 January 2015 Signature:
Kalyan Chakravarthy
,TagSPECI:FORM 2
The Patent Act 1970
(39 of 1970)
&
The Patent Rules, 2005

COMPLETE SPECIFICATION
(SEE SECTION 10 AND RULE 13)

TITLE OF THE INVENTION

“Adaptive Data Stall Identification and Smart Recovery Procedure”

APPLICANTS:
Name Nationality Address
SAMSUNG R&D Institute India - Bangalore Private Limited India # 2870, Orion Building, Bagmane Constellation Business Park, Outer Ring Road, Doddanekundi Circle, Marathahalli Post, Bangalore-560037, India

The following specification particularly describes and ascertains the nature of this invention and the manner in which it is to be performed:-

FIELD OF INVENTION
[001] The present invention relates to the field of telecommunication and more particularly to faster data stall identification where no exchange is possible and dynamic data recovery in telecommunication.

BACKGROUND OF INVENTION
[002] There has been an exponential increase in the number of mobile data users across the globe. Owing to digital transformation, majority of general public have started using social media websites as well as email services on a day to day basis. In addition to this, people relay on mobile internet for availing services such as but not limited to online video streaming, Global Positioning Service based route tracking, and chat applications.
[003] However, there are certain issues with mobile networks that adversely affect data services. One prominent issue is termed as “Data stalling”. Data stalling refers to a state in which a User Device (UE) believes that it has active data connection, whereas none of the data services work on the UE. The user may be able to see a data icon on the UE; however, data connection may not be working at all. As of now, an effective solution to counter data stalling problems is to detecting data stalling and triggering recovery options as soon as it happens.
[004] Systems that are currently being used for data stall detection are static in a way that they work based on a set process regardless the type of network the system is used with. The existing systems wait for a set time period even after detecting the data stall, to initiate the recovery process. The delay in initiating data recovery process may result in the system taking more time for recovering data, or for triggering data recovery measures; which in turn affects efficiency of the system.

OBJECT OF INVENTION
[005] The principal object of the embodiments herein is to quickly identify occurrence of data stall in a mobile network.
[006] Another object of the invention is to identify delay in responses to at least one data packet transmitted from the User Equipment (UE) to the mobile network, and identify occurrence of a data stalling event.
[007] Another object of the invention is to check severity of a delay, based on data stored in a Data-Stall-Profile database, and a Quality of Network (QoN) Rank database.
[008] Another object of the invention is to trigger at least one data recovery process to counter the identified data stalling event.

SUMMARY

[009] Accordingly the invention provides a method for triggering network specific data recovery in a telecommunication network. In this method, a delayed response to at least one data packet transmitted from a User Equipment (UE) to at least one mobile network is identified by a data stall identification and recovery module. Further, severity of the identified delay is checked, and if the severity indicates that the delay is a critical delay, the data stall identification and recovery module triggers at least one data recovery process to recover at least one data, wherein the critical delay represents occurrence of a data stalling event. After recovering the data, data stall identification and recovery module monitors the recovered data for verifying stability of the at least one recovered data, and triggers at least one other data recovery process if the at least one recovered data is found to be unstable.
[001] Accordingly the invention provides a User Equipment (UE) for triggering network specific data recovery in a telecommunication network. The UE comprising a hardware processor and a non-volatile memory comprising instructions. The instructions are configured to cause the hardware processor to identify a delayed response to at least one data packet transmitted from the UE to at least one mobile network, by a data stall identification and recovery module. The data stall identification and recovery module checks severity of the identified delay and triggers at least one data recovery process to recover at least one data if the severity indicates that the delay is a critical delay, wherein the critical delay represents occurrence of a data stalling event. The data stall identification and recovery module monitors the at least one recovered data for verifying stability of the at least one recovered data, by the data stall identification and recovery module and triggers at least one other data recovery process if the at least one recovered data is found to be unstable.
[002] These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following descriptions, while indicating preferred embodiments and numerous specific details thereof, are given by way of illustration and not of limitation. Many changes and modifications may be made within the scope of the embodiments herein without departing from the spirit thereof, and the embodiments herein include all such modifications.

BRIEF DESCRIPTION OF FIGURES
[003] This invention is illustrated in the accompanying drawings, throughout which like reference letters indicate corresponding parts in the various figures. The embodiments herein will be better understood from the following description with reference to the drawings, in which:
[004] FIG. 1 illustrates a block diagram of data recovery framework, according to embodiments as disclosed herein;
[005] FIG. 2 illustrates a block diagram that shows components of data stall identification and recovery module , according to embodiments as disclosed herein; and
[006] FIG. 3 illustrates a flow diagram depicting the method of dynamically triggering data recovery in data recovery framework, according to embodiments as disclosed herein.

DETAILED DESCRIPTION OF INVENTION
[007] The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein can be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.
[008] The embodiments herein achieve dynamic data recovery in a telecommunication network. Referring now to the drawings, and more particularly to FIGS. 1 through 3, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments.
[009] FIG. 1 illustrates a block diagram of data recovery framework, according to embodiments as disclosed herein. The data recovery framework 100 comprises of a UE 101, and a mobile network 103. The UE 101 further comprises of a data stall identification and recovery module 102.
[0010] The UE 101 may be any device that is capable of establishing data connectivity, and which may be configured to perform data exchange with the mobile network 103. A few examples of UE 101 are, but not limited to a mobile phone, laptop, desktop, and other wearable and non-wearable computer devices.
[0011] The data stall identification and recovery module 102 may be configured to monitor data packet transfer between the UE 101 and the mobile network 103. The data stall identification and recovery module 102 may be further configured to quickly identify any delay from any Access Point Name (APN) associated with the mobile network 103 for any packet that has been transmitted from the UE 101, the delay may be representing occurrence of a data stall event. Further, the data stall identification and recovery module 102 checks severity of the identified delay which in turn may represent severity of the data stall event, and if the severity of the delay is found to be critical, then the data stall identification and recovery module 102 triggers at least one data recovery measure. In a preferred embodiment, after recovering data using the selected data recovery procedure, the data stall identification and recovery module 102 monitors and checks stability of the recovered data, so as to identify any possibly occurrence of delay i.e. a data stall event. The data stall identification and recovery module 102 may be further configured to trigger at least one other data recovery procedure to recover data.
[0012] FIG. 2 illustrates a block diagram that shows components of data stall identification and recovery module, according to embodiments as disclosed herein. The data stall identification and recovery module 102 further comprises of a data monitoring module 201, a delay measurement module 202, a memory module 203, a decision making module 204, and an action triggering module 205.
[0013] The data monitoring module 201 may be configured to monitor inflow and outflow of packets to the UE 101. The data monitoring module 201 may be further configured to track time stamp pertaining to inflow and outflow of each packet, and provide the time stamp information as input to the delay measurement module 202, instantly. For certain packets sent, the UE 101 may not receive any response from the mobile network 103. In that scenario, the data monitoring module 201 may wait for a set time, and if no response is received within the specified time period, the data monitoring module 201 sends information to the delay measurement module 202 that response has not been received for the packet.
[0014] The delay measurement module 202, based on the time stamp information received from the data monitoring module 201, quickly identifies that at least one packet has got a delayed response, or that a response has not been received at all. The delay measurement module 202 may be further configured to pass on information about the identified delay, to the decision making module 204.
[0015] The memory module 203 may be configured to store all inputs required for the delay measurement and data recovery process, preferably in the form of a Data-Stall-Profile database (DSP DB). The DSP DB may comprise the following information:
1) IP-Configuration of Data Stall Occurrence:
After identifying occurrence of every data-stall, IP configuration information pertaining to the identified data stall is collected and stored in the DSP. The IP configuration information may further comprise of IP, subnet info, gateway server, primary and secondary DNS server address, and IP version (IPV4, IPV6, or hybrid).
2) Access Point Name (APN) info:
Upon identifying data stall occurrence, all information about APN and corresponding APN settings are collected and stored in the DSP DB.
3) Time and Date:
Upon identifying data stall occurrence, Time and Date information pertaining to occurrence of data stall event is collected and stored in the DSP DB.
4) Location info:
Upon identifying data stall occurrence, all information pertaining to location of occurrence of the data stall event is collected and stored in the DSP DB.
5) Smart Recovery info:
After executing a particular data recovery process, information related to the data recovery process are collected and stored in the DSP DB. The information collected related to the data recovery process may include but not limited to recovery percentage, steps executed, and other miscellaneous data.

[0016] In addition to the DSP DB, the memory module 203 may also maintain a Quality of Network (QoN) rank database, which possesses information related to rank assigned to different data networks, based on their performance. For example, the data networks may be ranked on a scale of 1-5, 1 being the best and 5 being the worst, or vice-versa.
[0017] In an embodiment, the data stored pertaining to each network in the DSP DB, and the QoN rank DB may be updated on a periodic basis. In another embodiment, the data stored pertaining to each network in the DSP DB, and the QoN rank DB may be updated upon occurrence of certain pre-configured and pre-defined trigger events. An example of the trigger event is the network updating change in value of any network parameter.
[0018] In various embodiments, the data stored in the DSP DB may be collected using any suitable method, through any suitable channel, from respective data sources. The history data may be used for future reference and/or further processing at a later point of time.
[0019] The decision making module 204, based on the delay information, and data fetched from the DSP DB, and the QoN rank database, identifies severity of the delay. In various embodiments, the delay may be classified as critical and non-critical, based on various factors such as, but not limited to the network that produced the delay, and identified time delay. Further, based on the identified severity of the delay, the decision making module 204 decides time span within which a data recovery process needs to be initiated. The decision making module 204 may be further configured to instruct the action triggering module 205 to execute a specific data recovery process, based on the severity and familiarity of the delay.
[0020] The action triggering module 205, based on the instruction received from the decision making module 204, executes the specified data recovery process at the specified time. The action triggering module 205 can be further configured to monitor stability of the recovered data, and trigger at least one other data recovery procedure if occurrence of any data stall event is detected.
[0021] FIG. 3 illustrates a flow diagram depicting the method of dynamically triggering data recovery in data recovery framework, according to embodiments as disclosed herein. The data monitoring module 201 in the data stall identification and recovery module 102 monitors (302) on a continuous basis, packets that are transmitted from the UE 101 to the mobile network 103. The data monitoring module 201 further monitors response(s) that the UE 101 received from the mobile network 103 corresponding to each packet transmitted from the UE 101. While monitoring the inflow and outflow of packets, the data monitoring module 201 may also capture time stamp pertaining to the inward and outward packets.
[0022] The delay measurement module 202, based on the time stamp information received from the data monitoring module 201, checks (304) and identifies (306) quickly that at least one packet has got a delayed response, or that a response has not been received at all. In any network, a response that is not received within a specific time period may represent a delayed response; and may critically affect the UE 101 - mobile network 103 communication; which in turn may affect a data service being received by the UE 101. In order to identify the delay, the delay measurement module 202 may calculate difference between the outward packet and the corresponding inward packet (i.e. response) as a response time. Further, the response time is compared with a reference time, and if the response time is more than the reference time, it is considered as a delay.
[0023] Upon identifying a delay, the decision making module 204 checks (308) severity of the delay, based on inputs fetched from the memory module 203. In a preferred embodiment, the severity of the delay may vary based on the network that has caused the delay. For example, consider two networks A and B. Assume that history data pertaining to the network A indicates that the network A is vulnerable to frequent failures, and the QoN rank DB indicates that the network has got a bad rank, then any delay caused by the APN associated with network A may be considered as a critical delay. In this scenario, the decision making module 204 may instruct the action triggering module 205 to trigger a data recovery process, without any delay. Whereas, if history data pertaining to the network B indicates that the network B is generally stable, and the QoN rank DB indicates that the network has got a good rank, the decision making module 204 may consider any delay caused the APN associated with the network B as non-critical. Small delays from network which is generally stable, and has got good QoN rating may not be considered as a data stall event.
[0024] If the delay identified is of critical nature (310), then the decision making module 204 instructs the action triggering module 205 to trigger at least one data recovery process. In a preferred embodiment, the severity of the delay indicates increased probability of occurrence of data stall. The decision making module 204 may also instruct action triggering module 205 to trigger the data recovery process after a specified time period.
[0025] Upon receiving the instruction from the decision making module 204 to trigger the data recovery process, the action triggering module 205 checks (314) whether a smart recovery procedure is possible or not. In an embodiment, the smart recovery procedure can be triggered only if the identified delay is familiar; which in turn is detected based on whether a similar or same delay has occurred in the past. If occurrence of a same/similar delay has been recorded in the DSP database, the action triggering module 205 triggers (318) the smart recovery procedure.
[0026] In the smart recovery procedure, the action triggering module 205 can use history data present in a DSP database stored in the memory module 203, wherein the history data refers to information such as but not limited to at least one data recovery mechanism used corresponding to a same or similar delay detected in the past. For example, assume that for a same/similar type of delay occurred in the past, the action triggering module 205 had used APN offloading as a recovery procedure, and that the APN offloading procedure helped in data recovery. This implies that the APN offloading process can be an efficient solution for the detected delay, and in this case, the action triggering module 205 can select the APN offloading process as the data recovery procedure.
[0027] In another embodiment, if the identified delay is not familiar, i.e. the DSP database doesn’t possess information related to occurrence of a similar/same delay in the past, then the action triggering module 205 can trigger (316) a normal recovery process in which any of the available data recovery procedures is picked and executed in a random order, or in a specified order.
[0028] In a preferred embodiment, after recovering the data by executing the selected data recovery procedure, the action triggering module 205 checks (320) stability of the recovered data, wherein stability of the recovered data can be evaluated by checking for any further occurrence of delay even after executing the data recovery procedure.
[0029] If the recovered data is found to be unstable, then the action triggering module 205 checks (324) if APN offloading procedure has already been tried during the initial data recovery procedure, i.e. normal or smart recovery process. If the APN offloading procedure has not been triggered, then the action triggering module 205 triggers (328) the APN offloading procedure to ensure data stability. In the APN offloading process, the action triggering module 205 checks if functions being handled by this API can be performed by any other APN in the network. Upon identifying another APN with same/similar capabilities, the data packets being handled by the trouble-causing APN are offloaded to the newly identified APN.
[0030] If the APN offloading procedure had already been triggered during the initial data recovery procedure, then the action triggering module 205 checks (326) if RAT offloading procedure had already been triggered during the initial data recovery procedure. If the RAT offloading procedure has not been triggered, then the action triggering module 205 triggers (330) the RAT offloading procedure to ensure data stability. In the RAT offloading process, the action triggering module 205 terminates non-reliable 3GPP (4G-LTE) connection, and instead, uses a 3GPP2 (3G, 2G) connection.
[0031] If the RAT offloading procedure had already been triggered during the initial data recovery procedure, then the action triggering module 205 triggers (332) the Data tech-type offloading procedure to ensure data stability. In the Data tech-type offloading, the data access technology is changed from 3GPP to non-3GPP (e.g. Wi-Fi, Wi-Max).
[0032] The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware and performing network management functions to control the elements. The elements shown in Fig. 1 can be at least one of a hardware device, or a combination of hardware device and software module.
[0033] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the embodiments as described herein.

STATEMENT OF CLAIMS
We claim:

1. A method of triggering network specific data recovery in a telecommunication network, said method comprising:
identifying a delayed response to at least one data packet transmitted from a User Equipment (UE) to at least one mobile network, by a data stall identification and recovery module;
checking severity of said identified delay, by said data stall identification and recovery module;
triggering at least one data recovery process by said data stall identification and recovery module, to recover at least one data if said severity indicates that said delay is a critical delay, wherein said critical delay represents occurrence of a data stalling event;
monitoring said at least one recovered data for verifying stability of said at least one recovered data, by said data stall identification and recovery module; and
triggering at least one other data recovery process if said at least one recovered data is found to be unstable, by said data stall identification and recovery module.
2. The method as claimed in claim 1, wherein identifying said delayed response further comprises:
monitoring a plurality of data packets sent from said UE to at least one Access Point Name (APN) in a mobile network, by said data stall identification and recovery module;
measuring a response time corresponding to each of said plurality of data packets, by said data stall identification and recovery module; and
comparing said measured response time with a reference time, by said data stall identification and recovery module.
3. The method as claimed in claim 1, wherein said severity of said identified delay is checked based on data from at least one of a Data-Stall-Profile (DSP) database and a Quality of Network (QoN) database.
4. The method as claimed in claim 1, wherein triggering said data recovery process comprises triggering a smart recovery process by said data stall identification and recovery module, wherein said smart recovery process further comprises:
comparing said identified delay with data in a Data-Stall-Profile (DSP) database;
identifying at least one match for said identified delay in said DSP database by said data stall identification and recovery module, wherein said at least one match is at least one of a similar delay occurred in the past;
identifying at least one data recovery process corresponding to said identified match, by said data stall identification and recovery module; and
triggering said identified at least one data recovery process, by said data stall identification and recovery module.
5. The method as claimed in claim 4, wherein said identified data recovery process is at least one of an Access Point Name (APN)-offloading, Radio Access Technology (RAT)-offloading, and a Data – Tech – Type – offloading.
6. The method as claimed in claim 1, wherein triggering said data recovery process comprises triggering a normal recovery process by said data stall identification and recovery module, wherein said normal recovery process comprises triggering at least one of an Access Point Name (APN)-offloading, Radio Access Technology (RAT)-offloading, and a Data – Tech – Type – offloading.
7. A User Equipment (UE) for triggering network specific data recovery in a telecommunication network, said UE comprising:
a hardware processor; and
a non-volatile memory comprising instructions, said instructions configured to cause said hardware processor to:
identify a delayed response to at least one data packet transmitted from said UE to at least one mobile network, by a data stall identification and recovery module;
check severity of said identified delay, by said data stall identification and recovery module;
trigger at least one data recovery process to recover at least one data if said severity indicates that said delay is a critical delay, by said data stall identification and recovery module, wherein said critical delay represents occurrence of a data stalling event;
monitor said at least one recovered data for verifying stability of said at least one recovered data, by said data stall identification and recovery module; and
trigger at least one other data recovery process if said at least one recovered data is found to be unstable, by said data stall identification and recovery module.
8. The UE as claimed in claim 7, wherein said data stall identification and recovery module is further configured to identify said delayed response by:
monitoring a plurality of data packets sent from said UE to at least one Access Point Name (APN) in a mobile network, by a data monitoring module in said data stall identification and recovery module;
measuring a response time corresponding to each of said plurality of data packets, by a delay measurement module in said data stall identification and recovery module; and
comparing said measured response time with a reference time, by said delay measurement module.
9. The UE as claimed in claim 7, wherein said data stall identification and recovery module is further configured to check severity of said identified delay based on data from at least one of a Data-Stall-Profile database and a Quality of Network (QoN) database.
10. The UE as claimed in claim 7, wherein said data stall identification and recovery module is further configured to trigger said data recovery process by triggering a smart recovery process, wherein said data stall identification and recovery module is further configured to trigger said smart recovery process by:
comparing said identified delay with data in a Data-Stall-Profile (DSP) database;
identifying at least one match for said identified delay in said DSP database, wherein said at least one match is at least one of a similar delay occurred in the past;
identifying at least one data recovery process corresponding to said identified match; and
triggering said identified at least one data recovery process.
11. The UE as claimed in claim 7, wherein said data stall identification and recovery module is further configured to execute at least one of an Access Point Name (APN)-offloading, Radio Access Technology (RAT)-offloading, and a Data – Tech – Type – offloading as said smart recovery process.
12. The UE as claimed in claim 7, wherein said data stall identification and recovery module is further configured to trigger said data recovery process by triggering a normal recovery process, wherein said data stall identification and recovery module is further configured to trigger said normal recovery process by triggering at least one of an Access Point Name (APN)-offloading, Radio Access Technology (RAT)-offloading, and a Data – Tech – Type – offloading.
13. Date: 16 January 2015 Signature:
Kalyan Chakravarthy
ABSTRACT
Disclosed herein are a method and a User Equipment (UE) for triggering network specific data recovery. The UE monitors data packet flow from the UE to a mobile network, and identifies delayed response to any of the data packet sent. Upon identifying any delay, the UE checks severity of the delay, wherein the severity is network specific and/or device specific, and a critical delay may represent an occurrence of data stalling event. Upon identifying a data stalling event, the UE triggers at least one data recovery process; wherein the time span within which the data recovery process is triggered may vary based on severity of delay; which in turn may vary for each network. After recovering data by triggering the recovery process, the UE monitors and checks stability of the recovered data, and if the recovered data is unstable, triggers at least one other data recovery process.
FIG. 1