Detailed call records for voice over LTE calls

A performance monitoring system and method is based on a Detailed Call Record (DCR). A DCR contains records of events occurring in different network domains (14, 20, 40) that are related to a single, specific VoLTE call. The DCR events for each VoLTE call cover all legs of the call, and for each call leg, the relevant events are ordered by time. A DCR also contains basic information to identify the call: the IMS Charging Identifier (ICID), the International Mobile Subscriber Identity (IMSI) of all involved subscribers, and the start and stop timestamps of the call. A DCR has all the relevant user plane measurement, radio measurement, and control plane data from all the involved domains (14, 20, 40) for all call legs of a VoLTE call, in contrast to prior art systems that focus only on a single subscriber's activities for a given call. The DCR thus provides a complete view of the call, allowing more complete analytics and troubleshooting. Furthermore, the data are collected and assembled automatically, with results available real-time, or with a few seconds delay.

FIELD OF INVENTION

The present invention relates generally to performance monitoring in wireless communication networks, and in particular to an automated, (near) real-time system and method for performance monitoring of Voice over LTE (VoLTE) networks based on detailed call records.

BACKGROUND

Wireless communication networks are ubiquitous in many parts of the world. A modern wireless communication network is, in many respects, a complex dynamic system, in which system parameters are constantly monitored and adjusted, to attempt optimal operation in the face of changes in traffic load, usage patterns, channel quality, and other dynamic factors.

In early-generation wireless communication networks (e.g., Wideband Code Division Multiple Access, or WCDMA and Global System for Mobile communications, or GSM), voice services were delivered over circuit switched (CS) domains. CS networks provide guaranteed transport services for voice traffic, which is very sensitive to packet-level transmission characteristics, such as delay and loss or jitter. The Third Generation Partnership Project (3GPP) Long Term Evolution (LTE) was originally designed for high speed data transfer, and does not include circuit switched domains. Still, there is a strong motivation to support voice service over LTE networks. Voice over LTE (VoLTE) is much more bandwidth efficient than WCDMA and GSM voice. Once a good LTE coverage is achieved, the older network technologies (e.g., WCDMA and GSM) can be phased out and the frequency bands can be reused for newer, more efficient network technologies. LTE networks span numerous domains, or technologies, each optimized for different aspects of communication network operation.

FIG. 1depicts a diagram of some relevant nodes in an LTE network10, grouped into three domains: the Radio Access Network (RAN) domain14, the Evolved Packet Core (EPC) domain20, and the IP Multimedia Subsystem (IMS) domain40.

The radio access network (RAN) provides wireless connectivity between a large number of (possibly mobile) User Equipment (UE)12, such as smartphones, machine-to-machine (M2M) devices, laptop or tablet computers, and the like, and fixed terrestrial base stations (E-NodeB, or eNB)16a,16b.

The LTE RAN14, e.g., Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial RAN, or E-UTRAN, is connected to the Evolved Packet Core (EPC) domain20. EPC20is an IP-based multiservice core network providing end-to-end service delivery for user traffic and ensuring signaling-based mobility management in access networks. The EPC is a split architecture network, where the user and signaling plans are separated and handled by different network entities. Important EPC20functionalities include the Home Subscriber Server (HSS)26, a node that maintains a database containing the user and subscriber related information, and also is involved in session setup, authentication and authorization. The Serving Gateway (SGW)24is the gateway between the RAN14and the EPC20, while the Packet Data Network Gateway (PGW)28connects the EPC20to external IP networks, such as the Internet32and IMS domain40. PGW28includes IP address translation, and communicates with the Policy and Charging Rules Function (PCRF)30. The Mobility Management Entity (MME)22is a signaling node, responsible for tracking and mobility of the UE12in the RAN14.

