WO2009008783A1 - Procédé et appareil pour déterminer une performance de service - Google Patents

Procédé et appareil pour déterminer une performance de service Download PDF

Info

Publication number
WO2009008783A1
WO2009008783A1 PCT/SE2007/001126 SE2007001126W WO2009008783A1 WO 2009008783 A1 WO2009008783 A1 WO 2009008783A1 SE 2007001126 W SE2007001126 W SE 2007001126W WO 2009008783 A1 WO2009008783 A1 WO 2009008783A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
performance
message
session
filter
Prior art date
Application number
PCT/SE2007/001126
Other languages
English (en)
Inventor
Mattias LIDSTRÖM
Tor Kvernvik
Tony Larsson
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Priority to SE0901532A priority Critical patent/SE534032C2/sv
Priority to CN200780053683.5A priority patent/CN101690304B/zh
Priority to GB1001724A priority patent/GB2467236B/en
Publication of WO2009008783A1 publication Critical patent/WO2009008783A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/02—Capturing of monitoring data
    • H04L43/028—Capturing of monitoring data by filtering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5077—Network service management, e.g. ensuring proper service fulfilment according to agreements wherein the managed service relates to simple transport services, i.e. providing only network infrastructure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
    • H04L43/106—Active monitoring, e.g. heartbeat, ping or trace-route using time related information in packets, e.g. by adding timestamps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/535—Tracking the activity of the user
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/61—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources taking into account QoS or priority requirements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/08—Testing, supervising or monitoring using real traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements

