WO2013029215A1

WO2013029215A1 - Method and apparatus for modeling a service delivered over a communication network

Info

Publication number: WO2013029215A1
Application number: PCT/CN2011/078969
Authority: WO
Inventors: Martin Adams; Dan Jurca; Renaud Cuny; Sergio BAKER
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2011-08-26
Filing date: 2011-08-26
Publication date: 2013-03-07
Anticipated expiration: 2014-02-26

Abstract

The invention relates to a method (100) for modeling a service being delivered through a terminal to a user over a communication network during a service session, a progress of the service being determined by the user interacting with the service through the terminal. The method (100) comprises: determining (101) a service implementation type indicating an implementation of the service; assigning (103) a user experience centric service model to the service implementation type, the user experience centric service model comprising a first service state and a second service state; determining (105) a transition between the first service state and the second service state by observing the progress of the service during the service session; and determining (107) a user-originated reason for the transition based on the user experience centric service model.

Description

DESCRIPTION

Method and apparatus for modeling a service delivered over a

communication network

BACKGROUND OF THE INVENTION

The present invention relates to a method and apparatus for modeling a service delivered over a communication network

Service monitoring is of main importance for network service providers. The importance of service monitoring has two aspects. Firstly, the operator needs to assess the quality of the offered service in order to comply to committed levels and secondly, the operator needs to provision the service both to comply with the expected quality and to operate the network efficiently. The first aspect relates to the performance of the service and how it impacts usability and experience for the user. It is widely accepted that a good usage experience leads to reduced churn rates and increased recurrent income as a result of returning customers and word- of-mouth recommendation. The latter relates to the performance of the service needed to provide the user with a good enough experience in terms of

acceptability and satisfaction. The performance of the service relies on its technical implementation and as such it is dependent on the network resources and how they are dimensioned and optimized. The service modelling allows bridging both aspects of service monitoring by mapping the monitored quality to the service performance and ultimately to the network resources themselves, revealing the dependencies between the quality objectives and the service components.

Service modelling is mapping Key Performance Indicators (KPIs) calculated from the measurements taken from the network to the so called Quality of Service (QoS) which is a measure for a quality of the service offered by the network. The service modelling lays the basis for establishing relationships between the calculated KPIs and the so called Key Quality Indicators (KQIs) which are high level quality indicators that are reflecting a business process view of the service, i.e. they allow monitoring the service provider business processes involved in the service provisioning and the business processes that the information technology is providing.

The user is not considered as a receiver of the service in any of these models. Likewise, the user activities while using a given service are not considered.

SUMMARY OF THE INVENTION

It is the object of the invention to provide a new user-oriented service concept for a communication network that represents the perceived service quality as seen by the user.

This object is achieved by the features of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the figures.

The invention introduces a methodological approach to service modelling and applies user experience centric service models which represent the user activities while using the service of a communication network. The methodology approach allows for economies of scale since a common way of analysing and representing the resulting analysis is possible. The service modelling is oriented to the user's perception of the service, i.e. to the Quality of Experience (QoE) as seen by the user. A user experience centric service model is introduced that analyses the service from the user perspective with respect to human factors, usage contexts, and objectives of the user. Service states of the user experience centric service model are determined by considering activities of the user when using a service of the communication network. Additionally, the user experience centric service model determines transitions from one state to another one or to the same one and investigates the different reasons for transitioning. For each combination of a transition and a reason an impact on the user appreciation, e.g. positive, negative or neutral, is determined representing a measure for the Quality of Experience perceived by the user.

In order to describe the invention in detail, the following terms, abbreviations and notations will be used:

QoS: Quality of Service. QoS is defined as a set of quality requirements on the collective behavior of one or more objects of the service. Quality of service comprises requirements on all the aspects of a service in a data network, such as service response time, loss, signal-to-noise ratio, cross-talk, echo, interrupts, frequency response, loudness levels, capacity and coverage of the network, blocking and outage probability of the network, etc.,

QoE: Quality of Experience. QoE defines a metric that reflects or predicts the subjectively experienced quality. QoE represents the cumulative effect on subscriber satisfaction of all imperfections affecting the service. Equivalent terms are: perceived user quality, user perceived performance, video subjective quality, quality perceived by the user, degree of satisfaction of the user,

KPI: Key Performance Indicator. KPI is a term for a type of measure of

performance. KPIs give a good understanding of what is important for the network service provider,

KQI: Key Quality Indicator. KQI is a term for a type of measure of quality. KQIs provide an overview of the network quality to the network service provider, MOS: Mean Opinion Score. MOS provides a numerical indication of the perceived quality of received media after transmission,

USM: User experience centric Service Modelling. USM is using a service model that is based on a user-oriented perspective, as seen by the user of the service,

Rx: Reason x, with x being a number,

Ex: Event x, with x being a number, fx: fraction x, with x being a number,

SDR: Session Data Record. SDR is a record containing details of a session and is also referred to as Call Data Record (CDR).

ECM: Evaluation and Computation Model. An ECM is applied to the observed traffic in order to calculate parameters from the observed traffic. An example for an ECM is a buffer emulator which models a size of a buffer in a network device, e.g. a receive buffer in a video client, based on the observed data traffic in the network. eNB ID: eNodeB identity,

QM: Quality metric. QM is a measure for the quality, TCP: Transmission Control Protocol. TCP is one of the core protocols of the Internet Protocol Suite. TCP is one of the two original components of the suite, complementing the Internet Protocol (IP), and therefore the entire suite is commonly referred to as TCP/IP. TCP provides reliable, ordered delivery of a stream of bytes from a program on one computer to another program on another computer, TCP FIN/ACK: sequence of TCP messages to signal the end of a TCP session,

TCP RST: Reset message sent by TCP to end a TCP session, HTTP: Hypertext Transfer Protocol. HTTP is a networking protocol for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web,

IP: Internet Protocol. The Internet Protocol is the principal communications protocol used for relaying datagrams, i.e. data packets, across a data network using the Internet Protocol Suite. IP is responsible for routing packets across network boundaries. It is the primary protocol that establishes the Internet. IP has the task of delivering datagrams from the source host to the destination host solely based on their addresses. For this purpose, IP defines addressing methods and structures for datagram encapsulation,

Communication network or simply referred to as a network, is a collection of computers and devices interconnected by communications channels that facilitate communications and allows sharing of resources and information among interconnected devices,

Service: A service is a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description; A service in a data network refers to a set of related software or hardware

functionalities, together with the policies that should control its usage,

Session: A session is a semi-permanent interactive information interchange, also known as a dialogue, a conversation or a meeting, between two or more communicating devices, or between a computer and a user. A session is set up or established at a certain point in time, and torn down at a later point in time. An established communication session may involve more than one message in each direction. A session is typically, but not always, stateful, meaning that at least one of the communicating parts needs to save information about the session history in order to be able to communicate, as opposed to stateless communication, where the communication consists of independent requests with responses.

Segment: A segment is a group of sessions,

Server: A server is a computer based device, also called a 'host', dedicated to delivering a service.

Video server: A video server is a computer based device, also called a 'host', dedicated to delivering video. Client: A client is an application, a system or a device that accesses in a client- server system a remote service on another computer system, known as a server, by way of a network, or exchanges in a peer-to-peer system data with a remote client, by way of a network. Video client: a video client is a client dedicated to accessing a video service on a video server.

Terminal: a terminal is a device which is capable of communicating over a line. DPI: deep packet inspection - is a method to inspect network packets and extract relevant information from the packet payload,

SPI: Shallow Packet Inspection. It is a method to inspect network packets and extract relevant information from the packet headers, up to application layer protocol headers, OSI model: Open Systems Interconnection model,

According to a first aspect, the invention relates to a method for modeling a service, the service being delivered through a terminal to a user over a

communication network during a service session, a progress of the service being determined by the user interacting with the service through the terminal. The method comprises: determining a service implementation type, the service implementation type indicating an implementation of the service; assigning a user experience centric service model to the service implementation type, the user experience centric service model comprising a first service state and a second service state; determining a transition between the first service state and the second service state by observing the progress of the service during the service session; and determining a user-originated reason for the transition based on the user experience centric service model or based on the user experience centric service model and observing the progress of the service during the service session.

The service may be delivered from a server or another terminal to the user through the terminal. For example, for a client-server service, the service is delivered from a server, whereas for a client-to-client service, also referred to as peer-to-peer service, the service is delivered from another terminal.

The method may implement a user centric quality of experience service model comprising at least one of: analysing the service from the user perspective: what human factors, usage contexts, and objectives need to be considered, identifying the service states: what activities are going to be observable by the user. Identify the states at the heart of the service purpose and those states peripheral to the purpose of the service itself but which allow the service to be established , identifying the transitions from one state to each other state, identifying the different reasons for transitioning, defining the KPIs allowing to identify the session, and within the session the states and the transitions between states, defining the impact of each combination on user experience, e.g. transition or reason, on the user appreciation such as positive user appreciation, negative user appreciation, neutral user appreciation, optionally optimizing comprising at least one of:

a. Adding transitions that might result from actions taken by the user due to a given result

b. Pruning transitions that do not produce any substantial change in the user appreciation

c. Adding states when new transitions are found that can be identified and have substantial impact in the user appreciation

d. Pruning or merging states for which transitions can't be identified or do not add any impact on user appreciation by being introduced or separated.

Applying the user experience centric service model offers the following

advantages. The user experience centric service model takes the actual user view when using the service. The user experience centric service model allows for different representations at different aggregation levels e.g. session, segment or network, saving storage space and processing power for coarse granularities when the session detail is not needed. The user experience centric service model guarantees independence from the technical implementation layers. The user experience centric service model keeps back compatibility with existing service models. The user experience centric service modelling methodology ensures scalability and reusability of the whole or parts of the service model. The user experience centric service modelling methodology is based on widely adopted referentials, but simplified to consider only the critical components, creating economies of scale.

The user experience centric service model may comprise user-originated and network originated reasons, i.e. reasons without user interaction, e.g. network failure, loss of connection terminating the session etc. Interactions may be user originated or network originated. User originated interactions, such as, e.g. pushing the stop button on a user's streaming

application, are distinct from user originated reasons, i.e. the reasons why the user performed a corresponding user originated interaction, e.g. such as the user pushes the stop button because he perceives a quality degradation. A user originated reason such as, e.g. a user perceived quality related reason, may effect a user originated interaction. A non-user perceived quality related reason or an unknown reason will not effect a user originated interaction but may effect a network originated interaction.

