Patent Application
20110035434
The invention relates to messaging systems, and more particularly to the manner of storage, retrieval, and update of messaging service attributes in real time.
The Lightweight Directory Access Protocol (LDAP) is commonly used to store subscriber-specific, or configuration-specific information in an open-standards based VOIP system such as voicemail or videomail. There are many scenarios where it is desirable to provide high speed reliable dynamic attributes on a per-subscriber basis. While LDAP backends provide high speed reading ability that is scalable to support systems supporting millions of subscribers, the throughput on writes to LDAP databases is not sufficient to support dynamic attributes that scale to millions of subscribers.
U.S. Pat. No. 7,035,846 (IBM) describes a framework for answering LDAP queries. A proxy server maintains a cache of information about queries and uses this information to determine if a current query can be answered from the local cache.
U.S. Pat. No. 6,779,025 (Cisco) describes an application server for providing subscriber attribute information from a remote database server.
Although the “write” performance of LDAP servers is improving with some implementations providing throughput of up to hundreds of writes per second, these throughputs fall short of the current requirements of thousands of writes per second.
The invention is directed towards achieving improved write performance for directories, thus enabling enhanced real time messaging services to be performed.
According to the invention, there is provided a messaging system for a communication network, the system comprising at least one directory server, wherein the system further comprises a proxy having a database storing a subset of messaging service attributes and the balance of the attributes being stored in the directory server, and the proxy comprises a server adapted to:
In one embodiment, the proxy is adapted to identify attributes as dynamic according to a configuration table.
In one embodiment, the proxy is adapted to identify as a dynamic attribute an attribute which is a count of a number of times a particular operation has been performed for a subscriber.
In one embodiment, the proxy is adapted to cease maintaining a count of a particular operation when the count value exceeds a threshold.
In one embodiment, the proxy is adapted to perform a write to the directory server of a dynamic attribute when it lies outside a configured range, so that said attribute ceases to be a dynamic attribute.
Preferably, the proxy is adapted to identify as a dynamic attribute an attribute which is a count of a number of times a particular item of content has been automatically downloaded to a subscriber.
In one embodiment, the proxy is adapted to identify as a dynamic attribute an attribute which is a count of a number of times a notification has been automatically transmitted to a subscriber.
In one embodiment, the proxy is also adapted to perform retrieve, modify, or delete operations on said dynamic attributes and to add a new dynamic attribute to the proxy database.
In one embodiment, the proxy is adapted to generate results using dynamic attributes which it has written to the proxy database and to generate results from requests to the directory server, and to join said results to provide the client response.
In another embodiment, the proxy database is organised as a hash table with a subscriber identifier as a hash key.
In one embodiment, in the proxy database, proxy keys are correlated with directory server keys using a protocol for routing of requests to be handled by the directory server. In one embodiment, said protocol is LDAP.
In one embodiment, a subscriber identifier such as a telephone number is a correlation key.
In one embodiment, the proxy is multi-threaded in a manner to handle many requests in parallel in a reliable manner.
In one embodiment, the proxy ensures that transactions are atomic for concurrent access to attributes for a subscriber.
In one embodiment, the proxy performs atomic transactions composed of reading a record; verifying that a current record value is the same as a current value of a request; changing the current value to that in the request; and writing the record.
In one embodiment, the proxy uses at least one mutex for operations to ensure atomicity.
In one embodiment, the proxy is adapted to delete attributes and/or records from its database and to write them to the directory server.
In one embodiment, the system further comprises at least one server acting as a client, and wherein the proxy is adapted to process requests from one or more servers to provide to the server real time access to the dynamic attributes in a manner which is transparent to the server acting as a client.
In one embodiment, the system further comprises a provisioning server acting as a client of the proxy, and wherein the proxy is adapted to:
In one embodiment, the system further comprises a notification server acting as a client, and wherein the proxy is adapted to:
In one embodiment:
In one embodiment, the system further comprises a video/voice server and an application server, and wherein the system is adapted to perform the method steps of:
In one embodiment, the system is adapted to perform the additional steps of:
In one embodiment, the proxy is adapted to use dynamic attributes to control playing of content such as a broadcast alert or advertising content each time a subscriber logs on or receives a notification, and to perform cycling by playing a next item of content if there have been N repetitions of playing current content over a number of messaging sessions for a particular subscriber, a count up to N being a dynamic attribute, and an identifier of current content being another dynamic attribute; and the proxy updating the count dynamic attribute each time content has been played for the subscriber, and updating the current content identifier dynamic attribute upon commencement of each cycle.
In one embodiment, the subset of attributes identified as dynamic include attributes for handling any data that has transient values, such as Boolean dynamic attributes to indicate whether a subscriber needs a specific service.
In one embodiment, the subset of attributes includes attributes to record whether an A-party subscriber has already received an out-of-office notification from a given B-party subscriber, wherein a dynamic attribute holds for the out-of-office B-party subscriber the MSISDN of one more A-party to whom an OOTO notification is sent in response to a message delivery attempt from such an A-party to the B-party, and wherein another dynamic attribute indicates whether the B-party subscriber has out-of-office notification service activated.
In one embodiment, the proxy is adapted to map IP addresses to MSISDNs, whereby instead of storing the IP address to MSISDN mapping in a Radius store, a WAP gateway instead does an LDAP add operation to the proxy when a start accounting request is received.
In one embodiment, the proxy is adapted to delete a mapping when a stop accounting request is received.
In one embodiment, the proxy is adapted to combine contents of the Radius store in its database with the subscriber data in LDAP and return this data as a single query result.
In another aspect, the invention provides a computer program product comprising a computer usable medium having a computer readable program code embodied therein, said computer readable code adapted to be executed to implement the steps of:
The invention will be more clearly understood from the following description of some embodiments thereof, given by way of example only with reference to the accompanying drawings in which:—
Glossary of terms and their definitions:
Referring to
The DAP 6 intercepts operations for a small number of attributes for each subscriber and provides high-speed, reliable access to these attributes. The proxy 6 provides add, delete, modify and retrieve operations, but only provides those operations for the attributes that require high speed dynamics. LDAP client requests that do not address these attributes are forwarded to the directory server 5 in a conventional manner. The proxy 6 is also responsible for effectively joining the results of requests that have both high-speed dynamic attributes as well as “static” attributes that are stored in a directory server 5.
Because the proxy 6 intercepts and services such requests with high speed and reliability in a highly available environment, “intelligent” services that involve maintaining dynamic attributes for large numbers of subscribers in a distributed environment can be deployed.
The database 23 may reside in either a RAID or a SAN and is physically connected to the two-host cluster 20, 21 via a high-speed bus (SCSI or FIBRE in two embodiments). The RAID or SAN provide the database 23 as highly available to the nodes which comprise the DAP 6.
Logically, the database 23 is organized as a hash table. The key to the hash table is correlated with a key used by the directory server. In one embodiment, the subscriber's telephone number is this key. Multiple keys could be used. The hash table provides extremely efficient access, particularly if the hash key is the subscriber's MSISDN, and most preferably if this correlates with the key used by the directory server.
The DAP 6 severs 20 and 21 are the only writer and only reader of the database 23. The DAP 6 may serve any number of clients at a time (multi-threaded application), but is responsible for ensuring that each of the transactions that it performs are atomic. For example, the DAP 6 performs the following actions on an LDAP_MODIFY of a given dynamic attribute:
1. Read the record
2. Verify current value same as current value in request
3. Change current value to new value in request
4. Write the record
The DAP 6 ensures that these actions are atomic by using a mutex around these operations such that only one thread of execution can manipulate the dynamic attribute for a given key at a time. A simple DAP can use a single mutex for all transactions, but a more sophisticated DAP can map each request (based on telephone number) to one of many mutexes to achieve even more parallelism. We have shown however, that a single mutex is sufficient to achieve thousands of writes per second.
The DAP 6 is installed as a service under a highly-available cluster (in this simple example, Host A 20 and Host B 21). The service is typically deployed as a pair of hosts (nodes) arranged such that the cluster server is in an active/passive configuration.
LDAP clients connect to the DAP 6 using the standard LDAP protocol. The DAP 6 proxies requests to the directory server 5 and locally intercepts and processes attributes that have been identified as dynamic. The dynamic attributes can be identified to the DAP 6 by a simple configuration table such as the example presented in Table 1 below.
There are three particularly important data flows:
An example of each of these flows is discussed below.
In this example, the DAP 6 partitions the record such that a new record is created on the directory server and additionally a new record is created on the DAP 6 with the NotificationCount=0 for key telephone number=8045550000.
In a similar manner, dynamic attributes could have been used to control the delivery of advertising content. For example, the “intelligent” service of playing an advertisement each time a subscriber logs on and cycling to the next advertisement after n repetitions, can easily be realized with two controlling dynamic attributes (one identifying which advertisement and one identifying repetition count).
As can be seen from the above data flow examples, the DAP 6 is used as a mid-stream probe/interceptor. The content of interest is configurable and initialized by the provisioning server, the DAP 6 probes the LDAP stream and acts on the subset of data of interest and provides fast write support for that subset. The above examples all involve taking an action a fixed number of times for each subscriber, and using dynamic attributes for the purpose of counting. The examples apply equally well to both the videomail and the voicemail domains. In the scenarios where the DAP 6 is used to count up or down to a certain value, the attribute loses its need to be a dynamic attribute once it reaches the specified limit. By specifying the range of values under which an attribute needs to be dynamic, the DAP 6 can automatically remove a dynamic attribute from control of the DAP 6 once it reaches a limit, by simply writing the value of the attribute (once) to the directory 5 store and removing the attribute from its own store. By performing this as a low priority background task, the DAP 6 can ensure that the last write achieves the same high performance as other writes and the DAP 6 can also keep its internal database minimally sized to achieve continued high performance. All of the writes performed to the DAP 6 database are dynamic and there is no advantage to synchronising the directory 5 store with it until after the value reaches a limit. Of course, all requests are made to the DAP 6 and so there is no risk of out of date information being provided.
Referring to
Referring to
The invention allows a much simpler implementation of this functionality. Instead of having a separate Radius store in the WAP gateway and a separate query interface, the DAP performs a highly efficient mechanism mapping IP addresses to MSISDNs (effectively the information in the Radius store). Instead of storing the IP address to MSISDN mapping in the Radius store, the WAP gateway instead does an LDAP add operation to the DAP when the start accounting request is received. As a result, the DAP will introduce this mapping in the DAP database. Any other system needing the IP address as part of the subscriber data will do a standard LDAP query to the DAP. The DAP will combine the contents of the Radius store in the DAP with the subscriber data in LDAP and return this data as a single query result, allowing a much simpler implementation for the systems using this data as they need to do only a single request to LDAP instead of separate requests to LDAP and the Radius store. In this example it also becomes apparent that the DAP must support a standard LDAP Delete operation. This operation would be performed when a stop accounting request is received and the DAP would remove the mapping from its database.
It will be appreciated that the invention provides very high speed “intelligent” data flows for real time performance of services, some of which involve user interaction in real time. Without the invention some of these services would not be possible. Examples are playing an advertisement a fixed number of times per subscriber, playing “Novice” prompts during the first N logins to the system by a given subscriber, or providing “Help” during the first N notifications reminding a subscriber how to retrieve messages. In addition to providing functionality per subscriber based for example on a fixed number of times that a subscriber has used or has been provided with a particular service, it will be appreciated that the invention allows dynamic attributes to be used handling any data that has transient values to achieve, for example, advanced messaging services such as out-of-office status notifications.
Once the DAP is incorporated into the messaging platform, it can be utilized by any application that needs to manipulate dynamic attributes over a large set of subscribers. The applications that can potentially use this service include, but are not limited to, SMSC, MMSC, VoiceMail, VideoMail, VideoPortal, VoicePortal, and enhanced personalised messaging services platforms, and applications providing personalised routing of messaging traffic.
The invention is not limited to the embodiments described but may be varied in construction and detail.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/IE2009/000009 | 3/26/2009 | WO | 00 | 10/20/2010 |
| Number | Date | Country | |
|---|---|---|---|
| 61064805 | Mar 2008 | US |
