METHOD AND APPARATUS FOR DETERMINING SERVICE PERFORMANCE.

TECHNICAL FIELD

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.

BACKGROUND

A multitude of different multimedia services have been developed using packet-switched communication over IP (Internet Protocol). Multimedia services typically involve the transmission of media in different formats and combinations over IP networks. A network architecture called IMS (IP Multimedia Subsystem) has been developed by the 3 ^rd Generation Partnership Project (3GPP) as a platform for handling and controlling multimedia services and sessions, commonly referred to as the IMS network. Examples of services that can be implemented by using IMS are MMTeI (Multimedia Telephony) and 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. Today, various solutions and systems are known for finding any performance-related shortcomings, and for configuring and optimising different parameters in the mobile network impacting the general network performance. Moreover, the network performance is

monitored also to ensure that various obligations towards subscribers and content providers are met, such as service level agreements, and that expected levels of QoS (Quality of Service) are fulfilled. Performance monitoring is typically handled in mobile networks by the function called OSS (Operation and Support System), e.g. to support fault management. Practically all nodes in the mobile network, e.g. base stations, MSC (Mobile Switching Centre) and RNC (Radio Network Controller) , can be configured to provide more or less performance-related information to the OSS or other similar systems over specific interfaces. Various sensors and counters are thus installed in the different network nodes, in order to collect measurements of relevant performance-related parameters in each node during operation of the network. In this context, a performance-related parameter is often referred to as KPI (Key Performance Indicator) . Data throughput and success rate for establishing a radio bearer are typical examples of such network performance-related parameters or KPIs.

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. In practice, a relatively great number of sensors and counters are required in a plurality of nodes and interfaces in order to achieve an adequate view of the network. Such 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. when bad performance has been observed for a specific service, allowing the operator to monitor a specific part of the network. The development towards IP and IMS based multimedia services mentioned above, hereafter referred to simply as "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.

For circuit-switched networks where control signalling and data traffic are handled more or less uniformly by the same nodes, a number of KPIs have thus been accurately defined. However, in a packet-switched network, the control signalling is separated from the data traffic, being handled by different nodes, and many packet-based IP

services will also be executed on plural platforms as well. These facts increase the complexity of using sensors and counters in the different traffic nodes, and collecting KPIs for IP services in the traditional manner becomes more complex as well.

Today, 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.

Further, it is desirable to define "service- oriented" KPIs for specific IP services, reflecting the performance or quality as perceived by the service user, in contrast to the "network-oriented" solutions above. As the performance of these IP services is typically dependent on a combination of nodes, functions and elements in the network, it is a problem that complexity must be introduced in order to aggregate and combine KPI measurements from plural sensors and counters at different locations throughout the nodes involved.

Hence, obtaining relevant service-related KPIs for a multitude of different IP services is certainly a difficult task also requiring considerable amounts of processing and signalling capacity, particularly as new services are frequently introduced. Some 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.

SUMMARY

It is an object of the present invention to address the problems outlined above. Further, it is an object to provide a solution for determining performance indicators of IP services with reduced complexity and allowing for easy introduction of new IP services. These objects and others may be obtained by providing a method and apparatus according to the independent claims attached below.

According to one aspect, a method is provided 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.

When service-related messages communicated with a policy control node for the service session are detected, 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.

According to another aspect, an apparatus is provided 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.

Different embodiments are possible in the method and apparatus above. For example, 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.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will now be explained in more detail by means of exemplary embodiments and with reference to the accompanying drawings, in which:

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 .

DETAILED DESCRIPTION

Briefly described, 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

Initiation Protocol) or RTSP (Real Time Streaming Protocol) . However, the present invention is not limited to any specific network architectures or protocols.

It has been found that a policy control node typically associated with the access network can actually be used for obtaining relevant measurements related to IP service performance, basically representative of the total network, by logging service-related messages to and from the policy control node. The policy control node thus holds information that can be used for measuring or aggregating service performance parameters or indicators, hereafter referred to as "performance indicators" for short, instead of relying on measurements in multiple network nodes in the manner described above. The term "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. For example, 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.

When a session is established for a user terminal according to a requested IP service, 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. 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). These messages are processed by PCRF based on subscription information stored in a database called SPR (Subscription Profile Repository) . In TISPAN, the corresponding interfaces are called Gq' and Rq' . However, 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) . Further, the standardized service-related DIAMETER messages exchanged with the GGSN node over the Gx interface include: CCR (Credit Control Request), CCA (Credit Control Answer), RAR (Re-Authorization Request), and RAA (Re- Authorization Answer) . These messages and others are well- known in the art and are not necessary to describe further to understand the following embodiments.