Thus, the user originated interaction as such is unequal to the user originated reason behind this interaction. The user perceived quality related reasons are distinct from unknown reasons or non-user perceived quality related reasons. A transition in the user experience centric service model occurs due to a user- originated interaction and not due to a network originated interaction, but both interactions may happen at the same or nearly the same time. The transition in the user experience centric service model may be performed based on the same message or may occur in the same step as a transition due to a network originated interaction. For example, the user originated interaction is to stop e.g. a video stream by pushing the stop button of the streaming application. Then, the message containing this information provides the information needed to determine the transition to the stop state and at the same time the information that the user interacted with the session to request the stop. At this time, further information is desired to determine the user-originated reason. The user experience centric service model can deliver such information.

The user experience centric service model comprises criteria, e.g. user perceived quality parameters like number of stalls, Mean Opinion Score (MOS), etc. to determine which user originated reason was most likely the reason for the transition and calculates these parameters, e.g. by observing the service during the session or other actions. The user experience centric service model may evaluate one or more parameters per reason, e.g. by identifying parameters surpassing a certain threshold or other identification strategies. In a first possible implementation form of the method according to the first aspect, the service is a streaming service provided by a server and the service

implementation type includes one of the following: Hypertext Transfer Protocol streaming, Real-Time Transport Protocol streaming, and hypertext markup language version 5 streaming, HTML5 streaming.

The service implementation type includes HTML streaming as a semantic-level markup language and associated semantic-level scripting APIs (Application Programming Interfaces) for authoring accessible pages on the Web ranging from static documents to dynamic applications.

The service implementation type includes applications that are used by users on an occasional basis, or regularly but from disparate locations, with low CPU requirements. The service implementation type includes streaming applications such as online purchasing systems, searching systems, games, in particular multiplayer online games, public telephone books or address books,

communications software, in particular e-mail clients, instant messaging clients, discussion software, document editing software, etc.

The service implementation type includes the hypertext transfer protocol (HTTP) streaming as a networking protocol. The service implementation type thus includes distributed, collaborative, hypermedia information systems, in particular data communication for the World Wide Web.

The service implementation type includes the Real-time Transport Protocol (RTP) streaming and thus includes standardized packet formats for delivering audio and video over IP networks. The service implementation type includes RTP streaming used in communication and entertainment systems that involve streaming media, such as telephony, video teleconference applications and web-based push-to-talk features. The service implementation type includes HTML5 streaming as a language for structuring and presenting content for the World Wide Web, a core technology of the Internet. HTML5 is the fifth revision of the HTML standard originally created in 1990 and most recently standardized as HTML4 in 1997. Its core aims have been to improve the language with support for the latest multimedia while keeping it easily readable by humans and consistently understood by computers and devices such as web browsers, parsers, etc. HTML5 is intended to subsume not only HTML4, but XHTML1 and DOM2HTML, in particularly JavaScript as well. The service implementation type also includes HTML streaming in its lower versions like HTML4 etc. and it includes JavaScript streaming applications.

In a second possible implementation form of the method according to the first aspect as such or according to the first implementation form of the first aspect, the determining the service implementation type comprises at least one of: capturing network packets of a network packet stream transporting the service, and determining a type of the captured network packets, capturing a service request transmitted by the terminal towards the server, and capturing a message exchanged between the server and the terminal.

The service implementation type is information exchanged between a server and a terminal when a service session is initiated. This information is transported by network packets of the network packet stream transporting the service or by a service request message used for initialization of the service or by messages exchanged between the server and the terminal. The method is able to acquire this information. In a third possible implementation form of the method according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the determining the transition comprises at least one of: inspecting a type of network packets of a network packet stream exchanged between the terminal and the server, and inspecting a payload field of a network packet of a network packet stream exchanged between the terminal and the server.

Network packets comprise a type field which indicates the type of packet, e.g. an IP packet, a UDP packet, a TCP packet, an RTP packet, etc. This type is available from the packet header and may be acquired by Shallow Packet Inspection (SPI). SPI investigates types of traffic based on ports. It inspects IP packets up to the layer 4 (TCP/UDP layer) of the OSI model, extracts basic protocol information such as IP addresses (source, destination) and other low-level connection states. This information typically resides in the packet header and reflects only

rudimentary information about the communication. SPI applied to mobile communications systems can provide KPIs and metrics on accessibility, throughput, port usage, data volume, data retransmission and loss, etc. SPI can be used for blocking ports, e.g. in firewall technology. The payload of the packet and its start address in the packet depends on the type of packet, as the packet type defines the packet structure. For inspecting the payload of the data packet, Deep Packet Inspection (DPI) can be applied. DPI focuses on analyzing all the content of data packets passing through the network, which includes the headers and the data protocol structures (as opposed to the prior "Shallow Packet Inspection" that would only analyze the packet header), and compares this content against rules or signatures (for example, virus signatures). Based on these rules or signatures, the traffic will be treated appropriately by blocking, allowing, or tagging the packets. As a result, this would prevent malicious intrusions or viruses to penetrate a protected network by analyzing the threats buried within the data. By applying SPI, the method can acquire the desired information very fast, e.g. if a lot of sessions have to be analyzed in parallel, SPI can provide the required efficiency. By applying DPI, the method can focus on a single session and gather accurate information on that session, e.g. for failure analysis or precise modeling the user experience centric service model of a specific user.

In a fourth possible implementation form of the method according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the user-originated reason is determined if the service has left the first service state or the second service state after a predetermined period of time.

The user may need a reaction time for interacting with the network after he has perceived a quality degradation. Therefore, a change from the first or second service state to another service state takes some time if the change is caused by a user originated interaction. If a transition takes place before a predetermined period of time, a reason„wrong stream" is determined.

The transition from one of the states to another one of the states is a measurable event, while a transition between one and the same state, which is a virtual transition, cannot be measured. A timer expiring at intermediate time intervals makes virtual transitions observable. The impact on the user appreciation can be measured in continuous time intervals.

In a fifth possible implementation form of the method according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the user-originated reason is determined by emulating a behavior of a video buffer in the terminal.

A buffer emulator emulates, i.e. reconstructs, a receive buffer in the user terminal. That means, the buffer emulator provides a buffer model of the receive buffer in the user terminal. The buffer emulator comprises a buffer which is configured to buffer multiple streaming packets, e.g. video packets. The buffer has a buffer size b. The buffer size b which represents a size of the receive buffer in the user terminal corresponds to a measure of time, e.g. seconds, of a streamed file which is stored and respectively buffered in the form of streaming packets in the receive buffer before being streamed by the user. The larger the size of the receive buffer emulated by the buffer is, the more data packets can be stored in the receive buffer of the terminal before the streaming file is played and the less buffer stall events will occur. Streaming packets are received by the network with an instantaneous network rate r(t), also called network packet rate, and each packet is provided to a playback unit for playing the stream with a playback rate v(t). Depending on the

instantaneous network rate r(t), the receive buffer and thus the emulated buffer is filled with streaming packets until the buffer size b representing the size of the receive buffer in the terminal is reached. When the buffer is filled up to the buffer size b, the receive buffer in the terminal is sufficiently full and the terminal starts playing the stream at the playback rate v(t). If the network rate r(t) is greater than the playback rate v(t), the buffer is filled with packets. If the playback rate v(t) is greater than the network rate r(t), the receive buffer in the terminal and also the emulated buffer drains and eventually can become empty, causing the stream to stall on the terminal display. The buffer size b may form a minimum constraint on how much should be buffered before playback is started or restarted after a freeze.

The variables v(t) and r(t) are related to the end-to-end communication path. r(t) can be obtained by observing and monitoring the packets of the streaming session. v(t) can be obtained by deep packet inspection (DPI) on the first packets of the streaming session. v(t) is a parameter included in the metadata in some packets of the streaming file containing the data stream. The buffer size b cannot be obtained by packet inspection, it has to be estimated. Depending on the precision of the buffer emulator, the behavior of the video buffer in the terminal is determined. Small deviations in an estimated buffer size b can be the reason for a user- experienced quality degradation triggering a user-originated interaction.

In a sixth possible implementation form of the method according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the user-originated reason is determined by observing a number of video stalls during the service session.

When the video in the user terminal stalls, the user perceives a quality degradation. By observing these stalls, the method can determine the user-originated reason.

In a seventh possible implementation form of the method according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the user experience centric service model comprises at least two distinct user-originated reasons for the transition between the first service state and the second service state, and the method comprises determining a user- originated reason for each transition by observing the progress of the service.

Alternatively to modeling the transition from the first service state to the second service state by one transition with a plurality of reasons, the transition of the first service state to the second service state may also be modeled by a plurality of transitions from the first service state to the second service state, wherein each transition has only one reason. The same applies to the modeling of other transitions between other service states.

In an eighth possible implementation form of the method according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the method comprises adding a further reason for the transition between the first service state and the second service state by observing the progress of the service if the further reason for the transition occurs, pruning a further reason for the transition between the first service state and the second service state by observing the progress of the service if the further reason for the transition does not occur, adding a further state of the service when a transition towards the further service state is determined by observing the progress of the service, and pruning or merging service states of the service by observing the progress of the service.

Adding further transitions or reasons for a transition between states of the service may result from interactions the user is performing due to a given result the service provides. Transitions or reasons that do not produce any substantial impact on the appreciation of the user may be pruned. When transitions are determined having substantial impact on the appreciation of the user, further service states may be added. Service states that do not produce any substantial impact on the appreciation of the user may be pruned or merged, and the transitions to or from such states disappear. By such optimizing steps, the computational effort for determining the user experience centric service model can be reduced.

In a ninth possible implementation form of the method according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the first service state or the second service state comprises one of: a start of the video session, a start of downloading a video file from the server, a termination of the video session, network or user initiated a jump request of the user into the video file, a pause request initiated by the user, a resume request initiated by the user, a file request, a file play, and a file end. In a tenth possible implementation form of the method according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the reason for a transition comprises at least one of: for a termination of the video session, one of a quality-related user abort, a non- quality-related user abort, a quality-related network abort, a non-quality-related network abort, a content unavailable, and a network timeout; for a start of downloading a video file from the server, a download start; for buffering the video session, a display start.

In an eleventh possible implementation form of the method according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the service is providable to different groups of users, and the method is performed for different service sessions of the service for a certain group of users to obtain the user experience centric service model of the service for the certain group of users.

