WO2011115625A1

WO2011115625A1 - Method and apparatus pertaining to assessing ordinary end-to-end performance of a mobile data network

Info

Publication number: WO2011115625A1
Application number: PCT/US2010/027941
Authority: WO
Inventors: Tengywe E. Hong
Original assignee: Velocent Systems Incorporated
Priority date: 2010-03-19
Filing date: 2010-03-19
Publication date: 2011-09-22

Abstract

These teachings provide for facilitating the automatic assessment of ordinary end-to-end performance of a mobile data network. This generally comprises receiving (101) packets as comprise a packet stream for the data network and then identifying (102) the packets that comprise mobile session data packets that relate to TCP-based end-to-end measurements for at least one selected delivery component. For each of at least substantially all of the selected mobile session data packets, these teachings then provide for automatically determining (103) a plurality of TCP parameters and using (104) those TCP parameters to develop corresponding end-to-end mobile data network measurements. Those measurements can then be stored (105) and, if desired, processed (106) to provide aggregated measurements as regards both user mobile session end-to-end performance and end-to-end mobile data network performance as pertains to the plurality of selected mobile session data packets.

Description

METHOD AND APPARATUS PERTAINING TO ASSESSING ORDINARY END-TO- END PERFORMANCE OF A MOBILE DATA NETWORK

Technical Field

[0001] This invention relates generally to performance assessment for data networks and more particularly to performance assessment for mobile data networks.

Background

[0002] Data networks, and in particular mobile data networks, are known in the art. A mobile data network serves to permit mobile end users (and their communication platforms) to communicate (typically wirelessly) while moving or at least without being physically tethered to a specific geographic point. Such networks are increasingly characterized by a large number of infrastructure elements including but not limited to various service delivery components such as base stations, gateways, routers, and so forth. Many of these networks move at least some of their data through the network as data packets and often while making use of the well-known Transmission Control Protocol (TCP).

[0003] Administering such a network involves, at the least, keeping the constituent infrastructure elements in good working order. Such administration can also encompass growth of the network to extend its range and/or its data-handling capabilities. These tasks, in turn, benefit from information regarding the existence and location of weak performance within the network. Such information can avoid expenditures and efforts that ultimately fail to fully remedy a given weakness or fully leverage a growth opportunity.

[0004] The prior art uses monitoring systems to attempt to develop such information.

These monitoring systems typically develop their performance measurements using network control signaling messages (i.e., the signaling messages that permit one network component to communicate with another network component with respect to management of traffic flow there between). For example, request success and request failure results or transactional latencies as pertain to network or application signaling messages often serve in these regards. Unfortunately, such approaches typically do not produce end-to-end measurements that genuinely reflect the actual end-user's experienced quality in significant part because such information often only pertains to the limited pathway between two network components that are not situated at opposing ends of the network. Furthermore, such approaches also typically lack an ability to produce an end-to-end view of mobile data network performance. (As used herein, "end-to-end" will be understood to refer to the communication pathway from a discrete point at one end of the network to a discrete point at the opposing end of the network. In an illustrative example where the pathway begins at one end with a mobile platform and then passes serially through a cell edge element, a cell site, various network elements, routers and/or switches, and finally to a server, the mobile platform comprises one "end" while the server comprises the opposing "end .)

[0005] Many of these prior art approaches make use of passive monitoring schemes and employ passive probes and/or network element performance counters. Such systems tend to focus on measuring network performance and user experience quality with respect to a particular mobile data network interface and lack an ability to directly measure end-to-end network performance. These approaches also tend to focus on measuring network performance and user experience quality during session creation and tear-down. The latter activities typically comprise only a small part of overall network performance, however, and hence do not always fairly represent the desired scope of functionality.

[0006] In some cases, these prior art approaches seek to indirectly determine end-to-end network performance by aggregating numerous disjointed data sources (by measuring, for example, the time it takes for signaling messages to return a response on specific links) from diverse and segmented protocol layers. Such inputs are typically difficult to correlate and calibrate into consistent, understandable, and reliable end-to-end performance indicators. In other cases, these prior art approaches seek to measure network performance by measuring application content download time. While a useful approach in some application settings, such a methodology cannot reliably parse or factor in the wide-ranging set of variables that can produce large variances in actual mobile network content delay or user perceived speed (many of which may, in fact, have nothing to do with network performance per se).

