WO2013013726A1

WO2013013726A1 - Inter-domain service provision

Info

Publication number: WO2013013726A1
Application number: PCT/EP2011/063039
Authority: WO
Inventors: Ralf Keller; Hans Nordin; Herbie Francis; Andreas Witzel; Andreas Anulf
Original assignee: Telefonaktiebolaget L M Ericsson (Publ)
Priority date: 2011-07-28
Filing date: 2011-07-28
Publication date: 2013-01-31

Abstract

The invention refers to providing a service controlled by a first server (1) of a first telecommunication network (1), the first server (1) performing the following steps: receiving a service request to provide a service with respect to a subscriber terminal –UE- (3), identifying that the service is to be supported by a second telecommunication network (2),and defining a plurality of consecutive actions, wherein the plurality of actions comprise a trigger to contact a second server (2) of the second telecommunications network (2) for providing a corresponding service support. The invention further refers to an application server (11, 21) and corresponding computer program.

Description

Title

Inter-Domain Service Provision Technical Field

The invention refers to an inter-domain provision of services, and more specifically relates to a co-operation of circuit switched and packet switched domain communication networks in view of a service provision. The invention further relates to providing IMS services comprising an interaction of circuit switched and packet switched domain communication networks.

Background Mobile communications networks are currently evolving from circuit switched (CS) networks towards packet switched (PS) networks, and by that integrate into Internet Protocol (IP) based infrastructures that are e.g. used by the Internet and the World Wide Web respectively.

One significant enhancement in GSM was the mobile network integration with intelligent network (IN). Within this frame, the so-called Customized Application for Mobile network Enhanced Logic (CAMEL) has been developed in order to be able to create telephony services, also been referred to as Value Added Services (VAS). CAMEL allows telecom operators to flexibly add new services to the existing network infrastructure. Exam ples of existing VAS are call screening, number translation services, enhanced call forwarding (time and location dependent) private numbering plan (SPNP), Prepaid Card Services, free phone and Universal Number. Such services are provided to terminals accessing the CS domain being supported by dedicated functions or entities, e.g. so-called serving switching functions being adapted to detect an IN service request and a serving control functions adapted to control the execution of such service, e.g. in conjunction with dedicated servers.

More recently, an architecture called IP Multimedia Subsystem (IMS) has been defined by the Third Generation Partnership Project (3GPP) for delivering multimedia services over mobile communication networks. IMS is able to provide new and rich person-to-person communication services or network-to- person communication services by means of text, audio, video, and/or messaging or any combination thereof, employing IP for transport and Session Initiation Protocol (S IP) for service signaling. Hereto, calls from and to subscribers of the multimedia services using a Circuit Switched based access (e.g. WCDMA/GERAN), in the following also being referred to as CS access, are routed through the IMS network in order to reach an IMS service engine. This concept is called IMS Centralized Services (ICS), and is described in the standardization document TS 23.292 (current release 1 1 ) established by 3GPP.

By the introduction of the IMS a similar set of VAS shall also be available to subscribers accessing the IMS. Such a similar set of VAS in the IMS domain are being referred hereinafter as Multimedia Telephony (MMTEL) services, being supported by a (Multimedia) Telephony Application Server (TAS) for configuring and controlling multimedia services for subscribers, and a Home Subscriber Server (HSS) node that comprises subscription-related information, performs authentication and authorization of the subscriber, and might further provide information about the subscriber's location and IP information.

It is desired that at least a subset of both VAS and MMTEL services are similar with regard to user experience; in other words the user shall not experience a difference of any service dependent on with domain (CS or IMS) with which the user is accessing the network. With regards thereto, the aforementioned TS 23.292 specifies architectural requirements for delivery of consistent IMS based services, stipulating that changes made on the VAS data through one of the domains (e.g. IMS) shall also be made available when the user access the VAS through the other domain (e.g. CS).

One known solution to ensure such requirements could be to duplicate each service, e.g. by "translating" each VAS service into a corresponding MMTEL service. Another solution being considered could be that the IMS domain accesses VAS fu n ct i on s i n the C S d om a i n by com m unicating with corresponding service instances. Summary

