WO2009132710A1

WO2009132710A1 - Selection of a service within a telecommunications network

Info

Publication number: WO2009132710A1
Application number: PCT/EP2008/055877
Authority: WO
Inventors: Joerg Niemoeller; Roman Levenshteyn; Raphael Quinet; Konstantinos Vandikas
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2008-04-30
Filing date: 2008-05-14
Publication date: 2009-11-05

Abstract

The invention refers to selecting services in a communications network to be invoked with respect to a user terminal (10), comprising a method with the steps of receiving a request to provide a certain service with respect to a user terminal (10), identifying a plurality of service offers that are associated to the certain service, performing for each of the service offers a service price prediction based on a price information associated to each service offer and a service usage prediction associated to the user terminal (10), and performing a selection out of the service offers based on the service price prediction; further a service composition entity (13) and a database (15, 16) maintaining profiles comprising service usage prediction information with respect to the user terminal (10) is disclosed.

Description

Title

Selection of a Service within a Telecommunications Network

Field of the Invention

The present invention relates to selecting services to be provided to user terminals of a telecommunications network.

Background of the Invention

In modern telecommunication networks, service price determination functions, also being referred to as charging functions, are split into a service domain comprising service providing nodes and a charging domain comprising a central charging and billing system. The charging functions in the service nodes provide information about the usage of telecommunication services to the central charging system. Based on this information the central charging system either logs the received service usage information for later billing (offline charging) or it deducts the service price from the user account (online charging). For both cases the detailed information about the price for service usage is stored in the central charging and billing system of the charging domain. On reception of service usage details from the service nodes, the prices are determined. This means that the service nodes do not have information about the finally charged prices. Details of this concept are described for example in the so-called 32-series of the 3^rd Generation Partnership Project -3GPP- technical specifications, such as in the document 3GPP TS 32.200 describing Charging Principles, in the document 3GPP TS 32.240 describing Charging Architecture and Principles, in the document 3GPP TS 32.250 describing Circuit Switched (CS) Domain Charging, in the document 3GPP TS 32,251 describing Packet Switched (PS) Domain Charging, and in the document 3GPP TS 32.216, describing IP Multimedia Subsystem (IMS) Charging. Advanced telecommunications networks increasingly provide services that are dynamically selected and/or composed e.g. just at the time of a service request. For such services, the user might not contact a specific server to provide a service just carried out or controlled by that server, but might order a service of a certain category from an instance, e.g. from a service broker or from a service selection function, without knowing the instances that will eventually provide the requested service. A request for each of such services sets a number of defined requirements for the service. Based on these requirements, the service selection function selects one or a plurality of services out of services that are available at the time of the request and best satisfies the requested requirements. Such service selection is usually based on a service database keeping stored service descriptions of available services e.g. comprising an actual availability and/or performance information of such services.

In order to provide transparent charging to the users, service providers usually offer (or have to offer) services at predetermined known price parameters, e.g. a fixed price, a price dependent of the amount of downloaded data, and/or dependent on the duration (price rate). Moreover, there is a tendency to offer comprehensive services, e.g. location based services, at fixed prices. However, for a dynamic service selection and/or composition, the price to be paid for might depend on usage details like for example the duration of the usage, the transferred data volume and the time and date of service invocation. When the service is selected, these details might not all be known yet and therefore a service broker offering the requested service might not be able to predict the price to be paid for before completion of the service. Moreover, the price determination logic and data might not available where the price information is needed. For calculating a price, the detailed definition of the tariff is needed, usually being stored in the charging domain and not in the service domain where the service selection function needs to evaluate it.

Summary of the Invention It is an object of the present invention to provide an improved service selection. This object is achieved by the independent claims. Advantageous embodiments are described in the dependent claims.

According to embodiments of the invention, a service in a communications network shall be selected with respect to a user terminal, wherein the selection shall be based on a price prediction and comparison amongst a plurality of service offers being available to the user terminal.

In an embodiment, a service selection entity receives a request form a user terminal or with respect to the user terminal (e.g. from another terminal associated to the user) to provide a certain service. The service selection entity identifies a plurality of service offers that are associated to the certain service, e.g. a plurality of single services each matching to the service request, or a plurality of sets of services forming a composite service matching to the service request. The service selection entity performs for each service offer a service price prediction based on price information associated to the service offer and a service usage prediction associated to the user terminal. Eventually, the service selection entity selects one service out of the plurality of service offers based on the service price prediction and on price-based selection criteria.

