TECHNICAL FIELD

The present application is related to performance monitoring in communications networks.

BACKGROUND

In traditional telecommunications network operations, the conventional approach for the analysis or validation of quality of the media (or bearer) signal in a telephone call targeted for monitoring is to play out a known signal at one end of the call, record the signal at the other end, and assess the performance of the call by evaluating the quality and characteristics of the output signal, as compared to the known input signal, to determine metrics such as an objective quality score, delay, changes in the signal level or its spectral content, etc. These objective measures are checked against expected values to determine if the quality of the target call is as expected.

There are established and standardized methods to calculate such metrics, and there is a range of products from vendors such as Agilent, Ascom, Spirent, etc. that can be used to run such tests and obtain the objective metrics.

In the data communications context, there are also tools that "sniff bearer packets on live networks and analyze Session Initiation Protocol (SIP), Real-Time Transport Protocol (RTP), and RTP Control Protocol (RTCP) performance to obtain statistics such as loss, jitter, delay, etc., at the points in the network where data is collected.

With the introduction of new media-related services to traditional telecommunications, along with the ever-increasing complexity of the transport networks, there is increasing interest in validation and performance monitoring of these services.

SUMMARY

The techniques and apparatus described herein use the traffic channel for a data session (which may carry a voice call, and/or other multimedia data, and/or other data) to accumulate performance data at various points within the bearer path, from one end of the session to another. This approach allows the described tools to infer the actual topology for a data session, as well as to provide real-time monitoring of performance indicators at the nodes that serve the target data session.

Furthermore, with the techniques described herein, it is possible to take advantage of and enhance established standardized protocols devised for obtaining data and statistics that are intended to shed light on performance issues. The enhanced protocols are combined with an application designed for on-line and dynamic control of data collection, as well as the processing and interpretation of the collected data.

An example embodiment of the disclosed techniques is a method suitable for implementation in a first bearer-processing node in a multi-node bearer path for a data session. This example method begins with receiving, from another node in a first direction in the multi-node bearer path, an instruction to collect one or more performance metrics related to the data session for at least the first bearer-processing node and to send the collected performance metrics in the first direction. The method further comprises collecting and sending the one or more performance metrics in the first direction, over the bearer path, for each of one or more intervals or events during the data session.

In some embodiments, collecting and sending the one or more performance metrics in the first direction comprises collecting and sending one or more of: CPU load data for the first bearer-processing node; network bandwidth utilization of the first bearer-processing node; an alarm or notification for the first bearer-processing node; a jitter metric for a specific termination of the first bearer-processing node; a packet loss for a specific termination of the first bearer-processing node; a vocoder type and/or mode for a specific termination of the first bearer-processing node. Other metrics, useful notifications, or performance data may be sent, in various embodiments. In some embodiments, sending the one or more performance metrics in the first direction comprises labeling performance metrics for the first bearer- processing node with a node identifier for the first bearer-processing node and labeling performance metrics for a given termination of the first bearer-processing node with a termination identifier for the given termination.

In some embodiments, the method further includes sending, to a second bearer-processing node in a second direction in the multi-node bearer path, an instruction to collect one or more performance metrics related to the data session for at least the second bearer-processing node and to send the collected performance metrics to the first bearer-processing node. In some of these embodiments, the bearer- processing node subsequently receives, from the second bearer-processing node, over the bearer path, performance metrics related to the data session for at least the second bearer-processing node, and relays the received performance metrics in the first direction. This relaying may comprise combining the received performance metrics with collected performance metrics for the first bearer-processing node, before sending both in the first direction.

Another example method according to some embodiments of the techniques disclosed herein, as carried out in a first bearer-processing node in a multi-node bearer path for a data session, comprises: collecting one or more performance metrics related to the data session for the first bearer-processing node, for each of one or more intervals or events during the data session; receiving, from a second bearer- processing node in a first direction, over the bearer path, one or more performance metrics related to the data session for at least the second bearer-processing node, for one or more intervals or events; and combining the performance metrics for the first bearer-processing node and the performance metrics for the second bearer-process node and sending the combined performance metrics to a network node in a second direction. The same range of performance metrics summarized above are applicable to this example, as are the techniques summarized above for labeling performance metrics for the first and second bearer-processing nodes.

Another example method is suitable for implementation in a data-collecting node operable to communicate with a first bearer-processing node in a multi-node bearer path for a data session. This data- collecting node is also a bearer-processing node, in some embodiments. In some other embodiments, the data-collecting node is a server node distinct from any bearer -processing node in the bearer path, and the first bearer-processing node is an endpoint in the bearer path. This example method includes the step of sending, to a first bearer-processing node, an instruction to collect one or more performance metrics related to the data session for at least the first bearer-processing node and to send the collected performance metrics to the data-collecting node. The example method further includes receiving performance metrics for at least the first bearer-processing node, for each of one or more intervals or events during the data session. As in the example method summarized above, the performance metrics may comprise, for example, one or more of: CPU load data for the first bearer-processing node; network bandwidth utilization of the first bearer-processing node; an alarm or notification for the first bearer- processing node; a jitter metric for a specific termination of the first bearer-processing node; a packet loss for a specific termination of the first bearer-processing node; a vocoder type and/or mode for a specific termination of the first bearer-processing node; estimates of peer-to-peer delay for a specific termination. In some embodiments, the received performance metrics comprise performance metrics for the first bearer-processing node that are labeled with a node identifier for the first bearer-processing node and further comprise performance metrics for at least a first termination of the first bearer-processing node that are labeled with a termination identifier for the first termination.

In some embodiments, the method carried out by the data-collecting node further comprises receiving, from the first bearer-processing node, performance metrics related to the data session for a second bearer-processing node, for each of the one or more intervals or events during the data session. In some of these embodiments, the performance metrics for the first bearer-processing node and the performance metrics for the second bearer-processing node are received together, for each of the one or more intervals or events, and are distinguished from one another by node identifier labels corresponding to the first and second bearer-processing nodes, respectively. In some embodiments, the method further comprises determining a bearer -path topology for the data session, based on node identifier labels and termination labels included with the received performance metrics, for at least the first and second bearer - processing nodes.

