Service provisioning method, system and computer program product

The invention relates to a method, system and computer program product for provisioning in a communications network. The provisioning method includes at least a step for sending at least one request for defining measures relating to customers and/or services and/or network elements, the method including processing (20-23) each request, executing tasks according to the results of the processing step, and reporting the results to the requesting entity. In accordance with the invention, the processing steps are performed in functional layers (20-21) and the method steps of at least one layer (22) are performed by independently mountable and dismountable functional modules (30-34).

The invention is related to a method according to the preamble of claim1, a system according to the preamble of claim12and a computer program product according to the preamble of claim15.

In conventional techniques, a request processing functionality has been either tightly fixed into the system architecture or such functionality has been developed per customer (customer specific functionality).

If the request processing functionality is tightly fixed into the system architecture, it is very difficult to have discrete system functionality per operator type. Desired request processing functionality is in the product or not—nothing between.

If the request processing functionality is developed per customer, it is difficult to sell and manage this functionality in a productised way. The same type of functionality has to be implemented each time to a new customer and this means a lot of work and testing. It is challenging to further develop core system functionality since there can be any kind of request processing functionality developed to customers and it is not necessary possible to change system core without breaking customer specific functionality.

It is an object of the present invention to overcome the drawbacks of the above-described techniques and to provide an entirely novel type of method, system and computer program product.

The goal of the invention is achieved by implementing the system such that the provisioning system must receive service requests from a client system (e.g. customer care system, self care system), which triggers the request processing functionality defined in the service modules. System itself must take care of correct time and order of service request execution.

A service module is a request processing functionality of provisioning system, which implements some predefined functionality. A service module consists of two main parts; service module specific user interface, which provides a way to configure and manage service module, and functional part, which implements request processing functionality.

The system has basic rules, which define in which order service requests are processed through the installed service modules. It is not limited what kind of request processing functionality each service module may contain.

Another purpose of the invention is to be able to flexible provide different kind of service provisioning (subscriber creation and service activation) system functionality for telecommunication operators having different kind of provisioning system needs. For example operator having fixed network has different kind of needs for provisioning request management than operator having mobile network. In the service module concept, the system core and advanced provisioning request processing functionalities are separated, so each operator installation consists of system core and desired service modules, which together fulfils operators service provisioning requirements

More specifically, the method according to the invention is characterized by what is stated in the characterizing part of claim1, the system by what is stated in the characterizing part of claim12, and the computer program product by what is stated in the characterizing part of claim15.

In this document communication means all kind of tele-, data- or other communication in which computer or computers, computer program or computer programs or suchlike logic are used to manage provisioning operations.

In this document provisioning or service provisioning means for example creation, modification, activation and/or deactivation of subscribers, services, service providers, network elements, network devices, business support systems, customer care systems and/or billing systems with computer, computers, computer program, computer programs and/or suchlike logic systems in communication network in any combination mentioned above.

The invention offers significant benefits.

A request processing functionality for a service provisioning system can be developed independently from the system core. It is possibility to have different kind of customer installations with combination of system core and one or more service modules. If some customer needs some customer specific functionality, it can be developed in controlled way as a service module and new functionality can be offered also to other customers.

THE LOGICAL ENVIRONMENT OF THE INVENTION ACCORDING TO FIG.1

The product, for which the invention is made, works as provisioning system1, which can be used to create subscribers and activate services for them in a telecommunications network4. There can be multiple client systems2in the business support system layer5, for example, customer care systems and self care systems. These client systems2send service requests into provisioning system1, which executes requests into one or multiple network elements4. Typical network elements4are, for example in the mobile network, home location register (HLR), voice mail system (VMS) and short message service centre (SMSC). After provisioning system1has executed the service request, it sends a response back to the client system5containing the status of the service request.

