EMPLOYING HANDOVER FAILURES FOR NETWORK FAULT PREDICTION OR REMEDY

• US 20110086634A1
• Filed: 10/13/2009
• Published: 04/14/2011
• Est. Priority Date: 10/13/2009
• Status: Active Grant

• Current Assignee: AT&T Intellectual Property I LP (AT&T, Inc.)
• Original Assignee: AT&T Intellectual Property I LP (AT&T, Inc.)
• Inventors: Rahman, Moshiur
• Granted Patent: US 9,148,809 B2
• Time in Patent Office: Days
• US Class Current: 455/423
• CPC Class Codes: H04W 24/04 Arrangements for maintaining operational condition
• CPC Class Codes: H04W 24/08 Testing, supervising or monitoring using real traffic
• CPC Class Codes: H04W 36/00 Hand-off or reselection arrangements

Abstract

The disclosed subject matter relates to an architecture that can detect a potential fault condition in a wireless communication network. In particular, the architecture can reference handover transaction failures in order to identify issues, e.g., before such issues escalate to more severe fault situations. In addition, the architecture can dynamically query a set of devices or components potentially responsible for the handover failure and/or take appropriate actions aimed at remedying the issue in an expeditious manner.

Claims

1. A system that detects a potential fault condition in a wireless communication network, comprising:

a monitor component that examines handover transaction messages received by a network component, and that identifies a handover failure;

an aggregation component that stores information associated with the handover failure to a data store; and

a fault management component that dynamically queries connected components associated with the handover failure in order to determine a potential fault condition prior to escalation.

2. The system of claim 1, the network component is a Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN)-based Radio Network Controller (RNC), and the monitor component is included in or operatively coupled to the RNC, wherein the RNC receives handover transaction messages and manages handover operations for user equipment (UE) with respect to a source channel and a target channel.

3. The system of claim 1, the fault management component dynamically determines a set of connected components connected to the network component.

4. The system of claim 3, the fault management component dynamically queries all or a portion of the set of connected components.

5. The system of claim 4, the fault management component transmits a query to a connected component that includes at least one of a request for a status of the connected component, a request for a status of an interface between the connected component and the network component, a request for a type and number of applications running on the connected component, or a request for a status of one or more applications running on the connected component.

6. The system of claim 4, the fault management component identifies a faulty component included in the set of connected components based upon an analysis of responses to the queries.

7. The system of claim 1, the handover failure relates to an interruption of a call or a data session.

8. The system of claim 1, the handover failure relates to an unintentional termination of a call or a data session.

9. The system of claim 1, the handover failure relates to a soft handover in which both a source channel and a target channel are maintained in parallel for a period during the handover.

10. The system of claim 1, the handover failure relates to a softer handover in which a soft handover is maintained for both forward link and reverse link in connection with a call or data session.

11. The system of claim 1, the handover failure relates to a hard handover in which a source channel is released contemporaneously with connection to a target channel.

12. The system of claim 1, the aggregation component maintains a count of a number of handover failures.

13. The system of claim 12, the aggregation component compares the count to a predefined threshold and notifies the fault management component when the count meets or exceeds the predefined threshold.

14. The system of claim 1, the fault management component determines an appropriate action in order to isolate or remedy the potential fault condition.

15. The system of claim 1, the fault management component transmits a notification to a maintenance component, wherein the notification includes an identification of the potential fault condition.

16. The system of claim 1, further comprising an intelligence component that determines an order to query devices based upon an inference as to which component is more likely to be at fault.

17. A method for detecting an error condition before escalation to a fault in a wireless communication network, comprising:

monitoring handover transaction messages relating to wireless communication handover;

identifying a handover failure based upon the monitoring handover transaction messages;

registering the handover failure by storing in a failure list in a data store; and

dynamically querying components potentially responsible for the handover failure in order to isolate or remedy an error condition.

18. The method of claim 17, further comprising at least one of the following acts:

interfacing to a UTRAN-based RNC for monitoring handover transaction messages;

detecting the handover failure based upon an interruption to service for a call or a data session;

detecting the handover failure based upon an unintentional termination of a call or a data session;

identifying the handover failure in connection with at least one of a soft handover, a softer handover, or a hard handover;

determining a count of a number of handover failures registered to the data store;

or

dynamically querying components potentially responsible for the handover failure when the count equals or surpasses a predefined threshold.

19. A method for dynamically querying components potentially responsible for a handover failure in a wireless communication network, comprising:

receiving a failure list including a set of handover failures detected based upon data received by a RNC;

determining a set of devices connected to the RNC;

automatically transmitting one or more query to all or a portion of the set of devices connected to the RNC;

analyzing responses to the one or more query; and

determining at least one source of the set of handover failures based upon the analyzing.

20. The method of claim 19, further comprising at least one of the following acts:

consulting a topology database for determining the set of devices connect to the RNC;

including in the one or more query at least one of a request for a status of a device connected to the RNC, a request for a status of an interface between the device and the RNC, a request for a type and number of applications running on the device, or a request for a status of one or more applications running on the device;

determining an appropriate action in order to isolate or remedy the at least one source of the set of handover failures;

transmitting a notification to a maintenance component or entity;

or

including in the notification an identification of the at least one source of the set of handover failures.