DE19619801A1 - Service creation system for intelligent networks - Google Patents

Abstract

The system contains an editor arrangement for developing a service logic system using graphical devices. A converter arrangement generates object code and data structures using the developed service logic. The converter arrangement generates a further surface from the service logic which can be used to manage the data structures generated for the service logic. The automatic generation of service specific user surfaces from a service source database enables immediate parameterisation and availability of the service

Description

Each IN service requires a specific user interface (Operator Surface) with the help of a customer (Customer) be easy to administer. The creation this surface is a complex task.

So far, service-specific user interfaces (masks) by the developers of the IN software (system developers) in implemented, already in the system development phase lung.

The creation of the user interface already in the phase of System development has the disadvantage that between the idea and the implementation of a service in at least a period of time on the order of about six months (Development period).

The invention has for its object the mentioned to eliminate part.

This task is performed by the service creation system according to An spell 1 solved.

By automatically generating the service-specific Be the user interface from the FSL source file is the service after the creation of this FSL source file can be parameterized immediately and therefore available.

In the following an embodiment of the invention, u. a. based on the drawing, explained in more detail.

Depending on the service logic of an IN service the wishes of the network operator (services) provider (service provider), service subscriber (service subscri  ber) or service user and the network area different requirements that have to be shifted the most diverse forms of this service logic being able to lead. For this reason, a tool is necessary the one in memory-programmed switching systems quick and flexible adjustment or new service creation most possible.

The named tool with which the stated goal is achieved can be called "Flexible Service Logic" (FSL) or briefly referred to as service logic. At the ge called service logic is a service-specific Logic structure, its elements, the so-called service modules (SIB) each a logical representation of a functional rou tine, which performs a sub-function of the IN service, represent.

A service logic is thus determined by the process of ver different functional routines being customized It can be determined which routines are used and what the logical sequence is.

An FSL data structure and thus a specific service logic with the help of a special tool, the so-called service creation system (Service Creation Environment SCE). With the help of this tool, first a logic structure designed and a service source file (FSL-Src) generated.

The named service source file contains a description of the Logic structure (graph description), a description of the SIBs of the FSL, a description of those related to the Service-relevant transient connection data (CID-Be spelling) and a description of those related to the Service required semi-permanent data.  

Using a so-called service converter mask prototypes, data structure and object code of the FSL. The masks mentioned prototypes are created by a so-called Customer Service Control CSC used to carry out a service check.

Fig. 1 shows the hardware embedding of a service provision system SCE within a control system (SCP, SMP) of an intelligent network. The service creation system comprises a service definition SD, a service management SM and a customer service control CSC. The parts mentioned are implemented on a corresponding development platform SCEP (Service Creation Environment Point), which has different operating modes for this purpose.

Each component SIB of a service logic FSL acts against different dates:

• - dynamic, connection-specific data that follows are called the Call Instance Data CID,
• - Static data, only with specific administrations functions can be changed and only used by a SIB can be read (this data is in the following as Service Support Data SSD),
• - static data read and modified by the SIBs can be. This data is referred to below as a service Data templates called SDT. (If in the following of semi permanent data is talked about, so are both types of static data, namely both SSD and SDT ge means).

The functions of the individual parts (subsystems) of the service creation system SCE (including with reference to FIGS. 2 to 4) are explained in more detail below.

In Figs. 2 to 4 Arrows indicate the origin (top arrow) and the target (arrowhead) an action. Two-headed arrows are used to indicate complex dialogs, the details of which are, however, not of interest for understanding the invention.

The "Service Definition SD" part includes the functions of a Editors for drafting an FSL, the functions of a test Direction to check the designed FSL according to certain Rules and the functions for controlling the conversion process an FSL (generating object code, data structures and masks from the source file of an FSL).

Fig. 2 is based on information flows cooperation between SD and SMP. To create a new service, an operator at system level creates an FSL and converts it using a so-called service converter (the conversion referred to means compiling with regard to the service logic and generating data structures from these data types with regard to the data types).

For a better understanding of the term used here "Customer" is now an explanation of the term. In intelligent networks, the terms are usually used Network operator, service provider, service subscriber and Service users differentiated. In contrast to this Be The service creation system only knows the distinction between handles the role model of "Customers" and "Customer Opera tors ".

Customers are organized in a flexible hierarchy system nized. The assignment of functions to a customer a certain hierarchical level is therefore flexible. That be indicates that this assignment by the IN-Customers themselves can be carried out. Those who are for one Customer Admi corresponding to a given hierarchy level carry out administration activities, become customer operators called.  

This role model makes it possible for a customer both a service provider and a service subscriber, can also be a service user. The role that a Cu stomer takes each, is determined by the be sought relationship with another customer.

After this excursion to the term customer, it continues with the description of the part "Service Management SM".

