Patent Description:
Call services are usually provisioned by updating a home location register (HLR) and/or home subscriber server (HSS) to indicate which services should be enabled for a particular subscriber. Alternatively, provisioning can be done directly in an application server (AS). This is an inflexible system as the services need to be updated manually. Moreover, the call services are the same for every call made by the subscriber. This can be inefficient because every call for that subscriber is routed via the application server providing the call service, even if call services are not required for every call.

In existing Network as a Platform (NaaP) and Telecommunications as a Service (TaaS) approaches, services for fully provisioned customers may be triggered by the network.

<CIT> describes linking a user account to a PBX extension by receiving an association request (comprising a PBX extension telephone number) from a user account, sending an association code to the user account, calling the PBX extension, receiving the activation code from the PBX extension (verifying that the user account and PBX extension belong to the same user) and linking the PBX extension and user account together.

<CIT> describes controlling multiple distinct identities of a mobile device across different forms of communication including telephone calls, short message service (SMS), personal and business voice mail, where each identity corresponds to a different phone number (e.g. for distinct business and personal identities). The system determines which identity of the mobile device to employ in response to detecting an inbound or outbound communication, based on in-band signaling that is provided along with the communication and/or an out-of-band signaling mechanism, such as a data channel.

However, call handling in prior art methods is broadly based on a preconfigured profiled for each subscriber. Services are not configurable for each session, which may be beneficial in certain cases. For example, a call recording service may be required by a subscriber only for certain calls. The telecommunications network has no way of determining which calls require the service and has no way of activating/deactivating the service on a call-by-call basis. The network must therefore assume that the service is required every time and route all the calls via the recording application server. This results in an inefficient system due to increased signalling requirements and increased resource use at the application server.

The present invention aims to address the drawbacks in the prior art.

<CIT> describes a system and method of communicating callee device preferences to a network.

The scope of the present invention is defined in the claims. A number of examples useful for understanding the invention (but not necessarily within the scope of the invention) are also provided below. Against the background described above, the present invention aims to provide an improved method in which session services are activated only for the specific session for which the services are required. According to the proposed methods, a user device may activate services on a per-session basis. In one example, the user device sends a message containing call preferences from their handset, before the call is initiated. The preferences are stored in a data store. Then the handset establishes the call. During call setup, the operator network retrieves the preferences from the database and dynamically provisions call services, based on the preferences. Advantageously, by sending the preferences before establishing the session, the operator network is able to deduce the required services for the call, without the user needing to specify any additional parameters in the signalling for the session itself.

According to a first aspect of the invention defined by independent claim <NUM>, a method of initiating a telecommunications session in a telecommunications network is provided. The method comprises:.

The second message (the message sent to the telecommunications network to initiate the telecommunications session) may comprise the one or more session parameters.

The method may further comprise receiving a substitute terminating party identifier from the server. The second message (the message sent to the telecommunications network to initiate the telecommunications session) may comprise updated session parameters comprising the substitute terminating party identifier.

In other words, the second message comprises updated session parameters, in which the terminating party identifier is replaced by the substitute terminating party identifier. The substitute terminating party identifier may also be referred to as a substitute terminating subscriber identifier.

The method may further comprise sending a message to a provisioning server. The message sent to the provisioning server may comprises authentication data for verifying an identify of one or more of:.

In some examples, the provisioning server may be a separate entity to the server to which the first message is sent or may be the same entity.

In some examples, the session parameters may comprise a label for identifying the telecommunications session. The method may comprise generating the label and the first message may comprise the label. Alternatively, the method may further comprise receiving the label in response to the first message. The second message may further comprise the label. The label may be linked to the service preferences so that the telecommunications network is able to fulfil one or more services specified in the service preferences, based on the label in the session parameters.

According to a second aspect of the invention defined by independent claim <NUM>, an electronic device configured to perform the methods according to the first aspect is also provided. The electronic device may be a user equipment (UE).

According to a third aspect of the invention defined by independent claim <NUM>, a method of initiating a telecommunications session in a telecommunications network is also provided. The method comprises:.

In some examples, a data store may be a service comprising a database and one or more interfaces for accessing the database (writing to and reading from the database). The one or more interfaces may be accessible by the originating endpoint, and one or more network entities in the telecommunications network (such as a service management application server).

