WO2010034350A1

WO2010034350A1 - Method for processing database communications

Info

Publication number: WO2010034350A1
Application number: PCT/EP2008/062922
Authority: WO
Inventors: Daniel MATEOS PÉREZ; Jesus Solana Gonzalez
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2008-09-26
Filing date: 2008-09-26
Publication date: 2010-04-01

Abstract

Method, apparatus and computer programs for processing communications between a database server and a database client. The database server stores (210) a plurality of credentials usable for authenticating the same client. The server further stores (230) a processing priority in relationship with each of said credentials, wherein the processing priorities related to a first and a second credentials of said client among said plurality differ, and wherein a processing priority comprises information usable for determining the assignation of processing resources in the database server to serve a request received from a database client within a communication session. The database server assigns (237, 238) the related priority (Pl, P2) for serving a request received from the database client within a communication session according to the credentials (Cl, C2) used for authenticating said database client when establishing (235, 237) said communication session.

Description

METHOD FOR PROCESSING DATABASE COMMUNICATIONS

FIELD OF THE INVENTION

The present invention relates to methods, apparatuses and computer programs for processing communications between a database server and a database client.

BACKGROUND

Traditionally, information and telecommunications services have been offered based on the use of monolithic servers. Such a kind of servers comprise processing logic and data storage capabilities that allow them to process the signaling they can receive, as well as the signaling to be sent, by using data they store internally.

However, factors such as, among others: scalability, performance or deployment/implementation cost, are starting to drive towards another kind of solution, wherein the functionality provided by some monolithic servers is -say- "tiered" resulting into a layered architecture. The principle behind this kind of solution consists on decoupling the service logic processing from the mere data storage .

A layered architecture comprises, in essence: a plurality of signaling front-ends FEs and a back-end database server DBS. In short, the FEs comprise the necessary signaling and processing means for providing the specific service (s) they serve, while the DBS merely stores the data that can be needed by a FE for processing a service. Depending on factors, such as: the amount of data to be stored, access availability, data distribution policies, etc; the DBS can comprise one or more physical databases DB (e.g. implemented along separated machines), wherein, also depending on implementation factors, some data can be replicated in more than one DB.

For example, in a telecommunications system, servers which are being envisaged so as to be adapted according to a layered architecture are, among others: Home Location Registers HLR, Home Subscriber Servers HSS, Device Configuration Registers DCR, Service Policy Controllers SPC, Authorization and Authentication servers AAA. A brief description of them will be later provided. All these kind of servers, in monolithic implementations, hold and store internally data related to a plurality of users, some of which can be common regardless the application/service type served by a specific server, and, therefore, can benefit from a layered architecture implementation, wherein some/all of the user data related to these applications are stored in a common DBS.

In these kinds of layered scenarios, FEs of a telecommunications system (e.g. HLR-FEs, HSS-FEs, DCR-FEs, etc) can then become (standard) database clients of a database server DBS, which makes possible to use commercially available database solutions rather than devising costly proprietary products. For example, some DBSs available today offer high-performance storage and reliability features, and allow using well-known standardized access protocols, such as the "Lightweight Directory Access Protocol" LDAP, for providing access to many kinds of eventual database clients. Among other features and advantages, LDAP provides authentication mechanisms for establishing a communication session (LDAP session) between a database client and a database server, which provides remote access security, and thus allows the database clients and the DBS to be distributed across different geographical locations (e.g. accessible through intranets and/or through the Internet) . By providing authentication credentials to a database client, and storing the corresponding credentials in the DBS, the client can use its credentials for being identified and authenticated by the DBS, and establishing with it a communication session (e.g. a LDAP session), which allows said client to request database operations to the DBS within said session.

A further advantage of a layered architecture is that the signaling load from service clients of a given service, for example clients of the services provided by a HLR or HSSs (such as e.g.: Mobile Switching Centers/Visitor Location Registers MSC/VLRs, Serving GPRS Support Nodes SGSNs, Call Session Control Functions CSCFs, etc) , can be distributed along the plurality of available HLR and/or HSS FEs acting, on the one side, as if they were monolithic HLR/HSS servers for the service clients and, on the other hand, as database clients for the DBS. Therefore, the service availability is increased, since the signaling load due to these clients can be distributed along a plurality of available FEs, which can be selected by using any suitable distribution algorithm. Besides, these FEs can be implemented by -say- "light-weight" machines that do not require a high data storage capacity. Also, operation and maintenance O&M tasks over the necessary user data is simplified, as only the DBS is to be contacted and not a plurality of servers, which also helps to keep data consistency when the same user data is used for more than one application/service. However, the final performance of a system comprising a plurality of database clients (such as the signaling FEs cited above) and a back-end database server DBS relies significantly on the performance of the DBS. Therefore, optimizing the usage of its resources becomes of the outmost importance.