An IP Multimedia Subsystem (IMS) domain40provides the control and media functions for voice and other real-time multimedia services in LTE networks10. The IMS signaling protocol is the Session Initiation Protocol (SIP), which is standardized by the Internet Engineering Task Force (IETF). IMS40includes the Call Session Control Functions (P-CSCF44, I-CSCF48, and S-CSCF46). The Proxy-CSCF (P-CSCF)44is a SIP proxy that is the first point of contact for the IMS domain40. It acts as an anchor point to the IMS40—encrypting and decrypting outgoing and incoming traffic, respectively. Interrogating-CSCF (I-CSCF)48is another IMS function serving as an edge node of the IP administrative domain. It includes a Domain Name System (DNS) address, enabling external servers to find the IMS system40. Serving-CSCF (S-CSCF)46is a central SIP server performing session control and SIP registration. It connects the different SIP addresses and user profiles. Diameter protocol is used by S-CSCF46to obtain user profiles from HSS26in the EPC domain40. Application Servers (AS)52host and control various services, such as voice, video, gaming, etc. An E.164 Number to URI Mapping (ENUM) node50translates telephone numbers into internet addresses. The ENUM50connects to a telephony AS providing various voice call services. Other networks may connect to the IMS domain40, such as the Public Switched Telephone Network (PSTN)34.

The complex network architecture and variety of network functionalities involved in providing multimedia services in mobile networks10require a performance monitoring and troubleshooting system that assures proper network operation and achievement of contracted services level. Such systems collect data from a variety of source, such as the network interfaces, terminals, and from the network node logs. In a mobile network10, a very large amount of data is produced; therefore the management systems usually work on well selected data. Network nodes usually have performance management functions that are based on statistical counters. These contain time-aggregated data which may further be aggregated for other dimensions, cells, users, services, etc. Network nodes also generate event data in the form of streaming events or network logs. These contain more detailed information of the network operation. The active counters and events are configurable.

In the network interfaces, network probes generate an output of the protocol information. Performance monitoring systems collect this information. Since there are many network entities which are involved in the network operation, these data have to be collected and correlated from many network sources, in order to be able to obtain adequate information from end-to-end sessions or services.

Although counter based network management systems are suitable for high-level performance monitoring (PM), because they are based on statistical data, the details and individual problems are hidden. These systems are deficient for monitoring service levels of individual subscribers, and for troubleshooting.

In the case of event-based monitoring systems, the output is often time-aggregated, which has similar drawbacks to the counter-based systems. In case of failures, the call details are not available for detailed troubleshooting.

In many PM solutions, where data are available at the subscriber level, data for one user are correlated. The originating and terminating sides of calls, and PM data of the participating parties, are either not visible, or not correlated with each other in the output of the PM system.

Furthermore, most of the existing monitoring systems, even if they provide per-user information, only work within one domain (e.g., RAN14, EPC20, IMS40, etc.) and do not perform cross-domain correlation. These systems can monitor and detect problems within a specific domain, but cannot map this information into end-to-end performance metrics due to a lack of information from other domains.

Using existing monitoring systems, network operators can collect cross-domain information, but they need to use multiple, (e.g., four to five) different monitoring solutions, and perform extensive manual “correlation like” steps to collect the information and put it in a useable form. Due to the extensive manual intervention, operators cannot apply their analysis for all of the customers; rather, it is limited to only certain specified users, such as drive testers. Furthermore, the typical delay in accessing and correlating this information is on the order of 30-45 minutes, at best.

The Background section of this document is provided to place embodiments of the present invention in technological and operational context, to assist those of skill in the art in understanding their scope and utility. Unless explicitly identified as such, no statement herein is admitted to be prior art merely by its inclusion in the Background section.

SUMMARY

The following presents a simplified summary of the disclosure in order to provide a basic understanding to those of skill in the art. This summary is not an extensive overview of the disclosure and is not intended to identify key/critical elements of embodiments of the invention or to delineate the scope of the invention. The sole purpose of this summary is to present some concepts disclosed herein in a simplified form as a prelude to the more detailed description that is presented later.

According to one or more embodiments described and claimed herein, at least some of the above described deficiencies in the prior art are alleviated by a performance monitoring system and method based on a Detailed Call Record (DCR). A DCR contains records of events occurring in different network domains14,20,40that are related to a single, specific VoLTE call. The DCR events for each VoLTE call cover all legs of the call, and for each call leg, the relevant events are ordered by time. A DCR also contains basic information to identify the call: the IMS Charging Identifier (ICID), the International Mobile Subscriber Identity (IMSI) of all involved subscribers, and the start and stop timestamps of the call. A DCR has all the relevant user plane measurement, radio measurement, and control plane data from all the involved domains for all call legs of a VoLTE call, in contrast to prior art systems that focus only on a single subscriber's activities for a given call. The DCR thus provides a complete view of the call, allowing more complete analytics and troubleshooting. Furthermore, the data are collected and assembled automatically, with results available real-time, or with a few seconds delay.