In some examples, sending one or more messages to one or more corresponding application servers to fulfil one or more services specified in the service preferences may comprise sending a message to a corresponding application server for each of the one or more services specified in the service preferences.

In some examples, the second message may comprise the session parameters.

In some examples, the session parameters may comprise a terminating party identifier. The method may further comprise sending a third message to the terminating party to initiate the session between the originating party and the terminating party.

Some examples can be useful in the originating and/or the terminating side of the session. Where the originating party is a subscriber of the network, services can be activated on the originating leg of the call. However, if the originating process of the session is not available (for example because the originating party is not a customer of the telecommunications network providing the services) some examples can be used on the terminating side of the call. For this case, the methods may be modified by replacing the terminating party with a substitute "service number" that is owned/managed by the telecommunications network providing the services.

The session parameters may comprise a terminating party identifier. The method may further comprise sending a substitute terminating party identifier to the originating party. The second message may comprise updated session parameters comprising the substitute terminating party identifier.

In some examples, storing the service preferences and session parameters in a data store may further comprise storing the updated session parameters in the data store.

The method may further comprise sending a third message to the terminating party to initiate the telecommunications session between the originating party and the terminating party.

In other words, the first message to the server comprises the service preferences and session parameters, which may comprise the terminating party identifier. The server may store the service preferences and session parameters (including the terminating party identifier) in a data store. The server may then send a substitute terminating party identifier to the originating party. The substitute terminating party may be a subscriber of the telecommunications network (e.g. a reserved number that is used to ensure call signalling is routed via the telecommunications network). When the call routing reaches an entity in the telecommunications network that is configured to determine the required services (e.g. the service management application server), the entity may determine the required services, based on the updated session parameters (comprising the substitute terminating party). The entity may send one or more messages to fulfil the required services. However, at this stage, the session is between the originating party and the substitute terminating party, rather than the terminating party. The entity may therefore also determine the terminating party (i.e. the party that the originating party intends to initiate a session to) from the session parameters in the data store and may set up the telecommunications session by sending a message to the terminating party.

In some examples, a method of initiating a telecommunications session may therefore comprise:.

In some examples, storing the session parameters and service preferences in a data store may comprise storing service preferences, session parameters (comprising the terminating party identifier), and updated session parameters (comprising the substitute terminating party identifier) in the data store.

The session parameters may comprise an originating party identifier. The method may further comprise determining, based on the originating party identifier, whether the originating party is a subscriber of the telecommunications network or a subscriber of a different network.

If the originating party is a subscriber of a different network, the method may further comprise sending a substitute terminating party identifier to the originating party, as described above.

The method may further comprise receiving a provisioning message from the originating party.

The provisioning message may comprise data for authenticating one or more of:.

The method may further comprise verifying the electronic device, software application or user, based on the authentication data.

The second message may be received by a service management application server configured to perform the steps of:.

The method may further comprise sending a message to a subscriber management server in the telecommunications network, preferably a Home Subscriber Server, HSS, or Home Location Register, HLR, to indicate that signalling for telecommunications sessions initiated by the originating party should be routed via the service management application server.

There are several possible ways to configure the telecommunications network so that session signalling for a particular subscriber (e.g. the originating or terminating party) is routed through the service management application server. In some examples, the provisioning server (ACS) may directly send a message to the HSS and/or HLR. However, in many other examples, the messages will go through a provisioning stack of the telecommunications network (IT layer) that needs to be aware of provisioning services.

In some examples, the session parameters may comprise a label for identifying the telecommunications session. The first message may comprise the label. Alternatively, the method may further comprise generating the label and sending the label to the originating party.

In some examples, storing the service preferences and session parameters in a data store may comprise storing the service preferences in association with the label.

In some examples, the second message may further comprise the label (e.g. the session parameters or the updated session parameters comprise the label). Querying the data store to determine service preferences may comprise querying the data store using the label.

According to a fourth aspect of the invention defined by independent claim <NUM>, a server configured to perform any of the methods according to the third aspect above is also provided.

