METHODS , APPARATUSES AND PROGRAMS FOR USING AN SH INTERFACE FOR COMMUNICATIONS BETWEEN A DATABSE CLIENT AND A DATABASE SERVER

BACKGROUND OF THE INVENTION

5 1. Field of the Invention

The present invention relates to a method and apparatus for use in a telecommunications network.

10 2. Description of the Related Art

IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the number of basic applications and the media which it is possible to combine, the number of services offered to the end users 15 will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called "combinational IP Multimedia" services.

By way of background, UMTS (Universal Mobile Telecommunications System) is a

20 third generation wireless system designed to provide higher data rates and enhanced services to subscribers. UMTS is a successor to the Global System for Mobile

Communications (GSM), with an important evolutionary step between GSM and UMTS being the General Packet Radio Service (GPRS). GPRS introduces packet switching into the GSM core network and allows direct access to packet data networks (PDNs).

25 This enables high-data rate packets switch transmissions well beyond the 64kbps limit of ISDN through the GSM call network, which is a necessity for UMTS data transmission rates of up to 2Mbps. UMTS is standardised by the 3 ^rd Generation

Partnership Project (3GPP) which is a conglomeration of regional standards bodies such as the European Telecommunication Standards Institute (ETSI), the Association of

30 Radio Industry Businesses (ARIB) and others. See 3GPP TS 23.002 for more details.

The standardisation of UMTS has progressed in phases. The first phase was known as Release '99. The Release '99 specifications define the basic architecture that consists of

the UMTS Terrestrial Radio Access Network (UTRAN), Circuit Switched Core Network (CS-CN) and Packet Switched Core Network (PS-CN). The release '99 specification offers traditional circuit as well as packet-switched services. The next phase in the standardisation process was Release 4, adding new services to the '99 architecture. Release 5 represented a significant shift, offering both traditional telephony as well as packet-switched services over a single converged packet-based network.

The UMTS Release 5 architecture added a new subsystem known as the IP Multimedia Subsystem (IMS) to the PS-CN for supporting traditional telephony as well as new multimedia services. IMS provides IP Multimedia services over mobile communication networks (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 Releases 5 to 7). IMS provides key features to enrich the end-user person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP- based networks. The IMS is able to connect to both PSTN/ISDN (Public Switched Telephone Network/Integrated Services Digital Network) as well as the Internet.

The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to- user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly. The 3GPP has chosen SIP for signalling between a User Equipment (UE) and the IMS as well as between the components within the IMS.

Figure 1 is an illustrative diagram showing a UMTS communications network 200 comprising a User Equipment (UE) 204 located within a Visited Network 202. The UE 204 is attached to a Serving GPRS Support Node (SGSN) 208 via a UTRAN 206, which is in turn in communication with a Gateway GPRS Support Node (GGSN) 210. Within the Visited Network 202, the GGSN 210 communicates with a Proxy Call

Session Control Function (P-CSCF) 212, which is the first point of contact in the visited IMS network for the UE 204. The P-CSCF 212 forwards SIP registration messages and session establishment messages to the Home Network 214.

The first point of contact within the Home Network 214 is the Interrogating Call Session Control Function (I-CSCF) 216, which is an optional node in the IMS architecture, whose main purpose is to query the Home Subscriber Server (HSS) 220 to find the location of the Serving Call Session Control Function (S-CSCF) 218. The S- CSCF 218 performs session management for the IMS network, and there can be several S-CSCFs in the network. The HSS 220 is a centralised subscriber database, and has evolved from the Home Location Register (HLR) from earlier UMTS releases. The HSS 220 interfaces with the I-CSCF and the S-CSCF to provide information about the location of the subscriber and the subscriber's subscription information.

The communications network 200 further comprises an application server 222, a database 224 and a mail server 226 located in the Home Network 214. From the S-CSCF 218, signalling messages are passed to the intended destination, which may be another Release 5 IMS network 228 comprising a UE 230, or to a legacy network 232 comprising a PSTN interfaced through a Media Gateway Control Function (MGCF), or to an IP network 234.

