Directory-based service activation system and method

#The present invention relates to configuring and activating complex IP-based services such as Voice over IP (VoIP), Virtual Private Network (VPN) and Video on Demand (VoD) on a telecommunications network running the TCP/IP protocol using, in one preferred embodiment, a Lightweight Directory Access Protocol (LDAP) directory to store a model of all the service parameters and network settings.

#Activation (also known as provisioning) of services plays an important role in a complex network such as the Internet. Activation refers to altering settings in a network equipment or server. Adding a new network device may also be considered being part of activation. Activating different IP-based services and network equipment using disparate systems with different databases and client interfaces is not efficient. In an environment where subscribers desire multiple Internet services (IP telephony, Email, IP access, etc.), where common subscriber credentials are required (e.g., name, address, credit card number, email address, username, password, etc.) for bill generation and user authentication, using a single system, which delivers a coordinated activation of all these services and that eliminates the duplication of customer information in many disjointed systems and databases is desirable. By using a single Directory, such as an LDAP directory, to store all the subscriber account and authentication information, the present invention can reduce or eliminate many of these problems.

#A directory is a data store that has been optimized for millions of reads; when applied to problems that require far fewer writes as compared to reads, directories are known to provide significant performance advantages compared to Databases. Historically, the most popular implementations of directories have been corporate organizational directories where millions of searches are typical and in white/yellow page applications supporting user authentication/authorization/accounting (AAA) functions.

#FIG. 1 is a block diagram of one preferred embodiment of the directory-based service activation system and method of the present invention. P-LDAP refers to a primary directory, while S-LDAP refers to a secondary directory.

#FIG. 2 is a diagram illustrating data state changes between various components of an embodiment of the system and method.

#FIG. 3 is a detailed version of FIG. 1 showing various components of the system and method and their interfaces.

#DAS breaks down the service activation process into three tiers as illustrated in FIG. 1. The goal of the creating multiple tiers is to eliminate the need for an end-to-end synchronous process which starts when a service change request comes from a client application such as a browser and ends when the change is implemented on the IP network, returning a successful message to the customer. Although a synchronous process is the most straightforward implementation, it does not scale well. Breaking down the process into tiers allows asynchronous signaling to be used where it optimizes scalability and performance.

#In the first tier of the process (FIG. 1, TIER-1, steps (1) and (2)), a user (or subscriber) uses the web browser to access a URL in which an interface to primary directory is implemented. The user requests changes to the service (e.g., changes the 3DES encryption key for a VPN tunnel). The requested change causes a change in a data entry within the primary directory (e.g., the 3DesKey data entry associated with the user's tunnel) and through the replication protocol, it gets relatively instantaneously replicated in the secondary directory. This step creates an illusion of a successful physical implementation of the service change onto the IP network, although service changes have not yet been implemented. That is, the data in the primary directory which models the service settings (e.g., new 3DesKey) and the actual service settings on the IP network (e.g., the 3DesKey stored within the router) are out of sync. Tier-1 is a synchronous process.

#Next the data changes which arise from a user's IP service setting changes (FIG. 1, TIER-2, step (3)), are implemented in another secondary directory which is an integral part of DAS. The difference between DAS as a secondary LDAP directory and a standard secondary LDAP directory is that DAS maintains old data, as well as new data, simultaneously. A typical secondary directory immediately overwrites the old data with the new data upon a replication request from the primary LDAP server.