The first message may be sent via a first communication protocol, which is preferably a web services protocol such as Hypertext Transfer Protocol, HTTP or Hypertext Transfer Protocol Secure, HTTPS. The second message may be sent via a second communication protocol that is different to the first communication protocol. The second communication protocol is preferably a signalling protocol, such as Session Initiation Protocol, SIP.

In some examples, sending the first message comprising service preferences to the server may comprise sending a web services message to the server via a web services interface, such as http or https.

The session parameters may comprise one or more of:.

In some examples, location data may be determined from a GPS location or a cell-ID).

In some examples, the session parameters may comprise one or more of:.

The originating party and terminating party may be referred to an originating endpoint and a terminating endpoint or an originating subscriber and a terminating subscriber.

According to a fifth aspect of the invention defined by independent claim <NUM>, a computer software is also provided. The computer software comprises instructions that, when executed on a processor of a computer, cause the computer to perform any of the methods described above.

Further embodiments are set out in the dependent claims.

In some examples, a method performed by a network entity (such as a service management application server) is also provided. The method comprises receiving a second message from an originating party initiating a telecommunications session. The second message comprises session parameters. The method further comprises determining service preferences for the telecommunications session by querying a data store. The method further comprises sending one or more messages to one or more corresponding application servers to fulfil one or more services specified in the service preferences.

As will be appreciated by the skilled person, optional steps described above may be performed by the network entity in some examples.

According to some examples, a network entity configured to perform the method is also provided.

According to some examples, a method performed by a server (such as a web server or data store) is also provided. The method comprises receiving a first message from an originating party, the first message comprising service preferences for a telecommunications session and one or more session parameters for identifying the telecommunications session. The method further comprises storing the service preferences and session parameters (e.g. in a database). The method further comprises receiving, from a network entity (e.g. as described above), a query comprising the session parameters. The method further comprises sending the service preferences stored in association with the session parameters to the network entity.

As will be appreciated by the skilled person, optional steps described above may be performed by the server in some examples.

According to some examples, a server configured to perform the method is also provided.

In existing arrangements, the provision of services may consist of invoking the relevant IT stack for the user. Such arrangements may have several drawbacks. Firstly, services cannot be configured in real time. Secondly, every change needs to be developed not only on the network but also on the IT side (and therefore takes time and resources to action). Thirdly, the client needs to be owned by the operator.

<FIG> illustrates a system architecture according to a specific example. An originating party <NUM> (such as a mobile device or user equipment) initiates a telecommunications session via a telecommunications network <NUM>. The telecommunications network <NUM> comprises the following components:.

In the following specific examples that illustrate the proposed methods, the proposed solution may involve:.

Two specific options for executing the service are described below: a direct option (OPTION A) and an option involving a rerouting (OPTION B).

In the flow diagrams illustrated in <FIG> and <FIG>, an example of the provisioning method and different use cases to execute a service are provided.

<FIG> illustrates a flow diagram for an example provisioning messaging flow. At step S221, mobile device <NUM> downloads an application from an online application repository <NUM> (such as the Apple App store (RTM) or the Google Play store (RTM)).

At step S222, the mobile device <NUM> sends a message to a provisioning server <NUM> in the telecommunications network (such as an AutoConfiguration server, ACS). In the example illustrated, the message is sent from the mobile device <NUM> to a gateway <NUM> (such as a Wireless Access Point Gateway WAP-GW). Then, the gateway sends the message to a proxy server <NUM> (such as a proxy XML configuration access protocol server, Proxy XCAP). The proxy server <NUM> sends the message to the provisioning server <NUM>. The message may be an HTTPS request comprising an application ID and/or a registration ID (such as a Google Cloud Messaging Registration ID, GCM RegID). The message may further comprise a subscriber identifier, such as an International Mobile Equipment Identity (IMEI), International Mobile Subscriber Identifier (IMSI) or Mobile Station International Subscriber Directory Number (MSISDN).

As step S223, the provisioning server <NUM> may send a message to the mobile device <NUM>. The message may comprise an identifier, such as a cookie. The response message may be sent via the proxy server <NUM> and the gateway <NUM>.

At step S224, the provisioning server <NUM> sends a message to the mobile device <NUM>. The message may be a short messaging service message (SMS). The message may comprise a one time password (OTP).