The method allows for different representations at different aggregation or granularity levels, i.e. session level, segment level and network level. At session granularity level the transitions are known, so a particular sequence of states and transitions can be identified for a session. If mappings from KPIs to QoE are defined, then given the order in which the transitions happened can yield the QoE experienced by the user at any given time. When the service is structured in sessions, each session can be identified as a unit of service and within the session different transitions between states of the session can be identified. Once the session is identified, the same user experience centric service model can be instantiated at different granularity levels which are: · Session level: the user experience centric service model is instantiated per session.

• Segment level: the user experience centric service model is instantiated per group of sessions meeting a certain criteria that allows to create segments (filtering)

· Network level: the model is instantiated for all the sessions of the service being modelled in a given network.

Scalability effects can be exploited and the computational complexity can be reduced. In particular when some sessions are finished while other ones are newly started, the user experience centric service model as a whole does not have to be recomputed as only the change of the user experience centric service model due to the finished or newly started sessions has to be computed.

In a twelfth possible implementation form of the method according to the eleventh implementation form of the first aspect, the certain group of users is determined by users fulfilling a certain criterion, in particular a common geographical location, and a common quality of service requirement.

In a thirteenth possible implementation form of the method according to the first aspect as such or according to the first implementation form of the first aspect, the user experience centric service model comprises a plurality of distinct user originated reasons for the transition between the first state and the second state, wherein the method comprises selecting a user-perceived quality indicator value of a set of user-perceived quality indicator values for each of the plurality of distinct user-originated reasons (R1 , R2) associated to the transition between the first state (State 1 ) and the second state (State 2).

By determining the transitions, the following steps can be evaluated: monitoring the user experience, analyzing usage of the service by evaluating the determined states and transitions, forecasting usage of the service by evaluating the user experience centric service experience and applying the user experience centric service experience to an assessment of a Quality of Experience. Keeping in mind segment and network granularity levels defined above, the user experience centric service models are keeping track of a series of statistics that can be used for monitoring the user experience centric service experience and analysing the usage of the service by a segment or all the users of the service globally. The transition rate/probability, the average number of times that each state was visited, the average KPI values among other can all be used to analyse the usage characteristics of the group of users of a segment or the network. In the case of a video streaming service, we can say that the session represented by the model has too many "pauses", leading to some analysis regarding the buffer size, the design of the player or quality of the network. Also, by using the QoE definitions mentioned above the service provider can forecast not only the characteristic session, e.g. how many times the user is expected to "stall" for the video

streaming service example, but also the expected QoE value resulting from it.

In a fourteenth possible implementation form of the method according to the thirteenth implementation form of the first aspect, the step of selecting a user- perceived quality indicator value of a set of user-perceived quality indicator values comprises selecting a different user-perceived quality indicator value of the set of user-perceived quality indicator values for each combination of a transition and a user-originated reason. In a fifteenth possible implementation form of the method according to the first aspect as such or according to the first implementation form of the first aspect, the method comprises observing progresses of a plurality of services of the same implementation type to determine a statistic probability of the transition between the first service state and the second service state. In a sixteenth possible implementation form of the method according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the method comprises storing the user experience centric service model as a Session Data Record. According to a second aspect, the invention relates to a computer program for performing the method according to the first aspect as such or according to any of the implementation forms of the first aspect when run on a computer.

According to a third aspect, the invention relates to a service monitoring device for modeling a service, the service being delivered from a server through a terminal to a user over a communication network during a service session, the device comprising a data interface unit being configured to capture network packets between the server and the terminal, and a service modeling unit configured to determine a service implementation type upon the basis of the captured network packets, the service implementation type indicating an implementation of the service state, to assign a user experience centric service model to the service implementation type, the service model comprising a first service state and a second service state, to determine a transition between the first service state and the second service state by observing a progress of the service during the service session, and to determine a user-originated reason for the transition based on the user experience centric service model (501 ) and by observing the progress of the service during the service session.

The service modeling unit can also be referred to as user experience centric service modeling unit, The service modelling unit is used to model a user experience when using the service in order to identify an impact of the different aspects of the service on the user perception. The service modelling unit utilises a methodological approach to identify the main aspects impacting user perception and a user experience centric service model to represent them functionally, wherein the methodology may use a top-down approach, the user is introduced in the modelling through its interaction with the service through a terminal delivering the service, relevant user interactions are actions the user effects on the service and results the service provides to the different actions the user performs, states of the service and transitions between states represent all possible sessions of the service, a transition from one state to a different one triggers an impact evaluation on the user perception, a transition from one state to the same state is a virtual transition that triggers an evaluation on the user perception at intermediate times during the session, reasons for transition from one state to each other state affects the evaluation of the impact of that transition on the user perception, and the methodology includes an optimization step to continuously improve the user experience centric service modelling. In a first possible implementation form of the service monitoring device according to the third aspect, the service is a streaming service provided by a server and the data interface unit is configured to execute the computer program according to the second aspect to perform the method according to the first aspect as such or according to any of the implementation forms of the first aspect.

In a second possible implementation form of the service monitoring device according to the third aspect as such or according to the first implementation form of the third aspect, the service monitoring device is forming a network probe on a network interface or a monitoring software in a centralized monitoring system. The communication network can for example be a network used for transmission in wireless networks, in particular in GSM/UMTS/LTE cellular networks and WLAN. According to an alternative implementation form, the communication network is a network used for transmission in wired networks, operating in a circuit-switched or packet-switched manner. According to an implementation form, the

communication network is IP-based, ATM-based or TDM-based. According to an implementation form, the communication network is an XDSL network. According to an implementation form, the communication network is an optical data network. According to an implementation form, the communication network is an electrical data network. According to an implementation form, the communication network provides optical and electrical transmission.

The invention can be applied to fixed or mobile networks. The invention can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations thereof.

BRIEF DESCRIPTION OF THE DRAWINGS Further embodiments of the invention will be described with respect to the following figures, in which:

Fig. 1 shows a block diagram of a method for modeling a service according to an implementation form;

Fig. 2 shows a block diagram of physical entities constituting a user experience centric service model according to an implementation form;

Fig. 3 shows a state diagram of a user experience centric service model according to an implementation form; Fig. 4 shows a state diagram of a user experience centric service model according to an implementation form;

Fig. 5 shows a block diagram of communication layers constituting a user experience centric service model according to an implementation form;

Fig. 6 shows a block diagram of a service monitoring device according to an implementation form; Fig. 7 shows a state diagram of a user experience centric service model of a video session between a server acting as a video server and a terminal acting as a video client according to an implementation form;

Fig. 8 shows a schematic diagram of a method or computer program according to an implementation form;

Fig. 9 shows a schematic diagram of a method or computer program according to an implementation form; Fig. 10 shows a schematic diagram of a method or computer program according to an implementation form;

Fig. 1 1 shows a schematic diagram of a method or computer program according to an implementation form;

Fig. 12 shows a listing of events and reasons of the user experience centric service model according to an implementation form;

Fig. 13 shows a listing of a session data record of the user experience centric service model according to an implementation form; Fig. 14 shows a state diagram of a user experience centric service model according to an implementation form;

Fig. 15 shows a state diagram of a user experience centric service model according to an implementation form;

Fig. 16 shows a state diagram of a user experience centric service model according to an implementation form; Fig. 17 shows a state diagram of a user experience centric service model according to an implementation form;

Fig. 18 shows a listing of a session data record of a user experience centric service model according to an implementation form;

Fig. 19 shows a state diagram of a user experience centric service model according to an implementation form; and

Fig. 20 shows a state diagram of a user experience centric service model according to an implementation form.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

Fig. 1 shows a block diagram of a method 100 for modeling a service 205 according to an implementation form. As depicted in Fig. 2, the service 205 is delivered through a terminal 209 to a user 21 1 over a communication network 203 during a service session. A progress of the service 205 is determined by the user 21 1 which interacts 213 with the service 205 through the terminal 209. The method 100 comprises a determining the service implementation type step 101 , an assigning the user experience centric service model step 103, a determining a transition step 105 and a determining a reason step 107. The service implementation type indicates an implementation of the service 205. As depicted in Fig.5, a user experience centric service model 501 is assigned 103 to the service implementation type. Alternatively, another service model may be

assigned to the service implementation type, e.g. a network centric service model, an operator-oriented service model or a performance-oriented service model. The service model 501 can be represented as a state diagram as depicted in Figs. 3 and 4. Accordingly, the user experience centric service model 300, 400 comprises a first service state (State 1 ) and a second service state (State 2). The transition t(1 ,2) between the first service state (State 1 ) and the second service state (State 2) is determined 105 by observing the progress of the service 205 during the service session. The user-originated reason R1 , R2 as shown in Fig. 4 for the transition t(1 ,2) is determined based on the user experience centric service model 501 . Fig. 2 shows a block diagram of physical entities constituting a user experience centric service model according to an implementation form. These entities are a terminal 209 delivering a service 205 to a user 21 1 , a server 207 delivering the service 205 and a network 203 for transmitting the service 205 from the server 207 to the terminal 209. For delivering the service 205, the server 207 communicates with the terminal 209 through the network 203 by using interactions 217 which are messages sent through the network 203. The terminal 209 constitutes the interface to the user 21 1 allowing the user 21 1 to initiate actions 213 and receiving results 215 upon these actions 213 with respect to the service 205 being delivered. The network 203 comprises network interfaces and network elements which are responsible for transmitting the interactions 217 between the terminal 209 and the server 207 in order to provide the service 205 from the server 207 to the terminal 209 and further to the user 211 .

The user experience centric service model takes the view of the user 211 of a service 205 instead of the service provider view. The user 211 perceives the service 205 as a series of results 215 to the actions 213 he/she performs on a terminal 209 through which the service 205 is received. The session is the unit of service 205 being received. In the case of a video streaming service, a session spans from the request of the video to the last frame played on the terminal 209, whether this frame is the final one or some intermediate one. The sequence of actions 213 and results 215 to those actions 213 throughout the session