In order to determine and measure relevant performance indicators, 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.

Referring to Fig. 1, an exemplary procedure and arrangement will now be described for monitoring the service performance of an IP service consumed by means of a mobile terminal 100. 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, and another schematic step 1:1b illustrates that terminal 100 and GGSN node 102 establish media transport resources in the access network for the session.

The application function 104 and the GGSN node 102 are both connected to a policy control node 106 that has

access to subscriber information stored in an SPR 108 in order to perform its conventional policy function, as described above. 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. Likewise, 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.

When communicated, these service-related messages are detected as message events by the policy control node

106, or alternatively by active probes (not shown) installed at the respective interfaces Rx and Gx. The type of 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

110, as shown by a further step 1:3. Thus, the session entry will contain a sequence of message events for the invoked IP service, including message types and timestamps. A person skilled in the art will readily understand that 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. Thus, 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.

In a next step 1:4, the logged raw data of the session entry is supplied to 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. For example, 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. It should be noted that 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. Alternatively, 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. Although shown as separate elements here, 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.

In this way, 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. As mentioned above, 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. In Fig. 2, 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. In a first step 200, 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. In a next step 202, 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.

As the session entry has been formed in the session database, the consumed IP service and the sequence of message events in the session entry are identified in a further step 204. Then, 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. Alternatively, the measured performance indicator may simply be lodged in a suitable storage means, e.g. in the policy control node. In one way or another, 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. In this context, "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. 1, for some exemplary conventional

signalling procedures involving a policy control node associated with a mobile access network. In addition, each of figures 3-5 basically shows how steps 200 and 202 of Fig. 2 can be made in these three examples in the case when a mobile terminal is used. Without limitation, the examples relate to some typical procedures for enabling an IP service:. Fig. 3 illustrates an example of network attachment, Fig. 4 illustrates an example of terminal initiated PDP (Packet Data Protocol) context, and 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. In Fig. 3, 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. In a first step 3:1, 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. When 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.

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 ₂ . Finally, GGSN 302 sends an attach response message to terminal 300 in a step 3:4. Thus, two service-related messages have been detected and logged as raw data in the session database: CCR (T ₁ ) and CCA (T ₂ ) .

In the example shown in Fig. 4, 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. As in the previous example, a GGSN 402 serving the terminal 400 communicates over a Gx interface with a PCRF 404 being the policy control node. Further, application function 406 communicates over an Rx interface with PCRF 404.

In a first step 4:1, a SIP session is generally established between terminal 400 and application function 406. According to prevailing routines, application function 406 then sends an AAR message to PCRF 404 in a next step

4:2, basically requesting for authorization of terminal 400. When this service-related message is detected by PCRF 404, or by an active probe on the Rx interface, the message type AAR and a current time Ti are logged as a message event in a session database (not shown) , as schematically indicated in the figure.

In this signalling example, the terminal 400 initiates a PDP context for the forthcoming media session. At some point, 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. When this service-related message is detected by PCRF 404, or by an active probe on the Gx interface, the message type CCR and a current time T ₂ are logged as a message event in the session database. After processing the CCR message, 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.

In a further step 4:7, PCRF 404 sends an AAA message to application function 406 in response to the AAR message according to prevailing routines. When this service- related message is detected, the message type AAA and a current time T ₄ 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. When this service-related message is detected, the message type STR and a current time T ₅ 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. At some point, 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. As indicated in the figure, when these service-related messages are detected, the message types CCR and CCA and current corresponding timestamps T ₆ and T ₇ , respectively, are logged as further message events in the session database.

Finally, 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. When this service- related message is detected, the message type STA and a current time Te are also logged as a message event in the session database.

Thus, no less than eight service-related messages have been detected and logged as raw data in the session database during the above-described example of Fig. 4: AAR (Ti), CCR (T ₂ ), CCA (T ₃ ), AAA (T ₄ ), STR (T ₅ ), CCR (T ₆ ), CCA (T ₇ ), and STA (Ts). As a result, 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. For example, 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.

Further, 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.