In some of these latter embodiments, the method may further comprise generating a representation of the determined bearer-path topology for display, the representation including depictions of each bearer-processing node in the determined bearer-path topology and further including representations of one or more of the performance metrics for at least the first and second bearer- processing nodes. In some embodiments, the method includes updating the representation of the determined bearer-path topology, in response to receiving updated performance metrics and/or topology information for one or more bearer -processing nodes in the bearer path. In some of these and in some other embodiments, the method further includes determining a geographic location for each of two or more bearer-processing nodes in the determined bearer-path topology, wherein generating the representation of the determined bearer-path topology for display comprises overlaying the depictions of each bearer-processing node in the determined bearer-path topology on a depiction of a map, based on the determined geographic locations, such depiction also indicating how the nodes are connected to each other. Other embodiments disclosed herein include variations of the methods summarized above, as well as apparatus adapted to carry out any one or more of these methods and corresponding computer program products and computer-readable media.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 illustrates the relaying of accumulated performance in a bearer path from an LTE device to a data collection agent (DCA), and the transmission and relaying of instructions from a DCA to the nodes in the bearer path.

Figure 2 illustrates an example of a data session topology.

Figure 3 shows an example of termination numbering for terminations on a bearer-processing node.

Figure 4 illustrates an example descriptor block for a node' s terminations and upstream peer nodes.

Figure 5 shows an example of a node descriptor for a node in an example session topology. Figure 6 illustrates the progression of topology data through nodes.

Figure 7 is an example of the encapsulation of performance metrics.

Figure 8 illustrates an example of encapsulated control messages.

Figure 9 illustrates an example of a DCA topology and performance metric display.

Figure 10 illustrates an example of a DCA's display of geographical location and topology for in- path bearer-processing nodes.

Figure 11 is a process flow diagram illustrating an example method carried out by a bearer- processing node.

Figure 12 is a process flow diagram illustrating an example method carried out by a data- collecting node.

Figure 13 is a block diagram illustrating components of an example bearer-processing node or data-collecting node.

DETAILED DESCRIPTION

Validation of media-related services that are newly introduced to the telecommunication network, maintenance of the target quality of experience for these services, and trouble-shooting of calls and/or media sessions with poor quality can all benefit from insight and detailed information pertaining to the topology of the call/session under investigation, as well as the performance metrics and key performance indicators related to the individual nodes that comprise the call path.

As noted above, various tools and techniques have been used to evaluate end-to-end quality of voice calls placed through a telecommunications network. These techniques involving voice quality test tools are adequate when the performance characteristics fall within the expected range. Since the measured metrics reflect overall performance from one end of the call to the other, should any unexpected degradation be registered, such as an objective mean opinion score (MOS) that is too low, or an end-to- end delay that is too high, the current techniques and tools cannot provide any further insight that might help narrow down the source of the degradation, nor any clues to its location within the call path.

Typically, in such circumstances, the next step is to resort to tedious and time-consuming manual procedures to try to determine the precise identity of the nodes serving the call, followed by further manual processes to check into registers that might help understand the cause of the problem. Further, these manual undertakings are only possible if the problem is repeatable, or if the call can be kept up for further analysis. Commonly, neither of this situations is the case.

In recent years, advances have been introduced with the purpose of facilitating troubleshooting and bearer-plane analysis by enabling the collection of media streams at the media gateway nodes that are on the call path. In a proprietary solution developed by Telefonaktiebolaget L M Ericsson, this was introduced in the form of a feature known as the "Audio Capture Tool," which was developed for the use in a product for use in Code-Division Multiple Access (CDMA) wireless networks. This tool was later enhanced to provide a more user-friendly, web-enabled applications program interface (API).

The Audio Capture Tool and its enhancement in the form of "Call Insight," is an important step towards exposing useful information on the in-path performance, since it automates the process of identifying the media gateways serving a target call as well as the streaming of bearer data at these nodes. However, by the virtue of its design, this tool has a number of limitations. First, the scope of its function is strictly limited to the media gateways under the control of a Mobile Switching Center (MSC). Second, online analysis is not feasible; data retrieval is only possible off-line, following the end of the call.

Further, for a given call, there is no easy way of temporally correlating the events and data collected on one node with events and data collected at another node serving the same call. Still further, extending the tool's capabilities, e.g., for collection of new data types and arbitrary selections thereof, requires development effort both at the MSC as well as the media gateways.

As for the currently available tools that sniff traffic packets for analysis of the RTP and related protocols, in general they require the placement of probes at appropriate locations within the network, which necessitates access to these locations. While in some cases, performance data may be sent from one node to a peer node over the bearer path, e.g., using RTCP and RTCP Extended Reports (RTCP XR), it is still necessary, using these tools alone, to have probes at multiple locations to get information about all the nodes in a bearer path.

Furthermore, while these tools can be used to gain insight on performance, they may not be able to induce the in-path nodes to alter the type of information or performance metric to be transmitted, and their visibility may be constrained to the types of data generated automatically by such nodes.

To address these problems and limitations, the techniques and apparatus described herein use the traffic channel for a data session to accumulate performance data from one end of the session to another. This approach allows the described tools to infer the actual call topology, as well as to provide real-time monitoring of performance indicators at the nodes that serve the target data session. The term "data session," as used herein, should be understood broadly, and may carry audio, video, real-time data, and/or non-real-time data.

Furthermore, with the techniques described herein, it is possible to take advantage of and enhance established standardized protocols devised for obtaining data and statistics that are intended to shed light on performance issues. The enhanced protocols are combined with an application designed for on-line and dynamic control of data collection, as well as the processing and interpretation of the collected data.

RTCP and associated signaling protocols such as SIP are the means suggested as the preferred approach for carrying out several of the techniques described herein. However, it will be appreciated that it is possible to devise an entirely proprietary protocol rather than enhancing the standard ones.

The techniques and apparatus disclosed herein provide numerous advantages over previously existing tools and techniques. First, these new techniques can be used to reveal the call topology for a given data session, and can provide performance information for all of the in-path bearer -processing nodes that support the proprietary protocol or an enhanced version of the RTCP protocol. Second, the collected data can be viewed in real-time, allowing the effects of events such as handover to be observed as the events occur, along with, for example, the performance indicators that triggered the handover. Third, some embodiments of the presently disclosed techniques and apparatus allow monitoring to be performed on any type of device capable of communications, ranging from smartphones to tablets and other types of computing devices without the need to install specialized data collection/analysis software. The specific metrics obtained for a given node in the data session path can be altered selectively in real- time, allowing the focus of the analysis to be changed and different metrics to be examined dynamically as needed.