The correlated data may be assembled into a DCR by generating a DCR comprising a header including one or more of a type of call, user IDs, call ID, and start and stop timestamps; start and end conditions for the call including one or more of location, radio environment metrics, and bearer information; and detailed event level information from at least one network domain selected from the group consisting of radio access network14, evolved core network20, and IP multimedia subsystem40.

The detailed event level information from the evolved core network20may include one or more of session and bearer setup information, session and bearer management information, QoS information, handover information, and location.

The detailed event level information from the radio access network14may include one or more of radio environment statistics, handover information, radio environment statistics during handover, cell quality information, and cell health.

The detailed event level information from the IP multimedia subsystem40may include one or more of Registration, call setup, and call release.

One embodiment relates to a method of generating a DCR for a VoLTE call in an LTE wireless communication network. For each leg of the call, network data associated with the call from all involved domains are collected using domain-specific identifiers associated with a subscriber. For each leg of the call, the collected data are pre-correlated by mapping the domain-specific identifiers to a common identifier associated with a subscriber. The data are correlated across all legs of the call, using the common identifiers, to generate a DCR including all events, across all domains, for all legs of the call.

Another embodiment relates to a computer communicatively connected to an LTE wireless communication network, and operative to generate a DCR for a VoLTE call in the LTE network. The computer includes communication circuits operative to exchange data with one or more LTE network nodes. The computer also includes processing circuitry operatively connected to the communication circuits. The processing circuitry is operative to, for each leg of the call, collect network data associated with the call from all involved domains using domain-specific identifiers associated with a subscriber; for each leg of the call, pre-correlate the collected data by mapping the domain-specific identifiers to a common identifier associated with a subscriber; and correlate the data across all legs of the call, using the common identifiers, to generate a DCR including all events, across all domains, for all legs of the call.

Yet another embodiment relates to a non-transitory computer-readable medium containing program instructions which, when executed on processing circuitry communicatively coupled to an LTE wireless communication network, are operative to cause the processing circuitry to generate a DCR for a VoLTE call in the LTE network by performing the steps of: for each leg of the call, collecting network data associated with the call from all involved domains, using domain-specific identifiers associated with a subscriber; for each leg of the call, pre-correlating the collected data by mapping the domain-specific identifiers to a common identifier associated with a subscriber; and correlating (106) the data across all legs of the call, using the common identifiers, to generate a DCR including all events, across all domains (14,20,40), for all legs of the call.

Still another embodiment relates to an apparatus communicatively connected to an LTE wireless communication network, and operative to generate a DCR for a VoLTE call in the LTE network, the apparatus adapted to: for each leg of the call, collect network data associated with the call from all involved domains using domain-specific identifiers associated with a subscriber; for each leg of the call, pre-correlate the collected data by mapping the domain-specific identifiers to a common identifier associated with a subscriber; and correlate the data across all legs of the call, using the common identifiers, to generate a DCR including all events, across all domains, for all legs of the call.

Still another embodiment relates to a computer program, comprising instructions which, when executed on processing circuitry are operative to cause the processing circuitry to carry out the method according to method claims.

Still another embodiment relates to an apparatus communicatively connected to an LTE wireless communication network, and operative to generate a DCR for a VoLTE call in the LTE network. The apparatus comprises a first module configured to, for each leg of the call, collect network data associated with the call from all involved domains using domain-specific identifiers associated with a subscriber. The apparatus comprises a second module configured to, for each leg of the call, pre-correlate the collected data by mapping the domain-specific identifiers to a common identifier associated with a subscriber. The apparatus comprises a third module configured to correlate the data across all legs of the call, using the common identifiers, to generate a DCR including all events, across all domains, for all legs of the call.

DETAILED DESCRIPTION

For simplicity and illustrative purposes, the present invention is described by referring mainly to an exemplary embodiment thereof. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be readily apparent to one of ordinary skill in the art that the present invention may be practiced without limitation to these specific details. In this description, well known methods and structures have not been described in detail so as not to unnecessarily obscure the present invention.

Overview