The Service Management SM includes the following functions:

• - the assignment of service logic to an IN service,
• - The generation of IN-customers and the assignment of IN numbers for the generated IN customers,
• - The assignment of Service Logic to IN-Customers and
• - The assignment of semi-permanent data structures and Mas to IN-Customers,
• - The generation of operators for IN-customers and the assignment Access rights for the generated operators to the mentioned semi-permanent data structures on the genann masks,
• - Functions for controlling the transfer (sending) of the Objects generated from the source file (object code, data structures and masks) to the corresponding hardware platform shape).

Fig. 3 shows information flows based on the cooperation between SM and SMP in transferring a converted FSL by the SMP to the SCP.

The part "Customer Service Control CSC" represents for the custo mer also a subset of the entire functions of the Service creation system available. The task of the CSC is the administration of IN objects (semi-permanent data structures) of the customer via the ge called masks. CSC provides an inexpensive means of access for Customer represents only reduced access rights to IN-Objek  have. CSC offers the opportunity for the customer manage accessible fields of the IN objects.

Fig. 4 shows based on information flows cooperation between CSC and SMP.

The SMP essentially consists of two parts. One part serves to collaborate or exchange data with others IN subsystems (SCEP-SD, SCEP-SM, SCEP-CSC and SCP), where the internal structures are invisible to the SMP. The one the other part is used to carry out the central access control for all interconnected IN subsystems.

The SCP is used to execute the calls in the IN system, whereby in particular all routing activities are carried out.

Fig. 5 shows the service Converter according to the invention. Since the function of the service definition SD (service creation) and the function of the SCP (service execution) are different, the format in which the FSLs are stored in these two facilities is different.

A service logic in the so-called In terchange File Format IFF saved that has been developed is to save FSL graphs in a file (IFF file). The information stored in this format is described in Ver binding with further information from the service converter used to u. a. a transfer format of a service lo gic (Transfer FSL) to generate that for the transfer to SCP (and possibly already for the execution of the Ser vice logic in the SCP). The saved in the IFF file The information provided gives the service converter the number of SIBs and the way in which the SIBs interlink are bound.  

In addition to the transfer format of a service logic, the ser viceconverter also called the semi-permanent data structure doors.

Finally, the service converter also creates masks for Entry of data in the semi-permanent data mentioned structures (Surface for data structure administration at the CSC), whereby the input is carried out by a customer operator leads.

Through the aforementioned automatic generation of an operator There is no early space for the customer operator Design of the user interface of a service by the Ent developer of the IN system.

The service converter does not necessarily have to run on a special system (SD, SMP or SCP), but the development platform SCE-SD is the preferred platform. If the service converter is to run on the SMP (as assumed in FIG. 2) or SCP, it must be ensured that all necessary data are available on these platforms. An important aspect that speaks for the SCE-SD platform is the use of macro SIBs. To use the Servicecon verter it is necessary that descriptions are available for all SIBs used in macro SIBs.

The task of the CSC is the administration of semi-permanent Customer data structure records (customer records). The Be user interface (mask) for the administration of the in the Re cords contained fields is stored in the SMP, namely together with the customer records and access rights. If a customer operator wants to manage data via the CSC must the SMP first the specific user interface of each customer operators and their access rights in the CSC load. The CSC then ensures that only those fields the user interface can be edited or visible  be made for those according to the loaded access rights of the logged-in customer operator is granted access.

The following are internal processes of the service converter explained in more detail.

The service converter contains a parser that executes the IFF-Da Parts that contain the description of the service logic, ana lysed. This analysis (parse process) checks whether only known through the converting process of the source FSL, d. H. SIBs described as SIB templates were instantiated. An internal (data) structure is created during the analysis builds, which represents the graph of the FSL and the respective Assignment (reference) of a noted in this data structure SIB instance for your SIB template (for the SIB templates han it is a fixed set of template files that describe the SIBs available at the SCP). The internal Representation of an FSL thus ultimately contains information both file types (IFF file and SIB template file) and is used for the generation of masks by the Service Conver ter used.

Fig. 6 shows the production of the masks for the administration of the data structures shows a Customers. First, the system developer creates mask prototypes (mask templates, mask templates) (if necessary with the help of a special tool). The mask templates mentioned are read in by a parser of the service converter and fed to a mask generator which is also contained in the service converter. The named mask generator then generates the masks from the prototypes, with the help of the internal representation of the service logic (internal data structure) and with the addition of the information from the SIB templates (referenced by the mentioned internal data structure).

Claims (1)

Service creation system of an IN system, with

• a) an editor means for designing a service logic (FSL) with graphic means,
• b) a converter means for generating object code and data structures based on the designed service logic, characterized in that
• c) the converter means also generates an interface from the service logic, via which the data structures generated for the service logic can be managed.