There is a need to do request processing for the received requests in the provisioning system1before or during execution into network elements3. The request processing can be, for example, routing of the service orders into the correct network element3(for example based on the number ranges), parameter manipulation, retrieval of information from a network element to be used in the service request execution or authorization of request sent by a client system2. This request processing functionality differs from operator to operator depending on the type of the network and complexity of business support system5. In a fixed (PSTN) network subscriber services are mostly located on a single network element, but in mobile networks a business service in a BSS layer can mean activation of subscriber data into multiple elements on the network level5. If a BSS system does not contain view of the network (i.e. it only manages subscriber services on a business level), the provisioning system1must be able to convert business request into network level5operations. In this case provisioning system1has to offer an abstraction of the network level service to BSS system, so it has to only manage business level services to provisioning system.

PROVISIONING SYSTEM ARCHITECTURE ACCORDING TO FIG.2

The provisioning system contains four layers; client system layer20, request processing layer21, service module layer22and task execution layer23.

The client system layer20is responsible to receive service requests from the client systems2, converts request into systems internal format and stores them into database. When the request has been executed and it has a final status, the client system2delivers a response to the client system.

The request processing21layer has the basic request processing functionality common to all provisioning product installations. It manages the correct execution order of the received service requests, handles the priorities so that service requests with higher priority may bypass requests with lower priority. If a service request is timed, the request processing layer takes care that the request will be executed in the correct time.

The service module layer22manages the service modules. Modules can be installed dynamically into the system and also removed dynamically. The core of the product has rules how requests are executed through installed service modules. Service Module Layer22receives requests from Request Processing Layer21, sends network element specific operations (tasks) to Task Execution Layer23, receives responses to tasks from it and sends the finalized request responses back to Request Processing Layer21.

The task execution layer manages the connections to the network elements3and uses network element specific network element interfaces29(NEI) to execute tasks (network element specific service operations) into a network element3. The network element interface29converts the order into a format network elements3understand it and provides a response to the executed task.

SERVICE MODULE LAYER ACCORDING TO FIG.3

Service Module Layer22receives requests from Request Processing Layer21, sends network element specific operations (tasks) to Task Execution Layer23, receives responses to tasks from it and sends the finalized request responses back to Request Processing Layer21.

Meaning of service modules30-34is to offer customizable functionality for the customer through service module GUI. This functionality may be used for creating complicated business logics, routing and authorization rules. Service modules30-34are plug-in components, which may be installed and taken into use separately. They interact with the product core through a service module interface.

There are two types of service modules as indicated in theFIG. 3. The request service modules30-31contain functionality to manage requests and task service modules manage functionalities of network element specific tasks.

In theFIG. 3there is an example of one possible configuration. On the request service module layer21there are two service modules; request authorization30and business tool service modules31. The request authorization service module30has its own configuration, which defines the type of service requests each client system may send into execution. There is a relation defined into system that if request fails in the authorization service module30, it is rejected and response created immediately. If the request is successfully authorized, it is passed to the business tool service module31. The business tool service module31contains its own configuration, which defines how requests will be split into multiple network level tasks.

On the task service module layer23there are two different types of service modules; task parameter modification32-33and basic task routing service module34. The task parameter modification service module can modify task parameter data. For example if a network element requires subscriber number without a country code, this validation and modification can be made in this module. It is also possible to execute task layer23service modules to the responses, so for example it is possible to do parameter modifications to responses from the network elements. The basic task routing can be used to define into which physical network element a task is routed. Network elements can be defined to serve, for example, a certain number range, which can be used as a routing criteria to which physical element task is executed.

The product core is able to process requests even if there are no service modules installed into the system. There is a default way defined for handling the incoming requests, sending tasks to Task Execution Layer, receiving task responses from it and sending the request responses back to the Request Processing Layer21.

MAIN FUNCTIONALITY OF SERVICE MODULES

Service Module Layer22loads installed and active service modules30-34during system startup. The information about installed service modules is loaded from a database or file. Service modules30-34load their own configuration from the database or file at startup and when commanded by the system core.

When Service Module Layer22receives a request from Request Processing Layer21, it gives the request to business logics31, which may split the request into tasks, modify them and send task(s) back to Service Module Layer21. It checks if there are Task Service Modules32-34installed and calls them in configurable order for modifying the task. After this the task is sent to Task Execution Layer23.