At step S225, the mobile device <NUM> sends a message to the provisioning server <NUM>. The message may be an HTTPS request comprising the OTP and/or the identifier (e.g. the cookie). The message may be sent via the gateway <NUM> and the proxy server <NUM>.

At step S226, the provisioning server <NUM> sends a message to a service management application server <NUM>. The message may configure the service management application server <NUM> to fulfil services for the mobile device <NUM>. The provisioning server <NUM> may also send a message to the HSS and/or the HLR, so that signalling for sessions initiated by the mobile device are routed via the service management application server <NUM>. The provisioning server <NUM> may also send one or more messages to one or more application servers to configure these application servers to provide one or more services for the mobile device <NUM>.

At step S227, the provisioning server sends a message to a data store <NUM> (or a database).

At step S228, the provisioning server sends a message to the mobile device <NUM>. The message may comprise configuration data (such as XML configuration data). The message may be sent via the proxy server <NUM> and the gateway <NUM>.

The provision of the service / application is implementation specific. The authentication server (which may be an RCS authentication server, RCC14 device configuration server or similar) provides the following services:.

As described above, the provisioning server may also send a message to a HSS and/or HLR. This message may configure a profile of the mobile device so that signalling for sessions involving the mobile device is routed through the service management application server <NUM>. The subscriber identifier (e.g. MSISDN, IMEI or IMSI) sent to the provisioning server in step S222 may be used to identify a profile of the subscriber associated with the mobile device <NUM> in the HSS and/or HLR.

This provisioning method may further comprise provisioning service-specific application servers. This step may be needed if calls are not currently routed through the application servers. This step may be performed as part of provisioning rich communication services (RCS).

Once provisioning is complete, relevant information about the status of the request and other relevant information may be sent back to the application on the mobile device <NUM>.

<FIG> illustrates a flow diagram for initiating a telecommunications session by a mobile device. For example, this flow may illustrate the process for placing a call, where a call service is provided by an application server.

At step S351, mobile device <NUM> sends a message (such as a webservices message) to a server <NUM>. The message may be sent from the mobile device by an application on the mobile device <NUM>. The server <NUM> may be a data store or database. The message comprises service preferences for the telecommunications session and one or more session parameters for identifying the telecommunications session with the relevant information to uniquely identify the call. For example, the message may comprise an identifier of the originating party (e.g. the MSISDN of the mobile device), an identifier of a terminating party of the call (e.g. the MSISDN of the called party), and an indication that SERVICE A and SERVICE C are required for the telecommunications session.

At step S352, server <NUM> sends a message to the mobile device. The message may be a <NUM> OK response. The message may comprise a timeout parameter.

At step S353, mobile device <NUM> sends a message to the telecommunications network to initiate a telecommunications session. The message may be a SIP INVITE. The message may be sent to a Call Session Control Function (CSCF) <NUM> of the telecommunications network.

The message that the mobile device sends to the telecommunications network (to initiate the telecommunications session with the terminating party) may be sent in a standard manner, without any special features on the (SIP) message itself.

At step S354, the CSCF sends a message to the service management application server <NUM>. The service management application server <NUM> may be included in the signalling path due to the configuration of the HSS and/or HLR profile for the originating party.

After the service management application server <NUM> receives the message, the service management application server <NUM> sends a query to the data store <NUM> at step S355. The query may comprise one or more session parameters for identifying the telecommunications session. For example, the query may comprise an originating party identifier and a terminating party identifier (e.g. originating party MSISDN and terminating party MSISDN).

At step S356, the data store determines whether services are required for the telecommunications session (based on the one or more session parameters for identifying the telecommunications session). If the data store determines that services preferences for the telecommunications session have been provided by the mobile device (e.g. in step S351), the data store returns the service preferences for the telecommunications session. For example, the data store may respond to the query by sending a message to the service management application server <NUM> indicating that SERVICE A and SERVICE C are required for the telecommunications session. The message may be a <NUM> OK response.

If the data store query returns one or more services to be executed, the data store <NUM> may create a record marking the service as executed in the database (in order to not repeat a service already executed).