Since the data collection approaches described herein are based on a bearer-plane vehicle, such as RTCP, the disclosed techniques should have no dependence on a particular network technology or access product. Thus, these techniques can be applied, for example, to Voice-over-Long-Term-Evolution (VoLTE), Universal Mobile Telecommunications System (UMTS), North American CDMA networks, and even certain flavors of GSM networks, as long as the media-processing nodes in these systems are upgraded to support the required protocol enhancements.

Still further, since the data collection approaches described herein are based on a bearer-plane vehicle, these techniques can be used for complex call paths comprising multiple technologies, with no application-specific coordination required in the control plane other than the SIP signaling. This also means that an analysis application based on these techniques can be implemented independently from the particular releases of the networking products.

Finally, it will be appreciated that the techniques and apparatus disclosed herein are not limited in their application to the monitoring and performance of voice calls. These techniques and apparatus are instead more generally applicable to any of various types of data sessions, including voice calls, video sessions, and other data sessions.

According to some embodiments of the new techniques and apparatus disclosed herein, the monitoring and analysis of media performance metrics comprises two distinct parts: protocols and a data collection/control/display agent, hereinafter referred to as the "data collection agent" (DCA). The protocols include a set of two protocols that 1) indicate, at session set-up time, the intent to target the session for data collection, and 2) provide for the transfer of performance data as well as control signals pertaining to the collection of the data during the session. The protocols can be defined from scratch, or they can be defined in terms of enhancements of SIP and RTCP. The latter is chosen as basis for the description in this document. The DCA is a device, or an application running on a device or a server, that provides system access to a user, allowing the user to set up a session, collect the data, and perform the analysis of the collected data. The DCA also provides a user interface for viewing the analysis results as well as for the control of the data collection and display.

These two components, i.e., the protocols and the DCA, are put together in a manner that allows the data collection agent to do real-time (or offline, if desired) analysis and display of the metrics associated with a sequence of bearer-processing nodes that serve a target voice/video/data session.

Figure 1 depicts the schematic diagram for an example point-to-point voice call, where the DCA is shown at one end of the call to an LTE device. The dashed lines show the direction of relaying of accumulated performance metric data from the LTE device (on the left) towards the data collection agent (on the right), and the direction of the relay and distribution of DCA control messages. Performance data thus flows from the LTE device towards the data collection agent, in a manner where each bearer- processing node in the path receives performance data from its upstream node, and relays it to its downstream bearer-processing node after combining its own performance data and metrics. Note that as used here, "upstream" refers to the direction in which instructions flow from the DCA to bearer- processing nodes, while "downstream" refers to the direction in which performance data is relayed towards the DCA.

In some embodiments, the collection of performance metrics process takes place continually, e.g., at regular intervals, allowing the data collection agent to receive and process the combined information package, to provide a glimpse into the state of the operation of the bearer-processing nodes in the session for the time interval corresponding to the latest set of data, either in real time, or offline. The DCA can send control messages to all nodes that support the inband protocol, as shown in Figure 1.

Two types of protocols are employed to implement the accumulation and relaying of performance metrics illustrated in Figure 1. The first is used during session set-up to negotiate the establishment of the performance data traffic. The second is the protocol that defines how performance data and control instructions are carried through the nodes and acted upon.

New protocols or extensions of existing protocols may be used to establish traffic of performance data and control messages. Although it is possible to define a completely new protocol, the preferred approach (described here) is to extend the SIP protocols already defined to set up RTCP Extended Reports (RTCP XR), and to extend them to provide for the end-to-end negotiation of the protocol for collection of performance data and distribution of the control instructions. One possible implementation is to place specifications in the body of various SIP messages, in a similar manner as is used for Session Description Protocol (SDP) payloads. The new extensions proposed here can be used, in various embodiments, to achieve the following:

• The protocol will signal the desire to establish the new type of payload, such as a new extension of RTCP XR. The negotiation process also serves to identify the direction of the flow of collected metrics; each node collecting such metrics (potentially from multiple connections/ports) would relay them in the direction from which the SIP request originated.

• The new payload type will carry the implicit requirement for each node involved in the SIP negotiation to attempt to negotiate the same extension with all peer nodes associated with the same session.

• The full or partial range of performance measures and indicators to be collected may be specified.

• The specification could be defined, optionally, to specify specific modes of data collection, including, for example, data collection to be initiated for specified time intervals, or data collection to be triggered by specific events, such as when certain performance thresholds are exceeded.

• In some embodiments, the protocol will indicate the version of the performance metric collection protocol to be used.

• In some embodiments, the protocol defines parameters to provide access control.

Similarly, new protocols or extensions of existing protocols may be used to provide for collection of performance data and for distribution of control instructions. Below, a protocol is described for transfer of performance metrics from bearer-processing nodes to the data collection agent and for the transfer of control information from the data collection agent to the bearer-processing nodes. While it is possible to define a completely new protocol for this purpose, the preferred method would be to extend the capabilities of RTCP XR, especially since RTCP XR was already designed to accommodate extensions based on future needs.

As shown in Figure 1, the requirement is for each bearer -processing node in the traffic node to build up the encapsulation of performance data by adding its own performance metrics, measured over the latest time interval or for the most recent event, to the encapsulation received from the upstream node. This cumulative package is then relayed to the next bearer -processing node downstream (as determined by the direction and the termination from which the SIP negotiation for data collection originated), such that the final set of data records arriving at the data collection agent contains the full set of performance information pertaining to all participating bearer-processing nodes in the session, for a given time interval.

Note that since RTCP (including RTCP XR) is defined only for peer-to-peer exchange of information, an important part of the extension addressed here is to define how the accumulation of performance information is to take place. Furthermore, since the voice/video/data session topology, not known a priori to the data collection agent, could be complex, e.g. in the case of teleconference scenarios, and dynamic, e.g. due to handover or changes in the number of conference attendees, it is necessary to define a mechanism that can allow the data collection agent to construct the topology model for the session, and to correctly associate the collected data to their respective nodes and their terminations/ports.