Embodiments of the present invention provide a data collection, correlation, and analysis system for (near) real-time, automated, cross-domain VoLTE call monitoring and troubleshooting. The system eliminates the expensive drive tests and human analysis of collected log files. The inventive system monitors multiple domains of the wireless communication network (including, but not limited to, RAN14, EPC20, and IMS40), collects extensive information related to VoLTE calls, performs cross-domain correlation, and generates Detailed Call Records (DCR). These DCRs contain information from all legs (mobile originating and terminating) of a VoLTE call. As used herein, a “leg” of a call includes all network nodes involved in delivering VoLTE service to a user terminal. For example, a two-party (mobile-to-mobile) call has two legs; a conference call may have as many legs as participants.

The inventive real-time system creates DCRs in three steps (seeFIGS. 2 and 3). First, in a data collection step, the state of being involved in a VoLTE call is tracked at the individual subscribers' levels based on SIP messages. Events in the call's timeframe for the subscriber(s) are collected in all the involved domains, using domain-specific identifiers, such as the IMS Charging Identifier (ICID). Second, in a pre-correlation step, the domain-specific identifiers for the data and events are mapped to a common identifier, such as the International Mobile Subscriber Identity (IMSI). Third, in a correlation step, the data for the individual call legs is assembled to create the call's complete DCR.

The DCR may then be analyzed, monitored, used to troubleshoot problems, and the like. The DCR may be sent to a performance monitoring node or the like in a streaming event, or it may be stored in a file or database for selective retrieval and analysis. The DCR is further processed by higher network layer components, where rules-based processing, aggregation, or other processing can be implemented to support different troubleshooting and monitoring use cases.

The DCR may be assembled by a dedicated DCR server54(FIG. 1), which is not a part of any of the monitored domains14,20,40. As used herein “server” is a functional term, such as used in the phrase “application server,” and does not limit the type or architecture of the hardware (e.g., client/server distinctions). In general, any suitable computer having processing circuitry and communication circuits operative to exchange messages and data with network10nodes, which is appropriately programmed, may function as a DCR server54.

FIG. 2provides a general overview of the inventive system. The DCR server collects, e.g., control plane data and user plane measurements from UEs12via eNBs16in the RAN14, from the EPC20, and from the IMS40for each leg of a VoLTE call. After data collection and mediation102, the data are processed in a pre-correlation step104to ensure a consistent identifier across all domains14,20,40for each leg. In a DCR correlation step106, the data from all legs of the call are correlated to generate a full DCR. The DCR—containing extensive information on a single VoLTE call, across all domains, and for all call legs—is then available for analytics and other processing.

FIG. 3depicts the functional steps in a process of generating a DCR (corresponding to a method described with reference toFIG. 5). The specific steps in this process are described in detail below.

Data Collection and Mediation

In this step102, data are collected separately for each leg of the call, from different domains (including, but not limited to, RAN14, EPC20, and IMS40), and prepared for further processing. The data are collected in the form of event streams, network events, and measurement reports. The data are received and processed within seconds after an event occurs in the network. In case of IMS procedures, events are reported at the end of the procedures. Examples of the specific information collected are detailed herein. Data relevant to a VoLTE call are identified by domain-specific identifiers associated with a subscriber in each different domain. For example, an ICID may identify IMS domain40events, while an S1APID may identify messages in the EPC domain20(See, e.g., 3GPP TS 36.401, § 6.2.1).

The main purpose of the pre-correlation step104to ensure that, for each leg of the VoLTE call, events from different domains have uniform keys, such as the IMSI of the subscriber terminating that leg, for identifying individual subscribers' event sequences across all domains. In those domains where IMSI is not readily available in the events, for example in case of LTE radio events where sessions are identified by S1APIDs, the domain-specific IDs are resolved to IMSIs, in order to use the IMSI as the common ID. Domain-specific IDs include, for example, Mobile Station International Subscriber Directory Number (MSISDN), S1APIDs, IP Multimedia Public Identity (IMPU), and user Internet Protocol (IP) addresses. The resolution to IMSI is accomplished by maintaining domain ID—IMSI mappings for each domain, and using them for ID resolution. The pre-correlation step104augments the incoming event streams with a common identifier (e.g., IMSI) for each leg of the call, and produces a matching outgoing stream, also in real-time fashion.

Correlation Across Call Legs