represents the experience or perception 201 of the user 21 1 with the session of the service 205. This experience or perception 201 of the user 211 is also characterized as user-centric service experience 201 . Again, for the case of the video streaming service, the user 21 1 may request a video, then due to a stall in the play, the user 21 1 can decide to pause the player in the terminal 209 waiting for the buffer to contain enough packets to play fluently. The actions 213 of the user 21 1 are then a result from his/her own objectives and also a result of his/her experience 201 with the session of the service 205. The sequence of actions 213 and results 215 represents then the experience 201 of the user 211 for a particular session of the service 205. For each action 213 the user 21 1 expects a result 215. The degree of satisfaction with the received service 205 depends on the fitness (or matching) of the received results 215 with respect to the expected ones. The user satisfaction is a function of a wide set of factors, ranging from the user objectives and previous experiences with the service 205, i.e. the human factors, to more technical aspects like the terminal 209 capabilities, the network 203 and server 207 performances among others. Figure 2 represents the service 205 as seen by the user 21 1 and the main considerations for user experience centric service modelling. According to an implementation form, the user experience centric service model is implemented in the terminal 209. According to an implementation form, the user experience centric service model is implemented in the server 207. According to an implementation form, the user experience centric service model is implemented in a network interface or a network element of the network 203. Fig. 3 shows a state diagram of a user experience centric service model 300 according to an implementation form. According to an implementation form, the user experience centric service model 300 is implemented in one of the physical entities as depicted in Fig. 2. The user experience centric service model 300 comprises a state machine in which the states represent the actions 213 and results 215 of the user's 21 1 interaction with the service 205. The transitions between the states represent the ways in which the user 21 1 can interact with the service 205. The user experience centric service model represents then a session of the service 205 as seen by the user 21 1 .

The user experience centric service model 300 represents the service activities as seen by the user 21 1 , while also keeping a link to the technical implementation of the service 205 in order to be able to identify the states and the transitions by observing the interactions 217 between the terminal 209 and the server 207, and between the terminal/server 209/207 and the network 203. The transitions marked in Figure 3 by t(x,y) indicate a transition from state x to state y and for which transition the result 215 for the user 21 1 is observed as a one-time outcome for the current session. In Fig. 3, the user experience centric service model 300 comprises four states which are indicated as State 1 , State 2, State 3 and State 4. A transition from State 1 to State 2 is indicated as t(1 ,2) and back to State 1 is indicated as t(2,1 ). A transition from State 2 to State 3 is indicated as t(2,3) and back to State 2 is indicated as t(3,2). A transition from State 1 to State 4 is indicated as t(1 ,4), a transition from State 2 to State 4 is indicated as t(2,4) and a transition from State 3 to State 4 is indicated as t(3,4). Virtual transitions are denoted as transitions between one and the same state. A virtual transition from State 2 to State 2 is indicated as t(2,2) and a virtual transition from State 3 to State 3 is indicated as t(3,3).

According to an implementation form, the user experience centric service model 300 comprises a different number of states, in particular any integer number. According to an implementation form, the user experience centric service model 300 comprises a different number of transitions, in particular any integer number of transition and/or virtual transitions, in particular all possible transitions between different states and all possible virtual transitions within one and the same state.

When the service 205 is in such a state that it produces results that can be continuously appreciated by the user 211 , which is the "play video" state in the case of the video streaming service, this appreciation has two different outcomes: the real-time appreciation and the post-mortem appreciation of the result 215. The latter is represented by a transition to a different state. In order to account for the real-time appreciation, transitions noted as t(x,x) are introduced into the user experience centric service model 300. These intra-state transitions account for a "virtual transition" producing a result 215 that can be appreciated by the user 21 1. Virtual transition periodicity can be accommodated to that of a monitoring system evaluating satisfaction.

According to an implementation form, the service 205 is a video streaming service, State 1 is a "request video" state and State 2 is a "play video" state. While the video is playing in the video streaming service, the service stays in the "play video" state, but the user 211 is constantly evaluating the result 215 at every "virtual transition"

Fig. 4 shows a state diagram of a user experience centric service model 400 according to an implementation form. The user experience centric service model 400 has the same number of states and transitions as the user experience centric service model 300 depicted in Fig. 3. Additionally, to each of the transitions t(x,y) between different states x and y one or more reasons R1 , R2, R3 are attached.

In the user experience centric service model 400 the different reasons for a transition are represented by Rx. As the service 205 evolves through the session, the impact of an observed result 215 may trigger different evaluations from the user 21 1 , and even trigger different actions 213. A given transition might occur for different reasons, implicating that transition t(x,y) Rz is a transition from state x to state y due the reason z. The reasons R1 and R2 are attached to the transition t(1 ,2) from State 1 to State 2 and the reason R1 is attached to the transition t(1 ,2) from State 2 back to State 1 . The reasons R1 and R2 are attached to the transition t(2,3) from State 2 to State 3 and the reasons R1 , R2 and R3 are attached to the transition t(3,2) from State 3 back to State 2. The reasons R1 and R2 are attached to the transition t(1 ,4) from State 1 to State 4, the reason R1 is attached to the transition t(2,4) from State 2 to State 4 and the reasons R1 , R2 and R3 are attached to the transition t(3,4) from State 3 to State 4. For the virtual transitions t(2,2) and t(3,3) no reasons are attached to. Although every time denoted as "R1 ", the first reason R1 for the transition t(1 ,2) and the first reasons R1 for the other transitions like t(2,1 ), t(2,3), t(3,2), etc are typically different reasons.

Different reasons will trigger different appreciations of the result 215 on the user 21 1 , and different results 215 will cause different actions 213 by the user. In the case of the video streaming service, a transition from "play video" state to "end video" state may occur because of normal termination, i.e. end of file reached, but also may occur because of the user cancelled the play due to poor network performance because of recurrent rebuffering. The user evaluation of the service received will be impacted by the sequence of transitions and the different reasons. An algorithmic representation of the user experience centric service model 400 allows for visualizing the impact of each reason R1 , R2, R3 for every transition t(x,y) on the user appreciation of the resulting service 205 for a session. Key Performance Indicators (KPI), as shown in Fig. 5, which are needed to identify the sessions are calculated from the measurements coming from the different measurement points in the terminal 209, the network 203 and the server 207. The transitions t(x,y) produce an impact on the user 21 1 appreciation of the service 205 but don't measure the satisfaction itself. Mapping the impact as modelled by the user experience centric service model 400 to a measure of satisfaction which is the Quality of Experience (QoE), 521 , as depicted in Fig. 5, is performed by using evaluation models.

Fig. 5 shows a block diagram of communication layers constituting a user experience centric service model 501 according to an implementation form. The user experience centric service model 501 comprises a network-centric service modelling layer 503 and an additional modelling layer, which is called the user experience centric service modeling (USM) layer 505. The user experience centric service model 501 describes the relationship between the USM layer 505 and the service management domains 507, 509, 511 with their application layers 515 of KQIs and business layers 517 of KQIs, the network layers of KPIs 519 and the measured parameters 513.

The network-centric service modelling layer 503 is a collection of data aggregated and correlated according to the relationships given by the mapping. Service management domains 507, 509 and 51 1 are defined that group the KQIs and KPIs into metrics that are related to the operational aspects of the service. The generally used service management domains described here are: retainability domain 507, accessibility domain 509 and integrity domain 51 1. Each of these service management domains relates to one aspect of the service dealing with the customer received quality. The accessibility domain 509 relates to the ability to obtain a service from the network, the retainability domain 507 relates to the ability to keep the service once obtained, and the integrity domain 511 relates to the ability of the network to provide the service without impairments once obtained. Figure 5 represents the resulting mapping of the retainability domain 507, the accessibility domain 509 and the integrity domain 51 1 to the corresponding measurement parameters 513 through the different layers of KQIs and KPIs representing the application layer 515 of KQIs, the business layer 517 of KQIs and the network layer 519 of KPIs. There could be more than one KQI describing the quality of a service management domain.

The network-centric service modelling layer 503 lays the basis for establishing relationships between KQIs and KPIs, but the information is organized in different layers: application layer 515 and business layer 517 for the KQIs and network layer 519 for the KPIs. All the layers are covered from the resources to the high level KQIs through the network KPIs and business and application KQIs. The network-centric service modelling layer 503 puts forward a business process view of the service which is the view of a service provider or the view of the information technology (IT). In the network-centric service modelling layer 503 alone, the user 21 1 is not considered as a receiver of the service.

The user's perspective is considered by the USM layer 505 constituting an additional modelling layer complementing the network-centric service modelling layer 503. Thus, the main "human factors" impacting the user perception of the received quality can be made evident. A mapping from the human factors to the service management domain KQIs, i.e. the retainability domain 507, the

accessibility domain 509 and the integrity domain 51 1 , allows linking the Quality of Experience (QoE) 521 of the user 21 1 to the already existing service models, i.e. to the network-centric service modelling layer 503, for a service provider view of the perceived quality for the service being delivered. This new mapping allows tying directly the QoE 521 to the service component's KPIs. Figure 5 shows the USM layer 505, directly facing the user 21 1 of the service. From the user experience centric resulting service model 501 , it is possible to reuse the existing service model, i.e. the network-centric service modelling layer 503 or to map directly to the network KPIs 519 and to the measured parameters 513.

Fig. 6 shows a block diagram of a service monitoring device according to an implementation form. The service monitoring device 600 comprises a data interface unit 607 and a service modeling unit 609, also referred to as user experience centric service modeling unit 609.

The service monitoring device 600 is modeling a service 205 which is delivered from a server 207 through a terminal 209 to a user 21 1 over a communication network 203 during a service session, as depicted in Fig. 2. A progress of the service 205 is determined by the user 21 1 interacting 213 with the service 205 through the terminal 209. The data interface unit 607 captures network packets between the server 207 and the terminal 209.

The service modeling unit 609 is configured to determine a service implementation type upon the basis of the captured network packets and to assign a user experience centric service model 400, 501 to the service implementation type as described above with respect to Figures 3, 4 and 5. The service implementation type indicates an implementation of the service state. The user experience centric service model 400 comprises a first service state (State 1 ) and a second service state (State 2) as depicted in Figures 3 and 4. The service modeling unit 609 further determines at least one transition t(1 ,2) between the first service state (State 1 ) and the second service state (State 2) by observing the progress of the service 205 during the service session. The service modeling unit 609 further determines a user-originated reason R1 , R2 for the transition t(1 ,2) by observing the progress of the service 205 during the service session.