One example of how to achieve this is through the topology coding techniques described below. A systematic approach is required to label the nodes involved in a voice/video/data session, as well as the connections linking them. This is needed in order for the DCA to be able to construct a model of the call topology, correctly associate performance metrics with the appropriate nodes and links, and to facilitate the transmission of control messages to the desired nodes.

A number of factors need to be considered in defining an appropriate method for encoding the topology of the session. First, bearer-processing nodes can enter and leave the topology dynamically, as the session topology changes due to call processing events, handovers, etc. Second, the knowledge of the session topology has to be built up incrementally, and updated over time, with each node contributing its own knowledge and information in such a manner that its topological relationship with upstream nodes are manifested and decoded uniquely. Even for a session with a stable topology, the data collection agent is likely to see changes in the topology information as updated performance and topology data arrive from more distant nodes in the bearer path asynchronously. Similarly, a given node in the bearer path is likely to receive topology information from the upstream nodes that may vary over time. Further, since each in- path node has a role in building up the topology information, it is necessary for a given node to present topology information to its downstream node in a way that the labels applied to the same upstream nodes and terminations remain constant over time. The continuity is required because each node has to be able to keep track of upstream nodes from one data collection epoch to the next. However, as long as the node/termination labels passed on to the downstream node retain their correspondence to the applicable (upstream) node and termination, a node does not necessarily have to use the same labels that it received from its upstream node when transmitting the built-up topology data downstream.

A bearer-processing node is connected to one or more peer nodes, and exchanges bearer data with them, via terminations. Each node in the session is connected to at least one other node. The simplest topology is a case with a single bearer-processing node, connected to the data collection agent. For the purpose of developing a systematic formulation to describe a topology, the specific pieces of information required to define a given node are:

· The node ID, i.e., a label used to identify a specific node.

• Knowledge of the peer nodes, participating in performance data collection, to which the given node is connected.

• The number of terminations defined for the node. Note that each of these terminations may or may not be connected to a peer node that participates in performance data collection.

· IDs or labels for the terminations.

Figure 2 depicts a session in which five bearer-processing nodes, nodes B, C, D, E, and F, are connected to a data collection agent, node A. In this figure, nodes A, D and F are each connected to a single peer node involved in the performance data collection activity, nodes B and E are each connected to two such peer nodes, and node C is connected to three such peer nodes. It is also observed that nodes A and F each have one set of terminations, nodes B, D, and E have two terminations each, and node C has three terminations. Figure 2 shows an incomplete topology (node D has a connection with no determined endpoint). This illustrates a situation in which there may not be sufficient information to derive the full bearer topology. The techniques described herein can be applied, nevertheless.

To facilitate the identification of the terminations of a node, a numbering scheme can be applied as shown in Figure 3. The termination that connects the node (directly or indirectly through other downstream in-path nodes) to the data collection agent is called the "primary" termination. In Figure 3, the primary termination is identified with the letter "P." The primary termination for any given node is identified as the termination to the peer node that initiated, with the given node, the negotiation for bearer performance monitoring. The other terminations of the node will be numbered in the sequence in which they are created over time. In Figure 3, terminations numbered 1, 2, 3, and 4 are illustrated.

It should be noted that for as long as a termination exists, the number assigned to it remains the same. Furthermore, if a termination is removed, its number should remain reserved and will not be assigned to any other termination. This is necessary to avoid confusion and to allow stability of the termination labels for downstream bearer-processing nodes, and ultimately, for the data collection agent. Topology information and performance metrics computed for each termination in a node, or arriving from other nodes, are accumulated and transmitted towards the DCA through the primary termination of each node.

Since, as stated above, the topology information has to be built up as the information passes through the in-path bearer-processing nodes towards the data collection agent, it is useful to define a descriptor block for a single node. An example descriptor block is shown in Figure 4, for the example of a node with four terminations. The fields in this example are defined as follows:

• "Node Descriptor" is a constant, preferably defined as a unique (unmistakable) value, and is used as a marker to identify the start of a node descriptor block.

• Node ID is a label for identification of a particular node, assigned by the node itself. In selecting a node ID, a node should attempt to base the selection on a mechanism that minimizes the probability of overlap with IDs from other nodes. This could be achieved, for example, through the use of a random component in the Node ID.

• The Node ID is followed by a set of entries, one for each of the terminations other than the primary termination.

• Each of the terminations is identified through the "Termination ID" fields, as numbered by the node. For each termination there is an entry to identify the Node ID corresponding to a peer node that delivers performance data through this particular termination. If the termination is not attached to such a node, the entry is Null.

• The concatenation of the Node ID and the Termination ID is the unique identifier of a termination in the session topology. It is used in the encapsulation of the performance data, to uniquely associate data with the specific termination of a specific node. Figure 5 illustrates a session topology where node A is the data collection agent. A Node Descriptor block for node C is shown, as an example. In this example, termination 2 on node C is identified by concatenating the node ID (C), with the termination ID (2), to get an identifier "C2."

Descriptor blocks such as those described above are transmitted by each participating bearer- processing node, along with the performance data and metrics, to the next downstream peer node. The downstream node generates its own node descriptor block and stacks it on top of the blocks it has received from the upstream node(s). In doing so, the node scans the received node descriptor blocks to determine whether its Node ID happens to have been used in the received data. If so, the node in some embodiments may continue to use its current Node ID, but will revise the overlapping Node ID(s) in the received data blocks to a new (unused) ID. Once a node defines a new ID to replace the overlapping Node ID that it found in a received data block, the same ID will be used henceforth to replace the overlapping ID in future epochs; the node will have to maintain a translation table for this purpose, as long as the overlap exists.

Figure 6 shows an example of the translation of a Node ID, due to overlap. The figure shows the flow of topology data for nodes A, B, and C, where these nodes are connected as shown in Figure 5, over consecutive time epochs. As shown in Figure 5, node C receives data (topology and performance metrics) from nodes D and E. It augments them with its own data and relays the combined data packet to node B. Node B augments the data that it receives with its own data, and passes the combined data packet to node A. Figure 6 shows the flow of data in four time intervals, or epochs. As shown in the figure, in the first epoch, nodes C, B, and A receive data from nodes E, C, and B, respectively. In the second epoch, C receives data from node D in addition to data from node E. In each epoch, each node passes on its own data in addition to data it received from upstream nodes in the previous epoch.