Detailed Call Records contain cross-domain correlated information from all legs of a VoLTE call, which form the basis of further analysis. Embodiments of the present invention collect the information from different data sources, as discussed above, identify the users and the VoLTE call ID in a few pre-correlation steps, then correlate the two call legs (or more in case of conference calls) and assemble the correlated information into a DCR. The DCR correlation logic106updates call states after each event, and immediately generates a DCR record for a call if an event or an internal timer indicates that the call has ended. This generates a real-time stream of DCRs for further analytics.

Analytics

The collected and correlated information content of a DCR, or multiple DCRs, are used for detailed analysis and troubleshooting. Typical fault cases can be identified manually, automatically by machine learning, or automatically based on predefined conditions. These methods may also be combined.

Data Sources

Some non-limiting examples of information collected from different wireless communication network domains are listed below.

Session and bearer setup (e.g. General Packet Radio Service (GPRS) Core Tunneling Protocol, GTP-C, protocol events or MME22/SGW24logs)

Session and bearer management (e.g. GTP-C protocol events or MME22/SGW24logs)

QoS information (e.g. GTP-C protocol events or MME22/SGW24logs)

Handover information (core network signaling or MME22logs)

Radio environment statistics (e.g. Radio Resource Control, RRC, measurement report events or eNB16logs)

Handover information (e.g. S1AP protocol events or eNB16logs)

Radio environment statistics during handover (e.g. RRC protocol events or eNB16logs)

Cell quality information (eNB16logs)

Cell congestion (eNB16logs)

Call setup (IMS40signaling)

Call release (IMS40signaling)

Detailed Call Record

Detailed Call Records contain cross-domain correlated information about all legs of a VoLTE call and form the basis for further analysis. Embodiments of the present invention collect102the information from different data sources mentioned above, identify the users and the VoLTE call ID for each leg in a pre-correlation step104, then correlate106the two call legs (or more in case of conference calls), and assemble the correlated information into a DCR. As discussed above, pre-correlation activities ensure events from different domains have uniform keys, such as the IMSI, for identifying individual subscribers' event sequences.

DCR Generation Logic

FIG. 4depicts a logic flow60for extracting relevant events from a subscriber's activity log—for example, within the IMS domain40. Events are processed in chronological order as indicated by their timestamps.

Start of a Call Leg and Data Collection

In the embodiment depicted inFIG. 4, the SIP INVITE message is selected as marking the beginning of a call leg, and the timestamp of the SIP INVITE message is selected as the start time of the call leg. As each event enters the DCR logic flow60(block62), it is inspected to determine whether it is a SIP INVITE message (block64). If so, the associated subscriber is determined to be in a VoLTE call session (block66). The IMS Charging Identifier (ICID) associated with the subscriber's IMSI is stored (block68). The ICID is the unique ID of the complete IMS session, and within the IMS session, in all the SIP events for all the involved parties, the ICID is the same. Therefore, the call leg event sequences of a call can be correlated by the ICID. At this point, the domain-specific identifier (ICID) and a common identifier of the subscriber (IMSI) are both known, and an association between them is formed, for the pre-correlation step104. A mapping—the ICID-IMSI key—is formed, and this key is stored with all subsequent events. For example, the current event—that is, the SIP INVITE message—is stored for this leg of the VoLTE call (block70), along with the ICID-IMSI key, and the processing of that event ends (block72).

After data collection for a call leg is “opened” as described above, each subsequent event within the domain, identified as associated with the subscriber by the domain-specific identifier (e.g., ICID), is processed, in chronological order according to timestamp, by the DCR logic60, beginning at block62. If the event is not an SIP INVITE message (block64) or an SIP BYE message (block74), and the subscriber is in a VoLTE call session (block76), then the event is stored in the DCR for this domain for this leg (block78), along with the ICID-IMSI key, and processing for this event ends (block72). The subscriber is determined to be in a VoLTE call session because the subscriber was so marked at block66, and has not yet been marked as not in a VoLTE call session at block84, as discussed below. All call measurements, events, and other data, identified as being associated with the subscriber by the domain-specific identifier (e.g., ICID), are subsequently processed by the DCR logic60in the same fashion, thus building a list of all events in the domain for this leg of the VoLTE call.

Pre-Correlation for Each Leg