According to an implementation form, the service modeling unit 609 comprises a buffer emulator for emulating a receive buffer in the video client 603, which receive buffer is configured to buffer a video file received from the video server 601 before playback. The states and transitions are derived from the captured data traffic by retrieving network data rates offered by the network and by retrieving a bitsize of the video file and by evaluating buffer events received from the buffer emulator. According to an implementation form, the service monitoring device 600 is a Network Monitoring Probe placed at TCP/HTTP level to monitor a HTTP video streaming session. According to an implementation form, the communication path between the server 207 and the terminal 209 is an end-to-end communication path between a video server and a mobile client accessing an LTE network. The service monitoring device 600 accesses the TCP layer and can be placed anywhere in the communication path, including the end devices 209 and 207. TCP provides a communication service at an intermediate level between an application program and the Internet Protocol (I P). That is, when an application program, e.g. the terminal 209 desires to send a large chunk of data across the Internet using IP, instead of breaking the data into IP-sized pieces and issuing a series of IP requests, the software can issue a single request to TCP and let TCP handle the IP details.

IP works by exchanging pieces of information called packets. A packet is a sequence of octets and consists of a header followed by a body. The header describes the packet's destination and, optionally, the routers to use for forwarding until it arrives at its destination. The body contains the data IP is transmitting.

Due to network congestion, traffic load balancing, or other unpredictable network behavior, IP packets can be lost, duplicated, or delivered out of order. TCP detects these problems, requests retransmission of lost data, rearranges out-of-order data, and even helps minimize network congestion to reduce the occurrence of the other problems. Once the TCP receiver has reassembled the sequence of octets originally transmitted, it passes them to the application program. Thus, TCP abstracts the application's communication from the underlying networking details. Therefore, data interfaces of monitoring devices according to implementation forms can connect to the TCP layer without caring about transmission in lower protocol layers. TCP is optimized for accurate delivery rather than timely delivery, and therefore, TCP sometimes incurs relatively long delays (in the order of seconds) while waiting for out-of-order messages or retransmissions of lost messages. It is not particularly suitable for real-time applications such as Voice over IP. For such applications, protocols like the Real-time Transport Protocol (RTP) running over the User Datagram Protocol (UDP) are usually recommended instead. Data interface units 607 of service monitoring devices 600 according to implementation forms connect to the UDP layer or the RTP layer. Thus, they can be applied for Voice over IP applications.

According to some implementation forms, the service monitoring device 600 is used for HTTP video streaming monitoring systems using the HTTP layer. The Hypertext Transfer Protocol (HTTP) is a networking protocol for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web. According to an implementation form, RFC 2616, which defines HTTP/1 .1 , is used as version of the HTTP protocol.

HTTP is an Application Layer protocol designed within the framework of the Internet Protocol Suite. The protocol definitions presume a reliable Transport Layer protocol for host-to-host data transfer. The Transmission Control Protocol (TCP) is the dominant protocol in use for this purpose. According to

implementation forms, the data interface unit 607of the service monitoring device 600 is configured to connect to an end-to-end communication path at TCP layer between the server 207 and the terminal 209. However, HTTP has found application even with unreliable protocols, such as the User Datagram Protocol (UDP) in methods such as the Simple Service Discovery Protocol (SSDP).

According to implementation forms, the data interface unit 607 of the service monitoring device 600 is configured to connect to an end-to-end communication path at UDP layer between the server 207 and the terminal 209. HTTP/1 .1 can reuse a connection multiple times, to download, for instance, images for a just delivered page. According to implementation forms, the data interface unit 607 of the service monitoring device 600 is configured to connect to an end-to-end communication path at HTTP layer between the server 207 and the terminal 209 in order to reuse connections multiple times. Hence service

monitoring devices 600 according to implementation forms experience less latency as the establishment of TCP connections presents considerable overhead.

HTTP functions as a request-response protocol in the client-server computing model. In HTTP, a web browser, for example, acts as the terminal 209 according to an implementation form, while an application running on a computer hosting a web site functions as a server 207 according to implementation forms. The terminal 209 submits an HTTP request message to the server 207. The server 207, which stores content, or provides resources, such as HTML files, or performs other functions on behalf of the terminal 209, returns a response message to the terminal 209. A response contains completion status information about the request and may contain any content requested by the terminal 209 in its message body. According to some implementation forms, the terminal 209 is referred to as a user agent (UA) or as a web browser or web crawler.

The HTTP protocol is designed to permit intermediate network elements to improve or enable communications between terminals 209 and servers 207.

According to implementation forms, the service monitoring device 600 is placed in the terminal 209 or in the server 207 or in any of the intermediate network elements. High-traffic websites often benefit from web cache servers that deliver content on behalf of the original, so-called origin server to improve response time. According to implementation forms, the service monitoring device 600 is placed in an origin server. HTTP proxy servers at network boundaries facilitate

communication when clients without a globally routable address are located in private networks by relaying the requests and responses between terminals 209 and servers 207. According to implementation forms, the service monitoring device 600 is placed in a HTTP proxy server.

Fig. 7 shows a state diagram of a user experience centric service model 700 of a video session between a server 207 acting as a video server and a terminal 209 acting as a video client according to an implementation form. The state diagram of the user experience centric service model 700 comprises different states and transitions between states, which characterize a video session as perceived by the end user. The user experience centric service model 700 illustrated in Fig. 7 comprises three states which are a first state (state 1 , 701 ), a second state (state 2, 702) and a third state (state 3, 703). The user experience centric service model 700 comprises a transition 712 between the first state 701 and the second state 702, a transition 713 between the first state 701 and the third state 703 and a transition 732 between the second state 702 and the third state 703. The second state 702 comprises three sub-states which are a first sub-state (state 2.1 , 721 ), a second sub-state (state 2.2, 722) and a third sub-state (state 2.3, 723) and transitions between these sub-states.

The user 21 1 starts the video session by making a file request, or by jumping in an already opened video stream (State 1 File Request/Jump in File, 701 ). The Play file state (state 2, 702) represents the state of the video session in which the user gets the requested video file displayed on the screen. This state contains three sub-states , namely 2.1 Display, 721 , when the file is displayed on the screen without interruption, the 2.2 Stall sub-state, 722, in which the user observes a video freeze on the screen, while the video player rebuffers, and sub-state 2.3 Pause, 723, in which the user intently pauses the playback of the video file. The third state (state 3, 703) is represented by the end of the video session. The arrows of the user experience centric service model 700 represent possible transitions between states. Each state or sub-state transition is accompanied by a reason for transition, and is triggered by a measurable event by the monitoring system, which is not shown in Fig. 7 but will be shown in Fig. 17. Each transition is characterized by at least one reason (R), and one triggering event (E) as will be described later with respect to Figs. 14 to 17.

To each state a set of Key Quality Indicators (KQIs) according to the

representation of Fig. 5 is associated which can be computed starting from measurable events observed by the monitoring system monitoring the video session.

According to some implementation form, the user experience centric service model 700 is applied to single session monitoring. According to an alternative implementation form, the user experience centric service model 700 is applied on aggregated level, in order to describe the video experience of the video session belonging to a network segment which can be all VIP (very important) users of a video service or all users accessing the video service in a given time interval, or to a complete network which means all video service users in a network.

Fig. 8 shows a schematic diagram of a computer program 800 according to an implementation form. The computer program 800 is represented in the form of a finite state machine diagram. The computer program 800 is configured for applying the user experience centric service model 700 as described with respect to Fig. 7 to the monitoring of a single video session. The finite state machine diagram 800 is used to identify the model states and transitions for a video session. The machine can be implemented in a service monitoring device 600 as described with respect to Fig. 6, in particular in the service modelling unit 609. The service monitoring device 600 can be implemented as service monitoring tool for video streaming systems. Starting from passive monitoring of traffic (state "START Listen", 801 ), the user experience centric service model 700 is instantiated once a new video session 803 is identified by receiving the event "EO.No", 805. An evaluation and computation model (ECM) applied to the observed traffic, which is a buffer emulator model according to some implementation form, is started 807 and a Session Data Record (SDR or DSR) is initialized for the video session when the event "EO.Yes", 809 is received. The events and reasons are identified either by observing network traffic for the session, i.e. through deep Packet Inspection or simple packet monitoring for the session, or through the evaluation and

computation model (ECM) applied to the observed traffic. The evaluation and computation model (ECM) may be implemented in the service modelling unit 609 while the observing of network traffic may be implemented in the data interface unit 607. From now on, the finite state machine is in a frame receiving state (state "FR", 81 1 ) watching the traffic associated to the identified video session, and recognizing the events which trigger the state (or sub-state) transitions inside the user experience centric service model 700. At the same time, the finite state machine collects the necessary information (events, reasons and other measurements) in order to compute the associated KQIs for the states and transitions. The information is organized as a Session Data Record (SDR or DSR). With each identified event E1 , E2, E3, the CDR gets updated with the relevant information.

When a download start event E2, 813 is received in the "FR" state 81 1 , the

Session Data Record is updated 815 and the finite state machine stays in the "FR" state 81 1 . When an ECM event E3, 817 is received in the "FR" state 811 , the Session Data Record is updated 819 and the finite state machine performs a transition into the "PLAY" state 821 , namely into the sub-state 2.1 of the "PLAY" state 821 . When an "Abnormal Termination" event E1 , 823 is received in the "FR" state 81 1 , the reason of this event is evaluated. Upon the reason "User Abort", R1 , 825 the Session Data Record is updated 831 , the ECM is stopped and the finite state machine performs a transition into the "END" state 837 where the video session is ended. Upon the reason "SP Abort, Content Unavailable", R3, 827 the Session Data Record is updated 833, the ECM is stopped and the finite state machine performs a transition into the "END" state 837. Upon the reason "Network Abort", R2, 829 the Session Data Record is updated 835, the ECM is stopped and the finite state machine performs a transition into the "END" state 837.

When an event E4, 839 is received in the "PLAY" state 821 , the finite state machine performs a transition into the "END" state 837. When an event E5, 841 is received in the "PLAY" state 821 , the finite state machine performs a transition into the "FR" state 81 1 .

Fig. 9 shows a schematic diagram of a computer program 900 according to an implementation form. The computer program 900 is represented in the form of a finite state machine diagram. The computer program 900 is configured for applying the user experience centric service model 700 as described with respect to Fig. 7 to the monitoring of a single video session. The finite state machine diagram 900 is used to identify the model states and transitions for a video session. The machine can be implemented in a service monitoring device 600 as described with respect to Fig. 6, in particular in the service modelling unit 609. The service monitoring device 600 can be implemented as service monitoring tool for video streaming systems. Starting from passive monitoring of traffic (state 1 , 901 ), the user experience centric service model 700 is instantiated once a new video session 903 is identified by receiving the event "EO.New", 905.