[0007] In yet other cases, these prior art approaches employ simulated users. These simulated users inject simulated traffic into the network with the monitored results serving as the basis for metricizing network performance. This simulated and sampled activity, however, again often fails to truly represent the actual user experience.

Brief Description of the Drawings

[0008] The above needs are at least partially met through provision of the method and apparatus pertaining to assessing ordinary end-to-end performance of a data network described in the following detailed description, particularly when studied in conjunction with the drawings, wherein:

[0009] FIG. 1 comprises a flow diagram as configured in accordance with various embodiments of the invention;

[0010] FIG. 2 comprises a block diagram as configured in accordance with various embodiments of the invention;

[0011] FIG. 3 comprises a block diagram as configured in accordance with various embodiments of the invention;

[0012] FIG. 4 comprises a block diagram as configured in accordance with various embodiments of the invention;

[0013] FIG. 5 comprises a flow diagram as configured in accordance with various embodiments of the invention;

[0014] FIG. 6 comprises a flow diagram as configured in accordance with various embodiments of the invention; and

[0015] FIG. 7 comprises a flow diagram as configured in accordance with various embodiments of the invention.

[0016] Elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions and/or relative positioning of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of various embodiments of the present invention. Also, common but well-understood elements that are useful or necessary in a commercially feasible embodiment are often not depicted in order to facilitate a less obstructed view of these various embodiments of the present invention. Certain actions and/or steps may be de<=™heH nr Henir.tfiH in a narrir.nlar order of occurrence while those skilled in the art will understand that such specificity with respect to sequence is not actually required. The terms and expressions used herein have the ordinary technical meaning as is accorded to such terms and expressions by persons skilled in the technical field as set forth above except where different specific meanings have otherwise been set forth herein.

Detailed Description

[0017] Generally speaking, pursuant to these various embodiments, these teachings provide for facilitating the automatic assessment of ordinary end-to-end performance of a mobile data network. This generally comprises receiving packets as comprise a packet stream for the data network and then identifying the packets that comprise mobile session data packets that relate to TCP-based end-to-end measurements for at least one selected delivery component (such as, for example, a given cell, cell site, network element, interface card, router, switch or the like as comprises a relevant constituent component of the network). For each of at least substantially all of the selected mobile session data packets, these teachings then provide for automatically determining a plurality of TCP parameters and using those TCP parameters to develop corresponding end-to-end mobile data network measurements. Those measurements can then be stored and, if desired, processed to provide aggregated measurements as regards end-to-end mobile data network performance as pertains to the plurality of selected mobile session data packets.

[0018] The applicant has determined that the TCP layer is the most prevalent transport layer that ensures reliable end-to-end delivery of data between, for example, a mobile platform and a counterpart server. By monitoring TCP behavior (in terms, for example, of retransmissions, congestion, latency, and throughput) these teachings significantly leverage TCP behavior metrics to effectively measure end-to-end performance. This same monitoring can also facilitate discovering TCP bottlenecks as correspond to particular service delivery components that comprise the TCP end-to-end path.

[0019] By one approach, identifying the packets that comprise mobile session data packets that relate to TCP-based end-to-end measurements for at least one selected delivery component can comprise segregating, for each such selected delivery component, the mobile session data packets from the packets from both non-mobile sessions and mobile session signaling packets. This can further comprise using mobile session identifiers as correspond to the selected mobile session data packets to obtain mobile session and TCP connection context information.

[0020] The aforementioned determination of TCP parameters can comprise using such mobile session and TCP connection context information to derive measurements for one or more of (and in some settings all of) TCP connection setup round-trip time, TCP data packet round- trip time, TCP retransmission ratio information, and TCP congestion events. These teachings will also accommodate using mobile session identifiers as correspond to each of the selected mobile session data packets to determine whether a TCP connection for each of the selected mobile session data packets has been dropped by a mobile unit as corresponds to the mobile session data packet.

[0021] As noted above, these teachings will also accommodate providing aggregated measurements as pertain to these findings. By one approach this can comprise providing an aggregated measurement as regards user session TCP end-to-end performance and/or as regards service delivery component TCP end-to-end performance.