Figure 6 also shows that nodes E and B happen to select the same Node ID (KKKK). This overlap is detected by node B in epoch 2, when it receives the data relayed from node E for the first time. Accordingly, node B replaces all references to the node E node ID with a new one (P). This results in node A receiving information of node E with the Node ID P, rather than KKKK.

Performance metrics can be encapsulated a number of ways. One way is for each node to simply concatenate its own performance metrics with the performance metrics it receives from an upstream peer node or nodes, using the node descriptor block as a delimiter. Other manners of encapsulation are possible, of course. The key to any approach is that it allows the DCA to decode the information and attribute it correctly to the different segments of the topology. The encapsulation technique may also provide additional data that may provide useful insight.

Figure 7 provides an example of a data block that encapsulates performance metrics. Significant aspects of the illustrated data block include the following:

· The "Performance Metric Block Identifier" is a constant, preferably defined as a unique

(unmistakeable) value, and used as a marker to identify the start of a performance metric data block. It is preferable to use each encapsulation to contain the metrics from a particular node. Several blocks can be concatenated to relay data from different nodes. • The "Timestamp" represents the time of the issue of the data according to the clock of the node whose performance metric is encapsulated in a performance metric data block.

• The Node ID and the Termination ID combine to specify the particular termination to which the subsequent data belongs. If the Termination ID is null, then the subsequent data pertains to the node itself, rather than any of its terminations. Examples of such data include the CPU load, the network bandwidth utilization of a node, and specific alarms or notifications.

• The "Performance Metric Identifier" field is a pre-defined value, used to identify the type of data that follows. Examples include jitter, packet loss, signal level, vocoder type and/or mode (encoded along with the corresponding direction, in some embodiments), etc. Other examples include delay estimates and node identification data, such as IP port address, physical location, type of platform, type of function, manufacturer, etc.

• It should be noted that any given metric could either be pre-defined according to a standard, or proprietary to a given vendor. For a given node, all such fields can be concatenated together, as shown in Figure 7.

• The "Length" field identifies the length of the subsequent data field.

• The "Data" field contains the performance metrics or other useful information. The format of the data could be defined according to industry standards, or remain proprietary to a given equipment vendor.

It should be noted that in addition to performance metrics, other useful information can also be sent by each node and relayed to the DCA. One example of such data is a catalog of the metrics that can be produced and transmitted by a node and/or a node termination.

The immediately preceding discussion was focused on the collection of performance metrics and the relaying of the performance metric data towards the data collection agent (DCA). The DCA can also send instructions or requests to control the information that it requires from each and every node in the session topology. For example, it can request a catalog of available metrics from all (or specific) nodes, or issue messages to specify the particular type of data it would like to receive from a given node, or a given node termination. When appropriate, a message sent from the DCA could also carry security-related information such as passwords or encryption parameters and/or keys. Individual nodes and their terminations are addressed using the node and termination IDs that are embedded in the topology information. The topology information which, as described above, is composed of the descriptor blocks, delivers to the data collection agent a description of the topology along with unique labels for each of the nodes and terminations. The collection agent can then address a request and/or instructions to particular nodes and/or node terminations in the topology using those same labels, and send them towards the destination through all of the in-path bearer-processing nodes. Each in-path bearer-processing node removes the message layer addressed to itself, in some embodiments, and transmit the remainder towards the node(s) from which it receives performance data. The portion of the message addressed to nodes that are no longer connected to an in-path node are dropped. As discussed in further detail below, a bearer- processing node that has provided an alternate node ID for an upstream node should substitute the upstream node's actual/original node ID in such messages before passing the messages upstream.

Figure 8 depicts an example of a control block that encapsulates several control messages.

Following are descriptions of the parameters used in the illustrated example:

• The "Control Block Identifier" is a constant, preferably defined as a unique (unmistakeable) value, and used as a marker to identify the start of a Control/Instruction/Message data block.

• The timestamp reflects the time of the issue of the block, based on the DCA clock.

• The Node ID and Termination ID fields are used for unique identification of the specific node termination to which a given instruction or message is addressed. If the Termination ID is null, the instruction is meant for the identified node rather than any of its terminations. If the Node ID is null, then the message is to be distributed to all the nodes in the session topology.

• The "Control Instruction/Message" field is a pre-defined and unique constant used to specify the particular instruction transmitted by the DCA. The set of constants can be defined as a standard, or remain proprietary to a given equipment vendor.

• The "Length" field specifies the length of the subsequent data segment.

• The data field contains any data, if necessary, related to the command, instruction or the message transmitted by the DCA.

As noted above, the IDs/labels seen by the data collection agent may have been altered by an in- path node, in order to ensure uniqueness of the labels. The DCA is generally unaware of this alteration. Accordingly, DCA messages/requests that start out with an "altered" node ID must be translated back to the original label once the request arrives at the in-path node that altered the ID, using the translation table that was generated to keep track of node ID translations.

As described above, the nodes in the data path of a given session combine their own performance metrics with those received from upstream nodes, and transmit the resulting data on their primary termination towards the DCA. In specific cases where an upstream node may not support the set of protocols defined here, it is still possible for a compliant node to relay performance metrics of a non- compliant peering node. For example, a Media Gateway compliant with the protocols defined here, which may be peering with a LTE terminal that does not support the protocols, could still bundle up and relay performance metrics that the LTE terminal reports using the standardized RTCP protocol.

The Data Collection Agent (DCA) collects the performance metrics relayed from upstream bearer-processing nodes, and provides the user interface to the bearer-performance monitoring system. The task of monitoring may include some or all of the following aspects, in various embodiments:

• Collecting the data arriving from upstream nodes to be processed on-line for immediate display, or stored for subsequent off-line analysis and viewing.

• Interpretation of the topology information to reconstitute the session topology.

• Analysis of the raw data to produce meaningful plots and representations.

• Display of the processed data in the form of the call topology, along with some or all of the processed information, with the display of the processed information suitably positioned to permit visual association of performance metric representations with the originating nodes and terminations. Figure 9, discussed in further detail below, provides an example of such a display.