An evaluation and computation model (ECM) applied to the observed traffic, which is a buffer emulator model according to some implementation form, is started 907 when the event "EO.Yes", 909 is received. The events and reasons are identified either by observing network traffic for the session, i.e. through deep Packet

Inspection or simple packet monitoring for the session, or through the evaluation and computation model (ECM) applied to the observed traffic. The evaluation and computation model (ECM) may be implemented in the service modelling unit 609 while the observing of network traffic may be implemented in the data interface unit 607. From now on, the finite state machine is in a frame receiving state (state 2, 91 1 ) watching the traffic associated to the identified video session, and recognizing the events which trigger the state or sub-state transitions inside the user experience centric service model 700. At the same time, the finite state machine collects the necessary information (events, reasons and other measurements) in order to compute the associated KQIs for the states and transitions. The information is organized as a Session Data Record (SDR or DSR). With each identified event E1 , E2, E3, the CDR gets updated with the relevant information. When an event E2, 913 is received in state 2, 91 1 , the impact is evaluated by the ECM 915 and the finite state machine stays in state 2, 91 1. When a "Buffer Full" event E3, 917 is received in state 2, 91 1 , the Session Data Record is updated 919 and the finite state machine performs a transition into the "PLAY" state 921 , namely into the sub-state 2.1 of the "PLAY" state 921. When an event E1 , 923 is received in state 2, 91 1 , the reason of this event is evaluated. Upon the reason R1 , 925 the impact is evaluated by the ECM 931 and the finite state machine performs a transition into the "END" state 937 where the video session is ended. Upon the reason R3, 927 the impact is evaluated by the ECM 933 and the finite state machine performs a transition into the "END" state 937. Upon the reason R2, 929 the impact is evaluated by the ECM 935 and the finite state machine performs a transition into the "END" state 937.

When an event E4, 939 is received in the "PLAY" state 921 , the finite state machine performs a transition into the "END" state 937. When an event E5, 941 is received in the "PLAY" state 921 , the finite state machine performs a transition into the "FR" state 81 1 as depicted in Fig. 8.

Fig. 10 shows a schematic diagram of a computer program 1000 according to an implementation form. The computer program 1000 is represented in the form of a finite state machine diagram. The computer program 1000 is configured for applying the user experience centric service model 700 as described with respect to Fig. 7. The machine can be implemented in a service monitoring device 600 as described with respect to Fig. 6, in particular in the service modelling unit 609.

Upon an event E3, 1017 the finite state diagram has performed a transition from a "FR" state as depicted in Fig. 8 into the "PLAY" state 1021 . The event E3, 1017 may correspond to the event E3, 817 as depicted in Fig. 8 and may correspond to the event E3, 917 as depicted in Fig. 9. The "PLAY" state 1021 may correspond to the "PLAY" state 821 as depicted in Fig. 8 an the "END" state 1037 may correspond to the "END" state 837 as depicted in Fig. 8.

When a "User Jump in File" event E5, 1043 is received in the "PLAY" state 1021 , the Session Data Record and the ECM are updated 1045, and the finite state machine performs a transition 1047 into the "FR" state 811 as depicted in Fig. 8. When a "Termination" event E4, 1023 is received in the "PLAY" state 1021 , the reason of this event is evaluated. Upon the reason "User Abort", R1 , 1025 the Session Data Record is updated 1031 , the ECM is stopped and the finite state machine performs a transition into the "END" state 1037 where the video session is ended. Upon the reason "Download finished", R4, 1049 the Session Data Record is updated 1051 , the ECM is stopped and the finite state machine performs a transition into the "END" state 1037. Upon the reason "Network Abort", R2, 1029 the Session Data Record is updated 1035, the ECM is stopped and the finite state machine performs a transition into the "END" state 1037.

Fig. 1 1 shows a schematic diagram of a computer program 1 100 according to an implementation form. The computer program 1 100 is represented in the form of a finite state machine diagram. The computer program 1 100 is configured for applying the user experience centric service model 700 as described with respect to Fig. 7. The machine can be implemented in a service monitoring device 600 as described with respect to Fig. 6, in particular in the service modelling unit 609. Upon an event "ECM", E3, 1 1 17 the finite state diagram has performed a transition from a "FR" state as depicted in Fig. 8 into the "PLAY" state 1 121 . The event E3, 1 1 17 may correspond to the event E3, 817 as depicted in Fig. 8 and may

correspond to the event E3, 917 as depicted in Fig. 9 and may correspond to the event E3, 1017 as depicted in Fig. 10. The "PLAY" state 1 121 may correspond to the "PLAY" state 821 as depicted in Fig. 8 or to the "PLAY" state 1021 as depicted in Fig. 10.

The "PLAY" state 1 121 comprises three sub-states which are a "DISPLAY" sub- state 2.1 , 1 151 , a "STALL" sub-state 2.2, 1 153 and a "PAUSE" sub-state 2.3, 1 155. The sub-state "DISPLAY", 1 151 may correspond to the sub-state 2.1 of the

"PLAY" state 821 as depicted in Fig. 8.

When an "ECM" event E6, 1 157 is received in the "DISPLAY" sub-state 1 151 , the Session Data Record is updated 1159, and the finite state machine performs a sub-transition or a virtual transition into the "STALL" sub-state 1 153. When a "User Pause" event E7, 1 161 is received in the "DISPLAY" sub-state 1151 , the Session Data Record is updated 1 163, and the finite state machine performs a sub- transition or a virtual transition into the "PAUSE" sub-state 1 155.

When a "User Pause" event E7, 1 165 is received in the "STALL" sub-state 1153, the Session Data Record is updated 1 167, and the finite state machine performs a sub-transition or a virtual transition into the "PAUSE" sub-state 1 155. When a "ECM" event E9, 1 169 is received in the "STALL" sub-state 1 153, the Session Data Record is updated 1171 , and the finite state machine performs a sub- transition or a virtual transition into the "DISPLAY" sub-state 1151 .

When a "User Resume" event E8, 1 173 is received in the "PAUSE" sub-state 1 155, the Session Data Record is updated 1175, and the finite state machine performs a sub-transition or a virtual transition into the "DISPLAY" sub-state 1 151 . When an event E4, 1 139 is received in the "PLAY" state 1 121 , the finite state machine performs a transition into the "END" state 837 as depicted in Fig. 8. When an event E5, 1 141 is received in the "PLAY" state 1 121 , the finite state machine performs a transition into the "FR" state 81 1 as depicted in Fig. 8.

Fig. 12 shows a listing of events and reasons monitored for the given session of the user experience centric service model and describes the method used to identify each of them according to an implementation form. The events and reasons may occur in a user experience centric service model 700 as described with respect to Fig. 7 or in a computer program 800, 900, 1000, 1100 as described with respect to Figs. 8, 9, 10 and 1 1 .

"EO.Yes" represents the beginning of a new video session, which will trigger the transition of the state machine into "File Request" state. The event is defined by observing a new "HTTP GET" message for a video file request. For example, youtube videos are requested by a "HTTP GET /playbackvideo" command followed by the unique identity of the video file.

"E0.No" or "EO.New" represents any other packet having been received.

"E1 .Abnormal Termination" represents an abnormal termination of the video session because of the reasons "User abort", R1 indicating a "TCP RTS" packet received on the uplink, "Network Abort", R2 indicating that a network timeout timer has expired and "Content Unavailable", R3 indicating a "HTTP 203" message indicating that a "ContentUnavailable" packet has been received on the downlink.

"E2. Download Start" represents a "HTTP 200 OK" packet received on the downlink.

"E3.ECM" and "E9.ECM" represent a buffer event triggered by the ECM. "E4.Termination" represents a "TCP FIN ACK" message and a session termination because of the reason R4,"File Download Complete".

"E5.User Jump in file" represents a "HTTP GET" request from the user and a "playbackvideo" packet on the uplink.

"E6.ECM" represents a buffer event triggered by the ECM.

"E7.User Pause" represents a pause in the video session because of the reasons "Cannot be observed in HTTP streaming" or "RTSP PAUSE message on the uplink".

"E8.User Resume" represents a resume of the video session because of the reasons "Cannot be observed in HTTP streaming" or "RTSP PLAY message on the uplink".

Tables 1 -6 present a list of Key Quality Indicators (KQI)s attached to each event, and the method to compute these KQIs according to an implementation form. Together with the service model states and transitions, they describe the user session for video streaming, as it is perceived by the user. According to further implementation forms, further KQIs are accommodated, either as independent KQIs or as processing of presented KQIs, e.g. as sum, as average, as count, or as minimum operations.

Method Method

Event Reason KQI KPi

(QoS) (KPi)

T1 - Time in itial file request

R1 - measu reme (EO.Yes)

user T2-T1 Time to abort

nt

abort T2 - Time TCP RST

(E1.R1 )

T1 - Time in itial file request

R2 - measu reme (EO.Yes)

network T2-T1 Time to abort nt

El

abort T2 - Time of TCP timeout

(E1.R2)

T1 ^■· Time in itial file request

R3 - measu reme (EO.Yes)

content

T2-T1 Time to abort nt

u navaiia

b!e T2 - Time HTTP 203 Not

Fou nd

Table 1. KQI definition and computation for event E1

Table 2. KQI definition and computation for event E2

Table 3. KQI definition and computation for event E3

Table 4. KQI definition and computation for event E4

Table 5. KQI definition and computation for event E5

Table 6. KQI definition and computation for event E6.ECM, E9.ECM

According to an implementation form, for each state and transition, the list of KQIs is further processed in order to obtain one QoE metric for each state, and ultimately, one QoE metric for the entire model. To this end, linear and non-linear functions on the set of KQIs for each state are used to combine them into a single QoE metric for the state. Another function, linear or non-linear on the set of QoE values for the states is used to combine them together into a single QoE metric for the complete model. The functions can either be arbitrarily set by the model operator, or can be deduced from subjective user tests. Exact instances for these functions can be e.g., an exponential function for State 1 , and MOS (mean opinion score) computation algorithms for the State 2. Other functions can be envisioned as well.

Fig. 13 shows a listing of a session data record of the user experience centric service model according to an implementation form. The session data record can be implemented in a service monitoring device 600 as described with respect to Fig. 6, in particular in the service modelling unit 609.