It is an objective of the present invention to provide an improved co-operation between different telecommunication network domains with regards to a provision of services to subscribers. This objective is achieved by the independent claims. Advantageous embodiments are described in the dependent claims.

According to embodiments of the invention, a service provision is performed within a telecommunication network comprising a plurality of different domains. A first server associated to a first network domain controls a service configuration of a service to be executed with respect to a subscriber terminal. The first server thereto performs the following steps: receiving a service request to provide a service with respect to the subscriber terminal, identifying that the service can be supported by a second network domain, and configuring the service by defining a plurality of consecutive actions, wherein the plurality of actions comprise a trigger to contact a second server associated to the second network domain for providing a corresponding service support. According to further embodiments of the invention, a service interaction involves both a packet switched network part, in the following also being referred to as PS network domain, and a circuit switched network part of a telecommunications network, in the following also being referred to as CS network domain. The PS network domain comprises a first server, in the following also being referred to as multimedia (telephony) application server or MTAS, adapted for controlling multimedia services with respect to a service subscriber's terminal or user equipment, and the CS network domain comprises a second server, in the following also being referred to as switching server or MSC server, adapted for controlling telephony services of the CS network part. The user equipment -UE- might subscribe only to services of either the CS network part or only to services of the PS network part or to both the CS and the PS network part.

In an embodiment, it is assumed that the user equipment is attached to the PS network. The subscriber (or any third party with respect to the same user equipment) requests a certain MMTEL service to be provided with respect to the user equipment. In response to the request, the application server configures the service e.g. according to subscriber service information associated with the UE. While configuring the service, the application server might identify that the service or a part of the service (sub service) can be performed or supported by the CS network part. While controlling an execution of the service, the appl ication server contacts the CS server to in itiate an execution of corresponding functions to be performed in the CS network part of said part of the service.

Either in advance or in response to the request, the application server acquires service information comprising information about the service, e.g. trigger points, service formats and a description of interactions.

In a further embodiment, activating the sub service to be executed by the circuit switched network part comprises sending a request to the switching server to initiate said execution of said sub service. The request m ight comprise a transaction type to inform the second server about a wanted function.

In a further embodiment, while configuring the service, a sub-service that can be performed (or is to be performed) by the circuit switched network part is identified by the application server and an interaction/message exchange between the application server and the switching server are configured to be performed at execution time. At a point in time where such service, in the following also being referred to as CS (sub) is required, the switching server, in response to receiving an information from the application server, initiates and/or controls an execution of the sub-service according to the configuration of the service. In a further embodiment, the execution of the CS function is monitored by the application server, i.e. by maintaining state information. The state information preferably comprises information of the contacted second server and a state of transaction. Thereto, the switching server might transmit information with regard to an actual state of the CS (sub) service execution.

In an embodiment, prior to performing charging with respect to a specific subscriber, it is determined if the charging will be performed by the first domain or the second domain (e.g. perform ing MSC-S charging or IMS charging). Corresponding information might be provisioned in a service data base (e.g. HSS). Depending on this information, the first server might instruct the second server (e.g. the MSC-S) to issue so-called charging data records (CDRs). In an embodiment, the MTAS instructs the MSC-S to issue charging records (CDRs). Thereto, an interworking function might be provided in the MTAS that will take input from a Charging Framework in the MTAS and connect and send data to the MSC-S charging function. Therewith, MMTel services executed in the MTAS can trigger the generation of MSC-S CDRs by means of the charging interface. Additionally IN/CAMEL services controlled by the MSC-S and invoked by the MTAS as discussed above might trigger the generation of MSC-S CDRs themselves.

Thus, a smooth migration from CS services (e.g. the well know IN services) to PS services (e.g. IP multimedia services) can be achieved by enabling the application server to make use of CS (sub) services out of the PS domain. Especially, a service provider offering IMS services might offer services that (partly) already exist, without a need to implement existing functionality of the CS dom ain , e. g . I N services , agai n with i n the I M S the dom ai n . As a consequence, double implementation of similar functionality can be avoided. Advantages are e.g. saving effort (money), enabling a quick realization of known/established CS services in the IMS domain, and avoiding that similar CS and IMS services show unwanted deviations towards the end users e.g. due to any lack of service translation.