The data collection process60collects all measurements, events, and other data, for each leg of the call, separately within each domain, using a domain-specific identifier associated with the subscriber. In a pre-correlation step104, these data are associated with a single, common identifier, such as the subscriber's IMSI. To accomplish this, mappings are maintained between each domain-specific identifier (e.g., ICID, S1APID, etc.) and the common identifier (e.g., IMSI). See block68. The pre-correlation processing is carried out separately for each leg of the call, using a common identifier (e.g., IMSI) associated with the subscriber for that leg. In the example depicted inFIG. 4, the pre-correlation step104occurs concurrently with the data collection step102—as network data are determined to be relevant to a call leg (by their domain-specific identifier and timestamp), they are tagged with an ICID-IMSI key as they are stored for further processing (blocks70,78,80). In other embodiments, data collected only using the domain-specific identifier can be post-processed to supply the mapping to a common identifier.

Termination of a Call Leg

As data and events for a call leg in a domain are logged, eventually an event identified by its domain-specific identifier is determined to be an SIP BYE message (block74). This marks the end of the call leg, and the timestamp of the SIP BYE message is selected as the stop time of the call leg. The event (i.e., the SIP BYE message) is stored as the final event (block80), along with the ICID-IMSI key, and the call leg is marked as complete and ready for further processing (block82). The subscriber's status is changed to no longer in a VoLTE call session (block84), so no further events associated with the subscriber (via the domain-specific identifier) are logged—that is, flow from block76will go straight to block72.

Correlation of Call Legs and Assembling the DCR

After all the pre-correlation processing104is complete, all data for all legs of the VoLTE call has been collected. All data within each leg are identified by a common identifier (e.g., IMSI) and each event has a timestamp. Based on the timestamps, event streams from the different sources, in different domains14,20,40, are merged (ordered by time). A DCR is assembled, in one embodiment, after the end of the BYE procedure is detected. The end of a call is detected for each of the individual call legs through separate BYE events, but only one DCR is generated per call. In one embodiment, this is achieved by independently tracking the legs involved in the call and their closure (block86), and generating the DCR (block88) only when the last leg is closed. BYE events may be missing for some of the call legs. This is handled in one embodiment by starting a time of a few seconds when the first BYE event in a call is processed. When the timer expires, the DCR is generated. After the DCR is generated, the call related events may be discarded (block90).

To generate the DCR (block88), a correlation step106correlates measurements, events, and other data for all the different legs of the VoLTE call, ordered chronologically by timestamp times. There are as many common identifiers (e.g., IMSIs) as legs of the call (which is the same as the number of subscribers, at least for mobile-to-mobile calls).

DCR Content

In general, a DCR may be organized in a number of ways. In one embodiment, a DCR has the following structure:

Header

Call ID (e.g. IMS charging ID)

Start and end conditions (for the mobile originating and terminating part)

Location

Detailed event level information (for the mobile originating and terminating part), arranged by the different domains from which the data were obtained.

Session and bearer setup (e.g. GTP-C protocol events or MME/SGW logs)

Session and bearer management (e.g. GTP-C protocol events or MME/SGW logs)

Handover information (core network signaling or MME logs)

Location

Radio environment statistics (e.g. RRC measurement report events or eNB logs)

Handover information (e.g. S1AP protocol events or eNB logs)

Radio environment statistics during handover (e.g. RRC protocol events or eNB logs)

Cell quality information (eNB logs)

DCR Analysis

In one embodiment, an automated solution for analyzing the correlated data reported in DCR is a Rule Engine. A Rule Engine is used to generate incidents or triggers based on predefined rules and conditions. Rules apply different conditions, thresholds, ranges, and logical relations to the DCR fields, and generate an output, called incident or trigger. Additionally or alternatively, other forms of analysis may be applied.

The collected and correlated information content of a DCR, or multiple DCRs, can be used for detailed analysis and troubleshooting. Typical fault cases may be identified manually, automatically by machine learning, or automatically based on predefined conditions. These methods may be combined as well.

In case of manual analysis, the message sequences and the timing of the messages are investigated. Typical fault cases can be identified by investigating the content of the DCR and comparing the reported output with the expected output of the standard procedures. Based on the identified faults, typical patterns are defined for the different fault cases in the DCR.

The fault cases than can be configured in the Rule Engine. After that the Rule Engine generates an incident whenever a fault case occurs. In this case, it is possible to detect and identify automatically the identified fault cases in larger network areas and over many subscribers. It is also possible to quantify the frequency and distribution of the different fault cases.