The figure gives details of the information contained in the CDR, which is created by the finite state machine for each monitored video session. The notation used in Figure 13, e.g., Update CDR(1 ) relate to the same notation as used in figures 8, 9, 10 and 1 1.

The CDR is updated by using an index. An index 0 indicates adding information to the CDR concerning the user identification, the user class or segment, the port number, i.e. source and destination addresses, the IP address, i.e. source and destination addresses, the protocol on top of the IP layer, the session start time to, the user location, i.e. the eNB identification, the user device capabilities, the initial buffer size bi and the video identification. An index 1 indicates adding information to the CDR concerning the session end time t1 and the reason for termination being a user abort. An index 2 indicates adding information to the CDR concerning the session end time and the reason for termination being a content unavailable message. An index 3 indicates adding information to the CDR concerning the session end time and the reason for termination being a network timeout. An index 4 indicates adding information to the CDR concerning the time of the first packet received on downlink, the video resolution, the video duration, the video bit rate, the video file size, the video frame rate and the video encoder profile. An index 5 indicates adding information to the CDR concerning the display start time t2 and the rebuffering index being set to 0. An index 6 indicates adding information to the CDR concerning the session end time and the reason for termination being a download finished. An index 7 indicates adding information to the CDR concerning the jump in file time and the Newpacket filter, i.e. the IP address and port number, the source and destination address and the protocol type. An index 8 indicates adding information to the CDR concerning an index for the number of rebufferings incremented by and the time on which the buffer runs empty. An index 9 indicates adding information to the CDR concerning the time on which the buffer runs full.

Fig. 14 shows a state diagram of a user experience centric service model 1400 according to an implementation form. The user experience centric service model 1400 may be implemented in a service monitoring device 600 as described with respect to Fig. 6, in particular in the service modelling unit 609.

The user experience centric service model 1400 is applied here to one video session. The user requests the file, thus entering STATE 1 , 1401 . After 1 sec, the user player starts displaying the video, thus the user experience centric service model 1400 enters in sub-state 2.1 , 1403. The video plays without interruption for 125 sec, with a quality metric (QM) of 90 on a scale of 1 -100. The video download finishes, and the connection is closed normally, thus the user experience centric service model 1400 enters STATE 3, 1405.

The STATE 1 , 1401 which is the "File Request" state may correspond to the "FR" state 81 1 as depicted in Fig. 8. The sub-state 2.1 , 1403 which is the "DISPLAY" sub-state may correspond to the 2.1 sub-state as depicted in Fig. 8 or to the "DISPLAY" sub-state 1151 as depicted in Fig. 1 1 . The STATE 3, 1405 which is the "END" state may correspond to the "END" state 837 as depicted in Fig. 8. Fig. 15 shows a state diagram of a user experience centric service model 1500 according to an implementation form. The user experience centric service model 1500 may be implemented in a service monitoring device 600 as described with respect to Fig. 6, in particular in the service modelling unit 609.

The user requests a file in STATE 1 , 1501. It starts displaying the file after 1.5 sec in STATE 2.1 , 1503. The video displays for 200 sec, during which, the player stalls once in STATE 2.2, 1507 for a duration of 3 sec. The quality measure of STATE 2, 1509 is 75 on a scale from 1 -100. The video finished downloading, and the session gets closed normally in STATE 3, 1505.

The STATE 1 , 1501 which is the "File Request" state may correspond to the "FR" state 81 1 as depicted in Fig. 8 or to the STATE 1 , 1401 as depicted in Fig. 14. The sub-state 2.1 , 1503 which is the "DISPLAY" sub-state may correspond to the 2.1 sub-state as depicted in Fig. 8 or to the "DISPLAY" sub-state 1 151 as depicted in Fig. 1 1 or to the "DISPLAY" sub-state 1403 as depicted in Fig. 14. The sub-state 2.2, 1507 which is the "STALL" sub-state may correspond to the "STALL" sub- state 1 153 as depicted in Fig. 1 1. The STATE 3, 1405 which is the "END" state may correspond to the "END" state 837 as depicted in Fig. 8 or to the "END" state 1405 as depicted in Fig. 14.

Fig. 16 shows a state diagram of a user experience centric service model 1600 according to an implementation form. The user experience centric service model 1600 may be implemented in a service monitoring device 600 as described with respect to Fig. 6, in particular in the service modelling unit 609.

The user requests a video file in STATE 1 , 1601 . After 8 seconds of waiting the video still does not start displaying. The user aborts, by closing the video session in STATE 3, 1605. The STATE 1 , 1601 which is the "File Request" state may correspond to the "FR" state 81 1 as depicted in Fig. 8 or to the STATE 1 , 1401 , 1501 as depicted in Figs. 14 and 15. The STATE 3, 1605 which is the "END" state may correspond to the "END" state 837 as depicted in Fig. 8 or to the "END" state 1405, 1505 as depicted in Figs. 14 and 15.

Fig. 17 shows a state diagram of a user experience centric service model 1700 according to an implementation form. The user experience centric service model 1700 may be implemented in a service monitoring device 600 as described with respect to Fig. 6, in particular in the service modelling unit 609. The user experience centric service model 1700 may correspond to the user experience centric service model 700 of Fig. 7 and may correspond to the user experience centric service models 1400, 1500 and 1600 of Figs. 14, 15 and 16. The user experience centric service model 1700, however, is applied on an aggregated scale for a set of sessions grouped together. The aggregated model for the segment or network level is computed by aggregating all individual session models, for the relevant sessions, present in the given segment, or network. With this respect all Key Quality Indicators (KQIs) present at session level and introduced in the previous section are inherited by the aggregated model 1700, as aggregate values of the individual sessions KQIs. Multiple aggregation functions can be used in the aggregation process, e.g., sum, average, min, max.

Additionally, the segment and network level aggregated model keeps KQIs for the model transitions, defined as fractions or percentage of the total number of sessions in the segment or network, taking the given transition in the model.

These KQIs are represented on the model in Figure 17 as fractions f1 -f7, and refer to the fraction or percentage of sessions taking the given transition (event E) for the given reason (R). Fig. 18 shows a listing of a session data record of the user experience centric service model 1700 described with respect to Fig. 17 according to an implementation form. The session data record may be implemented in a service monitoring device 600 as described with respect to Fig. 6, in particular in the service modelling unit 609. The states, transactions, events and reasons may occur in a user experience centric service model 700 or 1700 as described with respect to Figs. 7 and 17 or in a computer program 800, 900, 1000, 1100 as described with respect to Figs. 8, 9, 10 and 1 1.

The session data record (CDR) comprises a possible set of KQIs and additional information which is kept in the CDR for the given segment or network. General Information includes the segment ID, the segment filter, the number N of sessions and the timing info for the number N of sessions. A state 1 KQI includes the average state duration. A state 2 KQI includes the quality metric, i.e. VQE or light VQE, an average duration of the "Display" sub-state, an average duration of the "Stall" sub-state, an average duration of the "Play" state, an average number of stalls and an average stall duration. Transition 1 -3 KQIs include an event E1 with reason R1 and identify the fraction f1 or percentage of sessions taking the transition from state 1 to state 3 on event E1 for the given reason R1. Transition 1 - 3 KQIs include an event E1 with reason R2 and identify the fraction f2 or percentage of sessions taking the transition from state 1 to state 3 on event E1 for the given reason R2. Transition 1 -3 KQIs include an event E1 with reason R3 and identify the fraction f3 or percentage of sessions taking the transition from state 1 to state 3 on event E1 for the given reason R3. Transition 2-3 KQIs include an event E4 with reason R1 and identify the fraction f4 or percentage of sessions taking the transition from state 2 to state 3 on event E4 for the given reason R1. Transition 2-3 KQIs include an event E4 with reason R2 and identify the fraction f5 or percentage of sessions taking the transition from state 2 to state 3 on event E4 for the given reason R2. Transition 2-3 KQIs include an event E4 with reason R4 and identify the fraction f6 or percentage of sessions taking the transition from state 2 to state 3 on event E4 for the given reason R4. Transition 1 -2 KQIs include an event E3 and identify the fraction f7 or percentage of sessions taking the transition from state 1 to state 2 on event E3. Verification KQIs include a sum N of the fractions f1 , f2, f3, f4, f5 and f6. Verification KQIs include a sum Z of the fractions f4, f5 and f6. Verification KQIs include a sum N of the fractions f1 , f2, f3 and Z. Fig. 19 shows a state diagram of a user experience centric service model 1900 according to an implementation form. The user experience centric service model 1900 may be implemented in a service monitoring device 600 as described with respect to Fig. 6, in particular in the service modelling unit 609. The user

experience centric service model 1900 may correspond to the user experience centric service model 700 or the user experience centric service model 1700 of Figs. 7 and 17 and may correspond to the user experience centric service models 1400, 1500 and 1600 of Figs. 14, 15 and 16.

The user experience centric service model 1900 is applied to a given segment of users in the network, here for all gold users in a network. The model presents the average experience that a user from the given segment has while accessing a video streaming service. After the file request in STATE 1 , 1901 , the user must wait in average 1.45 sec before starting displaying the video on screen in STATE 2, 1903. The user experiences in average 1.33 stalls for a total display duration of 237 sec. The average stall duration is 2.55 sec, and the average experienced quality in this state is 78 on a scale of 1 -100. 85% of the video sessions for this segment will enter the "PLAY" state 1903, while 15% will be aborted before the video starts displaying. 77% of the sessions for the given segment will experience normal termination to "END" state 1905 after video display, while 8% will

experience abnormal termination while in "PLAY" state, 1903.

Fig. 20 shows a state diagram of a user experience centric service model 2000 according to an implementation form. The user experience centric service model 2000 may be implemented in a service monitoring device 600 as described with respect to Fig. 6, in particular in the service modelling unit 609. The user

experience centric service model 2000 may correspond to the user experience centric service model 700 or the user experience centric service model 1700 of Figs. 7 and 17 and may correspond to the user experience centric service models 1400, 1500 and 1600 of Figs. 14, 15 and 16. The user experience centric service model 2000 is applied to a given segment of users in the network, here for all bronze users in a network. The model presents the average experience that a user from the given segment has while accessing a video streaming service. After the file request in STATE 1 , 2001 , the user must wait in average 3.6 sec before starting displaying the video on screen in STATE 2, 2003. The user experiences in average 2.4 stalls for a total display duration of 285 sec. The average stall duration is 3.76 sec, and the average experienced quality in this state is 65 on a scale of 1 -100. 73% of the video sessions for this segment will enter the "PLAY" state 2003, while 27% will be aborted before the video starts displaying. 61 % of the sessions for the given segment will experience normal termination to "END" state 2005 after video display, while 12% will experience abnormal termination while in "PLAY" state, 2003.