• Analysis of timestamps delivered by the nodes in the topology, to estimate timing relationship between the nodes' clocks.

· Mapping of nodes on geographic maps based on the identification of the nodes, and how they are connected to form the call path, as shown in figure 10.

In some embodiments, the DCA also allows the control of the analysis/monitoring session as described below:

• Control of the particular form of data representation, such as histograms versus temporal diagrams.

• Transmission of control messages to all or specific nodes within the topology to customize the parameters of the data collection, such as the selection of the type of performance metrics to be transmitted by each node, the rate of update of the selected data, etc.

• Exercise of access control, e.g., using passwords, encryption keys, etc., in cases where nodes in the session topology may require it.

• The selection of on-line vs. off-line analysis, and the selection of particular session records in the case of off-line analysis.

The DCA implementation can also support a web interface from which the collected data can be displayed in a user-friendly and device-independent manner. This web interface may consist of a web server application and an HTML web client interface, in some embodiments. The web server application accepts parameters from the web client interface specifying, for example, user access credentials, the data that should be presented, the manner that the data is to be displayed, and the time period of interest. In the case of off-line analysis, the data is then retrieved from the DCA data store, analyzed, formatted, and sent to the web client interface for display. The web server application may be implemented with any number of technologies, such as a Java servlet, and executes on a web server accessible to authorized users. The web client interface may be an HTML web page that any compliant web browser may access from a web server. It presents an access point to an authorized user, accepts specifications from the user, sends the appropriate parameters to the web server application, receives data from the web server application, and displays the data in a meaningful manner.

The design of the display format for the DCA should provide for the presentation of captured information in a comprehensive, yet intuitive manner and in a compact form, to facilitate quick understanding by the viewer. An example of such a format is shown in Figure 9. This example format provides a visual representation of the session topology, in terms of the nodes that are in the path of the bearer signal. The type and identification of each node are reflected on the node's visual representation. IP addresses and port numbers are also shown on the nodes, at points corresponding to their respective terminations.

In various embodiments, for each link connecting the nodes, any or all of the following information is displayed: • The format of the data (e.g. the applicable vocoder, and vocoder mode or bitrate) in each applicable direction. Several options may be considered for the display of this type of data. For instance, the display can show the data corresponding to the stream entering a node, or the display can show the data corresponding to the stream exiting a node. Alternatively, both can be displayed, especially if analysis of data reveals a discrepancy between the data format transmitted by one node and that received by the nodes corresponding peer.

• The data is underlined by an arrow for the purpose of linking the data format to the particular flow direction. The arrows pointing in the same direction (but between successive nodes) are displayed in alignment, to present a logically continuous flow that is clearer and less cluttered. In the same spirit, arrows along the same logical flow are displayed in the same color. Arrows signifying flows in different directions are displayed in different colors.

• Format data associated with the arrows are preferably displayed in the same color as their respective arrows.

For each node selected statistics are plotted for each port of data entry, such that:

• For each port of entry the selected statistics are displayed together, so that there is a clear distinction between the different ports.

• For each port of entry, the selected statistics are on the same side of the node as the corresponding flow-direction arrow.

• Data plots are preferably displayed in the same color (or color theme) as their corresponding arrows.

The display may start with a default set of performance metric plots, if such metrics are provided by the nodes in the call path. However, the displayed metrics are intended to be easily switched as necessary, through means such as drop-down menus in the area of the plots, or on the appropriate side of the displayed node.

In some embodiments, the DCA may also provide for a view in which the nodes in the data session topology are illustrated with respect to their geographical positions. Information about the geographic locations of the nodes may be determined from location information sent by each node along with performance metrics data, and/or from a pre-stored lookup table indexed by node identifiers, for example. Figure 10 illustrates an example of this approach - in the figure, the bearer-processing path is superimposed on a map of North America. It can be seen that in this example, the data session path is revealed to be sub-optimal, as it needlessly traverses the continent multiple times, rather than proceeding between the end-points in a straight or nearly straight line.

In view of the detailed description above of the various techniques for accumulating and evaluating performance metrics in a data session carried out through a multi-node bearer path, it will be appreciated that Figures 11 and 12 are process flow diagrams illustrating generalized methods according to some of these techniques.

Figure 11, in particular, illustrates a method suitable for implementation in a first bearer- processing node in a multi-node bearer path for a data session. (Note that "first" is used here simply to distinguish this bearer-processing node from other nodes in the path, and is not intended to suggest that this node must be the "first" node in any given ordered list of the nodes.) This example method begins, as shown at block 1110, with receiving, from another node in a first direction in the multi-node bearer path, an instruction to collect one or more performance metrics related to the data session for at least the first bearer-processing node and to send the collected performance metrics in the first direction, i.e., towards the node from which the instruction was received. As shown at block 1140, the method further comprises collecting and sending the one or more performance metrics in the first direction, over the bearer path, for each of one or more intervals or events during the data session.

As discussed above in detail, in some embodiments, collecting and sending the one or more performance metrics in the first direction comprises collecting and sending one or more of: CPU load data for the first bearer-processing node; network bandwidth utilization of the first bearer-processing node; an alarm or notification for the first bearer-processing node; a jitter metric for a specific termination of the first bearer-processing node; a packet loss for a specific termination of the first bearer-processing node; a vocoder type and/or mode for a specific termination of the first bearer-processing node; estimates of peer- to-peer delay at a specific termination of the first bearer-processing node. Other metrics or performance data may be sent, in various embodiments. In some embodiments, sending the one or more performance metrics in the first direction comprises labeling performance metrics for the first bearer-processing node with a node identifier for the first bearer-processing node and labeling performance metrics for a given termination of the first bearer-processing node with a termination identifier for the given termination.

In some embodiments, the method further includes sending, to a second bearer-processing node in a second direction in the multi-node bearer path, an instruction to collect one or more performance metrics related to the data session for at least the second bearer-processing node and to send the collected performance metrics to the first bearer-processing node. This is shown at block 1120 of Figure 11. Note that this second direction is in a direction away from the node from which the first bearer -processing node received its instruction; thus, the instruction can be forwarded, step-by-step, in the second direction, by each node in the bearer path.