[0022] So configured, these teachings are able to utilize connection tracking, state and event-based measurements, and bottom-up correlation of network performance and user quality of experience to permit development of an accurate, consistent, and cost-effective indication of end-to-end network and user experience quality. These results are achievable using only a single point of network operability (i.e., a single link) as versus aggregations of diverse and disjointed link performance indicators from multiple links within the network. These teachings are particularly useful when that single link comprises a most-aggregated point of the network (such as a link that is functionally close or adjacent to the network's gateway).

[0023] By using TCP end-to-end packet latency in some application settings, as versus application content latency as tends to characterize many prior art approaches, these teachings yield performance metrics that tend to be considerably more valid and useful. Application content latency often fails to provide meaningful results because there is nothing standardized to measure. This being so, thousands of applications all running application extensions on other servers frankly represent an unmanageable challenge. Packets are the standardized lowest common denominator that allows for statistical analysis to isolate outliers. More particularly, TCP is the end-to-end transport layer for the application and the ability to monitor the underlying transport for the application provides more general, straightforward, and granular metrics than, for example, individual application layer monitoring. A similar benefit attains from using a large sample of live traffic rather than a limited sample of simulated traffic.

[0024] These and other benefits may become clearer upon making a thorough review and study of the following detailed description. Referring now to the drawings, and in particular to FIG. 1, an illustrative process that is compatible with many of these teachings will now be presented. Generally speaking, this process 100 serves to facilitate automatically assessing ordinary end-to-end performance of a mobile data network. This process 100 can itself be carried out via a corresponding control circuit as described below.

[0025] Pursuant to one step 101, this process 100 receives packets as comprise a packet stream for the data network. Packets comprise a well-understood area of practice and endeavor and require no further elaboration here though certain specifics will be presented below where appropriate and for the sake of illustration by example. It is not necessary that this packet stream represent only a single connection or session; in fact, these teachings benefit when this packet stream comprises an aggregation of many such connections/sessions. By one approach, this packet stream essentially represents essentially the totality of all connections/sessions as are being supported by the network at a given moment in time. Such a packet stream can be often obtained, for example, by tapping into the packet stream as corresponds to the network's gateway.

[0026] Generally speaking, it may be preferred for many application settings that these received packets comprise mirrored packets. Such a practice can avoid unduly interfering with the transit time of the original packets themselves.

[0027] By one approach, this step 101 can represent receiving such packets on only a sampled or sporadic basis. Generally speaking, however, these teachings are able to handle essentially all packets as may flow on a continuous basis. In such a case the overall results will typically be better for representing a complete or a nearly-complete view of packet movement through the network.

[0028] In a following step 102, this process 100 identifies the packets (from this packet stream) that comprise mobile session data packets that relate to TCP-based end-to-end measurements for at least one selected delivery component to thereby provide selected mobile session data packets. Particularly in application settings where the network supports both mobile and non-mobile sessions, this step 102 can comprise segregating, for each of the selected delivery components, the mobile session data packets from, for example, non-mobile session packets as well as mobile session signaling packets.

[0029] Next, at step 103, the process 100 automatically determines, for each of at least substantially all of the selected mobile session data packets, a plurality of TCP parameters. Again, and generally speaking, these teachings will often best serve the desired ends by making such a determination for all of the selected mobile session data packets. That said, a lesser percentage than one hundred percent might serve if there is some reason to provide for such a dispensation. By way of illustration, for example, ninety-nine percent of all such packets might be so assessed, or ninety-five percent. In some cases, and possibly depending upon a corresponding required degree of certainty or latitude in these regards, even a lesser amount, such as only eighty percent, might suffice. The particular percentage assessed will often depend to some extent upon the needs and/or opportunities as tend to characterize a given application setting.

[0030] By one approach, this determination of TCP parameters can comprise using mobile session identifiers as correspond to each of the selected mobile session data packets to obtain mobile session and TCP connection context information (the latter being well known and understood in the art). More particularly, such mobile session and TCP connection context information can be used by this process 100 to derive corresponding measurements for one or more of:

[0031] TCP connection setup round-trip time;

[0032] TCP data packet round-trip time;

[0033] TCP retransmission ratio information; and/or [0034] TCP congestion events.

[0035] By one approach, and if desired, this determination of TCP parameters can (in lieu of the foregoing or in combination therewith) comprise using mobile session identifiers for each of the selected mobile session data packets to determine whether a TCP connection for each of the selected mobile session data packets has been dropped by a mobile unit as corresponds to that mobile session data packet, respectively.

[0036] In any event, at step 104 this process 100 then uses these TCP parameters to develop corresponding end-to-end mobile data network measurements (such as, for example, an aggregation of measurements as pertain to selected delivery components that comprise the TCP path from one end to the other). Numerous possibilities exist in these regards and a number of specific illustrations examples are provided further below. The process 100 then, at step 105, stores these end-to-end data network measurements.

[0037] For some application purposes, the above may suffice. For many application settings, however, this process 100 can optionally but beneficially, at step 106, process this stored measurements information to provide aggregated measurements as regards end-to-end mobile data network performance as pertains to a plurality of the selected mobile session data packets. By one approach, for example, this can comprise providing one or more aggregated measurements as regard user session TCP end-to-end performance. By another approach, in lieu of the foregoing or in combination therewith, this can comprise providing one or more aggregated measurements as regard service delivery component TCP end-to-end performance.

[0038] The above-described processes are readily enabled using any of a wide variety of available and/or readily configured platforms, including partially or wholly programmable platforms as are known in the art or dedicated purpose platforms as may be desired for some applications. Referring now to FIG. 2, an illustrative approach to such a platform will now be provided.

[0039] This platform 200 comprises a control circuit 201 that operably couples to a network interface 202 and to a memory 203. The network interface 202 serves to receive the aforementioned packet stream. Such network interfaces are well known in the art. The specifics of a particular network interface will of course vary to suit the requirements of a given application setting. This is well within the competency of a skilled practitioner. The memory 203 can comprise a single component as suggested by the illustration or can comprise a plurality of components (in which case the illustration can be viewed as presenting a logical depiction of the platform). In the latter case the memory 203 can be comprised of discrete memory components that are all local to the platform or where some or all of the memory components can be located remotely from the platform, as desired. Such architectural options are well understood in the art.

[0040] The control circuit 201 itself can comprise a fixed-purpose (even hard- wired) platform or can comprise a partially or wholly-programmable platform as desired. In any case, the control circuit 201 is configured to carry out one or more of the steps, actions, and/or functions described herein as desired.

[0041] Such an apparatus 200 may be comprised of a plurality of physically distinct elements as is suggested by the illustration shown in FIG. 2. It is also possible, however, to view this illustration as comprising a logical view, in which case one or more of these elements can be enabled and realized via a shared platform. It will also be understood that such a shared platform may comprise a wholly or at least partially programmable platform as are known in the art.

[0042] For the sake of illustration and without intending any particular limitations, more particular examples in these regards will now be presented.

[0043] As shown in FIG. 3, the aforementioned control circuit 202 can include a mobile data session and TCP connection manager 302, a mobile data session TCP end-to-end measurement generator 308, a user session TCP end-to-end performance indicator aggregator 313, and a service delivery component TCP end-to-end performance indicator aggregator 314. The mobile data session and TCP connection manager 302 receives the aforementioned mobile data network packet stream 301 and processes those incoming packets (for at least a given reporting interval of each mobile data session and its corresponding TCP connections) on a per-mobile-data-session basis.

[0044] FIG. 4 provides a more detailed view of the functionality of the mobile data session and TCP connection manager 302. In this illustrative example, a mobile packet inspector 402 receives the incoming mobile data network packet stream 301 and inspects this stream in order to separate the packets into two categories; non-mobile session packets (which are automatically discarded 304) and mobile session packets. The latter are routed to a mobile session manager 402.

[0045] The mobile session manager 402 tracks mobile user session states and events.

This includes the creation, updating, and deletion of temporary mobile session contexts 404 in a temporary mobile session contexts real-time database 405. Using this approach, each mobile session context can include the mobile session context states (regarding, for example, context creation and deletion), events (regarding, for example, context updates), and the context traffic characteristics (regarding, for example, data volumes, context duration, context air time, and so forth). The mobile session manager 402 then forwards only the mobile session data packets to a TCP connection manager 403 while discarding any mobile session signaling packets.

[0046] The TCP connection manager 403, in turn, processes the mobile session data packets to track and manage the TCP end-to-end connections and cross-reference these with the mobile session context real-time database 405. The TCP connection manager 403 then passes the mobile session data packets as the output 307 to TCP connection manager 302 and the mobile session and TCP connection contexts as the output 305 to Mobile session and TCP connection contexts database 306.

[0047] Referring again momentarily to FIG. 3, the aforementioned mobile session TCP end-to-end measurement generator 308 receives that output 307 of the mobile data session and TCP connection manager 302. Generally speaking, the measurement generator 308 accesses the mobile session and corresponding TCP connection contexts 309 and processes the mobile session data packets to produce user session and corresponding TCP end-to-end measurements 311 as its output. This measurement generator 308 then eventually discards 304 these packets 310 subsequent to this processing activity.

[0048] Referring now to FIG. 5, further specifics with respect to the functionality of the mobile session TCP end-to-end measurement generator 308 will be provided. For each of the incoming mobile session data packets 307 this process 500 determines 501 whether the packet relates to one or more TCP end-to-end measurements of interest. When false, the packet is discarded 502. When true, the process 500 then obtains 503 the mobile session identifier from the packet's mobile session layer. The process 500 then uses this mobile session identifier to fetch 504 the mobile session and TCP connection contexts from the aforementioned mobile session and TCP connection contexts database 306.

[0049] These informational elements (i.e., the mobile session data packet, the mobile session context, and the TCP connection context) for a particular mobile data session are then processed 505 to determine corresponding measurements of interest. In this particular illustrative example this includes measuring 506 TCP connection set-up round-trip time, measuring 507 TCP data packet round-trip time, measuring 508 the TCP retransmission ratio, measuring 509 the number of TCP congestion events, and checking 510 whether the TCP connection has been dropped at the mobile platform.

[0050] These measurements for active mobile sessions are then saved 511 to temporary data storage 512 until they are eventually (for example, on some regular basis such as every five minutes) output 513 as the output 311 of the mobile data session TCP end-to-end measurement generator 308. As noted earlier, upon concluding this processing, the measurement generator 308 discards 502 the processed packets as those packets are no longer required.

[0051] Referring again to FIG. 3, a user session TCP end-to-end performance indicator aggregator 313 receives the aforementioned output 311. Generally speaking, this aggregator 313 takes the user session and corresponding TCP end-to-end measurements and cross references this information to a network topology database 315 to produce user session records and their corresponding TCP end-to-end performance indicators 316. The latter, which include the end-to- end network topology path as corresponds to the relevant user session, are then saved in a user session key performance indicator database 317.

[0052] Referring now to FIG. 6, further specifics with respect to the functionality of the user session TCP end-to-end performance indicator aggregator 313 will be provided. In this example, the mobile session measurements and the corresponding TCP end-to-end measurements 311 are received, and this process 600 aggregates 601, for each user's data session, the periodic user mobile data session control plane measurements into state and event- based user session records. By one approach, this comprises delineating the user session into sub-session records by states or events as pertain to the user's mobile activity (such as, by way of example, session volume and/or duration, user mobility (such as hand-off from one network element to another network element)).

[0053] This process 600 then reads 602 in the network topology 603 and uses that information to derive the user session's service delivery components (such as, for example, handset type or network elements, switches, routers, line cards, or the like that are in relevant play). This information, in turn, is included in each of the aforementioned user sub-session records.

[0054] This process 600 then undertakes 604 a number of calculations and/or aggregation activities. In this illustrative example, these undertakings 604 include (but are not limited to):

[0055] calculating 605 the average TCP connection set-up round-trip time key performance indicator of each user's sub-session records;

[0056] calculating 606 the average TCP data packet round-trip time key performance indicators of each user's sub-session records;

[0057] calculating 607 the average percentage of TCP retransmission key performance indicators of each user's sub-session records;

[0058] aggregating 608 the number of TCP congestion event key performance indicators of each user sub-session records; and/or

[0059] aggregating 609 the number of TCP connection drop key performance indicator at the mobile of each user's sub-session records.

[0060] This process 600 then saves 610 the mobile user's sub-session records and their corresponding TCP end-to-end key performance indicators to a temporary data storage 512. Then-current active mobile user sub-session records and their corresponding TCP end-to-end key performance indicators are then read and outputted 611 as the user session TCP end-to-end performance indicator aggregator 313 output 316. By one approach this can be done on a periodic basis (such as every five minutes or so). By one approach, this step 611 can further provide for outputting sub-session records for terminated user sessions as well, following which their last sub-session records are deleted from the temporary data storage 512. [0061] Referring again to FIG. 3, a service delivery component TCP end-to-end performance indicator aggregator 314 also receives the aforementioned user session and corresponding TCP end-to-end measurements 31 1. Generally speaking, this aggregator 314 also cross references to the network topology database 315 and produces service delivery component records and corresponding TCP end-to-end key performance indicators 318 that are stored in a service delivery component key performance indicator database 319.

[0062] Referring now to FIG. 7, further specifics with respect to the functionality of the service delivery component TCP end-to-end performance indicator aggregator 314 will be provided. In this example, the mobile session measurements and the corresponding TCP end-to- end measurements 311 are received, and this process 700 periodically (for example, every five minutes) extracts 701 all service delivery components (such as handset type, serving cell, serving cell site, network element(s), router(s), switches(s), and so forth) from the user session's measurements.

[0063] This process 700 then reads 702 in the network topology 603 and uses that information to derive additional service delivery components (such as, for example, handset type names, cell and cell site names, network element names, network element line card names, and the switches and routers that are in the user's data session path) from each user data session measurement.

[0064] A number of calculation and aggregation activities 703 are then carried out. In this illustrative example, these include:

[0065] Calculating 704 the average TCP connection set-up round-trip time key performance indicator of the service delivery components obtained from the preceding steps. The underlying data for the service delivery component calculation is from all mobile users' data sessions within the same measurement time interval that are associated with the same service delivery component. Accordingly, this calculation aggregates (here, by averaging) the associated sessions' TCP connection set-up round-trip time into the resulting averaged TCP connection setup round-trip time key performance indicator.

[0066] Calculating 705 the average TCP data packet round-trip time key performance indicator of the service delivery components obtained from the preceding steps. The underlying data for this service delivery component-based calculation is from all mobile users' data sessions within the same measurement time interval that are associated with the same service delivery component. Accordingly, this calculation aggregates (here, by averaging) the associated sessions' TCP data packet round-trip time into a resultant averaged TCP data packet round-trip time key performance indicator.

[0067] Calculating 706 the average percent of TCP retransmission key performance indicator of the service delivery components obtained from the preceding steps. The underling data for this service delivery component-based calculation is from all mobile users' data sessions within the same measurement time interval that are associated with the same service delivery component. Accordingly, this calculation aggregates (here, by averaging) the associated sessions' percent of TCP retransmission into a resultant averaged percent of TCP retransmission key performance indicator.

[0068] Calculating 707 the total number of TCP congestion event key performance indicator of the service delivery components obtained from the preceding steps. The underling data for this service delivery component-based calculation is from all mobile users' data sessions within the same measurement time interval that are associated with the same service delivery component. Accordingly, this calculation aggregates (here, by summing into an aggregated total) the associated sessions' number of TCP congestion events into a resultant total number of TCP congestion events key performance indicator.

[0069] And calculating 708 the total number of TCP connection drop key performance indicator of the service delivery components obtained from the preceding steps. The underling data for this service delivery component-based calculation is from all mobile users' data sessions within the same measurement time interval that are associated with the same service delivery component. Accordingly, this calculation aggregates (here, by summing into an aggregated total) the associated sessions' TCP connection drops into a resultant total number of TCP connection drops key performance indicator.

[0070] These results are then save 709 to a corresponding temporary data store 710 on an occasional basis. This can comprise a regular, periodic basis (such as, for example, every five minutes). Then, and again on an occasional basis (such as every five minutes), this information regarding current per-service delivery component records and their corresponding TCP end-to- end key performance indicators are output 71 1 from the aforementioned storage 710 and provided as the aforementioned output 318 of this aggregator 314. This step can further include, if desired, deleting the outputted records from the temporary data store 710.

[0071] It will be appreciated that these teachings will readily accommodate leveraging the TCP E2E protocol when monitoring a mobile network. In particular, these teachings will permit E2E monitoring at a single point within such a network via the packets of the TCP E2E protocol. This, in turn, permits aggregating the TCP E2E protocol measurements from all user data sessions into user session E2E performance indicators and aggregating the TCP E2E protocol measurements from all user data sessions and mobile network topology data into mobile network service delivery component E2E performance indicators.

[0072] So configured, these teachings provide a unique and effective way to gain unprecedented visibility regarding network performance and the user's data session quality with a high degree of consistency and accuracy. These teachings can be readily deployed in conjunction with many legacy networks and hence can serve to greatly leverage the presence of such existing systems while also serving to facilitate the future viability of such systems. These teachings are also highly scalable and can be successfully employed with a wide variety of networks of varying sizes and complexity and in conjunction with a wide variety of service delivery components.

[0073] Those skilled in the art will recognize that a wide variety of modifications, alterations, and combinations can be made with respect to the above described embodiments without departing from the spirit and scope of the invention, and that such modifications, alterations, and combinations are to be viewed as being within the ambit of the inventive concept.

Claims

We claim:

1. A method to facilitate automatically assessing ordinary end-to-end performance of a mobile data network comprising:

- receiving packets as comprise a packet stream for the data network;

further characterized by:

- identifying the packets that comprise mobile session data packets that relate to

Transmission Control Protocol (TCP)-based end-to-end measurements for at least one selected delivery component to provide selected mobile session data packets;

- for each of at least substantially all of the selected mobile session data packets,

automatically determining a plurality of Transmission Control Protocol (TCP) parameters;

- using the TCP parameters to develop corresponding end-to-end mobile data network measurements;

- storing the end-to-end data network measurements.

2. The method of claim 1, wherein identifying the packets that comprise mobile session data packets that relate to Transmission Control Protocol (TCP)-based end-to-end measurements is further characterized by segregating, for each of the at least one selected delivery component, the mobile session data packets from both non-mobile session packets and mobile session signaling packets.

3. The method of claim 1 wherein determining a plurality of TCP parameters is further characterized by using mobile session identifiers as correspond to each of the selected mobile session data packets to obtain mobile session and TCP connection context information.

4. The method of claim 3 wherein determining a plurality of TCP parameters is further characterized by using the mobile session and TCP connection context information to derive measurements for at least some of:

- TCP connection setup round-trip time; - TCP data packet round-trip time;

- TCP retransmission ratio information;

- TCP congestion events.

5. The method of claim 4 wherein deriving the measurements is further characterized by deriving measurements for each of:

- TCP connection setup round-trip time;

- TCP data packet round-trip time;

- TCP retransmission ratio information;

- TCP congestion events.

6. The method of claim 5 wherein determining a plurality of TCP parameters is further characterized by using mobile session identifiers as correspond to each of the selected mobile session data packets to determine whether a TCP connection for each of the selected mobile session data packets has been dropped by a mobile unit as corresponds to the mobile session data packet.

7. The method of claim 1 further characterized by processing the stored end-to-end mobile data network measurements to provide an aggregated measurement as regards end-to-end mobile data network performance as pertains to a plurality of the selected mobile session data packets.

8. The method of claim 7 wherein providing the aggregated measurement is further characterized by providing an aggregated measurement as regards user session TCP end-to-end performance.

9. The method of claim 7 wherein providing the aggregated measurement is further characterized by providing an aggregated measurement as regards service delivery component TCP end-to-end performance.

10. An apparatus to facilitate automatically assessing ordinary end-to-end performance of a data network comprising: - means for receiving packets as comprise a packet stream for the mobile data network; wherein the apparatus is further characterized by:

- means for identifying the packets that comprise mobile session data packets that relate to Transmission Control Protocol (TCP)-based end-to-end measurements for at least one selected delivery component to provide selected mobile session data packets;

- means for automatically determining a plurality of Transmission Control Protocol (TCP) parameters for each of at least substantially all of the selected mobile session data packets;

- means for using the TCP parameters to develop corresponding end-to-end data

network measurements for each of the at least one service delivery component; and

- means for storing the end-to-end data network measurements.

11. The apparatus of claim 10 wherein the means for determining a plurality of TCP parameters is further characterized as means for using mobile session identifiers as correspond to each of the selected mobile session data packets to obtain mobile session and TCP connection context information.

12. The apparatus of claim 11 wherein the means for determining a plurality of TCP parameters is further characterized as means for using the mobile session and TCP connection context information to derive measurements for each of:

- TCP connection setup round-trip time;

- TCP data packet round-trip time;

- TCP retransmission ratio information;

- TCP congestion events.

13. The apparatus of claim 10 further characterized by means for processing the stored end-to- end data network measurements to provide an aggregated measurement as regards end-to-end data network performance as pertains to a plurality of the selected mobile session data packets.

14. The apparatus of claim 13 wherein the means for providing the aggregated measurement is further characterized by means for providing an aggregated measurement as regards user session TCP end-to-end performance.

15. The apparatus of claim 14 wherein the means for providing the aggregated measurement is further characterized by means for providing an aggregated measurement as regards service delivery component TCP end-to-end performance.