In a further em bodiment, the service configuring comprises setting up a sequence of actions and activating one or a plurality of triggers each defining conditions to execute one or a plurality of said actions for each sub function accord ing to the subscriber service inform ation and to service form at descriptions stored in the application server or retrieved from servers connected to the application server.

In a further embodiment, the application server and the switching server communicate by means of the Stream Control Transmission Protocol according to the document RFC 2960 published by the Internet Engineering Task Force.

In an embodiment, the application server comprises the following elements: a receiver for receiving a service request (e.g. a SIP INVITE message) to provide a selected service with respect to the UE according to subscriber service information associated to said UE; a processor for configuring the specific service by identifying at least one sub-service out of a plurality of sub-services to be performed to provide said certain service, and for identifying one of the identified sub-services to be performed by a circuit switched network part of said telecommunications network; a controller adapted for sending a request while controlling the execution of the specific service.

In a further embodiment, a CS service (e.g. IN/Camel) with respect to the subscriber terminal is to be configured by a server (switching server; e.g. MSC- S/SSF) of the CS network domain. The switching server identifies that the service can be (or is to be) supported by a PS network domain, and in response thereto configures a trigger to contact a corresponding application server associated to the PS network domain for providing a corresponding service support.

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 showing a telecommunications network comprising a packet switched domain and a circuit switched domain,

Fig. 2 shows a block diagram of an exemplary application server for controlling services in the packet switched domain, and Fig. 3 shows an exemplary sequence diagram being performed in the application server for performing a service with respect to the user terminal.

Detailed Description

Fig.1 shows a block d iag ram showing a telecommunications network comprising a packet switched -PS- network (domain) 1 and a circuit switched - CS- network (domain) 2, and a subscriber or user equipment -UE- 3. By way of example, the PS network 1 shows a (multimedia) telephony application server - MTAS- 1 1 , a home subscriber server -HSS- 12, and a (serving) call session control function -CSCF- node 13. The CS network 2 shows a switching or MSC server 21 , home location register -HLR- 22 and an intelligent network -IN- node 23.

The HSS 12 is a database that supports the PS network entities in handling calls. I t comprises subscription related information (e.g. being stored as subscriber profiles), performs authentication and authorization of the user, and might further provide information about the subscriber's location and address information (e.g. IP address). According to embodiments of the invention, the HSS keeps stored trigger data of CS domain services (applicable IN/CAMEL trigger data) that have been moved or copied previously from the HLR 22 to the HSS 12. The HSS might store this data with an indication of whether this data can be used by the MTAS-1 1 . The data might for example be stored in an XML format and might be accessible over the so-called Sh interface. The CSCF node 13 provides session control for user terminals, e.g. the user equipment -UE- 3 in the example being shown in Fig. 1 , accesses services provided by the MTAS 1 1 and provides service to the users (even though these services may be on different or separate application platforms). It may perform routing and translation, maintaining session timers, and retrieving authorization, service triggering information and user profile information.

The MSC server 21 i s a network node generally handling call control and signalling within the CS network, in the following also being referred to as MSC Server or MSC-S. The MSC Server 21 might comprise the call control and mobility control parts of GSM/UMTS. It might be integrated together with a visiting location register (VLR) to hold the mobile subscriber's CS service data. The MSC server 21 terminates the user-network signalling and translates it into the signalling within the CS network 2. The MSC Server 21 further controls telephony services, e.g. IN supplementary telephone services as discussed above, to be carried out with respect to users connected to the CS network 2. Thereto, the MSC server 21 might comprise (or being co-located with) a so- called service switching point comprising a service switching function -SSF- to trigger so-called value-added services to be invoked for example at certain detection points during a call, for example by sending a corresponding query to a service control function -SCF- to wait for further instructions on how to proceed.

The home location register HLR 22 is a central database associated with the CS network 2 containing subscriber details of CS subscriber, specifically of all S IM cards issued by the corresponding mobile phone operator of the CS network part 2. Each SIM has a unique identifier (IMSI). Further, the HLR 22 might comprise subscriber information related to services the user is subscribed to, e.g. comprising parameters associated with the subscribed services, etc. The services might be IN (intelligent network) services according to CAMEL (Customized Applications for Mobile networks Enhanced Logic).