Received task responses are returned by Task Execution Layer23to the Request Service Module30, which has to know the actual state of the whole request. Request Service Module30may either return the request response to product core or continue processing the request using the business logics31.

After completing the whole request, Request Service Module30returns the response to Service Module Layer22, which then delivers the request response to Request Processing Layer21.

Service modules30-34are independent of each other and can be installed separately. Each module has its own GUI (Graphical User Interface) and configuration. GUI is installed with the module. Module configuration is modified with service module GUI, Service Module Layer22does not know about the module configuration.

Each service module30-34has also its own reporting interface, which can be used to print service module specific reports. The system core can call for the service modules reporting interface, which defines how many and what kind of reports service module supports. The report can then be activated from the user interface of the product, which retrieves user specified report from a service module using the report interface.

REQUEST EXECUTION IN SERVICE MODULE LAYER22

1) Service Module Layer22(SML) receives request (that may contain multiple tasks) from Request Processing Layer21.2) SML22sends request to Request Service Module30.3) Request Service Module30gives the request to the business logics31.4) Business logics process31request according to internal rules.5) Business logic31sends task to SML22.6) SML22checks if there are any Task Service Modules32-34installed and processes the task using them.7) SML22sends task to Task Engine Layer23and receives the response from it.8) SML22sends the task response to Request Service Module30.9) If there are other tasks to be executed, Request Service Module30continues processing the request (steps3-8)10) When all tasks are executed and the request is completed, the Request Service Module30sends the request response to SML22.11) SML22sends response to Request Processing Layer21.

In accordance withFIG. 4the request service module layer21may comprise only one module, namely a business service tool service module41communicating with the task parameter modification service module32in the flow to the task execution and further, with the task parameter modification service module33during the task response flow.

FIG. 5depicts a system in accordance with the present invention in which the provisioning system includes also an enhanced security service module51including rules an functionality for 3rdparty authorization. The enhanced security service module51communicates with 3rdparty business support systems52.

Further, the Invention includes Following Features:

The rollback feature of the invention allows you to create rollback rules for each task in a business service request. With the rollback rules you can define that if one of the tasks in the request fails, no other tasks are sent for execution and a rollback operation is performed on the executed task. This is a very useful feature, for example, when creating a subscriber into several network elements. There are no inconsistencies in statuses of the tasks belonging to the same request and no need for manual intervention in the network elements.

In case of failing tasks also other operations (or no operations) can be defined instead of the rollback operation.

The invention provides you with flexible tools for parameter manipulation. It is capable of fetching parameters from external sources and inheriting them from executed tasks. The parameter manipulation of the invention includes also number conversion capability, which means that the solution in accordance with the invention is able to modify parameters, such as a telephone number, to a format expected by the target network element. The invention enables you also to manipulate responses, which it creates in response to each executed task. You can do this by creating rules in the system in accordance with the invention to define how the parameters of responses should be modified. The response manipulation rules enable, for example, language conversion. This means that it is possible to convert an error message from a network element that is in English, for example, into a Spanish one.

The invention allows you to define what kind of requests specified business support systems may create and in which network elements these requests can be executed. This is called a enhanced security feature. The capability is especially useful for operators who share their network with third-party service providers and can be used to provide more security into provisioning activity.

The routing feature of the invention has been developed to ensure that the tasks are directed to the correct network elements even when a request itself does not include a target network identifier. The invention is capable of fetching the appropriate identifier either from within the system itself or from external sources, such as a number portability server.

The invention allows you to assign execution times for requests. You can define when a specified request is to be executed in the provisioning system. The system in accordance with the invention activates the service at the predefined time instead of activating it instantly. You can also set priorities for the requests to define their execution order. Request priorisation is a useful feature especially in situations where the number of provisioning requests is high and real-time responses are needed for some of the requests. The performance and real-time requirements grow as self-provisioning solutions become more widely available.