As shown at block 1130, in some of these embodiments, the bearer-processing node subsequently receives, from the second bearer-processing node and over the bearer path, performance metrics related to the data session for at least the second bearer-processing node. In these embodiments, the performance metrics received from the second bearer -processing node are relayed in the first direction. This relaying may comprise adding or otherwise combining the received performance metrics to collected performance metrics for the first bearer-processing node, before sending both in the first direction as shown at block 1140.

Some embodiments of the techniques discussed above may include additional signaling, including signaling of node capabilities. For example, in some embodiments, the first bearer-processing node may send an instruction to the second bearer-processing node, the instruction requesting the second bearer-processing node to send information (e.g., a list, or "catalog") of metrics and performance data it is capable of reporting. This instruction may be relayed from a downstream node, in some embodiments. In some embodiments, the first bearer-processing node may subsequently receive the information from the second bearer-processing node; the instruction to collect and forward performance metrics may then be based on the received information.

It should be appreciated that explicit instructions to collect and forward performance metrics data are not essential - some embodiments of the techniques disclosed herein may omit these instructions. In some of these embodiments, the bearer-processing nodes may be pre-configured, e.g., with default settings or with settings negotiated during call set-up (e.g., via SIP), to always collect and send the performance metrics, or to collect and send the performance metrics under certain circumstances.

Thus, for example, an example method according to some embodiments of the techniques disclosed herein, as carried out in a first bearer-processing node in a multi-node bearer path for a data session, may comprise: collecting one or more performance metrics related to the data session for the first bearer-processing node, for each of one or more intervals or events during the data session; receiving, from a second bearer-processing node in a first direction, over the bearer path, one or more performance metrics related to the data session for at least the second bearer-processing node, for one or more intervals or events; and combining the performance metrics for the first bearer-processing node and the performance metrics for the second bearer-process node and sending the combined performance metrics to a network node in a second direction. The same range of performance metrics discussed above are applicable to this example, as are the techniques discussed above for labeling performance metrics for the first and second bearer-processing nodes.

Figure 12 illustrates another example method that is suitable for implementation in a data- collecting node operable to communicate with a first bearer-processing node in a multi-node bearer path for a data session. This data-collecting node is also a bearer-processing node, in some embodiments. In some other embodiments, the data-collecting node is a server node distinct from any bearer-processing node in the bearer path, and the first bearer-processing node is an endpoint in the bearer path. As shown at block 1210, this example method includes the step of sending, to a first bearer -processing node, an instruction to collect one or more performance metrics related to the data session for at least the first bearer-processing node and to send the collected performance metrics to the data-collecting node. As seen at block 1220, the example method further includes receiving performance metrics for at least the first bearer-processing node, for each of one or more intervals or events during the data session. The performance metrics are received over the bearer path, in embodiments or instances where the data- collecting node is in the bearer path.

As in the example method shown in Figure 11, the performance metrics here may comprise, for example, one or more of: CPU load data for the first bearer-processing node; network bandwidth utilization of the first bearer-processing node; an alarm or notification for the first bearer-processing node; a jitter metric for a specific termination of the first bearer-processing node; a packet loss for a specific termination of the first bearer -processing node; a vocoder type and/or mode for a specific termination of the first bearer-processing node. In some embodiments, the received performance metrics comprise performance metrics for the first bearer-processing node that are labeled with a node identifier for the first bearer-processing node and further comprise performance metrics for at least a first termination of the first bearer-processing node that are labeled with a termination identifier for the first termination.

In some embodiments, the method carried out by the data-collecting node further comprises receiving, from the first bearer-processing node, performance metrics related to the data session for a second bearer-processing node, for each of the one or more intervals or events during the data session. This is also shown at block 1220. In some of these embodiments, the performance metrics for the first bearer-processing node and the performance metrics for the second bearer-processing node are received together, for each of the one or more intervals or events, and are distinguished from one another by node identifier labels corresponding to the first and second bearer-processing nodes, respectively. As shown at block 1230, in some embodiments the method further comprises determining a bearer-path topology for the data session, based on node identifier labels and termination labels, included with the received performance metrics, for at least the first and second bearer-processing nodes.

In some of these latter embodiments, the method may further comprise generating a representation of the determined bearer-path topology for display, the representation including depictions of each bearer-processing node in the determined bearer-path topology and further including representations of one or more of the performance metrics for at least the first and second bearer- processing nodes. This is shown at block 1240 of Figure 12. In some embodiments, the method includes updating the representation of the determined bearer-path topology, in response to receiving updated topology information and/or performance metrics for one or more bearer-processing nodes in the bearer path. In some of these and in some other embodiments, the method further includes determining a geographic location for each of two or more bearer-processing nodes in the determined bearer-path topology, wherein generating the representation of the determined bearer-path topology for display comprises overlaying the depictions of each bearer-processing node in the determined bearer-path topology, together with how they are interconnected, on a depiction of a map, based on the determined geographic locations.

Other variations and extensions of Figure 11 and 12 are possible, as indicated by the many details provided above in connection with the discussions of Figures 1-10.

Figure 13 is a schematic illustration of a node 1300 in which a method embodying any of the presently described network-based techniques can be implemented. A computer program for controlling the node 1300 to carry out a method embodying any of the presently disclosed techniques is stored in a program storage 1330, which comprises one or several memory devices. Data used during the performance of a method embodying the present invention is stored in a data storage 1320, which also comprises one or more memory devices, one or more of which may be the same as those used for program storage 1330, in some embodiments. During performance of a method embodying the present invention, program steps are fetched from the program storage 1330 and executed by a Central Processing Unit (CPU) 1310, retrieving data as required from the data storage 1320. Output information resulting from performance of a method embodying the present invention can be stored back in the data storage 1320, or sent to an Input/Output (I/O) interface 1340, which includes a network interface for sending and receiving data to and from other network nodes, and which may also include a radio transceiver for communicating with one or more terminals, in some embodiments. The CPU 1310 and its associated data storage 1320 and program storage 1330 may collectively be referred to as a "processing circuit." It will be appreciated that variations of this processing circuit are possible, including circuits include one or more of various types of programmable circuit elements, e.g., microprocessors, microcontrollers, digital signal processors, field-programmable application-specific integrated circuits, and the like, as well as processing circuits where all or part of the processing functionality described herein is performed using dedicated digital logic.