Specific details of the operation of the UMTS communications network 200 and of the various components within such a network can be found from the Technical Specifications for UMTS which are available from http://www.3gpp.org. Further details of the use of SIP within UMTS can be found from the 3GPP Technical Specification TS 24.228 V5.8.0 (2004-03).

Within the IMS service network, the Application Servers (ASs) are for implementing IMS service functionality. Application Servers provide services to end-users in an IMS system, and may be connected either as end-points over the 3GPP defined Mr interface, or "linked in" by an S-CSCF over the 3GPP defined ISC interface. In the latter case, Initial Filter Criteria (IFC) are used by an S-CSCF to determine which Applications Servers should be "linked in" during a SIP Session establishment (or indeed for the

purpose of any SIP method, session or non-session related). The IFCs are received by the S-CSCF from an HSS during the IMS registration procedure as part of a user's User Profile.

IMS defines an interface and mechanism that allows SIP Application Servers (ASs) and OSA (Open Service Access) Service Capability Servers (SCSs) to access end-user profile data stored in the Home Subscriber Server (HSS). This interface is called the "Sh" interface and is defined in 3GPP TS 29.328 ("IP Multimedia (IM) Subsystem Sh interlace; Signalling flows and message contents"; http://www.3 gpp.org/flp/Specs/html- info/29328.htm) and 3GPP TS 29.329 ("Sh Interface based on the Diameter protocol; Protocol details"; http://www.3gpp.org/ftp/Specs/htm1-info/29329.htm). It is an application that runs on top of the Diameter base Protocol specified by IETF RFC3588. The Sh interface is illustrated within the IMS architecture in Figure 2.

An embodiment of the present invention is intended to address one or more technical deficiencies associated with the Sh interface, as described below.

SUMMARY OF THE INVENTION

According to a first aspect of the present invention there is provided a method for use in a telecommunications network in which an Sh interface is used for communications between a database client and a database server of the network, the database server having access to at least one database for storing user data such as repository data and user profile data associated with different users of the network, comprising using the Sh interlace to convey at least one of the following types of extended data management information between the database client and the database server: first information enabling the database client to use the database server to perform a database operation on a part or parts of the user data; second information enabling the database server to provide a partial response to a request for user data from the database client; third information enabling the database server to control the flow of requests from the database client; and fourth information enabling the database server to choose the type of database used to store user data it receives from the database client.

The first information may specify the database operation to be performed.

The first information may specify a database operation to retrieve a part or parts of the repository data.

The first information may specify a database operation to retrieve a part or parts of a service data portion of the repository data.

The first information may specify a database operation to amend a part or parts of the user data.

The first information may specify at least one of: the data-model schema used to store the data; and the database type.

The second information may specify to which part or parts of the request for data the partial response relates.

The second information may specify information concerning a part or parts of the request not answered with the partial response.

Where a request relates to a plurality of data types, the second information may specify a priority for each data type, enabling the database server to respond to parts of the request in order of priority.

The method may comprise using the Sh interface to convey information enabling the database server to provide a deferred response to a request for data from the database client, for example when a previous request was provided with a partial response.

The third information may specify a limit to the number of requests that the database server can service from the database client.

The third information may specify a period of validity applicable to the specified limit.

The third information may specify whether or not requests relating to multiple data types are allowed.

The fourth information may inform the database client of the type of database used, for use subsequently as first information.

The information may comprise at least one attribute-value pair.

The network may be a Universal Mobile Telecommunications System.

The network may comprise an IP Multimedia Subsystem.

The database server may comprise a Home Subscriber Server of the Universal Mobile Telecommunications System.

The database client may comprise an Application Server of the Universal Mobile Telecommunications System.

At least one database may be provided externally of the database server.

According to a second aspect of the present invention there is provided an apparatus for use in a telecommunications network in which an Sh interface is used for communications between a database client and a database server of the network, the database server having access to at least one database for storing user data such as repository data and user profile data associated with different users of the network, comprising means for using the Sh interface to convey at least one of the following types of extended data management information between the database client and the database server: first information enabling the database client to use the database server to perform a database operation on a part or parts of the user data; second information enabling the database server to provide a partial response to a request for user data from the database client; third information enabling the database server to control the flow of requests from the database client; and fourth information enabling the database server to choose the type of database used to store user data it receives from the database client.

The apparatus may comprise the database client.

The apparatus may comprise the database server.

According to a third aspect of the present invention there is provided a method for use by a Home Subscriber Server of a Universal Mobile Telecommunications System, comprising choosing the type of database used to store application-defined repository data it receives from an Application Server of the Universal Mobile Telecommunications System based on one or more characteristics of the repository data, such as its size, service indicator and number of operations on the data.

The database types may include internal and external databases.

The method may comprise providing the Application Server with information concerning the choice made.

The method may comprise providing the information over the Sh interface.

According to a fourth aspect of the present invention there is provided a Home Subscriber Server of a Universal Mobile Telecommunications System, comprising means for choosing the type of database used to store application-defined repository data it receives from an Application Server of the Universal Mobile Telecommunications System based on one or more characteristics of the repository data, such as its size, service indicator and number of operations on the data.

According to a fifth aspect of the present invention there is provided an operating program which, when run on an apparatus, causes the apparatus to carry out a method according to the first or third aspect of the present invention.

According to a sixth aspect of the present invention there is provided an operating program which, when loaded into an apparatus, causes the apparatus to become an apparatus according to the second or fourth aspect of the present invention.

The operating program may be carried on a carrier medium. The carrier medium may be a transmission medium. The carrier medium may be a storage medium.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1, discussed hereinbefore, is a schematic diagram illustrating parts of a UMTS network;

Figure 2, also discussed hereinbefore, illustrates how the Sh interface fits within the IMS architecture;

Figure 3 shows a table setting out which Sh operations can be performed on which data types;

Figure 4 illustrates the UML format of transparent data;

Figure 5 illustrates some problems identified with the current Sh interface;

Figure 6 illustrates schematically an embodiment of the present invention; and

Figure 7 illustrates possible transparent data storage algorithms in one part of an embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The Sh interface has briefly been introduced above. A further discussion of the Sh interlace will now be provided, together with an explanation of certain deficiencies associated with the Sh interface that the present applicant has identified.

3GPP specifies which Sh operations can be performed on which data types, and the table shown in Figure 3 illustrates these operations per data type. Two generic data types are defined (see 3GPP TS 29.328 v6.4.0 and 3GPP TS 29.329 v6.3.0):

° Transparent data: identified by the Data-Reference AVP (Attribute- Value

Pair) containing "0". ° Non-transparent data: identified by the Data-Reference AVP containing

"Ix", where "x" varies between 0 and 7.

The 3GPP specifications state, in document 3GPP TS 29.328 v6.4.0, that an Sh operation can be performed simultaneously on transparent data and non-transparent data or only on one of the data types. As an example, the Sh-PuIl and Sh-Subs-Notif operations are described in 3GPP TS 29.328 as follows:

° To read transparent and/or non-transparent data for a specified user from the HSS.

° To subscribe to Notifications for when particular transparent and/or non- transparent data for a specified user is updated, from the HSS.

According to Table shown in Figure 3, the actual structure of the message in document 3GPP TS 29.329 v6.3.0 suggests that only one type of data in any given Sh operation is allowed and implemented by 3GPP (i.e. only the "or" part of the above statements is provided for). This would require an AS or SCS to perform several different Sh data requests for each different data reference, due to the complexity of operating on more than one data type in the same operation. As a consequence, there would be an increase in network traffic since an AS will have to perform several Sh operations if they wish to operate on more than one data type per user. However, it has been subsequently proposed how to handle the "and" part also, allowing 3G Application Servers to request multiple user data types (transparent and/or non-transparent) via a single Sh request, and allowing 3 G home subscriber servers and related user information servers to provide different user attributes (data references) in a single answer (see 3GPP TS 29.329 V7.2.0 (2006-06) TS 3GPP; Sh Interface based on the Diameter protocol; Protocol details (Release 7)).

One problem identified by the present applicant with the existing solution relates to the fact that transparent data is understood syntactically but not semantically by the HSS. It is data that an AS may store in the HSS to support its service logic. One example is

data that an AS stores in the HSS, using the HSS as a sort of repository. Transparent data is also called Repository-Data in the standard, and it includes three attributes: Service-Indication; Sequence-Number and Service-Data. This final attribute, Service- Data, is the attribute that stores all the transparent data defined by an AS to support its support logic. The UML (Unified Modeling Language) format of the transparent data is depicted in Figure 4, which is taken from 3GPP TS 29.328.

The Service-Data may contain structure, for instance it may conform to an XML (Extensible Markup Language) schema, yet the HSS has no knowledge of this structure (thus the "transparency" property). Hence, an AS currently needs to perform operations (read, write or send notifications) on the entire content of the Service-Data. This can be very detrimental to network performance, and already some operators are requesting to store up to 200 Kbytes of transparent data per user. Even if an AS wishes to read only a single value that occupies 1 byte in the Service-Data, currently they would be required to read the whole 200 Kbytes. Likewise, if the AS wishes to update one small value in the Service-Data (e.g. change YES to NO), it would need to send a whole new Service- Data version (i.e. all 200Kbytes) to perform this update. If an AS wishes to receive notifications of changes of a value in the Service-Data field, currently they would receive the entire Service-Data content. The inability to carry only parts or specific attributes related to the Service-Data in the Sh message is the origin of this problem.

Related to this, the current 3GPP handling of user data over the Sh interface, especially in the case of transparent data, does not consider properties related with the physical databases in which the data is stored. Such properties are: the data modelling schema and language, the database protocol used and operations that are specific to the database protocol. This is encouraging certain operators to attempt to bypass the Sh interface and use non-standardised commercial databases instead of the HSS. This is considered to be an undesirable situation from the point of view of standardisation because it duplicates the number of interfaces between the application server and the transparent data repository, or even non-transparent data repository, (i.e. Sh and other) thus increasing complexity in database administration and data inconsistency.

A further problem identified by the present applicant is that the current solution does not include a mechanism whereby each specific Sh operation (or request) can be handled differently depending on the priority or urgency of the operation. Nor does the current solution proposed in the standards define any mechanism to control the flow of Sh requests sent by an AS to the HSS, which in practice can create congestion in the HSS, considering that multiple ASs will be accessing the same HSS at the same time.

The above-identified problems are summarised in Figure 5.

As set out in further detail below, an embodiment of the present invention proposes a mechanism in the Sh interface that will enable one or more of the following:

° 3 G Application Servers to perform Sh operations on specific parts, values or attributes of the Service-Data in the transparent data. This also implies providing fine-grained syntactical structure for the Service-data attribute.

° 3 G home subscriber servers to provide information as part of the Sh protocol regarding the properties and characteristics of the actual databases and data modes used to store the user data. This will allow application servers to perform database specific operations, such as SQL

Join or LDAP Create.

° 3G home subscriber servers to be able to provide partial responses to requests for multiple user data types.

° 3G home subscriber servers to be able to send deferred responses (e.g. when an earlier request was given a partial response).

° 3 G home subscriber servers to be able to set a limit to control the flow of requests coming from a given application server.

An embodiment of the present invention provides an extended data management protocol that makes use of the Sh interface as the protocol to convey database operations and other types of extended data management information. This means that

applications are still able to use a single protocol and address when communicating with the HSS for the purpose of operating on subscription data (i.e. the Sh interface and HSS URL), but can embed into this protocol a wider range of operations and features. As set out below, a new set of AVPs or fields in the Sh Diameter message request is proposed that allows the Sh interface to incorporate a new set of functions and features in order to boost the overall technical advantages of the HSS server.

An embodiment of the present invention is illustrated schematically in Figure 6, which shows an Application Server (database client) 22 and a Home Subscriber Server (database server) 20 using the Sh interface to convey extended data management information between them.

A number of new AVPs are proposed for this purpose:

° Affected Data-References AVP. This AVP would indicate the number of datatypes that are affected by the request. It can take the following values:

° Single: indicating the data type (only one in this case).

° Combined: indicating which different data types are affected by the operation. It may contain an "order" attribute that indicates on which data type the operation must take place first and so on.

° List of transparent-data types AVP. This AVP would list the number of transparent data-types (indicating each affected Service Indicator) that are affected by the request. This would only present if the previous AVP reflects that the request relates to "single" and "transparent-data type".

° List of non-transparent-data types AVP. This AVP would list the number of non-transparent data-types that are affected by the request. This could be a numerical value (number of non-transparent data types present in the request), and would only be present if the previous AVP reflects that the request relates to "single" and "non- transparent-data type".

° Priority AVP. This AVP would be included in each specific data reference set and might indicate the order in which the different data references need to be catered for in the request. This would allow the HSS to discard Sh requests related to low priority when traffic is high, and only answer requests with higher priority. In order to avoid all data references having the same priority in a single Sh operation, it may be insisted that no repetition of a priority value is allowed in the same request.

° Service-Data specific element path AVP. This may be present for those operations related to transparent data. The path identifies a particular element, attribute, field, value or binary position in the block of data that is contained in the transparent data of a given Service Indicator and user. In this way, the Sh operation can be specified to affect only that piece of Service-Data rather than the entire content of the Service-Data. The actual format of the Service-Data element path may be an Xpath (if the transparent data follows an XML schema), an LDAP path (if the transparent data follows an LDAP DIT), or simply a value that is searched for in the Service-Data field. Other possibilities will apply to different scenarios.

° Flow control AVP. In order to control the flow of requests from a given AS, the

HSS may include in every response an AVP indicating the maximum number of requests that the AS should issue in a given period of time, or whether or not combined data-type operations are allowed (due to the extra processing involved). Should the AS exceed that limit, it may find that some requests are rejected or experience a slower response time. Those requests with higher priority would be processed first.

In order to allow the Application Servers to perform a wider set of operations on the user data stored in the HSS (particular but not exclusively in the case of transparent data) the following additional Sh AVPs are proposed:

° Data-model schema AVP. This AVP would reference the relevant data schema. It could simply be the URL or URN that points to where the data-model is stored. For instance, it could point to an XML data schema, to an LDAP data information tree (LDAP DIT) or other. This information will allow the application server to provide

detailed (or populate) paths in the above mentioned "Service-Data specific element path" AVP.

° Backend database type AVP. This AVP would specify the backend database type (as well the protocol) that is used by the HSS to store user data. If the value is empty, then this information is not available to Application Severs. Typical values for this AVP would be: LDAPv2, LDAPv3, SQL-1999, SQL-2003, etc.

° Backend database specific operation AVP. This AVP would specify an operation that is particular to the protocol used by the backend database. This allows an Application Server to perform a wider range of database operations (if authorised by the HSS) than the very reduced set currently defined by the Sh interface.

For an Application Server to make use of these AVPs over the Sh interface, the Application Server should be aware of certain issues such as which is the correct data- model schema, which backend databases are being used by the HSS and which operations are supported. In principle, this information can be configured offline by each Application Server.

An example of these AVPs is as follows:

° Data-model schema AVP: sql tablel, sql_table2

° Backend database type AVP: SQL

° Backend database specific operation:

SELECT fieldl , field2, field3

FROM sqljablel LEFT JOIN sql_table2ON sqljablel. keyfield = sql_table2.foreign_keyfield

The following mechanism is proposed to enable the HSS to provide a partial response to a request for data from the AS.

When the HSS receives a request for multiple data types it would evaluate whether the compilation of all requested information elements is feasible (if they are available) or if some information elements will require a longer processing time than others (for example, because they imply sending a request to another network node; this happens in requests when circuit switched and/or packet switched user state and location is requested, the HSS needs to interrogate the HLR about that information).

In the event that not all the information can be returned immediately, the HSS would generate a partial response, with the information elements that are available and also an indication about what the AS should expect about the remaining information elements. Such an indication would tell the AS whether there was a permanent condition that will prevent the return of that information (e.g. because that information is not available in the HSS or the HSS does not have the means to obtain it) or whether the information will be sent in a separate message.

Deferred responses can be handled as one-event notifications. A notification may be sent even in the case where an error prevents the inclusion of the requested information.

In addition to the previous improvements affecting the data management interface between the AS and the HSS, the HSS may also include a data storage decision mechanism and algorithm to allow the dynamic storing and re-distribution of application-defined transparent data to different data storage technologies (i.e. disk database, file-system, in-memory etc) based on a set of criteria. (Application Servers may directly define and create new transparent data over the Sh interface in the HSS without using any provisioning system.)

An example of possible transparent data storage algorithms is provided in Figure 7. The internal HSS mechanism selects which data storage technology is the most appropriate for each type of application defined transparent data. It retains control of where the data has been stored. It can also re-distribute the transparent data dynamically if conditions change. For example, if traffic on transparent data for a set of users becomes very high and the data was initially stored on disk then the data storage decision mechanism of the

HSS can re-evaluate the new conditions and shift the data to a more appropriate fast access database.

An embodiment of the present invention offers one or more of the following advantages.

The inclusion of mechanisms to control the load imposed by an AS on the HSS and the priority to process requests represents an advantage in terms of efficiency of the HSS, which is able to protect itself and guarantee that the performance of critical applications that it has to perform doesn't fall under a given threshold.

The inclusion of an internal data storage decision algorithm in the HSS allows the HSS to dynamically make use of a variety of heterogeneous data storage resources to ensure that its overall performance and is resource usage is always optimal. This approach fits in with overall data management architectures currently being specified in other technologies.

Allowing application services to perform fine grained operations on transparent data as well as informing the AS of the type of database in which the data is stored, protocol being used and data-model followed means that less data is transported over the network, and also ensures that applications need only use the HSS as their repository.

The Sh interface is provided with a set of operations that increase its value. An extended data management protocol is proposed that makes use of the Sh interface as the protocol to convey database operations amongst other types of information. This means that applications need only have knowledge of one protocol and address when communicating with the HSS for the purpose of operating on subscription data, but can embed into this protocol a wide range of operations and features. This reduces the need for Application Servers to bypass the HSS to allow for complex storage and retrieval database operations, which is a benefit for standardisation.

There is no existing solution that combines the benefits of allowing requests of multiple data types, together with the mechanisms to control load, priority of handling of

requests and possibility to return partial responses and deferred responses. In addition, the possibility of sending many database operations over a single protocol (in this case the Sh interface) does not exist. Neither is the possibility of dynamically selecting the database storage mechanism.

Although the above description has set out an embodiment of the present invention with reference to a HSS, it will be appreciated that the present invention can be applied to a general scenario where a database server is in communication with a database client using the Sh interface, whether or not the database server is called a HSS and whether or not the database client is called an Application Server.

It will be appreciated that operation of one or more of the above-described components can be controlled by a program operating on the device or apparatus. Such an operating program can be stored on a computer-readable medium, or could, for example, be embodied in a signal such as a downloadable data signal provided from an Internet website. The appended claims are to be interpreted as covering an operating program by itself, or as a record on a carrier, or as a signal, or in any other form.