Embodiments of the user experience centric service model may comprise only one hierarchy level of states, i.e. only states, or a plurality of hierarchy levels of states, e.g. states of a first level and states of a second hierarchy level, which are also referred to as sub-states. Multiple-hierarchy level user-experience centric service models may be mapped or flattened to single-hierarchy level user-experience centric service models and vice versa. For example, as shown in Fig. 15, the two subs-states 2.1 "Display2 and 2.2 "Stall" may have been obtained by merging two states "Display" and "Stall" into one state 2 "Play".

General purpose computers may implement the foregoing methods, devices and computer programs, in which the computer housing may house a CPU (central processing unit), memory such as DRAM (dynamic random access memory), ROM (read only memory), EPROM (erasable programmable read only memory), EEPROM (electrically erasable programmable read only memory), SRAM (static random access memory), SDRAM (synchronous dynamic random access memory), and Flash RAM (random access memory), and other special pupose logic devices such as ASICs (application specific integrated circuits) or

configurable logic devices such GAL (generic array logic) and reprogrammable FPGAs (field programmable gate arrays).

Each computer may also include plural input devices (for example, keyboard, microphone and mouse), and a display controller for controlling a monitor.

Additionally, the computer may include a floppy disk drive; other removable media magneto optical media); and a hard disk or other fixed high-density media drives, connected using an appropriate device bus such as a SCSI (small computer system interface) bus, and Enhanced IDE (integrated drive electronics) bus, or an Ultra DMA (direct memory access) bus. The computer may also include a compact disk reader, a compact disk reader/writer unit, or a compact disc jukebox, which may be connected to the same device bus or to another device bus.

The invention envisions at least one computer readable medium. Examples of computer readable media include compact discs, hard disks, floppy disks, tape, magneto optical disks, PROMs (for example, EPROM, EEPROM, Flash EPROM), DRAM, SRAM, SDRAM. Stored on any one or on a combination of computer readable media is software for controlling both the hardware of the computer and for enabling the computer to interact with other elements, to perform the functions described above. Such software may include, but is not limited to, user

applications, device drivers, operating systems, development tools, and so forth. Such computer readable media further include a computer program product including computer executable code or computer executable instructions that, when executed, causes a computer to perform the methods disclosed above. The computer code may be any interpreted or executable code, including but not limited to scripts, interpreters, dynamic link libraries, Java classes, complete executable programs, and the like. From the foregoing, it will be apparent to those skilled in the art that a variety of methods, systems, computer programs on recording media, and the like, are provided. The present disclosure also supports a computer program product including computer executable code or computer executable instructions that , when executed, causes at least one computer to execute the performing and computing steps described herein. The present disclosure also supports a system configured to execute the performing and computing steps described herein.

Many alternatives, modifications, and variations will be apparent to those skilled in the art in light of the above teachings. Of course, those skilled in the art readily recognize that there are numerous applications of the invention beyond those described herein. While the present inventions has been described with reference to one or more particular embodiments, those skilled in the art recognize that many changes may be made thereto without departing from the spirit and scope of the present invention. It is therefore to be understood that within the scope of the appended claims and their equivalents, the inventions may be practiced otherwise than as specifically described herein.

Claims

CLAIMS:

1 . A method (100) for modeling a service (205), the service (205) being delivered through a terminal (209) to a user (21 1 ) over a communication network (203) during a service session, a progress of the service (205) being determined by the user (21 1 ) interacting (213) with the service (205) through the terminal (209), the method (100) comprising: determining (101 ) a service implementation type, the service implementation type indicating an implementation of the service (205); assigning (103) a user experience centric service model (501 ) to the service implementation type, the user experience centric service model (501 ) comprising a first service state (State 1 ) and a second service state (State 2); determining (105) a transition (t(1 ,2)) between the first service state (State 1 ) and the second service state (State 2) by observing the progress of the service (205) during the service session; and determining (107) a user-originated reason (R1 , R2) for the transition (t(1 ,2)) based on the user experience centric service model (501 ).

2. The method (100) of claim 1 , wherein the service (205) is a streaming service provided by a server (207) and the service implementation type includes one of the following: Hypertext Transfer Protocol streaming, Real-Time Transport Protocol streaming, and hypertext markup language version 5 streaming, HTML5 streaming.

3. The method (100) of one of the preceding claims, wherein the determining (101 ) the service implementation type comprises at least one of: capturing network packets of a network packet stream transporting the service (205), and determining a type of the captured network packets, capturing a service request transmitted by the terminal (209) towards the server (207); and capturing a message exchanged between the server (207) and the terminal (209).

4. The method (100) of one of the preceding claims, wherein the

determining (105) the transition (t(1 ,2)) comprises at least one of: inspecting a type of network packets of a network packet stream exchanged between the terminal (209) and the server (207), and inspecting a payload field of a network packet of a network packet stream exchanged between the terminal (209) and the server (207).

5. The method (100) of one of the preceding claims, wherein the user- originated reason (R1 , R2) is determined if the service (205) has left the first service state (State 1 ) or the second service state (State 2) after a predetermined period of time.

6. The method (100) of one of the preceding claims, wherein the user- originated reason (R1 , R2) is determined by emulating a behavior of a video buffer in the terminal (209).

7. The method (100) of one of the preceding claims, the user-originated reason (R1 , R2) is determined by observing a number of video stalls during the service session.

8. The method (100) of one of the preceding claims, wherein the user experience centric service model (501 ) comprises at least two distinct user- originated reasons (R1 , R2) for the transition (t(1 ,2)) between the first service state (State 1 ) and the second service state (State 2), and wherein the method (100) comprises determining a user-originated reason (Rx) from the at least two user- originated reasons (R1 , R2) for the transition (t(1 ,2)) between the first service state (State 1 ) and the second service state (State 2) by observing the progress of the service (205).

9. The method (100) of one of the preceding claims, comprising: adding a further reason (Rx) for the transition (t(2, 1 )) between the first service state (State 1 ) and the second service state (State 2) by observing the progress of the service (205) if the further reason occurs; pruning a further reason (Rx) for the transition (t(2, 1 )) between the first service state (State 1 ) and the second service state (State 2) by observing the progress of the service (205) if the further reason does not occur; adding a further state (State 3) of the service (205) when a transition (t(2,3)) towards the further service state (State 3) is determined by observing the progress of the service (205); and pruning or merging service states (t(ij)) of the service (205) by observing the progress of the service (205).

10. The method (100) of one of the preceding claims, wherein the first service state (State 1 ) or the second service state (State 2) comprises one of: a start of the video session, a start of downloading a video file from the server (207), a termination of the video session, network (203) or user (211 ) initiated a jump request of the user (21 1 ) into the video file, a pause request initiated by the user (21 1 ), a resume request initiated by the user (21 1 ), a file request, a file play, and a file end.

1 1 . The method (100) of one of the preceding claims, wherein the reason (R1 , R2) for a transition (t(1 ,2)) comprises at least one of: for a termination of the video session, one of a quality-related user abort, a non- quality-related user abort, a quality-related network abort, a non-quality-related network abort, a content unavailable, and a network timeout; for a start of downloading a video file from the server (207), a download start; for buffering the video session, a display start.

12. The method (100) of one of the preceding claims, wherein the service (205) is providable to different groups of users (21 1 ), and wherein the method (100) is performed for different service sessions of the service (205) for a certain group of users (21 1 ) to obtain the user experience centric service model (501 ) of the service (205) for the certain group of users (21 1 ).

13. The method (100) of claim 12, wherein the certain group of users (21 1 ) is determined by users (21 1 ) fulfilling a certain criterion, in particular a common geographical location, and a common quality of service requirement.

14. The method (100) of one of the preceding claims, wherein the user experience centric service model (501 ) comprises a plurality of distinct user- originated reasons (R1 , R2) for the transition (t(1 ,2)) between the first state (State 1 ) and the second state (State 2), the method (100) further comprising: selecting a user-perceived quality indicator value of a set of user-perceived quality indicator values for each of the plurality of distinct user-originated reasons (R1 , R2) associated to the transition between the first state (State 1 ) and the second state (State 2).

15. The method (100) of claim 14, wherein the step of selecting a user- perceived quality indicator value of a set of user-perceived quality indicator values comprises selecting a different user-perceived quality indicator value of the set of user-perceived quality indicator values for each combination of a transition (t(1 ,2)) and a user-originated reason.

16. The method (100) of one of the preceding claims, comprising observing progresses of a plurality of services (205) of the same implementation type to determine a statistic probability of the transition (t(1 ,2)) between the first service state (State 1 ) and the second service state (State 2).

17. The method (100) of one of the preceding claims, comprising storing the user experience centric service model (501 ) as a Session Data Record.

18. Computer program (800, 900, 1000, 1 100) for performing the method (100) of any of the claims 1 to 17 when run on a computer.

19. A service monitoring device (600) for modelling a service (205), the service (205) being delivered through a terminal (209) to a user (211 ) over a

communication network (203) during a service session, a progress of the service (205) being determined by the user (21 1 ) interacting (213) with the service (205) through the terminal (209), the device (600) comprising: a data interface unit (607) being configured to capture network packets between the server (207) and the terminal (209); and a service modeling unit (609) configured: to determine a service implementation type upon the basis of the captured network packets, the service implementation type indicating an implementation of the service state, to assign a user experience centric service model (501 ) to the service

implementation type, the user experience centric service model (501 ) comprising a first service state (State 1 ) and a second service state (State 2), to determine a transition (t(1 ,2)) between the first service state (State 1 ) and the second service state (State 2) by observing a progress of the service (205) during the service session, and to determine a user-originated reason (R1 , R2) for the transition (t(1 ,2)) based on the user experience centric service model (501 ).

20. The service monitoring device (600) of claim 19, the service modeling unit (609) being configured to execute the computer program (800, 900, 1000, 1 100) of claim 18 to perform the method (100) of any of the claims 1 to 17.

21 . The service monitoring device (600) of claim 19 or 20, forming a network probe on a network interface or a monitoring software in a centralized monitoring system.