In the third signalling example shown in Fig. 5, again involving a mobile user terminal 500, a GGSN 502, a PCRF 504 and an application function 506, it is assumed that terminal 500 has already established a PDP context for some ongoing media session. As will be described below, 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.

In 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. For example, 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. As a result, application function 506 then sends. an AAR message to PCRF 404 in a next step 5:2, basically requesting for authorization of terminal 500. When this message is detected, the message type AAR and a current time Ti are logged as a message event in a session database. Further, 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. For this message event, the message type RAR and a current time T ₂ 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. When this message is detected, the message type RAA and a current time T ₃ 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 ₄ . The modified media session can then be executed according to a step 5:8.

Next, 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. When this service- related message is detected, 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 ₆ and T ₇ , 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.

Thus, eight service-related messages have been detected and logged as raw data in the session database during the above-described third example of Fig. 5: AAR

(Ti), RAR (T ₂ ), RAA (T ₃ ), AAA (T ₄ ), STR (T ₅ ), RAR (T ₆ ), RAA (T ₇ ) , and STA (Tg) . As a result, 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.

Thus, 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. Of course, 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. It will now be described how different exemplary performance indicators A) - G) can be measured by filtering the raw data logged, e.g., according to the above signalling example of Figure 4 and using corresponding predefined algorithms, basically implementing steps 208 and 210 in the procedure of Fig. 2.

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.

Using the present solution for the example of Fig. 4, 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 ₄ ) 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. In the example of Fig. 4, 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 ₄ ), that is, T ₄ -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.

In the example of Fig. 4, performance indicator C) can be measured by applying a performance filter that provides the message AAA (T ₄ ) sent by PCRF 404 in step 4:7 as a start trigger and the message STR (T ₅ ) 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.

Likewise referring to Fig. 4, performance indicator D) can be measured from the message AAA (T ₄ ) being a start trigger and the message STR (T ₅ ) being a stop trigger, just as for C). Thus, the successfully initiated

session has been terminated intentionally if message STR (T ₅ ) 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.

In the example of Fig. 4, performance indicator E) can be measured by applying a performance filter that provides the message STR (T ₅ ) received by PCRF 404 in step 4:10 as a start trigger and the message STA (T ₈ ) sent by

PCRF 404 in step 4:14 as a stop trigger, the latter message indicating that the session is terminated at the application function 406. Thus, performance indicator E) can be measured as the time between the messages STR (T ₅ ) and . STA (T ₈ ), that is, T ₈ -T ₅ .

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.

In the example of Fig. 4, 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 ₈ ) sent by PCRF 404 in step 4:14 as a stop trigger. Thus, performance

indicator F) can be measured as the time between the messages AAR (Ti) and STA (T ₈ ), that is, T ₈ -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.

In the example of Fig. 4, performance indicator G) can be measured by applying a performance filter that provides the message AAA (T ₄ ) sent by PCRF 404 in step 4:7 as a start trigger and the message STR (T ₅ ) 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. Thus, performance indicator G) can be measured as the time between the messages AAA (T ₄ ) and STR (T ₅ ), that is, T ₅ -T ₄ .

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. Thus, 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. For each 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.

In this way, the performance of the IP services can be evaluated with great accuracy and relevance .to the user's experience, since the 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. For example, if performance indicators are measured for both an originating party and a terminating party, 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.

It should be noted that 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. Thus, 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.

In operation, 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 ... on the raw data RD from identifying unit 600a, as illustrated by arrows from the predefined filters 60Od, thereby producing one or more sets of filtered raw data RD (F _A ), RD(F _B ), RD(Fc)... from each filter. As mentioned above, different predefined performance filters 60Od and corresponding algorithms 60Oe have been provisioned in filter engine 600 for different performance indicators. As mentioned above, 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.

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. To enable such additional filtering criteria when measuring performance indicators, 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.

It should be noted that the above description of exemplary embodiments relates generally to measuring a performance indicator for a single media session, for simplicity. However, 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. In that case, 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 . By implementing the present invention, e.g. according to any of the above-described embodiments, 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. For example, 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.

Further, 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.

While the invention has been described with reference to specific exemplary embodiments, the description is in general only intended to illustrate the inventive concept and should not be taken as limiting the scope of the invention. Although the concepts of IMS, SIP, GGSN and PCRF have been used when describing the above embodiments, any

other similar suitable standards, protocols and network elements may basically be used as described herein. The present invention is generally defined by the following independent claims.