Definitions

  • the present invention relates generally to a method and apparatus for determining performance indicators reflecting the performance of different IP services in communication networks, as perceived by users of the services.
  • the performance of IP based multimedia services can then be estimated based on such measured service performance indicators.
  • IMS IP Multimedia Subsystem
  • MMTeI Multimedia Telephony
  • PoC Push-to-talk over Cellular
  • Operators of cellular or mobile access networks hereafter referred to simply as “mobile networks”, typically monitor network performance with respect to various characteristics and aspects, to generally assess and diagnose their networks.
  • OSS Operaation and Support System
  • MSC Mobile Switching Centre
  • RNC Radio Network Controller
  • KPI Key Performance Indicator
  • the sensors and counters in the network nodes can be configured, to frequently send measurement results, i.e. measured KPI values, to the OSS.
  • So-called “active probes” can also be installed as sensors/counters in various interfaces to provide KPI measurements.
  • a suitable software in the OSS is configured to derive relevant information from the received measurements to provide a comprehensive overview of the current network performance.
  • sensors, counters and active probes are typically installed on a case-by-case basis in order to investigate a certain problem in the network, e.g.
  • IP services IP and IMS based multimedia services mentioned above, hereafter referred to simply as "IP services"
  • IP services IP and IMS based multimedia services mentioned above, hereafter referred to simply as "IP services”
  • IP services will most likely require additional functionality for the new services in the performance monitoring systems, in order to assess and control the service performance properly.
  • the overall performance of such services typically depends on the performance in plural individual service nodes and entities that are used in addition to the access network, such as nodes associated with the IMS system and any utilized application servers or functions.
  • the performance monitoring systems of today are mainly adapted for monitoring specific nodes, parts and subsystems in circuit-switched access networks such as mobile networks. This provides for a relatively accurate assessment of the network performance since the network- related KPIs typically depend on sensors/counters in a single node, as in the case of data throughput and success rate for establishing a radio bearer. The reported KPI may then be regarded as a more or less accurate indication of the network performance in terms of available bandwidth and accessibility of radio resources, respectively.
  • the counters/sensors and well-defined KPIs are thus designed for classical circuit-switched networks offering the primary voice service. If the counters/sensors and KPIs would be used for IP services in the packet- switched domain, it is a problem to find sessions and extract data from the different counters/sensors in the nodes involved, and to report the results in the aggregated KPI format defined for the circuit-switched domain.
  • IP services may also utilize a combination of plural subservices and/or different media components, which may be more or less shortlived and fluctuating. It is a further problem that even if sensor and counter measurements are collected from plural nodes and elements as described above, the resulting total KPI will typically only give a rough estimation of the actual user experience.
  • a method for measuring a performance indicator reflecting the performance of an IP service in a communication network when consumed or invoked by a user terminal in a service session.
  • a message type is logged with a timestamp for each detected service-related message as raw data in a session entry, thereby creating a sequence of message events in the session entry.
  • the timestamp indicates the time of communicating the message .
  • a predefined performance filter associated with the performance indicator is then selected based on information in the session entry.
  • the selected performance filter is applied on the raw data in a filter engine, and the performance indicator is calculated from the filtered data according to a predefined algorithm corresponding to the. applied performance filter.
  • an apparatus for measuring a performance indicator reflecting the performance of an IP service in a communication network when consumed or invoked by a user terminal in a service session.
  • the apparatus comprises a message detector configured to detect service-related messages communicated with a policy control node for the service session.
  • the apparatus further comprises a session database configured to log a message type with a timestamp for each detected service-related message as raw data in a session entry, thereby creating a sequence of message events in the session entry.
  • the apparatus also comprises a filter engine configured to select a predefined performance filter associated with the performance indicator based on information in the session entry, apply the selected performance filter on the raw data, and calculate the performance indicator from the filtered data using a predefined algorithm corresponding to the applied performance filter.
  • the filter engine may comprise an identifying unit configured to receive the raw data from the session database, identify the IP service and also one or more performance indicators relevant to that IP service, and to select a predefined performance filter from a set of filters, for each performance indicator relevant to the identified IP service.
  • the filter engine may further comprise a filtering unit configured to apply the selected performance filter on the raw data, and a calculating unit configured to calculate the performance indicator from the filtered data using the predefined algorithm.
  • the performance filter may be selected based on an IP service identifier included in the session entry, or based on the sequence of message events in the session entry.
  • the policy control node may communicate the service-related messages with a gateway node in the access network or with an application function that enables the requested IP service.
  • the service-related messages may then be detected by the policy control node or by active probes installed at interfaces with the gateway node and the application function, respectively.
  • Applying the selected performance filter may provide a timestamped first service-related message as a start trigger and a timestamped second service-related message as a stop trigger, for measuring the performance indicator.
  • the calculated performance indicator may be reported to a service evaluating function, or lodged in a storage means for later use.
  • a plurality of performance indicators can be measured simultaneously by applying different associated performance filters on the same raw data and calculating the performance indicators from the filtered data using corresponding algorithms, respectively.
  • One or more specific performance indicators may have been pre-selected for each of a plurality of different IP services as being relevant to that service, and a predefined performance filter and corresponding algorithm may have been provisioned in the filter engine for each specific performance indicator.
  • Plural performance indicators may also be aggregated over time to reveal trends. Further possible features and benefits of the present invention will be outlined in the detailed description below.
  • Fig. 1 is a schematic view illustrating the monitoring of service performance of an IP service utilized by a user terminal, in accordance with one embodiment.
  • Fig. 2 is a flow chart illustrating a procedure for providing a performance indicator measurement for an IP service, in accordance with another embodiment.
  • - Fig. 3 is a signalling diagram illustrating a first example of logging raw data when an IP service is utilized, in accordance with yet another embodiment.
  • Fig. 4 is a signalling diagram illustrating a second example of logging raw data when an IP service is utilized, in accordance with yet another embodiment.
  • Fig. 5 is a signalling diagram illustrating a third example of logging raw data when an IP service is utilized, in accordance with yet another embodiment.
  • Fig. 6 is a block diagram illustrating a filter engine when measuring one or more performance indicators, in accordance with yet another embodiment .
  • the present invention can be used for monitoring, assessing or evaluating the performance of IP services utilized or consumed in an access network by means of a user terminal, typically involving the admission and establishment of a media session at some point after network attachment.
  • the access network may be a mobile or fixed access network and the IP service may be enabled by, e.g., IMS or TISPAN (Telecom and Internet Services and Protocols for Advanced Networks) using SIP (Session
  • RTSP Real Time Streaming Protocol
  • present invention is not limited to any specific network architectures or protocols.
  • performance indicator is used in this description to generally represent any measurable parameter related to service performance that in some way reflects the user experience when consuming or at least invoking an IP service, such as the above-mentioned KPIs.
  • a performance indicator in this context may relate to session set-up latency, session set-up success rate, service availability, media latency, fulfilment of expected data throughput, and so forth. Even though the following examples and embodiments mostly refer to a single performance indicator, the present invention is not limited thereto and may involve the measurement of any number of performance indicators .
  • the utilized policy control node is basically responsible for authorising and admitting communication sessions for terminals connected to the access network, based on various predetermined policies and rules. According to 3GPP, the policy control node operates according to a function called PCRF (Policy and Charging Rule Function), sometimes alternatively referred to as PDF (Policy Decision Function) . Similar functions and protocols for policy control are also available for other networks using, e.g., the TISPAN concept.
  • PCRF Policy and Charging Rule Function
  • PDF Policy Decision Function
  • the policy control node communicates certain standardized messages, referred to as "service-related messages" in this description, with a gateway node in the access network and with an application function that enables the requested IP service.
  • service-related messages In 3GPP, the PCRF exchange such service-related messages with the network gateway GGSN (Gateway GPRS Support Node) over a Gx interface, and with an application function over an Rx interface, both interfaces typically using the protocol called "DIAMETER" (according to standard document RFC 3588).
  • GGSN Gateway GPRS Support Node
  • DIAMETER Application Function
  • These messages are processed by PCRF based on subscription information stored in a database called SPR (Subscription Profile Repository) .
  • SPR Subscribescription Profile Repository
  • the corresponding interfaces are called Gq' and Rq' .
  • the present invention can be applied for any such policy control node interfaces where service-related messages are communicated.
  • the standardized service-related DIAMETER messages typically exchanged with the application function over the Rx interface include: AAR (Authentication Authorization Request), AAA (Authentication Authorization Answer), STR (Session Termination Request), and STA (Session Termination Request) .
  • AAR Authentication Authorization Request
  • AAA Authentication Authorization Answer
  • STR Session Termination Request
  • STA Session Termination Request
  • CCR Clear Control Request
  • CCA Credit Control Answer
  • RAR Re-Authorization Request
  • RAA Re- Authorization Answer
  • the service-related messages are logged by the policy control node as message events provided with timestamps and message identifiers. These message events make up a message sequence for a consumed or invoked IP service and are stored as raw data in a session entry that further contains at least a service identifier, and possibly other service or session-related information as , well that can be used for filtering information of particular interest, which will be described in more detail below.
  • Terminal 100 is connected to a mobile network containing a GGSN node 102 for media communication, and invokes the IP service from an application function 104 that may reside in a server in an IMS network, or similar.
  • a schematic step 1:1a illustrates that terminal 100 establishes a service session with application function 104
  • another schematic step 1:1b illustrates that terminal 100 and GGSN node 102 establish media transport resources in the access network for the session.
  • a schematic step 1:2a illustrates that service-related messages are exchanged between application function 104 and policy control node 106 over an Rx interface.
  • a schematic step 1:2b illustrates that service-related messages are exchanged between GGSN node 102 and policy control node 106 over a Gx interface.
  • each detected service-related message is logged together with a timestamp, i.e. the time the message was communicated, as raw data in a session entry stored in a session database
  • the session entry will contain a sequence of message events for the invoked IP service, including message types and timestamps.
  • message events can be logged in basically the same manner for other types of access networks and terminals as well, e.g. using fixed access.
  • the illustrated GGSN node 102 generally represents any network function responsible for establishing network resources for the IP service when consumed or invoked by the user terminal and communicating service-related messages with the policy control node 106.
  • a filter engine 112 which is adapted to apply a relevant performance filter on the raw data and calculate an associated performance indicator from the filtered data as follows: First, the IP service and/or message sequence in the session entry is identified, and then the performance filter is determined and selected based on the service and/or message sequence of the session entry. Finally, the selected filter is applied on the message events with the raw. data in the session entry, and a performance indicator associated with the filter is calculated from. the filtered raw data using a corresponding algorithm predefined for the performance indicator.
  • Different performance filters and corresponding algorithms have thus been predefined for different performance indicators in the filter engine 112 during a provisioning phase, which may filter data and use the filtered data in different ways.
  • two particular filtered timestamped messages may be used as triggers for starting and stopping a measurement, respectively, which will be described in more detail below by way of examples.
  • the logged raw data is not corrupted by the filtering process, and further performance filters can be applied on the same raw data, e.g. simultaneously, to calculate multiple performance indicators which may further be aggregated in different combinations.
  • Further filter criteria may also have been defined in the performance filters responsive to additional information in the session entry, such as identities of the user and the terminal.
  • a final step 1:5 illustrates that the calculated performance indicator is reported to an OSS node 114, or to a similar function configured to use the performance indicator to evaluate, assess or estimate the performance of the consumed IP service.
  • the calculated performance indicator may simply be lodged in a suitable storage means 116 for future use, as shown by an optional step 1:5a.
  • the described, session database 110, filter engine 112 and storage means 116 can be implemented in the policy control node 106 or in close connection therewith.
  • service-related performance indicators can be continuously measured for session entries with logged message events by means of the above mechanism, which can be implemented basically at a single node: the policy control node.
  • the policy control node it is possible to simultaneously measure a plurality of different performance indicators from the same session entry, by applying different performance filters and corresponding algorithms on the same logged raw data. For example, a service setup time and a service availability ratio can be derived from the same session entry, using different suitable performance filters and algorithms. Thereby, a considerable reduction of complexity and increased flexibility can be achieved, still obtaining performance indicators that are relevant to the user's experience, as compared to the traditional solutions described in the background section.
  • a flow chart illustrates a procedure for providing a performance indicator measurement for a particular IP service when consumed by a user, in accordance with another embodiment.
  • the shown procedure is executed at a policy control node using a session database and a filter engine, such as the elements 106, 110 and 112 described above for Fig. 1.
  • service-related messages to/from the policy control node are detected as message events for a session involving a terminal used for consuming and/or invoking the IP service.
  • raw data of the detected message events are logged in the session database to form a session entry, including the type of message and the time each message was detected, i.e. their timestamps.
  • the filter engine determines and selects a performance filter associated with a particular performance indicator from a set of predefined performance filters, based on the identified service and/or message sequence, in a following step 206.
  • the performance indicator to be measured is thus given by the identified service and/or message sequence.
  • the selected performance filter is then applied on the raw data in the session entry to extract information on the message events relevant to the performance indicator, in a next step 208.
  • the performance indicator is finally calculated from the filtered data using a corresponding predefined algorithm, in a further step 210, and can be reported to some service evaluating function such as OSS, in an optional dashed step 212.
  • the measured performance indicator may simply be lodged in a suitable storage means, e.g. in the policy control node.
  • the measurement result can be used for assessing or evaluating the performance of the consumed IP services.
  • a plurality of similar measurements of performance indicators in connection with different service sessions may thus be used to evaluate the IP service on the whole.
  • “measuring" a performance indicator generally involves the steps 200-210 above.
  • the following figures 3-5 illustrate how different message events can be logged as raw data in the session database 110 of Fig.
  • FIG. 3 illustrates an example of network attachment
  • Fig. 4 illustrates an example of terminal initiated PDP (Packet Data Protocol) context
  • Fig. 5 illustrates an example of network initiated PDP context.
  • Creating a PDP context for a mobile terminal basically means that network resources are allocated for communication in a forthcoming session, generally involving establishment of a RAB (Radio Access Bearer) .
  • a primary PDP context is used for transporting signalling messages and can also be used for transporting media in a service session in some cases. Otherwise, a secondary PDP context is established for transporting media in the service session.
  • a user terminal 300 performs network . attachment by communicating . with a GGSN 302 in the access network, which in turn communicates over a Gx interface with a PCRF 304 being the policy control node in this example.
  • terminal 300 sends an attachment request to GGSN 302 which then issues a CCR message to PCRF 304 according to prevailing routines, in a following step 3:2.
  • this service-related message is detected by PCRF 304, or by an active probe on the Gx interface, the message type CCR and a current time Ti are logged as a message event in a session database (not shown) , as schematically indicated in the figure.
  • PCRF 304 After processing the CCR message, which may involve retrieval of subscriber information from an SPR and applying prevailing admission rules, PCRF 304 responds with a CCA message back to GGSN 302 in a step 3:3. This message is likewise logged as a message event in the session database, including the message type CCA and a current time T 2 . Finally, GGSN 302 sends an attach response message to terminal 300 in a step 3:4.
  • CCR (T 1 ) and CCA (T 2 ) two service-related messages have been detected and logged as raw data in the session database: CCR (T 1 ) and CCA (T 2 ) .
  • a mobile user terminal 400 initiates a media session by invoking an IP service in an application function, indicated as AF 406, which may reside in an IMS network or similar.
  • AF 406 an application function
  • a GGSN 402 serving the terminal 400 communicates over a Gx interface with a PCRF 404 being the policy control node.
  • application function 406 communicates over an Rx interface with PCRF 404.
  • a SIP session is generally established between terminal 400 and application function 406.
  • application function 406 then sends an AAR message to PCRF 404 in a next step
  • the terminal 400 initiates a PDP context for the forthcoming media session.
  • the terminal 400 thus sends a PDP context request to GGSN 402, in a further step 4:3, effectively requesting for network resources for a forthcoming media session controlled by application function 406.
  • GGSN 402 then sends a CCR message to PCRF 404 according to prevailing routines, in a next step 4:4.
  • the message type CCR and a current time T 2 are logged as a message event in the session database.
  • PCRF 404 sends a CCA message back to GGSN 402 in a step 4:5. This message is likewise logged as a message event in the session database, including the message type CCA and a current time T3.
  • a following step 4:6 illustrates a response message to terminal 400 from GGSN 402 indicating that the PDP context has been established.
  • PCRF 404 sends an AAA message to application function 406 in response to the AAR message according to prevailing routines.
  • the message type AAA and a current time T 4 are logged as another message event in the session database. This message effectively admits terminal 400 towards application function 406, and the media session can then be executed according to .a step 4:8.
  • This example proceeds by terminating the media session by means of a method referred to as "SIP BYE", in a step 4:9.
  • the application function 406 then sends an STR message to PCRF 404 in a step 4:10, in order to terminate the session therein.
  • the message type STR and a current time T 5 are logged as yet another message event in the session database.
  • PCRF 404 further receives a CCR message from GGSN 402 according to prevailing routines, in a next step 4:11.
  • the PDP context is also deactivated in a step 4:12, in practice actually involving a request message from terminal 400 and a response message from GGSN 402.
  • PCRF 404 responds to the CCR message by another CCA message back to GGSN 402, in a further step 4:13.
  • the message types CCR and CCA and current corresponding timestamps T 6 and T 7 are logged as further message events in the session database.
  • PCRF 404 responds to the STR message received in step 4:10 by sending an STA message back to the application function 406, in a step 4:14, to confirm that the session has been terminated properly.
  • the message type STA and a current time Te are also logged as a message event in the session database.
  • a session entry has been formed in the session database that include at least the above message event sequence with timestamps, and may also include a service identifier and possibly other service or session-related information.
  • the session entry may further include identities of the user, the terminal, and of the Gx and Rx sessions. This extra information can then be used to derive statistics on the service performance for different user groups, equipment types, and so forth.
  • the Gx and Rx protocol stacks in PCRF 404 may contain supervision timers and a state handling function, in order to detect whether an unexpected signal arrives in the "wrong" state, or if an expected signal fails to arrive within a certain time period. In that case, such information should also be included in the session entry.
  • a state handling function in order to detect whether an unexpected signal arrives in the "wrong" state, or if an expected signal fails to arrive within a certain time period. In that case, such information should also be included in the session entry.
  • terminal 500 has already established a PDP context for some ongoing media session.
  • the access network initiates a new PDP context when the session is modified in some way, e.g. requiring different network resources.
  • the terminal thus has an active PDP context, e.g. a primary PDP context for SIP signalling, meaning that an IP session is active. It is also possible that a media session is also active.
  • a first step 5:1 the media session is modified for an ongoing IP service in a SIP dialogue between terminal 500 and application function 506.
  • the IP service may involve one or more "sub-services" that may be activated and de-activated to support the overall IP service, thereby requiring modification of the ongoing session, or new media sessions, etc.
  • application function 506 then sends.
  • an AAR message to PCRF 404 in a next step 5:2, basically requesting for authorization of terminal 500.
  • the message type AAR and a current time Ti are logged as a message event in a session database.
  • this message triggers an RAR message from PCRF 504 to GGSN 502, in a following step 5:3, effectively requesting for re- authorization of the terminal.
  • the message type RAR and a current time T 2 are logged in the session database.
  • the RAR message is actually a request to GGSN 502 to install new rules for handling the new or modified media session.
  • the RAR message in step 5:3 triggers GGSN 502 to initiate a new PDP context for the terminal 500 according to the modified media session, in a further step 5:4.
  • a following step 5:5 simply illustrates that the new PDP context is established in a communication between terminal 500 and GGSN 502.
  • GGSN 502 then sends an RAA message to PCRF 504, in a next step 5:6, thereby confirming re-authorization of terminal 500 in response to the previous RAR message of step 5:3.
  • the message type RAA and a current time T 3 are logged as another message event in the session database.
  • PCRF 504 is now able to respond to application function 506 by sending an AAA message in a step 5:7, which is logged as a message event in the session database, containing the message type AAA and a current time T 4 .
  • the modified media session can then be executed according to a step 5:8.
  • the media session is terminated by means of the method SIP BYE, in a step 5:9.
  • the application function 506 then sends an STR message to PCRF 404 in a step 5:10, in order to terminate the session therein.
  • the message type STR and a current time T ⁇ are logged as yet another message event in the session database.
  • PCRF 504 further receives an RAR message from GGSN 502 in this case, in a next step 5:11. Further, the PDP context is deactivated in a step 5:12. PCRF 504 responds to the RAR message by another RAA message back to GGSN 502, in a further step 5:13. As indicated in the figure, when these service-related messages are detected, the message types RAR and RAA and current corresponding timestamps T 6 and T 7 , respectively, are logged as further message events in the session database. Finally, PCRF 504 responds to the STR message received in step 5:10 by sending an STA message back to the application function 506, in a step 5:14, to confirm that the session has been terminated properly. When this service- related message is detected, the message type STA and a current time Ts are also logged as a message event in the session database.
  • a session entry has been formed in the session database that include at least the above message event sequence with timestamps, and optionally also a service identifier.
  • Figures 3-5 illustrate three different examples of service utilization where performance indicators can be measured by means of the logged service-related messages communicated with the policy control node.
  • numerous other signalling procedures may be employed for different service usage situations for which service- related messages to/from the policy control node can be logged in this way, and the present invention is not limited to the three above-described examples.
  • Performance indicator A "Service accessibility ratio" . This performance indicator can be used to describe the probability of accessing a mobile IP telephony service when requested. A) is measured as the number of successful access attempts in relation to the total number of access attempts. From the originating user's perspective, after pushing a send button on his/her terminal, the access attempt is deemed successful when an alerting tone is heard indicating that the opposite terminating terminal rings.
  • performance indicator A can be measured at the policy control node PCRF 404 by applying a corresponding performance filter that provides the message AAR (Ti) received by PCRF 404 in step 4:2 as a start trigger and the message AAA (T 4 ) sent by PCRF 404 in step 4:7 as a stop trigger, since the latter message confirms that the access attempt was successful.
  • Performance indicator B "Service setup time". This performance indicator can be used to measure the time it takes to set up a session, e.g., an MMTeI call.
  • B) is measured as the time between a setup start trigger when .the originating user requests the service and a setup stop trigger when the terminating user is alerted. From the originating user's perspective, the service setup time is the time between pushing the send button and the time when an alerting tone is heard at the opposite terminal.
  • performance indicator B) can be measured as the time between the filtered messages of PCRF 404 receiving the message AAR (Ti) and sending the message AAA (T 4 ), that is, T 4 -Ti.
  • Performance indicator C) “Service cut-off session ratio". This performance indicator can be used to describe the probability that a successfully initiated session is terminated unintentionally. C) is measured as the number of unintentionally terminated sessions in relation to the number of successfully initiated sessions. From the user's perspective, a start trigger for this performance indicator is when an alerting or busy tone from the opposite terminating party is heard at the originating terminal, and a stop trigger is when the session is ended by either the originating party or the terminating party, confirming that the session has been intentionally terminated.
  • performance indicator C can be measured by applying a performance filter that provides the message AAA (T 4 ) sent by PCRF 404 in step 4:7 as a start trigger and the message STR (T 5 ) received by PCRF 404 in step 4:10 as a stop trigger, since the latter message indicates that the session has been terminated properly at the application function 406. Thus, the successfully initiated session has been terminated unintentionally if the latter message has not been logged.
  • Performance indicator D "Service session completion ratio". This performance indicator can be used to describe how often a successfully initiated session, maintained for a certain duration, is released intentionally by either the originating party or the terminating party. D) is measured as the number of intentionally terminated sessions in relation to the total number of successfully initiated sessions. From the user's perspective, the start and stop triggers for this performance indicator are the same as for performance indicator C) above.
  • performance indicator D can be measured from the message AAA (T 4 ) being a start trigger and the message STR (T 5 ) being a stop trigger, just as for C).
  • the successfully initiated session has been terminated intentionally if message STR (T 5 ) has been logged.
  • Performance indicator E "Service teardown time". This performance indicator can be used to measure the time it takes to terminate a service session. E) is measured as the time between a teardown start trigger when one of the users ends the session and a teardown stop trigger when the session has been released in the network. From the user's perspective, a start trigger for this performance indicator is when either user pushes a button to end the session, and a stop trigger is when the session has been released.
  • performance indicator E can be measured by applying a performance filter that provides the message STR (T 5 ) received by PCRF 404 in step 4:10 as a start trigger and the message STA (T 8 ) sent by
  • performance indicator E can be measured as the time between the messages STR (T 5 ) and .
  • Performance indicator F "Service mean holding time” . This performance indicator can be used to measure the mean time of the complete session duration, i.e. the time period when network resources are required. F) is measured as the time between a setup start trigger when the originating user requests the service and a teardown stop trigger when the session has been released in the network.
  • performance indicator F) can be measured by applying a performance filter that provides the message AAR (Ti) received by PCRF 404 in step 4:2 as a start trigger and the message STA (T 8 ) sent by PCRF 404 in step 4:14 as a stop trigger.
  • performance indicator F) can be measured as the time between the messages AAR (Ti) and STA (T 8 ), that is, T 8 -Ti.
  • Performance indicator G "Service average session time” . This performance indicator can be used to describe average time of the actual media communication part of the session, i.e. the time of consuming the service for which the user can basically be billed. G) is measured as the time between a setup start trigger when the originating user requests the service and a teardown stop trigger when the session has been released in the network.
  • performance indicator G) can be measured by applying a performance filter that provides the message AAA (T 4 ) sent by PCRF 404 in step 4:7 as a start trigger and the message STR (T 5 ) received by PCRF 404 in step 4:10 as a stop trigger.
  • the AAA message is the last PCRF message before the media session can be executed in step 4:8, and the STR message is the first PCRF message after termination of the session by a user in step 4:8.
  • performance indicator G) can be measured as the time between the messages AAA (T 4 ) and STR (T 5 ), that is, T 5 -T 4 .
  • the exemplary performance indicators A)-G) described above can be measured for a plurality of sessions when IP services are consumed or invoked by various users, to collect statistics and provide relevant information on the performance of the considered IP services.
  • a performance evaluating system can be configured such that one or more specific performance indicators have been preselected for each IP service, as being relevant to that service.
  • the service-related messages are detected at the policy control node whenever such an IP service is invoked, and the detected messages are logged with timestamps as raw data in a session entry.
  • the filter engine then applies an associated performance filter on the ⁇ raw data and calculates the performance indicator (s) from the filtered data, e.g. as in the examples above.
  • performance indicators can be "refined” in the manner described.
  • a single IP service session may require plural media components, while the access network will regard each media component as a separate service requiring a specific QoS.
  • performance indicators can be aggregated as a combination thereof, so as to enable evaluation "end-to-end".
  • Plural performance indicators can also be aggregated over time to reveal trends or the like.
  • Fig. 6 illustrates in more detail how a filter engine 600 can be configured to provide the functionality described above, according to another embodiment.
  • the filter engine 600 can be implemented basically as the filter engine 112 described for Fig. 1, comprising an identifying unit 600a, a filtering unit 600b and a calculating unit 600c.
  • the filter engine also holds a set of predefined performance filters 60Od and corresponding algorithms 60Oe, which have been provisioned in the filter engine 600 for different performance indicators that can be measured for different IP services in the manner described above. It is fairly easy to enable performance indicator measurements for any newly introduced IP services, by provisioning new filters and corresponding algorithms for the services in the filter engine 600.
  • this figure merely illustrates the various functional units in the filter engine 600 in a logical sense, while the skilled person is free to implement these functions in practice using any suitable software and hardware means.
  • the present invention is generally not limited to the shown structure of the filter engine 600.
  • Fig. 6 further illustrates a session database 602 (similar to database 110 in Fig. 1) and a message detector 604 for detecting service-related messages communicated with a policy control node for service sessions.
  • the message detector 604 may reside either in the policy control node or in active probes installed at interfaces between the policy control node and a gateway node in the access network and an application function that enables the requested IP service, respectively.
  • Message detector 604 thus provides timestamped service-related messages M(T) which are logged as raw data in the session database 602.
  • the identifying unit 600b is configured to receive raw data "RD" for each invoked IP service from session database .602, including service-related messages and their timestamps as message events in a session entry that may further contain a service identifier. By reading the service identifier, if present, or by analysing the sequence of message events in the session entry, identifying unit 600a can identify the IP service that has been invoked and also one or more performance indicators KPI A , KPI B , KPI C ... relevant to that IP service.
  • Identifying unit 600a is also configured to select a predefined performance filter from the set of filters 60Od, for each performance indicator relevant to the identified IP service or identified flow of service-related messages.
  • Each performance indicator KPI A , KPI B , KPI C ... is associated with a performance filter F A , F B , F c ... and corresponding algorithm A A , A B , A c .... Since plural performance indicators may be relevant to a particular IP service, it is possible to select more than one filter for the same session entry, as illustrated by the dashed arrows.
  • the filtering unit 600b is configured to apply one or more selected performance filters F A , F B , F c ...
  • the filter may also be selected merely from the identified flow of service- related messages. However, the message flow for an IP service may vary, and in some cases the message flow may be corrupted due to some network error or lost connection. In that case, the identifying unit 600a may be configured to recognise the faulty message (s) and select filter accordingly.
  • the calculating unit 600c is configured to apply a corresponding algorithm A A , A B , A c ... on each set of filtered data RD(F A ), RD(F B ), RD (F C )... from filtering unit 600b, as illustrated by arrows from the predefined algorithms 60Oe, thereby producing one or more performance indicators KPI A , KPI B , KPI C - relevant to the consumed or invoked IP service. These performance indicators can then be delivered to a service performance evaluating function, such as the OSS 114 in Fig. 1, or lodged in a suitable storage means for later use.
  • a service performance evaluating function such as the OSS 114 in Fig. 1, or lodged in a suitable storage means for later use.
  • the performance filters 60Od may have been defined with further criteria, such as user group, service class, IP address range of the user terminal, current location, and so forth, in order to filter out certain service sessions of particular interest according to the filter criteria.
  • this type of added information may be included in the session entry logged in the session database 602, or may be retrieved from an SPR or the like e.g. based on identities of the user or the terminal provided in the session entry. For example, it may be of interest to evaluate the service performance for users of a certain service class, e.g. "Platinum users", or users receiving some particular media, or users located in a specific area or having a specific type of terminal, etc.
  • the present solution allows for such further refinement of the measured performance indicators.
  • exemplary embodiments relate generally to measuring a performance indicator for a single media session, for simplicity.
  • an IP service often involves a plurality of media sessions of varying durations for different media components, also being activated and terminated at different points when consuming the IP service.
  • a performance indicator may be measured in the above-described manner for each media component, and the measured performance indicators could then be considered in a suitable way when evaluating the total service.
  • Each performance indicator may thus more or less contribute to the overall performance of the IP service .
  • performance indicators relevant to any IP services involving media sessions can easily be obtained from messages communicated with a single node: the policy control node.
  • This solution has no impact on the network performance and requires a minimum of complexity for deployment.
  • valuable information normally not available to the IMS network can also be used for measuring performance indicators, such as current location, terminal type, access type, etc.
  • the performance indicators can be obtained without accessing the IMS network nor the application function used, which enables the access network operator to monitor service performance even when the IMS network or application function is located in another operator domain. This solution also enables fast and easy deployment of new IP services.
  • the performance indicators can also be generated with great flexibility, e.g. for different media components (such as video and voice) , and depending on any predefined filter criteria.
  • the performance indicators can be generated continuously as the IP services are consumed by different users. Different performance indicators can also be aggregated over time to reveal trends or the like. The same raw data can be used to calculate plural different performance indicators, and the performance filters can be adopted to the IP services in any manner. Specific filters can also be selected for each executed service session.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Debugging And Monitoring (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un procédé et un appareil conçus pour mesurer un indicateur de performance reflétant la performance d'un service IP consommé ou invoqué par un terminal utilisateur dans une session de service. Un détecteur de message (604) détecte des messages relatifs au service communiqués avec un nœud de contrôle de règles (106) pour la session de service. Une base de données de session (110) consigne un message type avec un horodateur pour chaque message détecté en tant que données brutes dans une entrée de session. Un moteur filtre (112) sélectionne un filtre de performance prédéfini associé à l'indicateur de performance sur la base des informations contenues dans l'entrée de session, applique le filtre de performance sélectionné aux données brutes, et calcule l'indicateur de performance à partir des données filtrées en utilisant un algorithme prédéfini correspondant au filtre de performance appliqué. Ainsi, les indicateurs de performance peuvent être mesurés pour les services IP avec un minimum de complexité, en utilisant les messages consignés relatifs au service communiqués avec le nœud de contrôle de règles.
PCT/SE2007/001126 2007-07-11 2007-12-19 Procédé et appareil pour déterminer une performance de service WO2009008783A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
SE0901532A SE534032C2 (sv) 2007-07-11 2007-12-19 Metod och apparat för bestämning av prestanda hos tjänster.
CN200780053683.5A CN101690304B (zh) 2007-07-11 2007-12-19 用于确定服务性能的方法和设备
GB1001724A GB2467236B (en) 2007-07-11 2007-12-19 Method and apparatus for determining service performance

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
SE0701701-5 2007-07-11
SE0701701 2007-07-11

Publications (1)

Publication Number Publication Date
WO2009008783A1 true WO2009008783A1 (fr) 2009-01-15

Family

ID=40228807

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SE2007/001126 WO2009008783A1 (fr) 2007-07-11 2007-12-19 Procédé et appareil pour déterminer une performance de service

Country Status (4)

Country Link
CN (1) CN101690304B (fr)
GB (1) GB2467236B (fr)
SE (1) SE534032C2 (fr)
WO (1) WO2009008783A1 (fr)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013071958A1 (fr) * 2011-11-15 2013-05-23 Telefonaktiebolaget L M Ericsson (Publ) Génération de statistiques de réseau basées sur un contrôleur de règles
US9047558B2 (en) 2012-01-17 2015-06-02 International Business Machines Corporation Probabilistic event networks based on distributed time-stamped data
US9832663B2 (en) 2013-09-11 2017-11-28 At&T Intellectual Property I, L.P. Network performance management for broadcast messaging
EP3367630A1 (fr) * 2017-02-22 2018-08-29 Netscout Systems, Inc. Système et procédé permettant de calculer des indicateurs clés de performance de sip pour une fenêtre de temps
US10069691B2 (en) 2013-11-26 2018-09-04 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for anomaly detection in a network
US11080641B1 (en) * 2016-07-31 2021-08-03 Splunk Inc. Graphical user interface for enabling association of timestamped machine-generated data and human-generated data

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102982037B (zh) * 2011-09-05 2016-05-25 中国移动通信集团浙江有限公司 检测数据库节点健康状况的方法及装置
CN105814931A (zh) * 2013-07-02 2016-07-27 七网络有限责任公司 基于移动网络信号的网络建模
CN110445826B (zh) * 2018-05-04 2021-11-30 阿里巴巴集团控股有限公司 一种会话信息获取方法、装置及服务器
CN113610372A (zh) * 2021-07-27 2021-11-05 远景智能国际私人投资有限公司 服务等级协议的确定方法，装置，终端及可读存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003037019A1 (fr) * 2001-10-25 2003-05-01 Nokia Corporation Procede et systeme permettant d'optimiser les performances d'un reseau
WO2003096729A1 (fr) * 2002-05-08 2003-11-20 Aran Communications Limited Mesure d'experience d'abonne a un reseau de telecommunications
WO2005048629A1 (fr) * 2003-11-17 2005-05-26 Telecom Italia S.P.A. Architecture pour surveillance de la qualite de service, procede, logiciel, et progiciels a cet effet
US20080162637A1 (en) * 2006-11-03 2008-07-03 At&T Bls Intellectual Property, Inc. Application services infrastructure for next generation networks including a notification capability and related methods and computer program products

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100388693C (zh) * 2005-12-28 2008-05-14 华为技术有限公司 根据服务水平协议对服务质量进行监测的方法和系统
CN100518191C (zh) * 2006-03-21 2009-07-22 华为技术有限公司 通讯网络中对服务质量进行保障的方法及系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003037019A1 (fr) * 2001-10-25 2003-05-01 Nokia Corporation Procede et systeme permettant d'optimiser les performances d'un reseau
WO2003096729A1 (fr) * 2002-05-08 2003-11-20 Aran Communications Limited Mesure d'experience d'abonne a un reseau de telecommunications
WO2005048629A1 (fr) * 2003-11-17 2005-05-26 Telecom Italia S.P.A. Architecture pour surveillance de la qualite de service, procede, logiciel, et progiciels a cet effet
US20080162637A1 (en) * 2006-11-03 2008-07-03 At&T Bls Intellectual Property, Inc. Application services infrastructure for next generation networks including a notification capability and related methods and computer program products

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013071958A1 (fr) * 2011-11-15 2013-05-23 Telefonaktiebolaget L M Ericsson (Publ) Génération de statistiques de réseau basées sur un contrôleur de règles
JP2015507381A (ja) * 2011-11-15 2015-03-05 テレフオンアクチーボラゲット エル エム エリクソン（パブル） ポリシー制御装置を使用するネットワーク統計の生成
US9699676B2 (en) 2011-11-15 2017-07-04 Telefonaktiebolaget Lm Ericsson (Publ) Policy controller based network statistics generation
US9047558B2 (en) 2012-01-17 2015-06-02 International Business Machines Corporation Probabilistic event networks based on distributed time-stamped data
US9832663B2 (en) 2013-09-11 2017-11-28 At&T Intellectual Property I, L.P. Network performance management for broadcast messaging
US10069691B2 (en) 2013-11-26 2018-09-04 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for anomaly detection in a network
US11080641B1 (en) * 2016-07-31 2021-08-03 Splunk Inc. Graphical user interface for enabling association of timestamped machine-generated data and human-generated data
US11676092B1 (en) 2016-07-31 2023-06-13 Splunk Inc. Graphical user interface with hybrid role-based access control
EP3367630A1 (fr) * 2017-02-22 2018-08-29 Netscout Systems, Inc. Système et procédé permettant de calculer des indicateurs clés de performance de sip pour une fenêtre de temps
US11153443B2 (en) 2017-02-22 2021-10-19 Netscout Systems, Inc System and method for calculating SIP KPIs for a time window

Also Published As

Publication number Publication date
GB2467236A (en) 2010-07-28
SE0901532A1 (sv) 2010-02-11
GB2467236B (en) 2011-08-17
GB201001724D0 (en) 2010-03-24
SE534032C2 (sv) 2011-04-05
CN101690304A (zh) 2010-03-31
CN101690304B (zh) 2012-12-26

Similar Documents

Publication Publication Date Title
WO2009008783A1 (fr) Procédé et appareil pour déterminer une performance de service
US8121049B2 (en) Method and arrangement for controlling service level agreements in a mobile network
US8488460B2 (en) Method and apparatus for evaluating services in communication networks
JP5855268B2 (ja) ポリシー制御装置を使用するネットワーク統計の生成
EP2591573B1 (fr) Procédé et appareil de classification de trafic
EP2787695A1 (fr) Procédé de notification de bande passante d'abonné
US8155290B2 (en) Systems and methods for providing per call measurement data in an IMS network
EP2587737B1 (fr) Procédé et dispositif de surveillance de trafic de service
US9462049B2 (en) Method and apparatus for providing a centralized subscriber load distribution
US20100186064A1 (en) Method and device for obtaining capabilities of policy and charging enforcement function
US9450767B2 (en) PCRF and PCC rule setting method in a mobile communication network
WO2011116813A1 (fr) Appareil et procédé dans un réseau de télécommunication
WO2014146502A1 (fr) Procédé et appareil de gestion de congestion de réseau d'accès radio, et procédé et système de gestion de stratégie de congestion
WO2009067057A1 (fr) Procédé et appareil pour évaluer une performance de service
EP4064756B1 (fr) Limitation de bande passante dans un réseau d'accès radio
WO2011157137A2 (fr) Procédé de contrôle de politique, appareil et système de communication
WO2016091294A1 (fr) Estimation de composition de trafic de données d'un réseau de communication par extrapolation
CN109714798B (zh) 后向QoS保障方法、加速平台以及通信系统

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200780053683.5

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07852126

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: MX/A/2010/000058

Country of ref document: MX

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 520/DELNP/2010

Country of ref document: IN

ENP Entry into the national phase

Ref document number: 1001724

Country of ref document: GB

Kind code of ref document: A

Free format text: PCT FILING DATE = 20071219

WWE Wipo information: entry into national phase

Ref document number: 1001724.2

Country of ref document: GB

122 Ep: pct application non-entry in european phase

Ref document number: 07852126

Country of ref document: EP

Kind code of ref document: A1