The intelligent network -IN- 23 m ight comprise a control node also being referred to as Service Control Point -SCP- that receives queries from the SSF and initiates and/or controls an execution of the value added service(s).

The MTAS 1 1 is an application server for configuring and controlling multimedia services with respect to the UE 3. Specifically, the MTAS 1 1 provides so-called multimedia telephony services as explained in the introductory part. The MTAS 21 further comprises a processor for identifying that the MSC-S 21 is to be contacted e.g. by evaluating corresponding service data. Data to be evaluated might be associated to the CS domain e.g. being originally stored in an HLR. Such data might be requested by the MTAS 1 1 e.g. during service construction, or by evaluating service data that has already been provisioned in the MTAS or in the HSS. For an execution of the service, the MTAS 1 1 comprises functions for: identifying that the MSC-S is to be contacted by evaluating service data obtained for example from the HLR and potentially mapped to internal data, and/service data provisioned in the TAS or in the HSS; collecting data for establishing the MTAS - MSC-S contact (e.g. address, interface, protocol version) and communicating with the MSC-S in order to be able to request one or a plurality of wanted telecommunication functions. This communication might comprise a bi-directional exchange of messages between the MTAS and the MSC-S. - Further, so-called state logic, e.g. including information of the contacted MSC-S instance, state information and/or of type of transaction (e.g. charging, media, or IN/CAMEL) might be maintained by the MTAS for supervising the execution of the service function performed under a control of the MSC-S. The MTAS- MSC-S communications takes part of an interconnection between both servers being depicted as double arrow INT in Fig. 1 . As described above, this interface allows for a communication between both servers in order to perform a service over both network domains 1 and 2. Specifically, the interface allows the MTAS 1 1 to contact the MSC-S 21 in order to access and use CS network capabilities, e. g. I N/CAM EL services via INAP&CAP. Alternatively or additionally, the interface may be used to allow the MSC-S to access and use MTAS capabilities. Additional interfaces might be provided for exchanging charging functionality (e.g. to enable the MTAS to instruct the MSC-S to issue CDRs), accessing databases such as the Home Location Register -HLR- HLR e.g. to retrieve subscriber and/or service data (e.g. via MAP)., and/or to enable the MTAS to use a M-MGw controlled by MSC instead of MRFC/MRFP for media handling.

It is to be noted that the MSC-S needs to comprise corresponding functions in order to be able to communicate/work together with the MTAS.

The interface between MSC-S and MTAS may be implemented using SCTP as transport protocol and a new application protocol on SCTP.

It is to be noted that the above described entities are to be understood as logical or functional entities that might be physically realized in any way, e.g. each entity being realized in one separate physical device, or as one or a plurality of physical device. Alternatively, one or a plurality of the above described functional entities might be combined within one physical entity.

In the following Fig.2, selected functional entities of the MTAS 1 1 are described in more details. By way of example four service function modules 1 1 1 - 1 14, a CS domain interworking function 1 15, a service framing function 1 16, a service formats function 1 17, a SIP handler 1 18 and a data handler 1 19.

The service function modules 1 1 1 - 1 14 might be realized as SW modules e.g. as so-called plug-ins. Each service function module might be associated to one of a plurality of service functions or sub services such as Line ID Services, Barring, Forwarding, etc. The CS domain interworking function 1 15 enables a communication between the MTAS and the MSC-S. As discussed above, for this purpose, the CS domain interworking function might keep state information. The interworking function further provides functionality so that it can be handled in a similar manner to the service plug-ins 1 1 1 -1 14 by the service framing function as being described in the following. It can be regarded as a proxy server for the CS domain functions, e.g. the IN/CAMEL services provided by the CS network domain

It may also provide a monitor function, e.g. to receive signals from a Media Gateway.

The service framing function 1 16 receives service configuration information (e.g. from the SIP handler 1 18), this information comprising of information about the service functions to be used and on how the service functions of both the PS domain (MMTEL functions) and the CS domain (IN/CAMEL functions) are to be bound together (sequence of service functions). In response thereto, it builds up a service instance with a corresponding the chain of service functions by linking the corresponding service modules 1 1 1 - 1 14 and the IN proxy 1 15 and activating corresponding triggers. The configured service might comprise one or a plurality of services out of services associated to the service modules 1 1 1 -1 14 and the IN proxy (e.g. out of the MMTEL and IN/CAMEL services).