The embodiment allows a consideration of service prices already in the service selection phase where the details of the actual service usage are not available yet. Even if the actual service usage might differ from the predicted service usage, the embodiment allows a service selection based on a most likelihood price estimation of a user's service usage. If the service composition entity acts as a kind of service broker that offers composite services at predefined prices to the users, the invention might provide such service brokers with a tool that allows achieving a maximum possible business reliability. In an embodiment, one or a plurality of usage parameters are detected from the service usage prediction to be used together with a price information to obtain a predicted price. If the price information is a function, algorithm, or table, these parameters might be entered into such function, algorithm, or table to obtain the predicted price as result.

In an embodiment, the service selection is based on certain criteria. A criterion might be selecting a service having the lowest predicted price of the plurality of services. Alternatively, a criterion might be selecting one service out of services having a predicted price below a defined price limit. This service might be a first service detected to be below the limit, an arbitrary service or a service that matches a further (second order) condition, e.g. a service delivered by a preferred service provider. Further alternatively, a criterion might be to select a service having exactly a certain price or having a price within a certain price range.

In an embodiment, the service usage prediction is determined from information received from a database keeping stored service usage profiles individually associated to the user. Alternatively the service usage profile is determined from certain user information (e.g. a membership to a certain user group (e.g. prepaid user, or business user) that might be stored in a user or subscriber database. This user information might be used to select one out of a plurality of service usage profiles e.g. stored in a usage profile database that keeps stored (and maintains) service usage profiles associated to defined groups of users. This allows to significantly reducing the effort compared to defining individual service usage profiles for each user

In an embodiment, a plurality of usage profiles are defined each with respect to different exemplary types of services. Such exemplary types might be: voice calls, video calls, visual data streaming, video streaming, television data streaming, chat services or e.g. any other service wherein charging can be done based on usage dependent parameters (e.g. session based services implying a service usage duration).

In an embodiment, the price information associated to the service offer is received from a database keeping stored service details e.g. keeping stored price formulas, price tables etc., or links to further entities comprising such information.

In an embodiment, wherein the service usage prediction associated to the user terminal might comprise an information about an expected service a usage duration or a transmission volume. Different expected usages can be distinguished by provided data-rate, daily time of service invocation, weekly days of service invocation, and a date of service invocation.

In an embodiment, a service selection entity for selecting a service in a communications network to be invoked with respect to a user terminal is proposed. The service selection entity comprises:

- a service selection function for identifying a plurality of service offers that are associated to the certain service requested by the user terminal, and for selecting one service out of the plurality of service offers based on a service price prediction, and

- a price prediction function for performing for each service offer a service price prediction based on a price information associated to the service offer and a service usage prediction associated to the user terminal.

In an embodiment, a service usage profile is maintained to be used for a price prediction of a corresponding service. Thereto, data related to a certain service or service type delivered to one or a plurality of user terminals (10) might be monitored and certain usage parameters might be detected from the monitored data. Further, these parameters might be compared with usage parameters of the corresponding service usage profile kept stored for this service or service type. Depending on the comparison result, a corrective action might be carried out.

In an embodiment thereto, the data to be monitored is charging data being generated for charging the one or a plurality of user terminals. The following further steps might be performed:

- detecting service prices related to provided services from the monitored charging data,

- receiving predicted prices of these services, and comparing the received predicted prices with the service prices, and

- detecting a deviation between the service prices and the predicted prices.

Depending on the kind and/or amount of deviations, the corrective action might be providing a warning information, initiating an update of the actual service usage profiles, or initiating a change of a link to a predefined service usage profile. Such method allows for automatically keeping user profiles up to date and thus ensuring performing most accurate price predictions.

The present invention also concerns computer programs comprising portions of software codes in order to implement the method as described above when operated by a respective processing unit of a user device and a recipient device. The computer program can be stored on a computer readable medium.

The computer-readable medium can be a permanent or rewritable memory within the user device or the recipient device or located externally. The respective computer program can be also transferred to the user device or recipient device for example via a cable or a wireless link as a sequence of signals.

In the following, detailed embodiments of the present invention shall be described in order to give the skilled person a full and complete understanding. However, these embodiments are illustrative and not intended to be limiting. Brief Description of the Figures

Fig.1 shows a block diagram with a user terminal and exemplary entities of a communications network to select a service to be provided the user terminal;

Fig.2 shows a set of exemplary databases comprising user information being contacted in a course of service selection;

Fig. 3 shows an exemplary script of an exemplary usage profile,

Fig. 4 shows an exemplary script of an exemplary price formula used for a service price calculation, and

Fig. 5 shows a sequence diagram of exemplary control messages being exchanged between exemplary entities of the network and the user terminal.

Detailed Description of the Invention

Fig. 1 shows a block diagram with a user terminal 10, and a communications network comprising by way of example a first application server 11 , a second application server 12, a service composition entity 13, a charging system 14 and a usage profile database. The user terminal 10 can be any kind of user equipment usable for connecting to a communications network, e.g. a mobile telecommunications terminal, also being referred to as mobile station or as (mobile) user equipment, a fixed line telecommunications terminal of an or a personal computer having an appropriate network interface. Application server 11 and application server 12 are entities that are capable of providing application services to the user terminal 10. Such services might be any kind of communication services, e.g. voice communication, data streaming services, or more specifically short message services, location based services or any service providing specific or tailored information to the user of the user terminal 10. In the context of the invention, the charging system 14 is regarded to be a source for price information of services provided by the servers 11 and 12. The charging system can be a network centralized system (e.g. a centralized system of a mobile telecommunications network) being responsible for charging the users dependent on the usage of services provided the network to the users, e.g. provided by the servers 11 and 12 to the user terminal 10 in the example of this figure.

By way of example, three databases 15 and 16 and 17 are depicted, wherein the first database 15, in the following also being referred to as subscriber or user database 15 comprises information about the user (e.g., current registration, roaming, and telephony services information, subscription types and more). Such database might be a so-called Home Subscriber Server HSS, maintaining user information with regard to so-called IP Multimedia Subsystem (IMS) in a central location, or any other user databases.

The second database 16, in the following also being referred to as usage profile database 16 comprises information about usage habits for different services associated to the user terminal 10. Further details of such usage profile information will be described under Fig. 2. The third database 17, in the following also being referred to as service database 17, comprises information of a plurality of offered services available for users of the network. This database might comprise service conditions and pricing information associated to the different services (e.g. in form of mathematical formulas, look-up tables, and/or further addresses of pricing information sources). The representation of the databases as dedicated entities in the figures shall be regarded as a mere functional representation. The databases therein might e.g. be physically realized as combined device, each as a single device, or as a plurality of (decentralized) devices within the network.

The service composition entity by way of example comprises two functions (or sub units). A first function 13, in the following also being referred to as service selection function 131 is responsible for selecting one or a plurality of offered services being available for the user terminal 10, e.g. service offered by the application servers 11 and 12 within the frame of the example in Fig.1. This selection is carried out on the bases of a price prediction with respect to the offered services carried out by the second function 132, in the following also being referred to as price prediction function 132.

The lines between the nodes explained above shall symbolize exemplary interactions between such nodes. With an initial interaction, the user terminal 10 contacts the service composition entity 13 in order to obtain a certain service. This service might be a service out of a list of offered services. The services might be offered at fixed price conditions (e.g. a fixed price for the whole service provision, a price dependent on the amount of data and/or service duration). Within the service selection entity 13, the service selection function 131 contacts the service database 17 in order to get a list of available services that can be invoked with respect to the user terminal 10. Subsequently the service selection function 131 might trigger the price prediction function 132 in order to obtain a price estimation or prediction for each of the available services. The price prediction function 132 first collects necessary input information for the price calculation.

The price prediction function 132 thereto might look up the service price entry in the service description of the corresponding service within the service database 17. This database might comprise information of how the price of the service shall be determined, as part of the service description. If the price is directly defined in the service database 17 (i.e. in case of a local definition of the service price), the price prediction function 132 interprets and evaluates the defined formula or script in order to calculate a price, e.g. by using a basic formula and entering the variables being relevant for the price with the actual values, wherein the parameters could for example be retrieved from the user data and/or from the user's service usage profile being requested from the user database 15 and/or the usage profile database 16. The user database 15 might comprise specific information about the user, for example his subscription (e.g. basic, gold or flat rate), and the service usage data base 16 might comprise the service usage profiles. The following formula describes an exemplary simple price function for voice calls based on duration:

Price [euro] = 0.01 ^* call duration [minutes]

According to this formula, if the user according to this example is expected e.g. to conduct a 10 minutes call according to his usage profile, the predicted price thus would be 0.10 EUR.

In an alternative, the price definition is at least partly stored remotely, e.g. in the charging system 14. In this alternative, the price prediction function 132 might contact the charging system 14 or the remote server for initiating a price request dialogue. The address, link or reference of the remote server to be contacted might be detected by looking up the price definition for a service in the service database 17.

The price prediction function 132 could be implemented as illustrated by the following exemplary steps:

1. waiting for price prediction request,

2. receiving a request to predict a price for a certain service, 3. collecting information about the user specific service usage from the user database and/or the service usage database,

4. looking up price information for the service in the service database,

5. If the price definition is stored remotely, continue in step 11 ,

6. If the price definition is stored locally, continue in step 9, 7. returning an error (price cannot be predicted due to missing price definition),

8. go back to step 1 ,

9. interpreting and evaluating the price definition by applying user specific service usage data and determining a predicted price, 10. go back to Step 1 , 11. requesting a price from the charging system, the request comprising relevant details about the service, the user and the service usage,

12. If the charging system requests more or different information, providing the requested data, 13. receiving a response from the charging system with the expected price, and

14. returning the calculated price to the service selection function 131 and returning to step 1.

The service selection function 131 might then select one out of the services on the base of the predicted prices and a predefined condition. Such predefined condition e.g. might be the lowest price. Then, the service with the lowest price is selected to be invoked towards the user terminal 10. Alternatively, the predefined condition can be to select a service below a certain price limit. In this case, the price prediction might be terminated as soon as a service with a price below such limit is found, or a default service might be selected out of services below the certain price limit.

It is to be noted that the price-based conditions might be used by the service designer the same way as other conditions or constraints. What is different between the price-based conditions and the other conditions is that the price- based conditions show an (implicit) functionality that predicts the price in order to evaluate the condition.

Service usage habits are regarded to be individual. For example, some users usually only do short calls in the morning and they do longer calls in the early evening. Other users regularly do long phone calls throughout business hours and use the phone only for short calls in the evening. For a reasonable prediction of a service usage, it is therefore preferable to assign different usage profiles to different users. Such service usage profiles are preferably defined per service type. Thus, a plurality of usage profiles, e.g. usage profiles for voice calls, video calls, TV streaming, or chat might be specified with respect to each user. If a service type shall be used and no user specific service usage profile is available, a default profile might be used.

A service usage profile defines an expected usage of a specific type of service with respect to a certain user. Thereto, those details of a service usage might be specified that can be relevant for the charging of that type of service. For example, a relevant detail for the usage of a voice call might be the call duration, a relevant detail for the usage of a multimedia streaming service might be amount of the transferred data, and a relevant detail for a chat type of service might be the number of transferred messages per hour. The relevant property to be specified in the usage profile therefore depends on the type or nature of that service. The usage profiles thus reflect how a user will most likely use the service in view of charging.

In an embodiment, service usage profiles are defined being based on service usage habits of a group of users and might stored centrally with respect to the network. This allows to reducing the effort compared to defining individual service usage profiles for each user. Such a user group in one example might be all prepaid users among the whole users, or in another example might be the business users. The members of these two user groups usually show significantly different service usage habits that are preferably modeled into separate service usage profiles for the same type of service in order to reach a reasonably accurate usage prediction.

Additionally to the service usage profiles, other data from the user information might be relevant for the price calculation. This might be e.g. the subscription class of the user for certain services. The user might for example be subscribed to a voice flat-rate. This is taken into account by the price calculation algorithms. Service usage profiles might be defined per service type. Thus, a plurality of service usage profiles might be linked to a user. If a service type shall be used and no user specific service usage profile is available, a default profile might be used. Next to the service usage profiles, other user data might be relevant for the price calculation. This can e.g. be the subscription class of the user for certain services. The user might for example be subscribed to a voice flat-rate. Depending on the service type, such information might be taken into account by the price calculation algorithms or formulas.

Fig. 2 shows an arrangement of databases comprising the user database 15 and the usage profile database 16, wherein the user database 15 by way of example comprises two data sets for each one of user 1 and user 2. The data set of user 1 is exemplarily specified in more details: This data set comprises a first usage profile for voice calls and a second usage profile for chat services. Further, the data set comprises a first link to a usage profile for video calls and a second link to a usage profile for TV streaming, both links pointing to corresponding usage profile entries stored in the usage profile database 16. Further the data set of user 1 comprise additional user information, such as subscription types for the different service types; user 1 might e.g. be a prepaid user for video calls and business user for TV streaming services.

The usage database 16 further comprises a plurality of usage profiles each with respect to different exemplary types of services (voice calls, video calls, TV streaming, chat) and different users (individual) or exemplary user groups (default user, prepaid user, business user). Generally, the user database 15 might comprise for each service type either an individual usage profile or a link to a usage profile database 16 that comprises generalized user profiles each with respect to a defined user group, the user is associated to. In the example of Fig.2, the data set of user 1 comprises the specification of a service usage profile for services of type "voice calls" for user 1. This usage profile is individual for this particular user and specified directly within the data set of user 1 of the user database 15. For services of type "video calls" the user database 15 comprises a pointing to the service usage profile 002 defined for the prepaid user group of the service type "video calls". This service usage profile is thus referred to by multiple users. Further, for a "TV streaming" type of service, the data set of user 1 refers to the service usage profile 013. By way of example, this profile might be an individual profile, but being stored in the usage profile database 16 instead of the user database 15.

Not all service details might be relevant for all kinds of services. However the service usage profiles are not necessarily to be defined with a specific charging method in mind. While a certain voice service is for example charged based on the duration, another voice service might be charged based on the transferred data volume. A service usage profile for voice services therefore preferably defines both an expected duration and an expected data volume. When a service price is predicted from such a usage profile, the calculation function identifies the appropriate information according to the pricing definition of the service. Service usage details that could be relevant for charging might e.g. comprise estimations for the following service details:

- a call duration (e.g. for voice calls),

- a service usage duration (e.g. for chat),

- a used transmission volume,

- a used data-rate (e.g. for TV streaming),

- a time of service invocation, and/or - a date of service invocation.

Within the above-listed details, it can be distinguished between those parameters that might determine the prices (e.g. call or service duration, data rate and transmission volume) within one appropriate tariff, and those parameters that might (only) influence the selection of a tariff out of a plurality of tariffs to be applied (e.g. time and date of service invocation).

In an embodiment, the service usage profiles are automatically determined. Thereto a function might be introduced within the network that might e.g. monitor charging data sent to the charging system. This function might constantly checks whether usage predictions provided by current service usage profiles are still in line with the service usage observed in the network. If significant deviations are detected by this function it reports its observations to appropriate functions, e.g. the price prediction function 132 of the service composition entity 13. Additionally or alternatively, this function might initiate corrective measures to change or update the usage profiles or to change an assignment of usage profiles to users and user groups (e.g. changing links between the user data base 15 and the service usage database 16). Such function might form a separate node within the network. Alternatively such function might be integrated within other nodes, e.g. within the service composition entity 13, the usage profile data base 16 or any other appropriate node.

Fig. 3 shows a simple example of a formal usage profile definition. In this example a usage profile for a voice telephony service is defined. In this example, the only property being regarded to be relevant for charging is the duration of this voice service. By way of example, the usage profile definition distinguishes between different days of the week (e.g. weekdays: Monday to Friday, and weekends: Saturday and Sunday), and between different time periods of the day (e.g. 00:00 - 08:00, 08:00 -18:00 and 18:00 - 00:00) and assigns different expected durations depending on the day of the week and the time period (e.g. 10, 15 or 20 min).

Fig. 4 shows an exemplary simple script as part of a script-based price definition that might be used together with a basic price formula. The example shown here considers flat-rate and gold subscriptions. The basic price formula might not allow branching according to conditions like for example the user's subscription level. Here, a calculation script that can process conditions can provide more flexibility. Here, the user subscription is considered. For a flat-rate subscriber the price of this service invocation is zero, whereas else the price is by way of example 0.01 euro per second.

In order to be able to calculate the price the price calculation routine evaluating this price definition script needs to be able to obtain the user subscription from the user database 15 and the expected duration from the service usage profile e.g. stored in the usage database 16. Consistent and complete database entries are thus important for an accurate price prediction.

Fig. 5 shows a sequence diagram of exemplary control messages M1 - M22 being exchanged between the nodes and/functions shown in Fig. 1 , in order to select one serve out of a plurality of possible services (service offers).

In a first block of messages M1 - M11 , a price prediction of a first service offer, e.g. a service named service A offered by one of application server 11 or application server 12, shall be performed. Thereto the following exemplary sequence might be executed:

- the user terminal 10 sends a first message M1 comprising a service request to the service selection function 131 ,

- the service selection function 131 sends a second message M2 comprising a request for a list of available services (in other words: service offers) to the service database 17,

- the service database 17 sends a third message M3 comprising a list of available services, service A and service B in this example, to the service selection function 131 ,

- the service selection function 131 sends a 4^th message M4 comprising a request for a price prediction for a first one of the listed services, service A in this example, to the price prediction function 132; - the price prediction function 132 sends a 5^th message M5 to the user database 15 comprising a request for user information related to the user terminal 10,

- the user database 15 sends a 6^th message M6 comprising the requested user information to the price prediction function 132, - the price prediction function 132 sends a 7^th message M7 to the usage profile database 16 comprising a request for a service usage profile associated to the user of the user terminal 10, - the usage profile database 16 sends an 8^th message M8 comprising the requested service usage profile to the price prediction function 132,

- the price prediction function 132 sends a 9^th message M9 to the service database 17 comprising a request for a service price definition of Service A, and

- the service database 17 a 10^th message M10 to the price prediction function 132 comprising the requested service price definition.

With the reception of the price relevant information from the databases 15- 17, the price prediction function 132 performs a price prediction for service A as exemplarily shown under Fig. 3 and Fig. 4. It is apparent that the sequence of the messages might be carried out in a plurality of alternative orders, e.g. depending on the hierarchy of data (e.g. links between the data sets of the different databases) the messages M5, M7 and M9 might be sent in different order; correspondingly, messages M6, M8, and M10 can be received by the price prediction function 132 in a different order. Further, as discussed above the price relevant information can be stored in a single database or in any arrangement of databases within the network. After having performed the price prediction, the price prediction function 132 returns the price prediction for Service A to the service selection function 131 with the 11^th message M11.

In a following second block of messages M12 - M21 , a price prediction of a second service offer, e.g. a service named service B offered by one of application server 11 or application server 12, shall be performed. Thereto the following sequence that is by way of example different from the sequence of the first block above might be executed:

- the service selection function 131 sends a 12^th message M 12 comprising a request for a price prediction for a second one of the listed services, service B in this example, to the price prediction function 132; - the price prediction function 132 sends a 13^th message M13 to the user database 15 comprising a request for user information related to the user terminal 10,

- the user database 15 sends a 14^th message M14 comprising the requested user information to the price prediction function 132,

- the price prediction function 132 sends a 15^th message M15 to the usage profile database 16 comprising a request for a service usage profile associated to the user of the user terminal 10,

- the usage profile database 16 sends an 16^th message M16 comprising the requested service usage profile to the price prediction function 132,

- the price prediction function 132 sends a 17^th message M17 to the service database 17 comprising a request for a service price definition of Service B,

- the service database 17 a 18^th message M18 to the price prediction function 132 comprising the requested service price definition, - the price prediction function 132 sends a 19^th message M19 to the charging system 14 comprising a request to perform a price calculation based on information taken received from the databases 15- 17,

- the charging system 14 performs a price calculation and returns the calculated price for Service B with the 20^th message M20, and - the price prediction function 132 forwards the calculated price for Service B to the service selection function 131 with the 21^th message M21.

On the base of the price predictions for Service A and Service B the service selection function 131 performs a selection according to a predefined rule. In the example shown here, the predefined rule is to select the cheapest service offer out of the evaluated offers that is by way of example service B. An alternative rule might be to firstly identify all services below a defined price limit and secondly to select a default service out of these services. A further alternative rule might to predict the prices service offer after service offer until an offer below a defined price limit is identified. With a last message M22, the service selection function 131 invokes Service B as being selected. The invention allows a consideration of service prices already in the service selection phase where the details of the actual service usage are not available yet. The actual service usage might vary from case to case and from the predicted service usage in the service usage profiles. Nevertheless the service usage profiles can provide a kind of most likelihood price estimation of a user's service usage. If the service composition entity acts as a kind of service broker that offers composite services at predefined prices to the users, the invention might provide such service brokers with a tool that allows achieving maximum possible business reliability.

Claims

1. A method of selecting a service in a Communications network to be invoked with respect to a user terminal (10), the method comprising: - receiving a request (M1 ) to provide a certain service with respect to a user terminal (10),

- identifying a plurality of service offers (M3) that are associated to the certain service,

- performing for each service offer a service price prediction based on a price information (M6) associated to the service offer and a service usage prediction (M8) associated to the user terminal (10), and

- selecting (M22) a service out of the plurality of service offers, based on the service price prediction.

2. The method of claim 1 , comprising detecting one or a plurality of parameters from the service usage prediction (M8), and associating the one or plurality of parameters to the price information (M6) in order to obtain a predicted price for the service offer.

3. The method of the preceding claim, wherein the price information (M6) forms a part of a service description, comprising at least one of: a mathematical equation or set of equations wherein the estimated price is a function of the one or the plurality of parameters, an algorithm producing the estimated price as result of the one or the plurality of parameters, and a table comprising a list of estimated prices associated to different parameters, and an information of where to get further price information from.

4. The method of claim 1 or any one of the preceding claims, wherein the service selection (M22) is based on one or a plurality of the following rules: - selecting a service having the lowest predicted price of the plurality of services,

- selecting an arbitrary service out of services having a predicted price below a defined price limit, and - selecting a service out of service offers having predicted price below a defined price limit that matches a further condition,

- selecting a default service out of service offers having a predicted price below a defined price limit that matches a further condition,

- selecting a service having a predicted price within a defined price range, and

- selecting a service having a defined predicted price.

5. The method of claim 1 or any one of the preceding claims, wherein the service usage prediction (M8) is determined from information received from a first database (15) keeping stored a service usage profile individually associated to the user of the user terminal 10.

6. The method of claim 1 or any one of the preceding claims 2- 4, wherein the service usage prediction (M8) is determined from a user information stored in the first data base (15), the user information being used to select one of a plurality of service usage profiles of stored in a second database (16) keeping stored service usage profiles associated to defined groups of users.

7. The method of claim 5 or 6, wherein the first or second database (15, 16) comprises a plurality of usage profiles each with respect to different exemplary types of services.

8. The method of claim 7, wherein types of services comprises at least one of: voice calls, video calls, visual data streaming, video streaming, television data streaming, an chat.

9. The method of claim 1 or any one of the preceding claims, wherein at least one of:

- at least a part of the price information (M6) associated to the service offer is received from a third database (17) keeping stored price information attached to a corresponding service description, and

- at least a part of the price information (M6) associated to the service offer is received from a further entity (14) being indicated in an information received from the service database (17), preferably by means of an address information.

10. The method of claim 1 or any one of the preceding claims, wherein service usage prediction (M8) associated to the user terminal (10) comprises at least one of:

- a service usage duration, - a transmission volume,

- a data-rate,

- a daily time of service invocation,

- weekly days of service invocation, and

- a date of service invocation.

11.A computer program loadable into a processing unit of a service selection entity (13) the computer program comprising code adapted to execute the method of claim 1 or any one of the preceding claims.

12. A service selection entity (13) for selecting a service in a communications network to be invoked with respect to a user terminal (10), the service selection entity (13) comprising:

- a service selection function (131 ) adapted for identifying a plurality of service offers that are associated to the certain service requested by the user terminal (10), and for selecting (M22) one service out of the plurality of service offers based on a service price prediction, and - a price prediction function (132) adapted for performing for each service offer a service price prediction based on a price information (M6) associated to the service offer and a service usage prediction (M8) associated to the user terminal (10).

13.A method of determining a service usage profile with respect to a user terminal (10) and with respect to a price prediction of a service to be selected based on said usage profile, comprising:

- monitoring data related to a certain service or service type delivered to one or a plurality of user terminals (10),

- detecting usage parameters from the monitored data and comparing the usage parameters with the service usage profile kept stored for this service or service type, and

- initiating a corrective action with respect to the usage profile.

14. The method of claim 13, wherein initiating a corrective action comprises one of: providing an information for the service selection entity (13), initiating an update of the actual service usage profiles, and initiating a change of a link to a predefined service usage profile.

15. The method of claim 13, wherein the monitored data is charging data related to the certain service or service type and being sent to a charging system (14) for charging the one or plurality of user terminals (10), wherein service prices detected within the monitored charging data is compared to predicted prices received from a price prediction function

(132), and wherein the usage parameters are derived from a corresponding comparison result.

16. The method of claim 15, comprising comparing a set of prices of the monitored charging data with a corresponding set of predicted prices, and initiating a corrective action if the price differences exceed certain limits.

17.A node for determining a usage profile with respect to a user terminal (10) and with respect to a price prediction of a service to be selected based on said usage profile, adapted to perform the steps of the methods of claim 13 or any one of the claims 14 to 16.