At step S357, the service management application server <NUM> fulfils the required service(s), by sending one or more messages to one or more application servers 380A and 380B. The different services may be fulfilled by different application servers or may be fulfilled by the same application server.

To fulfil the services, the service management application server <NUM> may send a SIP INVITE to the one or more application servers 380A and 380B. The one or more application servers 380A and 380B may each send a SIP INVITE back to the service management application server <NUM>.

If there are no services to be executed on the database, the action can be configurable: continue the call, connect the call to an announcement, release the call, etc..

When the services are executed, the service management application server <NUM> sends a message to the CSCF <NUM> at step S358. In this way, the CSCF may continue executing any further services defined in the HSS and/or HLR.

The message sent from the service management application server <NUM> to the CSCF <NUM> may comprise the same ODI as the original message (the message sent to the service management application server <NUM> in step S354).

Services can be invoked on behalf of either the originating or terminating party, depending on which party is a subscriber of the telecommunications network. However, in order for the services to be fulfilled, either the originating party or the terminating party (or both) must be a subscriber of the telecommunications network. Therefore, the originating and/or terminating party may be provisioned before initiating the telecommunications session (so that one of the parties is already a customer of the telecommunications network).

<FIG> illustrates a flow diagram of a further example method in which services may be fulfilled even if neither the originating party nor the terminating party is a subscriber of the telecommunications network.

With this method, it is possible to serve originating services to a user that is not a customer of the telecommunications network. The flow is based on similar interactions to those illustrated in <FIG>. The provisioning process is similar to the process illustrated in <FIG>. However, there is no need to provision the user in HSS / HLR (and it is not possible to do so because the user is not a customer of the telecommunications network).

In this example, the user/app does not make the call directly to the terminating party. Rather, at step S451, the user device <NUM> sends a message to the data store <NUM> comprising one or more services to apply (service preferences) and relevant information for identifying the call (session parameters). The session parameters comprise the terminating party identifier (B party). The one or more session parameters may further comprise an originating party identifier (A party), location data, device data (such as IMSI, IMEI, device model), and the like. The data (service preferences and session parameters) is stored by the data store <NUM>. The message may be an HTTPS request. One example can be: User A has sent the following data; MSISDN of originating party, MSISDN of terminating party, CALL RECORDING, cell-id.

At step S452, the data store sends a message in response to the request, where the response comprises a substitute terminating party identifier (new B party). The response may be a <NUM> OK response. The substitute terminating party is a subscriber that is managed by the telecommunications network providing the services. In this way, the method ensure that the signalling for the session is routed via the telecommunications network providing the services.

At step S453, the mobile device uses the substitute terminating party identifier to initiate the session (e.g. by making a regular voice call to this number). The mobile device <NUM> initiates the session by sending a message to the telecommunications network, the message comprising updated session parameters, in which the terminating party identifier is swapped for the substitute terminating party identifier. Depending on whether the user is a customer of the telecommunications network or not, direct routing may be implemented or the routing will first be handled by a different network. If the mobile device is not a customer of the telecommunications network that is providing the services, the message will first be routed via their own telecommunications network (the network of which they are a customer). Then, the signalling is routed to the telecommunications network that manages the substitute terminating party. Either way, the signalling arrives at the telecommunications network that is providing the services. For example, the message may be a SIP INVITE. The message may arrive at the CSCF <NUM> of the telecommunications network.

The substitute terminating party is a subscriber that is managed by the telecommunications network providing the services. There are a number of ways in which the substitute terminating party identifier may be determined. One option is to use a rerouting range, with dynamic allocation. For this option, a fixed range with predefined routing is used to perform this service. In step S452, the data store <NUM> allocates a single number in the rerouting range to the call. For example, the range +34600190XXX may be reserved specifically for this purpose. Then, the specific number within the range, "XXX" may be used as a key to recover the data that is returned to the service management application server <NUM> in step S456 (including the service preference data and the terminating party identifier).

This substitute terminating party (new B party) may be managed by the data store, to ensure that it is uniquely allocated at any given time. For example, one substitute identifier may be allocated to an originating party and the substitute identifier would then be reserved until a session has been detected by the network that is addressed to the substitute terminating party. At this stage, the network would use the substitute identifier as a key top recover the data from the data store. Then the data store may mark that identifier as being available for use again.