The service formats function 1 17 describe the functions and interfaces of each of the service functions (comprising the MMTEL and IN/CAMEL services) that might be realized in form of so-called service plug-ins comprised by the service format function 1 17. The IN/CAMEL proxy service can be positioned in any position in the service chain (e.g. to emulate the same behaviour as the MSC-S is using for the CS services).

In a further embodiment, the MTAS instructs the MSC-S to issue charging data records (CDRs). Thereto, a corresponding interworking function might be provided in the MTAS that will take input from a charging framework in the MTAS and connect and send data to the MSC-S charging function. Therewith, MMTel services executed in the MTAS can trigger the generation of MSC-S CDRs by means of the charging interface. Additionally IN/CAMEL services controlled by the MSC-S and invoked by the MTAS as discussed above might tri gge r th e ge nerat io n of M S C-S CDRs themselves. Thus, existing billing/charging infrastructure in the CS-domain can be used to charge a subscriber for services provided by in the PS domain.

Fig. 3 illustrates an example method of configuring and executing a dual domain service, wherein the service is configured and controlled by the MTAS of the PS network domain. The m ethod m ight be d ivided into two parts: the first part refers to a configuration of the service comprising the first steps S1 -S3; the second part refers to an execution of the service comprising the next steps S4- S6: in a first step S1 , the MTAS receives a 3rd party registration (e.g. originated by an S-CSCF via SIP); the subscriber might not be known in the MTAS at this time; in a second step S2, the MTAS fetches, based on the registration, subscriber service information e.g. stored in the HSS (comprising information for provisioned MMTel services) including IN/CAMEL trigger data, if any (the service information and the IN/CAMEL triggers may be in the same or in different data objects in the HSS). This data might have been copied or moved from the HLR to HSS; alternatively, the IN/CAMEL trigger data might be fetched by MTAS on session setup (e.g. an initial SIP INVITE message) originated by the user. The service data might be provided (e.g. piggy backed) on a first event/message sent to the MSC-S - in a third step S3, if IN/CAMEL triggers are received, corresponding triggers in the service format are armed / activated; in a fourth step S4, the MTAS receives a service request (e.g. a so-called INVITE message according to SIP) that might be originated by the subscriber; in a fifth step S5, the service framework triggers the needed service actions in response to the service request. If there is one or a plurality of IN/CAMEL trigger armed in the service format, the needed data is collected and the service framework uses the MTAS - MSC-S interface to request the IN/CAMEL service; as discussed above, the MTAS

(IN/CAMEL IW) may keep own state information as the use of IN/CAMEL services may require a couple of signaling exchanges with the MSC-S (it may also require a monitor function); and in a sixth step S6, after having received requested responses from the MSC-S, the MTAS proceeds controlling the handling of the requested service; in other words, the service framework triggers further service actions as configured.

In a further embodiment, an error handling might be performed in order to resolve errors that might occur during the service provisioning. Thereto, error messages might be sent over the interface between the MSC-S and the MTAS in case of a local error (e.g. being identified on the PS domain side), a corresponding error indication is sent to the other side (e.g. the CS domain side) and needed actions are performed stopping transaction, freeing resources etc. As discussed above, the invention allows a smooth interaction of services in different telecommunication domains. Specifically, the invention allows a smooth migration from CS services (e.g. IN/CAMEL services) to PS services (e.g. IP multimedia services). Service functionality already developed for the CS domain can be reused in the PS domain avoiding a double development of similar functionality and thus enabling an easy deployment of CS services in the PS domain. Further more, the deployment might be performed for such users both of the CS domain and the PS domain that have already subscribed to IN/CAMEL services.

Claims

1 . A method of providing a service controlled by a first server (1 1 ) of a first telecommunication network domain (1 ), the first server (1 1 ) performing the following steps:

- receiving a service request to provide a service with respect to a subscriber terminal -UE- (3),

- identifying that the service is to be supported by a second

telecommunication network domain (2), and

- defining a plurality of consecutive actions, wherein the plurality of actions comprise a trigger to contact a second server (21 ) of the second telecommunications network domain (2) for providing a corresponding service support.