One example fault case is a dropped VoLTE call due to bad radio conditions. UE12ainitiated a call to UE12b, which later terminated. Inspection of a DCR for the call may reveal that the VoLTE dedicated bearer activation was successful on both sides, based on the signaling traffic captured inside EPC20. The call setup was successful, based on the signaling traffic captured inside IMS40. During the call, both UE12aand UE12bperformed a handover, based on RAN14and EPC20signaling. Both handover procedures failed. Based on periodic radio measurements, poor radio conditions led to failing handover procedures. The dedicated bearers were removed and the VoLTE call was dropped.

The detailed analysis of this scenario is possible because the following data sources would be correlated into a Detailed Call Record:

mobile originated call setup record from the IMS40;

mobile terminated call setup record from the IMS40;

periodic radio measurements on eNBs16a,16b;

handover procedures captured inside EPC20for both UEs12a,12b;

bearer related procedures captured inside EPC20for both UEs12a,12b; and

radio measurements during handover on eNBs16a,16b.

Another example fault case is a failed VoLTE call setup due to bad radio conditions at the mobile terminating side. UE12aattempted to initiate a call to UE12b. The VoLTE dedicated bearer activation was successful on both sides, based on the signaling traffic captured inside EPC40. The call setup failed at the mobile terminating side, based on the signaling traffic captured inside IMS40, because the signaling message sequence from the terminating side was incomplete. This lead to the expiration of the call setup timer at IMS40and the call setup procedure was canceled. When the call setup was canceled, control was forwarded to a voice mail procedure. Based on the periodic radio measurements, poor radio conditions can be observed at the terminating side.

The detailed analysis of this scenario is possible because the following data sources are correlated into a Detailed Call Record:

mobile originated call setup record from the IMS40;

mobile terminated call setup record from the IMS40;

periodic radio measurements on eNBs16a,16b; and

bearer related procedures captured inside EPC20for both UEs12a,12b.

Method of Generating a DCR

FIG. 5depicts the steps in a method100of generating a Detailed Call Record (DCR) for a Voice over LTE (VoLTE) call in an LTE wireless communication network. For each leg of the call, network data associated with the call are collected from all involved domains14,20,40, using domain-specific identifiers associated with a subscriber (block102). Also for each leg of the call, the collected data are pre-correlated by mapping the domain-specific identifiers to a common identifier associated with a subscriber (block104). Those of skill in the art will appreciate that steps102and104may occur concurrently or sequentially (or concurrently in one or more domains, and sequentially for another domain). When data collection102and pre-correlation104for all legs is complete (or times out), the data are correlated across all legs of the call, using the common identifiers, to generate a DCR including all events, across all domains, for all legs of the call (block106).

Hardware and Software

FIG. 6is a block diagram of a computer, referred to herein as a DCR Server54, operative to perform, e.g., the method100. The DCR Server54includes communication circuits92operative to exchange messaging and data with numerous network nodes in all relevant domains—e.g., RAN14, EPC20, IMS40, and the like. The communication circuits92may comprise a receiver and transmitter interface used to communicate with one or more other nodes over one or more communication channels or networks according to one or more communication protocols known in the art or that may be developed, such as Ethernet, TCP/IP, SONET, ATM, SIP, or the like. The communication circuits92implement receiver and transmitter functionality appropriate to the communication network links (e.g., optical, electrical, and the like). The transmitter and receiver functions may share circuit components and/or software, or alternatively may be implemented separately.

The DCR Server54also includes processing circuitry94operative to perform, e.g., the method100. The processing circuitry94may each be implemented as a sequential state machine operative to execute machine instructions stored as machine-readable computer programs in memory60, such as one or more hardware-implemented state machines (e.g., in discrete logic, FPGA, ASIC, etc.); programmable logic together with appropriate firmware; one or more stored-program, general-purpose processors, such as a microprocessor or Digital Signal Processor (DSP), together with appropriate software; or any combination of the above.