A second option is to use the context itself as the key to recover the preferences (and the terminating party) from the database. In this case, the lookup can be more complicated: for example, the A party, timestamp and location data may be used to uniquely identify the data relating to the session and recover the service preference data that is returned to the service management application server <NUM> in step S456. This option may result in difficulty when looking for consecutive calls from the same origin. To address this issue, the one or more session parameters used to identify the session can be enriched with an additional SIP header from the originating party (a label to identify the session).

At step S464, the CSCF <NUM> performs the usual processing for a session terminating at the telecommunications network. For example, the CSCF <NUM> may send a message to one or more servers responsible for one or more terminating triggers <NUM>. The one or more servers <NUM> may then send a message back to the CSCF <NUM>. The messages between the CSCF <NUM> and the one or more servers responsible for one or more terminating triggers <NUM> may be SIP INVITES.

The substitute terminating party (new B party) will be already provisioned and configured so that signalling is routed to the service management application server <NUM>. This can be performed individually for the substitute identifiers or using a range or PSI. At step S454, the CSCF <NUM> sends a message to the service management application server <NUM>. The message may be a SIP INVITE.

At step S455, the service management application server <NUM> sends a message to the data store <NUM> to determine what services are required for the session. The message may comprise updated session parameters for identifying the session. The updated session parameters may comprise the substitute terminating party identifier. The message may further comprise the originating party identifier and/or other session parameters used to identify the session. The message may be a SIP INVITE.

The data store may use the updated session parameters to retrieve the information that the user / app provided in step S451 (including the service preferences and the terminating party identifier). Then in step S456, the data store sends a message to the service management application server <NUM> comprising the service preferences.

At step S457, the service management application server <NUM> will fulfil the service preferences and apply the specific logic for the call. This may comprise sending one or more messages to one or more application servers <NUM> to fulfil the required services. For example, the service management application server <NUM> may send a SIP INVITE to one or more application servers <NUM> and receive a SIP INVITE in response once the one or more services have been activated for the session.

When the services are executed, the service management application server <NUM> sends a message to the CSCF <NUM> at step S458.

At step S459, the session signalling is routed onwards towards the final destination (the terminating party).

In this way, the service management application server <NUM> retrieves the required information from the data store <NUM>, invokes the required services (e.g. a call recording service) and routes the call to the B party (routing can be also influenced by other data it may hold, for example if it's also a provisioned user or not).

For simplicity, the above examples illustrate scenarios where the services are provided by one or two application servers. However, there may be a plurality of different application servers. Multiple application servers may be provided for redundancy or load balancing. The application servers may be provided to provide services for different groups of users. The application servers may be configured to each provide different services.

The messages illustrated in the flow diagrams and steps described in relation to the methods are not intended to provide a comprehensive list of all messages. Additional steps or messages may be exchanged between the method steps described. For example, a SIP client may send a "<NUM> Trying" and/or a "<NUM> Ringing" message after receiving an "INVITE" but before sending a "<NUM> OK". This may indicate that the request is being processed or that a user device is ringing.

The term "endpoint" has been used to refer to signalling and media destinations. These may alternatively be referred to as "terminals". They may also be described as devices or "subscribers" that may have an "address", "number" or "identifier".

An "address" could include a SIP signalling address (e.g. the "from" field in a SIP message). Alternatively, an "address" could be a "media address". A "media address" refers to an address to which session media is sent, once a session has been established (e.g. an SDP media address of an endpoint).

Whilst the above specific examples refer to "calls", the proposed signalling method may be used to establish different types of session between endpoints. These may include:.

Claim 1:
A method of initiating a telecommunications session in a telecommunications network, the method comprising:
sending (S351, S451) a first message from an originating party (<NUM>) to a server (<NUM>), the first message comprising service preferences for a telecommunications session and one or more session parameters for identifying the telecommunications session; and
initiating the telecommunications session by sending (S353, S453) a second message from the originating party (<NUM>) to the telecommunications network (<NUM>),
wherein the service preferences are associated with the session parameters so that the telecommunications network (<NUM>) is able to fulfil one or more services specified in the service preferences, based on the session parameters.