2. The method of the preceding claim, comprising identifying a plurality of sub-services (1 1 1 , 1 12, 1 13, 1 14, 1 15) to be composed together for providing the service, wherein identifying that the service is to be supported by a second telecommunication network domain (2) comprises identifying one or a plurality of said sub-services to be performed by the second telecommunications network domain (2).

3. The method of any one of the preceding claims, comprising fetching

subscriber service information associated to a service subscription of the subscriber terminal (3), and configuring the service dependent on the subscriber service information.

4. The method of anyone of the preceding claims, wherein the first

telecommunications network domain is a packet switched -PS- domain -, the second telecommunications network is circuit switched -CS- domain, the first server is an application server (1 1 ) for controlling services of the PS network, and the second server is a switching server (21 ) for controlling telephony services of the CS domain (2), wherein the application server (1 1 ) activates the trigger to contact the switching server (21 ) such that during an execution of the service, a request is transmitted to the switching server (21 ) to initiate an execution of the service support.

5. The method of the preceding claim, wherein the request comprises a transaction type to inform the second server (21 ) about a wanted function.

6. The method of the preceding claim, further comprising monitoring the execution of the wanted function by maintaining state information, the state information preferably comprising information of the contacted second server (21 ) and transaction state information.

7. The method of anyone of the preceding claims 4 - 6, wherein the

application server (1 1 ) fetches, in response to a service registration, subscriber service information from a subscriber database (12) comprising information for provisioned services and corresponding trigger information.

8. The method of the preceding claim, wherein the trigger data is IN/CAMEL trigger data being fetched by the application server (1 1 ) on a session setup originated or terminated by the user.

9. The method of the preceding claim, wherein the trigger data is received from the switching server (21 ) prior to an execution of the service.

10. The method of anyone of the preceding claims, wherein the first server (1 1 ) and the second server (21 ) communicate by means of the Stream Control Transmission Protocol according to the document RFC 2960 published by the Internet Engineering Task Force.

1 1 . The method of anyone of the preceding claims, wherein the first server (1 1 ) fetches information from a service data base (12, 22), this

information being indicative of whether a charging for the service is to be performed by the first telecommunication network domain (1 ) or by the second telecommunication network domain (2).

12. The method of the preceding claim, wherein the first server (1 1 ) sends the following information to the second server (21 ), if it determines that the charging is to be performed by the second telecommunication network domain (2):

- an instruction to perform or initiate a charging for the service, and

- charging information associated to a first service contribution

performed or controlled by the first server (1 ).

13. The method of the preceding claim, wherein the second server performs the charging by means of first charging data records associated to the first service contribution controlled by the first server (21 ) and second charging data records associated to a second service contribution controlled by the second server (21 ).

14. A server (1 1 , 21 ) associated to a first network domain (1 , 2) of a

telecommunications network comprising a plurality of network domains, for controlling a service with respect to a subscriber terminal -UE-, comprising:

- a receiver adapted for receiving a service request to provide a service with respect to a subscriber terminal -UE- (3),

- a processor adapted for identifying that the service is to be supported by a second telecommunication network domain (1 , 2), and for defining a plurality of consecutive actions, wherein the plurality of actions comprise a configuring a trigger to contact a further server (1 1 , 21 ) of a further telecommunications network domain (1 , 2) for providing a corresponding service support.

15. The server (1 1 ) of the previous claim, being associated to a packet switched network domain (1 ), adapted for configuring or controlling multimedia telephony services comprising internet protocol -IP- transport towards the UE (3), wherein the processor is further adapted for contacting the further server (21 ) being associated to a circuit switched network domain (2) for configuring or controlling intelligent network -IN- services with respect to the UE (3).

16. The server (21 ) of claim 14, being associated to a circuit switched

domain (2), adapted for configuring or controlling intelligent network -IN- services wherein the processor is further adapted for contacting the further server (21 ) being associated to a packet switched network domain (1 ) for configuring or controlling multimedia telephony services with respect to the UE (3).

17. An arrangement comprising the server (1 1 ) of claim 15 and the server (21 ) of claim 16.

18. A computer program loadable into a processing unit of the server (1 1 , 21 ) of claim 14, the computer program comprising code adapted to execute the method of claim 1 or any one of the preceding method claims.