Accordingly, in various embodiments of the invention, processing circuits, such as the CPU

1310, data storage 1320, and program storage 1330 in Figure 13, are configured to carry out one or more of the techniques described in detail above. It should be appreciated that the processing circuit, when configured with appropriate program code, may be understood to comprise several functional "modules," where each module comprises program code for carrying out the corresponding function, when executed by an appropriate processor.

Thus, for example, an apparatus adapted to carry out the method illustrated in Figure 11, or variants thereof, may be understood to comprise: a first receiving module for receiving, from another node in a first direction in the multi-node bearer path, an instruction to collect one or more performance metrics related to the data session for at least the first bearer -processing node and to send the collected performance metrics in the first direction; a collecting module for collecting one or more performance metrics, for each of one or more intervals or events during the data session; a first sending module for sending, to a second bearer-processing node in a second direction in the multi-node bearer path, an instruction to collect one or more performance metrics related to the data session for at least the second bearer-processing node and to send the collected performance metrics to the first bearer-processing node; a second receiving module for receiving, from the second bearer-processing node, performance metrics related to the data session for at least the second bearer-processing node; and a second sending module for sending the collected one or more performance metrics and for relaying the received performance metrics in the first direction.

Similarly, an apparatus configured to carry out the method of Figure 12, or variants thereof, may be understood to comprise: a sending module for sending, to a first bearer-processing node, an instruction to collect one or more performance metrics related to the data session for at least the first bearer- processing node and to send the collected performance metrics to the data-collecting node; a receiving module for receiving performance metrics for at least the first bearer-processing node, for each of one or more intervals or events during the data session; a topology determining module for determining a bearer- path topology for the data session, based on node identifier labels and termination labels, included with the received performance metrics, for at least the first and second bearer-processing nodes; and a display generation module for generating a representation of the determined bearer-path topology for display, the representation including depictions of each bearer-processing node in the determined bearer -path topology and further including representations of one or more of the performance metrics for at least the first and second bearer-processing nodes.

Of course, it will be appreciated that not all of the steps of a given technique are necessarily performed in a single microprocessor or, equivalently, that all of the functional modules in a given embodiment are implemented with a single processing circuit.

It will be further appreciated that various modifications may be made to the above described embodiments without departing from the scope of the present invention. The specific embodiments described above should therefore be considered exemplary rather than limiting the scope of the invention. Because it is not possible, of course, to describe every conceivable combination of components or techniques, those skilled in the art will appreciate that the present invention can be implemented in other ways than those specifically set forth herein, without departing from essential characteristics of the invention. The present embodiments are thus to be considered in all respects as illustrative and not restrictive.

In the present description of various embodiments of present inventive concepts, it is to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of present inventive concepts. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which present inventive concepts belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense expressly so defined herein.

As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. Well-known functions or constructions may not be described in detail for brevity and/or clarity. The term "and/or" includes any and all combinations of one or more of the associated listed items.

It will be understood that although the terms first, second, third, etc. may be used herein to describe various elements/operations, these elements/operations should not be limited by these terms. These terms are only used to distinguish one element/operation from another element/operation. Thus a first element/operation in some embodiments could be termed a second element/operation in other embodiments without departing from the teachings of present inventive concepts. The same reference numerals or the same reference designators denote the same or similar elements throughout the specification.

As used herein, the terms "comprise", "comprising", "comprises", "include", "including", "includes", "have", "has", "having", or variants thereof are open-ended, and include one or more stated features, integers, elements, steps, components or functions but does not preclude the presence or addition of one or more other features, integers, elements, steps, components, functions or groups thereof.

Furthermore, as used herein, the common abbreviation "e.g.", which derives from the Latin phrase "exempli gratia," may be used to introduce or specify a general example or examples of a previously mentioned item, and is not intended to be limiting of such item. The common abbreviation "i.e.", which derives from the Latin phrase "id est," may be used to specify a particular item from a more general recitation.

Example embodiments have been described herein, with reference to block diagrams and/or flowchart illustrations of computer-implemented methods, apparatus (systems and/or devices) and/or computer program products. It is understood that a block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by computer program instructions that are performed by one or more computer circuits. These computer program instructions may be provided to a processor circuit of a general purpose computer circuit, special purpose computer circuit, and/or other programmable data processing circuit to produce a machine, such that the instructions, which execute via the processor of the computer and/or other programmable data processing apparatus, transform and control transistors, values stored in memory locations, and other hardware components within such circuitry to implement the functions/acts specified in the block diagrams and/or flowchart block or blocks, and thereby create means (functionality) and/or structure for implementing the functions/acts specified in the block diagrams and/or flowchart block(s).

These computer program instructions may also be stored in a tangible computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instructions which implement the functions/acts specified in the block diagrams and/or flowchart block or blocks. Accordingly, embodiments of present inventive concepts may be embodied in hardware and/or in software (including firmware, resident software, micro-code, etc.) running on a processor such as a digital signal processor, which may collectively be referred to as "circuitry," "a module" or variants thereof.

It should also be noted that in some alternate implementations, the functions/acts noted in the blocks may occur out of the order noted in the flowcharts. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality/acts involved. Moreover, the functionality of a given block of the flowcharts and/or block diagrams may be separated into multiple blocks and/or the functionality of two or more blocks of the flowcharts and/or block diagrams may be at least partially integrated. Finally, other blocks may be added/inserted between the blocks that are illustrated, and/or blocks/operations may be omitted without departing from the scope of inventive concepts. Moreover, although some of the diagrams include arrows on communication paths to show a primary direction of communication, it is to be understood that communication may occur in the opposite direction to the depicted arrows.

Many variations and modifications can be made to the embodiments without substantially departing from the principles of the present inventive concepts. All such variations and modifications are intended to be included herein within the scope of present inventive concepts. Accordingly, the above disclosed subject matter is to be considered illustrative, and not restrictive, and the appended examples of embodiments are intended to cover all such modifications, enhancements, and other embodiments, which fall within the spirit and scope of present inventive concepts. Thus, to the maximum extent allowed by law, the scope of present inventive concepts are to be determined by the broadest permissible interpretation of the present disclosure, and shall not be restricted or limited by the foregoing detailed description.