The processing circuitry94is operatively connected to memory96operative to store machine-readable instructions, network event data, DCRs, and the like. The memory96may comprise any non-transitory machine-readable media known in the art or that may be developed, including but not limited to magnetic media (e.g., floppy disc, hard disc drive, etc.), optical media (e.g., CD-ROM, DVD-ROM, etc.), solid state media (e.g., SRAM, DRAM, DDRAM, ROM, PROM, EPROM, Flash memory, solid state disc, etc.), or the like. Those of skill in the art will understand that the processing circuitry94may itself include memory, such as registers, cache, and the like. Those of skill in the art additionally understand that virtualization techniques allow some functions nominally executed by the processing circuitry94to actually be executed by other hardware, perhaps remotely located (e.g., in the so-called “cloud”).

According to embodiments of the present invention, the memory96is operative to store, and the processing circuitry94is operative to execute, software98which when executed is operative to cause the DCR Server54to gather102measurements, events, and other data associated with a VoLTE call, pre-correlate104the data across all domains for each leg of the call, and correlate106the data between different legs of the call, as described and claimed herein.

FIG. 7illustrates example processing circuitry94, such as that in the DCR Server54ofFIG. 6. The processing circuitry94comprises a plurality of physical units. In particular, the processing circuitry94comprises a network data collection unit51, a pre-correlation unit53, and a correlation unit55. The network data collection unit51is configured to, for each leg of a VoLTE call, collect102network data associated with the call from all involved domains, using domain-specific identifiers associated with a subscriber. The pre-correlation unit52is configured to, for each leg of the call, pre-correlate104the collected data by mapping the domain-specific identifiers to a common identifier associated with a subscriber. The correlation unit54is configured to correlate106the data across all legs of the call, using the common identifiers, to generate a DCR including all events, across all domains, for all legs of the call.

FIG. 8illustrates example software98, such as that in the memory96of the DCR Server54ofFIG. 6. The software98comprises a plurality of modules. In particular, the software98comprises a network data collection module57, a pre-correlation module59, and a correlation module61. The network data collection module57is configured to, for each leg of a VoLTE call, collect102network data associated with the call from all involved domains, using domain-specific identifiers associated with a subscriber. The pre-correlation module59is configured to, for each leg of the call, pre-correlate104the collected data by mapping the domain-specific identifiers to a common identifier associated with a subscriber. The correlation module61is configured to correlate106the data across all legs of the call, using the common identifiers, to generate a DCR including all events, across all domains, for all legs of the call.

FIG. 9illustrates a plurality of modules comprising a virtual function module architecture operative to generate Detailed Call Records (DCR) for Voice over LTE (VoLTE) calls. A first module202is configured to, for each leg of a VoLTE call, collect102network data associated with the call from all involved domains, using domain-specific identifiers associated with a subscriber. A second module204is configured to, for each leg of the call, pre-correlate104the collected data by mapping the domain-specific identifiers to a common identifier associated with a subscriber. A third module206is configured to correlate106the data across all legs of the call, using the common identifiers, to generate a DCR including all events, across all domains, for all legs of the call.

Advantages of Embodiments of the Present Invention

Embodiments of the present invention present numerous advantages over prior art wireless communication network10performance monitoring systems and methods. The Detailed Call Record reports the important successful and unsuccessful system related events affecting the user experience, in correlation with radio measurement data and all the relevant signaling details. These data are collected from multiple data sources, across all domains14,20,40, for all call legs, and they are reported in time sequences with high granularity (e.g., seconds and sub-second, if needed). This enables: detecting a problem; localizing the problem (control plane, user plane, domain, node, etc.); and identifying the root cause of the problem (e.g., radio environment, signaling, user plane congestion, timing issue, or the like). These steps are obviously vital to solving the problem and similar problems in the network10.

The inventive DCR-based approach is well suited for an automatic, real-time monitoring and troubleshooting system for a large subscriber base. This enables a centralized monitoring and troubleshooting system that replaces current practice such as drive tests and manual troubleshooting activities based on node logs, probe outputs, and traces of external tools. The system collects and correlates all the available performance monitoring events in all domains of the network that are related to specific calls. These network domains include, for example, the user terminal12, radio access network14, core network20, and IMS40. This enables the system to automatically localize the problem and identify the main root cause. Performance monitoring information is correlated per session, including the originating and terminating parties of the call. Based on events, relevant data are correlated, but not aggregated, so that individual analysis is possible.

The present invention may, of course, be carried out in other ways than those specifically set forth herein without departing from essential characteristics of the invention. The present embodiments are to be considered in all respects as illustrative and not restrictive.