SUMN[ARY Aspects of the invention relate to a method, a database server, a database client and computer program products, as claimed in the independent claims. Embodiments of the invention are set out in the dependent claims.

According to one aspect of the invention, the database server stores a plurality of credentials, which are usable for authenticating the same database client, and, in relationship with each of said credentials, a processing priority, which comprises information usable for determining the assignation of processing resources in the database server to serve a request received from a database client within a communication session; wherein the processing priorities related to a first and a second credentials of said client among said plurality differ. Then, the database server assigns the related priority for serving a request received from the database client within a communication session according to the credentials used for authenticating said database client when establishing said communication session.

By assigning more than one set of credentials to the same client, and by assigning different processing priorities to these credentials, a flexible allocation of processing resources in the database server can be achieved when dealing with a high rate of requests coming from a plurality of database clients, which respective processing by the database server can be prioritized according to the credentials supplied in the corresponding different communication sessions.

In a system arranged according to a layered architecture, as well as in any other system comprising a plurality of database clients and at least a database, this flexible allocation feature allows optimizing the usage of processing resources of the back-end database system in a simplified way, as it does not requires modification in the database access protocol used.

According to one embodiment of the invention, a database client establishes a communication session with the database server using credentials, selected among a plurality of credentials of said client, according to a function being performed by said client, among a plurality of functions that can be performed by said client. These functions can comprise: end-user traffic functions, operation and maintenance functions, data provisioning functions and data report functions.

According to a further embodiment, first and second simultaneous communication sessions are established between a database client and the database server, each of said sessions being established using, respectively, first and second credentials selected among said plurality of credentials. Requests from the database client to the database server can be sent via any of these communication sessions, which shall be processed by the database server with the corresponding, different, processing priorities.

According to yet a further embodiment, the database server selects the processing priority that is to be stored in relationship with at least one of the plurality of credentials of a database client, which can be determined according to a plurality of functions that can be performed by the client.

Requests from the same database client are thus not necessarily processed in the database server according to the same priority criteria, but can be flexibly determined according to a function being performed by said client in a given time. The usage of processing resources in the database server for serving a plurality of, eventually concurrent, requests from database clients can therefore be advantageously adapted by indirect indication of the database clients, or even from the same database client, which can use their/its different credentials to distinguish requests made to the server, in separate communication sessions, depending on factors such as the time response requirements of the application function they/it are/is performing in a given moment.

Features of the invention therefore provide a simplified solution to prioritize signaling and task preemption in layered architectures, since they do not require any change in the communication protocol used to communicate with the database server, so as to convey information about the function being performed by a database client when sending a request to the database server. These features also permit the deployment of database clients, such as signaling front-ends in layered architectures, that can be arranged to serve a plurality of functions, which can be related to the same or different service/application, and which does not necessarily have the same time response requirements, wherein a database client can request in a easy way to the back-end database server a processing priority accordingly.

Features of the invention are advantageously applicable to telecommunications systems having some of their telecommunications nodes/servers arranged according to a layered architecture. Accordingly, database clients as disclosed herein can comprise, but are not limited to, signaling front-ends performing functions of: Home Location Registers HLR, Home Subscriber Servers HSS, Device Configuration Registers DCR, Service Policy Controllers SPC or Authorization and Authentication servers AAA.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 shows a schematic representation of a part of a telecommunications system comprising some nodes arranged according to a layered architecture according to one embodiment of the invention.

Figure 2 shows a flowchart illustrating some steps of a method according to embodiments of the invention.

Figure 3 shows details of a multi-session scenario in the telecommunications system of Fig.l. Figure 4 shows schematically some configuration data for assigning processing priorities in a database server according to one embodiment of the invention.

Figure 5 shows a schematic representation of some functional modules of a database server or a database client according to one embodiment of the invention.

DETAILED DESCRIPTION Exemplary embodiments of the invention shall now be described with reference to figures 1 to 5.

Traffic and number of subscribers/users of telecommunications and data communications systems trend to continuously grow. This fact causes the operators owning these systems to demand from technology providers solutions offering more performance, capacity and, at the same time, flexibility. As described earlier, a layered architecture applied to some servers can be a solution for these kinds of demands, wherein the processing logic and the mere data storage is, respectively, divided among signaling FEs and back-end storage DBS. The FEs thus behave as database clients database server DBS.

Figure 1 shows, schematically, part of a telecommunications system 100 comprising some nodes arranged according to a layered architecture according to one embodiment of the invention. For the sake of illustration, the system of Fig.l can be assumed to comprise functional entities of a 3^rd Generation 3G telecommunications system, as described in 3GPP Specification TS 23.002 V8.2.0 (Dec. 2007; http : //www.3gpp . org/ftp/Specs/archive/23_series/23.002/2300 2-820.zip) . Exemplary embodiments of the invention are described hereinafter with reference to functional entities (FEs and DBS) of the scenario illustrated in Fig.l. However, features and advantages of the invention are equally applicable to any scenario comprising database clients (not necessarily signaling FEs of a layered architecture) and a DBS. Shortly, a database client is a machine (e.g. a computer-based machine) arranged to communicate with other machine (e.g. another computer based machine) that holds the storage of data (referred herein as database server DBS) , for obtaining and/or setting and/or modifying and/or erasing some of these data. The protocol model commonly used in said kind of communications uses to align with the client-server model, wherein the clients (database clients in this particular case) perform protocol operations against server (s) (database servers in this particular case) . The "Lightweight Directory Access Protocol" LDAP (IETF RFC 4511, June 2006) is an example of such a kind of protocol.

Figure 1 illustrates part of a telecommunications system as described above comprising: Home Subscriber Server HSS and/or Home Location Register (HSS/HLR-LA) signaling FEs (101-1..101-N) , Service Policy Controller server (SPC-LA) signaling FEs (102-1..102-N) , Authorization and Authentication server (AAA-LA) signaling FEs (103-1..103- N) , and Device Configuration Register (DCR-LA) signaling FEs (104-1..104-N) . All these servers are shown arranged according to a layered architecture comprising: a plurality of FEs, and a database server system DBS 105, which stores data that are needed for the functional operation of the FEs. A short description of the functions performed by the functionality of these servers/nodes (which theoretically should not be affected irrespectively on whether they are implemented according to monolithic or layered architectures) is provided below. The function, or set of functions, (as summarized below) that distinguish and characterize the well-known generic functionality of a node/server is referred herein as "end-user traffic function".

A Home Location Register server HLR holds the main storage of data related to a plurality of users subscribed to mobile system, and provides some of these data to other servers in the system (such as MSC/VLRs, SGSNs, CSCFs, etc) for providing telecommunications services to these users. A Home Subscriber Server HSS performs a similar function in the so called Internet-Protocol Multimedia Subsystem IMS of a 3^rd Generation telecommunications system (such as UMTS) . As an option, a HSS can encompass also the functionality of a HLR, or be implemented as a stand-alone (monolithic or layered) server for IMS only, which is sometimes a more economical option when an operator starts deploying a IMS system. Signaling FEs 101-1 to 101-N can be assumed to comprise FEs implementing: HLR functionality, global HSS functionality, or IMS limited HSS functionality.

A Device Configuration Register DCR is a server which is arranged to automatically configure a user terminal attached to a mobile communications system, and, for this purpose, it needs to hold identification and configuration data of a plurality of users and terminals. Patent application WO 03/096724 Al describes a DCR in detail. A Service Policy Controller server SPC is arranged to provide policy decision services to policy enforcing points (PEPs) that route data packets for controlling, among other: quality of packet flows in packet based communications, packet inspection policies, etc. A brief description of a commercial SPC can be found on http : //www. ericsson. com/solutions/page . asp?ArticleId=DAC6FD 80-5870-4096-873C-79E5D947F099. Also, 3GPP Specification TS 23.203 (V8.2.0; June 2008) discloses a "Policy and Charging Rules Function" PCRF, which performs as a SPC in a 3^rd Generation telecommunications system.

Authorization, authentication and, usually, also accounting functions for users accessing packet-based data networks are generally provided by the so called AAA servers. For performing some of its functions, a AAA server holds user data for, at least, verifying the identity of a user from a terminal and granting access to said terminal to the services provided by, or through, a data network. The use of AAA servers in 3G telecommunications system has been envisaged for controlling access and service authentication/authorization for terminals connected to, for example, Local Area Networks (LAN) or wireless LAN (WLAN) .

To perform their respective functions, the servers/nodes cited above as examples, need to have access to data of the users and/or terminals to which they provide a final service, so as to obtain, set and/or modify some of these data and/or take functional decisions based on them. In the illustrated example, these server/nodes are implemented according to a layered architecture, wherein these data are stored by DBS 105, and wherein the access to these data is assumed to be provided by establishing LDAP communication sessions between the database clients FEs (101-1..104-N) and the DBS 105.

In the communication session establishment procedure, a database client, for example SPC FE 102-1, authenticates before the DBS by providing its credentials. Subsequently, said client is allowed to send further requests for managing data held by the LDAP server.

The communication session illustrated in Fig.l comprise: - Sessions Sl to SN established, respectively, by HSS/HLR FEs 101-1 to 101-N.

- Sessions Tl to TN established, respectively, by SPC FEs 102-1 to 102-N.

- Sessions Ul to UN established, respectively, by AAA FEs 103-1 to 103-N.

- Sessions Vl to VN established, respectively, by DCR FEs 104-1 to 104-N.

According to the known techniques, one session (e.g. LDAP session) suffices for a database client for sending request to the DBS, so as to retrieve, modify, set or delete, etc, data in the DBS, and Fig.l illustrates said case. Very basically, every time an LDAP BIND is received from an LDAP client (for example, HSS FE 101-1) in an LDAP server (DBS 105) , a LDAP session is established. Request/response messages exchanged within a LDAP communication session established between a LDAP client and a LDAP server can be identified in any of these entities by any data of the combined services said session implies, such as: transport connection (e.g. IP address and port number), TLS layer, SASL layer, etc.

Although not shown for simplicity, some of the FEs illustrated in Fig.l can also establish permanent/temporary communications with other entities to which they serve, and which requires access to the DBS 105. For example, HSS FE 101-1 can receive DIAMETER requests from a plurality of Interrogating or Serving CSCFs (I/S-CSCFs) and, for example HLR FE 101-1 can receive Mobile Application Part MAP requests from MSC/VLRs. Similarly, SPC FE 102-1 can receive indications from an Application Server that a data bearer has to be established for a user terminal, AAA FE 103-1 receive a request to authenticate a user terminal accessing from a WLAN, and DCR FE 104-N a request to send data to configure GPRS access to a particular terminal.

The functions referred above as examples for the illustrated FEs, and referred herein as "end-user traffic service function", encompass, for each FE, the function or set of functions that distinguish and characterize the generic (i.e. well-known, sometimes standardized) functionality of the node/server said FE implements, and which have been referred above with regard to HLRs, HSSs, SPCs, AAAs and DCRs, as examples.

As opposed to said "end-user traffic service functions", there are other functions that are commonly implemented by many servers and telecommunications nodes, such as:

Operation and Maintenance functions O&M, e.g. comprising tracing or, (pre) corrective actions like consistency checks (i.e., in general, node/server management functions); data Provisioning functions, e.g. for setting subscriber data at subscription creation or modification; or data Report functions, e.g. for periodical statistics generation about traffic load, service usage, etc. When a server/node is implemented according to a layered architecture, the corresponding FE is assumed to implement the logic to serve also these other functions, which, as can be clearly understood, usually require the FE(s) to access also to the DBS 105 so as to store/retrieve/delete/modify/etc the necessary data. Therefore, the term "end-user", as related to a kind of function ("traffic service function") is not to be construed herein as necessarily related to a human user (e.g. interacting from a terminal with a server/node), but rather to the kind of natural client consuming, or making use of, the well-known characterizing functionalities referred above.

In summary, Fig.l illustrates a scenario wherein different applications (HSS application, HLR application, SPC application, etc) are run from a plurality of FEs (101-1 .. 104-N), and wherein some of these FEs can perform various specific functions (among others: end-user traffic service functions, O&M functions, Provisioning functions, Report functions) . Namely, the same FE can act with different roles (e.g. a HSS subject to O&M operations, or a HSS serving -say- normal traffic requests) .

As cited earlier, a given FE, such as HSS 101-1, once its

(only) communication session Sl with the DBS 105 has been established, can send LDAP requests for accomplishing any of these functions (e.g. end-user traffic service functions, O&M functions, Provisioning functions, Report functions) . In fact, a LDAP request "Search" due to the accomplishment of a end-user traffic service function (e.g. a HLR FE has received a MAP operation "SendRoutinglnformation" and it subsequently searches for some subscriber data) is indistinguishable for the DBS 105 from another LDAP request "Search" due to another function (e.g. the same HLR FE has received a request from a O&M server or terminal to retrieve data of a given subscriber) .

This -say- "transparency" feature provided by the use of a standardized access protocol, such as LDAP, can turn into a disadvantage when the protocol is used in a multi- application environment, wherein some database clients implement, not only a -say- main characterizing application (e.g. a SPC application) or function (e.g. an end-user traffic service function) , but a plurality of applications or functions. Examples of these functions are the end-user traffic service functions, O&M functions, Provisioning functions and Report functions, cited above.

Embodiments of the invention provide solutions usable to discern among different functions performed by different database clients, and assigning corresponding processing priorities in the database server, so as to perform a controlled, and effective, processing of requests received in the database server from the database clients, aiming to optimize the processing capabilities and resources occupancy of the database server, and also to coordinate with the, usually different, processing priorities required by the different functions that can be performed by the database clients.

Most of the different kind of functions referred above are usually assigned different processing priorities in most of the monolithic implementations of server and nodes, such as: HLRs, HSSs, SCPs, DCRs or AAAs. However, when deploying nodes/servers according to a layered architecture, and standardized database access protocols are used, this advantageous prioritization characteristic can degrade, or can even be lost, given that, in most of these protocols, these requests and the subsequent responses are generic and, thus, also advantageously independent of the service/application being performed by the database client. As will be apparent from the description, embodiments of the invention provide a simplified solution to prioritize signaling and task preemption also in layered architectures, since they do not require any change in the communication protocol used to communicate with the database server, so as to convey information about the function being performed by a database client when sending a request to the database server .

Figure 2 shows a flowchart illustrating some steps of a method according to embodiments of the invention. For simplicity, the method illustrated in Fig.2 comprises steps executed in a single database client (e.g. HSS FE 101-1), and in a database server (e.g. DBS 105) with regard to said database client.

Step 210 represents the storage of authentication credentials related to database client 101-1 by the DBS 105 and by said client. As referred earlier, in the communication session establishment procedure between a database client and a database server, the database client authenticates before the DBS by providing its credentials, wherein LDAP request BIND is used to exchange authentication information. The nature of the credentials related to a database client can vary depending on the utilized (supported) authentication method, which is indicated in the BIND request.

LDAP allows "Simple" and "SASL" (Simple Authentication and Security Layer) as authentication choices. When using Simple authentication, the database client provides username and password. In turn, SASL (IETF RFC 4422) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms, which uses different kind of credentials. In either case, the LDAP server 105 stores the necessary credentials related to a particular database client so as to authenticate it in a communication session and, subsequently, allow said client to send subsequent requests for managing data held by the LDAP server. The database client can also store its credentials, just temporarily (as provided by another entity or user) before its use for authentication, or in a more permanent basis.

The storage step 210 in the database client 101-1 and in the database server 105 preferably comprises the storage of, not a single set of credentials for the client 101-1, but the storage of a plurality of credentials for said client. For example if the LDAP Simple authentication mechanism is selected, this implies the storage of a plurality of sets of username/password related to the same database client. Each of the credentials, among the plurality of credentials stored for database client 101-1, is therefore independently usable for authenticating successfully database client 101-1 before database server 105 when said client establishes a communication session. Step 220 represents an advantageous embodiment that can performed in the database server 105, wherein different processing priorities are selected to be assigned to each of the plurality of credentials of database client 101-1. The distribution when selecting processing priorities among credentials of a database client can vary. For example, a different processing priority can be selected for each credentials of said plurality of credentials, or the same processing priority can be selected for more than one of the credentials. The selection step 220 can be based on information held by the database server 105 (e.g. preconfigured therein, or obtained from the server 105) which can take into account the different functions or applications that can be performed by the concerned database client.

The processing priority that is related to each credentials of database client 101-1 is stored by the database server 105 in step 230. In order to obtain the advantages described earlier, the processing priorities assigned to first and second credentials of database client 101-1, among all the credentials stored for said client, differ. This will allow database server 105 processing with different criteria requests coming from said client, which can imply different usage of processing, storage and communication resources in database server 105, so that the response time for different requests (e.g. received from the same database client, but within different sessions established using different credentials) can vary depending on the corresponding assigned processing priority.

Steps 231 and 232 represent, respectively, the starting of different functions (Fl, F2) in the database client 101-1. Both functions are not necessarily are started simultaneously, nor necessarily run permanently, in database client 101-1. For example, if client 101-1 runs a HSS application (e.g. client 101-1 is a HSS-FE), function Fl can represent end-user traffic service functions due to its well-known (standardized) operation. Namely, Fl can for example comprise reception and processing of messages received from I-CSCFs or S-CSCFs for obtaining and/or modifying subscriber related information. In turn, function F2 can represent a data reporting function, wherein the HSS-FE client 101-1 has received a request (e.g. from a management or post-processing system) for sending data related to a plurality of subscribers.

Since HSS-FE client 101-1 is a signaling FE, for processing requests related to any of these functions cited as examples (Fl, F2) needs to get access to the database server DBS 105. On step 233 the client 101-1 selects credentials Cl, and establishes a communication session Sl with the database server 105 on step 235. On step 234 the client 101-1 selects credentials C2, and establishes a communication session S2 with the database server 105 on step 236. Accordingly, requests/responses between database client 101-1 and database server 105 related to end-user traffic function Fl are exchanged through session Sl, and the ones related to data reporting function F2 through session S2.

Credentials Cl and C2 are selected by database client 101-1 according to, respectively, functions Fl and F2. The relationship between: the plurality of functions (or applications) that can be executed/implemented by database client 101-1, and the corresponding credentials to be used for establishing communications sessions with the database server 105, can be preconfigured in the database client 101-1.

As cited above, the nature of functions Fl and F2 can differ, which can cause both sessions Sl, S2 to be active simultaneously in a given moment, or not. In the example referred above, is likely that (at least in normal operation) session Sl is permanently open, while session S2 can be opened ad-hoc, for example, opened when a data reporting related request is received by the client 101-1, and terminated when all the necessary data have been collected from the database server 105.

In step 237 the database server 115 assigns a processing priority Pl for processing request messages received within communication session Sl, and in step 238 it assigns processing priority P2 for processing request messages received within communication session S2. This can be accomplished by selecting the processing priority (Pl, P2) stored (step 230) in relationship with the credentials used by the database client 101-1 when establishing each of the sessions (Sl, S2) .

In other words, the credentials used by the database client during the establishment of a communication session (Sl or S2), are used by the database server to determine the corresponding priority (Pl or P2) which shall apply to process further requests received via said session. The means and method used for implementing different processing priorities usable for determining the assignation of processing resources for serving the process (or set of processes) related to a received message (e.g. a LDAP request message) in, for example, computer-based apparatuses are well-known by those skilled in the art, and comprise, among other: scheduling algorithms for concurrency control, different preemptive task processing queues, multi-threading in multithreaded processors, task preemption, etc. The result of assigning different processing priorities in the database server 105 to different sessions (established with the same client, or with different database clients) would consequently produce, e.g. in case of concurrency of requests related to different sessions, a faster response for some of these requests. In general, processing resource allocation (e.g. in terms of memory usage, scheduling of processing time, etc) when processing requests from database clients can be managed in the DBS according to the corresponding processing priority assigned to the credentials used in the corresponding session.

A further improvement can comprise assign several different processing priorities in relationship to one of the credentials of a given client per type of request, so as to distinguish between different request messages received from the same client within the same communication session, and process them according to different priorities. Accordingly, for requests received within the same communication session of a database client, for example, LDAP Search requests can be assigned a higher processing priority than LDAP Compare requests.

Figure 3 illustrates schematically some of the FEs referred in the description given before in relationship with Fig.l involved in a multi-session scenario with a database system DBS 105 structured according to an embodiment of the invention. This embodiment comprises a DBS structured into a first layer, comprising a LDAP client priority handler (LCPH) 105-1, and databases 105-2, 105-3.

The LCPH is illustrated in Fig.3 as a standalone entity, which communicates via network 30 with databases 105-2 and 105-3, although it can be co-located as an extra function (e.g. comprising software, hardware or combination thereof) in a monolithic DBS. The LCPH 105-1 can perform the following functions:

- Interception of traffic (e.g. LDAP traffic) between database clients (101-1, 101-2, 102-1) and the back end database(s) (105-2, 105-3).

- Assignation of priorities on a per-session based for processing requests from database clients, according to the corresponding (related) credentials used when a session with a database client was established, and

- Perform an optional flow control.

For accomplishing with these functions, the LCPH is preferably configured with a prioritization data table, such as the one illustrated in Fig.4, which shall be further detailed later. Said table could be used to assign processing priorities, which shall be usable to determine the usage of processing resources for processing in the DBS 105 a request received within a communication session from a database client.

Entries in said table can be addressed by using information identifying the communication session through which a LDAP request is received from a database client (as referred earlier: transport connection data trough which the request is received, etc) and, in a simplified embodiment, entries in the table can comprise e.g. alphanumeric values representing different processing priorities (numeric integer values are shown in the example of the Fig.4. Implicitly, entry information in this table would state (i.e. when the processing priorities are assigned accordingly with the configured credentials in the DBS and in the database clients) : the application from which the request is made (e.g. HSS application, DCR application, SPC application, etc) , and/or the functionality being performed by the database client when sending the request message

(e.g. an end-user traffic function, an O&M function, etc). In other words, the use of a plurality of different credentials from the same database client, and a proper assignation of different processing priorities in relationship with each of these credentials, provides in the DBS an effective application/function-aware processing in a simplified manner.

According to a simplified implementation, based on the processing priorities, the LCPH can buffer (e.g. message buffer, task processing buffer, etc) requests coming from database clients which can not be processed at a given moment (e.g. due to requests received from other clients, which are assigned to higher processing priority, and which are still being processed) . If, for example, a buffer becomes full in the LCPH, it can send a notification message using any suitable communication protocol to the corresponding client (s) with the purpose of flow-control of messages from said client (s). Alternatively, a less gracefully handling can be performed by sending, for example, a LDAP Notice of Disconnection to the affected client (s). Also, a simply drop of further request (s) received from said client (s) can be performed by the LCPH. The embodiment illustrated in Fig.3 shows various FEs have established different concurrent communication sessions established with a DBS 105. HSS FEs 101-1 and 101-2 have opened each 3 communications sessions with the DBS 105, and SPC-FE 102-1 has opened 2 communications sessions with the DBS 105. For the sake of illustration, it is assumed that all these sessions have been established from these FEs using different credentials assigned, respectively, to each of them; wherein first and second credentials used from a FE when establishing first and second communication sessions, and the corresponding assigned processing priorities in the DBS 105, differ. Preferably, the credentials selected by a FE when establishing a communication session with the DBS 105 are selected according to a function that can be performed by said FE, and for conveying requests (and subsequent responses) due to the execution of said function.

Sessions SlA and S2A carry LDAP request/response messages for O&M (or node management) functions being performed by, respectively, HSS-FE 101-1 and HSS-FE 101-2. In turn, LDAP request messages from SPC-FE 102-1, and the subsequent responses, due to the same kind of function are conveyed within communication session TlA. Sessions SlB and S2B carry LDAP request/response messages for end-user traffic service functions being performed by, respectively, HSS-FE 101-1 and HSS-FE 101-2. As cited earlier, these functions are due to the performance of -say- standardized HSS functions as such in these HSS FEs; for example, due to the reception in HSS-FE 101-1 or HSS-FE 101-2 of DIAMETER requests from I-CSCFs or S-CSCFs. In turn, LDAP request messages from SPC-FE 102-1, and the subsequent responses, due to end-user traffic service functions executed by SPC- FE 102-1 are conveyed within communication session TlB. As cited earlier, a Service Policy Controller SPC (as referred herein) can be a "Policy and Charging Rules Function" PCRF as described in 3GPP Specification 23.203. Accordingly, in a layered implementation of a PCRF, some of the traffic functions standardized for said kind of node require access to a data repository (e.g. the so called "Subscription Profile Repository" SPR in the aforementioned 3GPP Specification) , which relevant data can advantageously be stored by DBS 105. An example of this kind of end-user traffic service functions therefore comprise, among other, reception from a "Policy and Charging Enforcement Function" PCEF of notifications related to user's IP session establishment or termination. Sessions SlC and S2C are opened from, respectively, HSS-FE 101-1 and HSS-FE 101-2 to send their particular requests to the DBS 105 that are due to the respective execution in these FEs of data provisioning functions. As referred earlier, functions related to setting/modifying subscriber data (e.g. at subscription creation or modification) are usually known as data provisioning functions. Requests for data provisioning functions can come into a node/server (as any of the illustrated in Fig.l) from a provisioning server, or can also come as direct or indirect requests from a subscriber via his user terminal (function usually known as "self- provisioning") .

All the functions cited above with reference to Fig.3 (O&M functions, end-user traffic service functions, data provisioning functions) require for the concerned database clients (HSS-FE 101-1, HSS-FE 101-2, SPC-FE 102-1) to access to the data storage held by DBS 105. According to embodiments of the invention, and for any of said clients, said access can be made through separate communication sessions, which were established using different credentials of said client, and which are assigned to different processing priorities by the DBS 105; so that, for example, a LDAP Search request made from HSS-FE 101-1 via session SlA can be assigned to a higher processing priority that LDAP requests made from the same HSS-FE 101-1 via sessions SlB or SlC.

In the example illustrated in Fig.3, SPC-FE 102-1 has not opened simultaneous sessions for other functions than O&M (session TlA) and end-user traffic service (session TlB) functions. This does not necessarily mean that, for example, data provisioning or data reporting functions are not performed by SPC-FE 102-1, but that, as an option in SPC-FE 102-1, sessions for sending requests to DBS 105 related to these functions are opened when needed (e.g. when any of these functions is executed by SPC-FE 102-1), and closed when not needed.

Embodiments related to the assignation of processing priorities in a DBS, related to individual credentials of database clients, shall now be described with reference to Fig.4.

The table of Fig.4 illustrates, by way of examples, relationships between: the credentials held for some of the database clients illustrated in Fig.l, and the processing priorities that can be assigned to these credentials by the DBS 105 for processing requests from these clients received on a given communication session, depending on the credentials used by these clients when establishing their communication sessions. The illustrated embodiment considers a simplified implementation wherein higher/lower processing priorities are represented based on higher/lower numeric values. According to this simplified implementation, a relationship can be established between a numeric value (or a range of values) and the corresponding assignation of processing resources, for example, for prioritizing the related task(s) by applying scheduling algorithms, preemptive task processing queues, etc.

The left most column in Fig.4 (APPLIC/CRED) illustrates without detail the credentials of some of the database clients shown in Fig.l. For example, "101-1 CS" under column "APPLIC/CRED" represents (without detail) the plurality of credentials of FE 101-1 for each of the different functions that can be performed by said FE (MANAGEMENT, TRAFFIC, PROVISIONING, REPORT) . For example if the LDAP Simple authentication mechanism is used from FE 101-1, "101-1 CS" under column "APPLIC/CRED" intends to represent a plurality of sets username/password related to the same database client FE 101-1.

According to the illustrated example, 4 different credentials of e.g. database client 101-1 (not shown in detail, but represented grouped under reference "101-1 CS") are respectively assigned to processing priorities as follows :

- e.g. credentials Cl (not shown), processing priority 200, for O&M functions (MANAGEMENT) , - e.g. credentials C2 (not shown), processing priority 100, for end-user traffic service functions (TRAFFIC) ,

- e.g. credentials C3 (not shown), processing priority 40, for data provisioning functions (PROVISIONING) , and - e.g. credentials C4 (not shown), processing priority 10, for data report function (REPORT) .

Accordingly, requests received within a session established from FE 101-1 using e.g. credentials C2 shall be assigned to processing priority 100 by the DBS 105.

Not all the functions considered in the example of Fig.4 under "ACCESSING FUNCTION" need to be implemented by all the database clients, nor be assigned to separate credentials. This is illustrated by empty symbols "--" in, for example, data provisioning functions (PROVISIONING) corresponding to clients 102-1 and 102-2.

It is to be noticed that, although some examples of "functions" (ACCESSING FUNCTION) are shown in Fig.4, the DBS 105 does not need to be aware of them; but, in a simplified embodiment, be merely configured with the processing priority that is to be assigned for each of the credentials of any of the database clients that can establish a communication session with it. Therefore, the DBS 105 can be totally unaware of the functions, or applications, being performed by any of its database clients, and, in this respect, take only care of assigning a processing priority for serving requests received from a database client within a communication session according to the credentials used by said client when establishing said session. For accomplishing with this, the DBS 105 can merely store the plurality of credentials of a given client in relationship with the corresponding processing priorities.

Therefore, in a multi-application multi-function scenario, processing effectiveness in a DBS is achieved can be achieved a simplified manner, by simply configuring properly credentials to be used by clients in relationship with processing priorities. This basic embodiment provides an optimized resource allocation in a DBS for servicing requests from database clients in high demanding processing situations, which finally contributes to provide a better delivery of the final service.

According to the example illustrated in Fig.4, and referring to sessions illustrated in Fig.3, processing of requests coming from client 101-1 within session SlA (corresponding credentials assigned to processing priority 200) can preempt in DBS 105, in case of concurrency, over any request received from client 102-1 within any of its sessions TlA or TlB. In turn, requests made from client 102-1 due to management O&M functions (corresponding credentials assigned to processing priority 180) can preempt, in case of concurrency, in DBS 105 over any request received from clients 101-1 or 101-2 through their respective sessions SlB or S2B (end-user traffic service functions) . Alternatively, or additionally, and regardless of if concurrency takes place in the DBS 105 when processing requests from different clients received through different communication sessions, requests coming from e.g. client 101-1 within session SlA (processing priority 200) can be assigned to a higher processing windows/higher processing scheduling values/etc than e.g. requests received from client 102-1 within any of its sessions TlA or TlB (processing priorities 180 and 90, respectively).

Preferably, processing priorities related to credentials of database clients are configured in the DBS 105 so that requests related to real-time, or eventually crucial, functions/applications in the database clients are assigned to higher priorities than other kind of functions, as illustrated in the example of Fig.4. This preferably requires the database clients also to be configured accordingly, so as to select different credentials for establishing different communications sessions with the DBS 105 for, preferably, each of the type of functions or applications they serve, and to distribute the sending of requests related to these functions/applications through the corresponding established session (s).

As mentioned earlier, embodiments of the invention are equally applicable to database clients that implement the service logic for serving a plurality of applications. For example, in a layered architecture, the same FE can implement the necessary service logic for serving a HSS application and a AAA application. In such a case, different credentials are preferably stored in relationship with said FE for each of these different applications (e.g. HSS application and AAA application) and, eventually, also for different functions within these applications (e.g. O&M, end-user traffic, data provisioning, etc) , and be assigned to different processing priorities by the DBS 105.

The configuration example shown in Fig.4 can be simplified, so that database clients performing the same kind of application are assigned, either: the same plurality of credentials per function, or the same processing priority per each credentials to be used per function. For example, the same plurality of credentials (e.g. Cl, C2, C3 and C4, referred earlier) can be used by e.g. FEs 101-1 to 101-4. This would result in a shorter configuration table in the DBS 105 (e.g. Fig.4 with less "APPLIC/CRED" rows), since the same processing priority would be assigned by DBS 105 to requests coming from e.g. FEs performing HSS or HLR functions (e.g. 101-2, 101-2, 101-3, 101-4) . Nevertheless, assigning priorities to credentials in a more granular way (e.g. as illustrated in Fig.4) can be useful in scenarios where, for example, the same back end DBS serves requests coming from signaling FEs of different telecommunications operator, which can have different quality of service agreement with the owner of the system implementing the DBS.

A brief description is now provided with regard to implementation and/or adaptations of database servers and database clients according to an embodiment of the invention .

A database server (e.g. DBS 105) or a database client (e.g. 101-1) can, regardless specific construction details, be considered as functional entities that can be implemented as apparatuses comprising of one or more functional modules; each of them arranged to perform a specific (sub) function of the total functionality implemented by each of said entities. Once said functionality has been specified, the construction of the functional modules to build up a realization of the corresponding physical machine (s) accomplishing said apparatuses is a matter of routine work for those skilled in the art.

In particular database servers and database clients as described herein can be realized as a computer-based apparatus comprising software and hardware, and can be implemented within a single physical machine, or be distributed along various cooperating physical machines. The software comprises one or more computer programs having computer readable program code that, when executed by a computer-based apparatus makes it to behave according to a predefined manner, as determined by the specific program instructions in said programs, which can be arranged according to any of the described embodiments of the invention. Accordingly, the description given herein with reference to Fig.5 describes some functional components of a database client and a database server comprising means adapted to accomplish with the embodiments described heretofore, without falling into specific hardware and software construction details, which are well known by those skilled and, consequently, which are not needed to understand the invention.

The internal simplified structure of a database server 105, or of a database client 101-1, shall now be described with reference to Fig.5 considering a possible implementation as a computer-based apparatus. Said structure is illustrated comprising: a processing module 501, a communications module 502, a data storage module 503 and internal communication bus 504 which allow data communication and cooperation between them. Shortly, the operation is as follows. When a message is to be sent, the processing module 501 requests the communications module 402 to send the message and provides it with the necessary data, and, when a signaling message is received by the communications module, it transfers the relevant content to the processing module for triggering the necessary processing. In turn, the processing module 501 accesses the data storage module 503 to store/update/check/obtain the necessary data for the operation . The processing module 501 can comprise one or more processors (only one processor 5010 is shown in Fig.5) which, for example, can be arranged to work in load-sharing or active-backup mode. The operation in the computer-based apparatus is controlled by computer-readable program code comprising instructions that are executed by processor 5010. The execution of these instructions makes server 105, or database client 101-1, to perform according to embodiments of the invention described before.

Currently, the functionality of many of the nodes and servers in telecommunications and/or information systems are implemented by computer-based apparatuses. Accordingly, computer programs comprising computer-readable program codes are loaded in computer-based apparatuses of these systems causing them to behave according to a predefined manner, as determined by the respective program codes, which are in accordance to the functionality specified for the servers/nodes these apparatuses implement. Thus, those skilled in creating and/or modifying computer programs, would, without departing of the teachings of the present invention, readily apply them to create and/or modify computer programs suitable to be loaded in a computer-based database server or in a computer based database client, so as to make them to behave according to any of the described embodiments .

External communications are performed via communications module 502, illustrated in Fig.5 as comprising two communication devices 5021 and 5022. Depending on different implementation alternatives, a communication device can be suited to accomplish with one or more than one communication types (i.e. communications according to one or more communication protocols and/or signaling interfaces) . For example, in a database client 101-1 certain type of communications (e.g.: with the database server 105, or with I-CSCFs or C-CSCFs) can be implemented partially or totally by communication devices 5021 and/or 5022.

In a computer-based database client 101-1, as well as in a computer based database server 105, its corresponding data storage module 503 stores the data needed for their corresponding operation. In the particular case of the computer based database server 105, the data storage module can comprise internal and/or external databases storing the data to be held (i.e. stored, modified, retrieved, etc) by the database clients. A data storage module in a computer- based apparatus can comprise one or more data storage devices. In the example illustrated in Fig.5 it comprises storage devices 5031 and 5032. Memory chips and magnetic or optical discs are example of data storage devices. Depending on criteria such as data access speed for certain data, storage reliability, etc, the storage module of a database server 150, or of a database client 101-1, can comprise one or more storage devices of the same or different kind. Data storage module 503 preferably stores the computer-readable program to be executed by processor 5010.

The invention has been described with respect to some exemplary embodiments in an illustrative and non- restrictive manner. Variations can be readily apparent to those of ordinary skill in the art. For this reason, the invention is to be interpreted and limited in view of the claims .

Claims

1. A method for processing communications between a database server and a database client comprising the steps of: - storing (210) by the database server and the database client a plurality of credentials, each comprising information usable for authenticating the same database client when it establishes a communication session with the database server, - storing (230) by the database server a processing priority in relationship with each of the credentials of the database client, wherein the processing priorities related to a first and a second credentials of said client among said plurality differ, and wherein a processing priority comprises information usable for determining the assignation of processing resources in the database server to serve a request received from a database client within a communication session, and

- assigning (237 , 238) by the database server the related processing priority for serving a request received from the database client within a communication session according to the credentials used for authenticating said database client when establishing said communication session.

2. The method of claim 1 further comprising the steps of:

- establishing (235) a first communication session between the database client and the database server using first credentials (Cl) among said plurality, and

- establishing (236) a second communication session between the database client and the database server using second credentials (C2) among said plurality before the first communication session is terminated.

3. The method of claim 1, wherein the database client performs a plurality of different functions (Fl, F2) requiring the establishment of at least one communication session with the database server, further comprising the steps of:

- selecting (220) by the database server the processing priority that is to be stored in relationship with one of the credentials of the database client according to a function, among said plurality of functions, performed by said database client .

4. The method of claim 1, wherein the database client performs a plurality of different functions (Fl, F2) requiring the establishment of at least one communication session with the database server, further comprising the steps of:

- selecting (233, 234) by the database client one of the credentials among said plurality of credentials according to a function being performed by said client among said plurality of functions, and

- establishing (235, 236) a communication session with the database server using the selected credentials.

5. The method of claims 3 or 4, wherein said plurality of functions comprise at least two selected from:

- an operation and maintenance function,

- an end-user traffic service function,

- a data provisioning function, and - a data report function.

6. The method of claim 1, wherein the database client is a signaling front end Home Location Register server (101-1), or a signaling front end Home Subscriber Server server (101-1), or a signaling front end Device Configuration Register server (104-1), or a signaling front end Service Policy Controller server (102-1), or a signaling front end Authorization and Authentication server (103-1) .

7. The method of claim 1, wherein the protocol for establishing a communication session between the database client and the database server is the Lightweight Directory Access Protocol LDAP.

8. A database server (105) comprising a processor (5010) and a storage device (5031) in communication with said processor and storing instructions adapted to be executed by said processor to:

- store (210) a plurality of credentials, each comprising information usable for authenticating the same database client when it establishes a communication session with the database server,

- store (230) a processing priority in relationship with each of the credentials of the database client, wherein the processing priorities related to a first and a second credentials of said client among said plurality differ, and wherein a processing priority comprises information usable for determining the assignation of processing resources in the database server to serve a request received from a database client within a communication session, and

- assign (237 , 238) the related processing priority for serving a request received from the database client within a communication session according to the credentials used for authenticating said database client when establishing said communication session.

9. The database server of claim 8 wherein the storage device further stores instructions adapted to be executed by said processor to:

- select (220) the processing priority that is to be stored in relationship with one of the credentials of the database client according to a function, among a plurality of functions (Fl, F2), performed by said database client.

10. The database server of claim 9 wherein said plurality of functions comprise at least two selected from:

- an operation and maintenance function, - an end-user traffic service function,

- a data provisioning function, and

- a data report function.

11. A database client (101-1) comprising a processor (5010) and a storage device (5031) in communication with said processor and storing instructions adapted to be executed by said processor to:

- store (210) a plurality of credentials, each comprising information usable for authenticating said database client when it establishes a communication session with the database server,

- select (233, 234) one credentials among said plurality, and

- establish (235, 236) a communication session with the database server using the selected credentials.

12. The database client of claim 11 wherein the storage device further stores instructions adapted to be executed by said processor to:

- establish (235) a first communication session with the database server using first credentials (Cl) among said plurality, and

- establish (236) a second communication session with the database server using second credentials (C2) among said plurality before the first communication session is terminated.

13. The database client of claim 11 wherein the storage device further stores instructions adapted to be executed by said processor to perform a plurality of different functions (Fl, F2) requiring the establishment of at least one communication session with the database server, and wherein the storage device further stores instructions adapted to be executed by said processor to:

- select (233, 234) one credentials among said plurality of credentials for establishing a communication session (235, 236) with the database server according to a function being performed by said client among said plurality of functions.

14. The database client of claim 13 wherein said plurality of functions comprise at least two selected from:

- an operation and maintenance function,

- an end-user traffic service function,

- a data provisioning function, and

- a data report function.

15. The database client of claim 11 wherein the storage device further stores instructions adapted to be executed by said processor to perform as a signaling front end Home Location Register server (101-1), or as a signaling front end Home Subscriber Server server (101-1), or as a signaling front end Device Configuration Register server (104-1), or as a signaling front end Service Policy Controller server (102-1), or as a signaling front end Authorization and Authentication server (101-1).

16. A computer program product comprising computer- readable program code for performing the functions claimed in at least one of the claims 8 to 10 when the computer program product is run on a computer-based database server (105).

17. A computer program product comprising computer- readable program code for performing the functions claimed in at least one of the claims 11 to 15 when the computer program product is run on a computer- based database client (101-1).