DE19619803A1 - Diensterstellungssystem - Google Patents

Description

An die Dienstelogik eines IN-Dienstes (IN-Service) stellen sich je nach den Wünschen der Netzbetreiber (Network Opera­ tor), Diensteanbieter (Service Provider) Dienstteilnehmer (Service Subscriber) oder Dienstbenutzer (Service User) sowie der Netzgegebenheiten unterschiedlichste Anforderungen, die zu verschiedensten und vielfältigsten Ausprägungen dieser Dienstelogik führen können. Aus diesem Grund ist ein Werkzeug notwendig, das in speicherprogrammierten Vermittlungssystemen eine schnelle und flexible Anpassung bzw. Neuerstellung von Diensten ermöglicht.

Das genannte Werkzeug, mit dem das genannte Ziel erreicht werden kann, wird als "Flexible Service Logic" (FSL), als Ausprägung (Instanz) einer Dienstlogik oder kurz als Dienst­ logik (Service Logic) bezeichnet. Bei der genannten Dienstlo­ gik handelt es sich um eine dienstespezifische Logikstruktur, deren Elemente, die sog. Dienst-Bausteine (SIB), jeweils ein logisches Abbild einer funktionalen Routine, die jeweils eine Teilfunktion des IN-Dienstes ausführt, repräsentieren.

Eine (Ausprägung einer) Dienstlogik ist damit bestimmt durch den Ablauf von verschiedenen funktionalen Routinen wobei aus­ prägungsindividuell festgelegt werden kann, welche Routinen angewendet werden und wie die logische Ablauffolge ist.

Ein FSL-Datenstruktur und damit eine spezifische Dienstelogik wird mit Hilfe eines speziellen Werkzeuges, dem sog. Dien­ sterstellungssystem (Service Creation Environment SCE), er­ zeugt. Mit Hilfe dieses Werkzeugs wird zunächst eine Lo­ gikstruktur entworfen und daraus eine Dienst-Quelldatei gene­ riert.

Die genannte Dienst-Quelldatei enthält eine (Graph-)Beschreibung der Logikstruktur der FSL (Beschreibung der SIBs sowie deren Verkettung innerhalb der FSL), eine Be­ schreibung der im Zusammenhang mit dem Dienst relevanten transienten Verbindungsdaten (CID-Beschreibung) und eine Be­ schreibung der im Zusammenhang mit dem Dienst benötigten se­ mipermanenten Daten.

Aus der genannten Dienst-Quelldatei werden mit Hilfe eines sogenannten Dienstkonverters u. a. Datenstruktur-Prototypen und Object Code der FSL erzeugt.

Die Plazierung von SIBs innerhalb einer Servicelogik ist aus technischer Sicht nur an bestimmten Stellen im Pfad einer Servicelogik möglich, und selbst dabei nur unter Berücksich­ tigung der gesamten Logikstruktur. Die Beschreibung dieser Logikstruktur ist allerdings sehr komplex.

Die Zulässigkeit einer Plazierung einer SIB kann deshalb bis­ her nur durch aufwendige Tests ermittelt werden.

Der Erfindung liegt die Aufgabe zugrunde, den genannten Nach­ teil zu vermeiden.

Diese Aufgabe wird durch ein SCE gemäß Anspruch 1 gelöst.

Durch das Hinzufügen der Parameter in der SIB-Beschreibung (SIB-Template Description Language) kann das SCE nunmehr an­ hand einer Pfadanalyse feststellen, ob alle Parameter befrie­ digt sind. Das bedeutet, daß ohne zusätzliche aufwendige Tests beim Hinzufügen von SIBs immer die Vollständigkeit der Servicelogik geprüft werden kann.

Im folgenden wird ein Ausführungsbeispiel der Erfindung an­ hand der Zeichnung näher erläutert.

Fig. 1 zeigt die hardwaremäßige Einbettung eines Serviceent­ wicklungssystems SCE (Diensterstellungssystem) innerhalb ei­ nes Steuerungssystems (SCP, SMP) eines intelligenten Netzes. Das Serviceentwicklungssystem umfaßt eine Servicedefinition SD, ein Servicemanagement SM und ein Customer Service Control CSC. Die genannten Teile sind auf einer entsprechenden Ent­ wicklungsplattform SCEP (Service Creation Environment Point), die zu diesem Zweck entsprechende unterschiedliche Betriebs­ arten aufweist, realisiert.

Jeder Baustein SIB einer Servicelogik FSL agiert gegenüber unterschiedlichen Daten:

• - dynamischen, verbindungsspezifischen Daten, die im folgen­ den Call Instance Data CID bezeichnet werden,
• - statischen Daten, die nur bei spezifischen Administrations­ funktionen geändert werden können und von einem SIB nur ge­ lesen werden können (diese Daten werden im folgenden als Service Support Daten SSD bezeichnet),
• - statischen Daten, die von den SIBs gelesen und geändert werden können. Diese Daten werden im folgenden als Service Data Templates SDT bezeichnet. (Wenn im folgenden von semi­ permanenten Daten geredet wird, so sind damit beide Typen von statischen Daten, nämlich sowohl SSD als auch SDT gemeint.)

Im folgenden werden die Teile (Subsysteme) des Service Ent­ wicklungssystems SCE näher erläutert.

Der Teil "Service Definition SD" (Diensterstellungssystem) umfaßt die Funktionen eines Editors zum Entwurf einer FSL, die Funktionen einer Prüfeinrichtung zur die Überprüfung der entworfenen FSL nach bestimmten Regeln, die Funktionen eines Konverters zum Erzeugen von Object Code und Datenstruktur-Pro­ totypen aus der Quelldatei einer FSL sowie Funktionen zum Transferieren der aus der Quelldatei erzeugten Objekte (Object Code, Datenstruktur-Prototypen) zu den entsprechenden Hardwareplattformen, d. h. zu dem Service-Management-Point SMP und dem Service Control Point SCP.

Der Teil "Service Management SD" umfaßt folgende Funktionen:

• - die Zuordnung von Service Logic zu einem IN-Service,
• - die Erzeugung von IN-Customers (IN-Provider oder IN-Subscriber),
• - die Zuordnung von Service Logic zu IN-Customers und
• - die Zuordnung von semipermanenten Datenstrukturen zu IN-Cu­ stomers.

Der Teil "Customer Service Control CSC" stellt für den Custo­ mer eine Untermenge der gesamten Funktionen des Serviceent­ wicklungssystems zur Verfügung. Die Aufgabe des CSC ist die Verwaltung von IN-Objekten (z. B. semipermanenten Daten­ strukturen) der Customer. CSC stellt ein preiswertes Zugangs­ mittel für Customer dar, die nur verringerte Zugangsrechte zu IN-Objekten haben. CSC bietet die Möglichkeit, die für den Customer zugänglichen Felder der IN-Objekte zu verwalten.

Der SMP umfaßt im wesentlichen zwei Teile. Der eine Teil dient zum Aufnehmen von Daten von anderen IN-Subsystemen (SCEP-SD, SCEP-SM, SCEP-CSC und SCP), wobei die internen Strukturen für den SMP unsichtbar sind. Der andere Teil dient zur Ausführung der zentralen Zugangskontrolle für alle unter­ einander verbundenen IN-Subsysteme.

Der SCP dient zum Ausführen der Calls im IN-System, wobei insbesondere alle Routineaktivitäten ausgeführt werden.

Fig. 2 zeigt einen Servicebaustein SIB, der die kleinste kon­ figurierbare Softwareeinheit zur Konstruktion einer Service­ logik mit Hilfe des SCEs darstellt. Bei einem SIB handelt es sich sw-technisch um einen generischen abstrakten Datentyp, der durch die Festlegung seiner Konfiguration, insbesondere seiner externen Schnittstellen, in ein Set von abstrakten Da­ tentypen (Objekttypen) umgewandelt wird. Aus diesem werden wiederum durch Instantiierung Instanzen (Objekte, abstrakte Datenstrukturen) gebildet.

Ein Template eines Servicebausteins wird also durch ein Set von Objekttypen (Datentypen) gebildet, die den Servicebau­ stein vollkommen beschreiben bzw festlegen, d. h. seine Schnittstellen, seine Funktionalität, seine grafische Präsen­ tation und Benutzung, und optional eine Hypertexthilfeinfor­ mation. Diese Objekttypen können als verschiedene Entitäten behandelt werden und deshalb unabhängig voneinander transfe­ riert (zum SCP oder SMP) und zugänglich gemacht (für den Ope­ rator) werden.

Fig. 3 zeigt die genannten Objekttypen eines Servicebausteins.

Ein Servicebaustein ist vom System-Designer derart entworfen, daß seine Funktionalität, sein Eingangspunkt (Entry Point), sowie seine Ausgangspunkte (Exit Points) und die auf diesen Ausgangspunkten verfügbaren Daten vollkommen unabhängig von der Position des Servicebausteins innerhalb einer Servicelo­ gik und auch unabhängig von dem in der Position vorhergehen­ den und nachfolgenden Servicebausteinen sind.

Die externen Schnittstellen eines Servicebausteins sind defi­ niert durch seinen Eingangspunkt und seine Ausgangspunkte, wobei es unbedingte und optionale Ausgangspunkte gibt. Unbe­ dingte Ausgangspunkte (Mandatory Exit Points) müssen mit ei­ nem Nachfolgeservicebaustein unbedingt verbunden werden. Op­ tionale Exitpunkte ermöglichen es dem Service-Designer (Benutzer des SCEs), zu entscheiden, ob er einen optionalen Ausgangspunkt mit einem Nachfolgeservicebaustein verbinden will oder nicht. (Jeder Servicebaustein muß mindestens einen optionalen Ausgangspunkt haben, der zu einer entsprechenden Reaktion im Falle eines Fehlers führt, z. B. fehlende Ein­ gangsdaten oder ein SIB-interner Fehler.)

Diejenigen Servicebausteine, die keinen verbindbaren Aus­ gangspunkt haben (mit Ausnahme des Ausgangspunktes für den Fehlerfall), werden Terminierungs-Bausteine oder auch Blatt-Ser­ vicebausteine genannt. Sie bilden die Terminierungsbedin­ gung einer Servicelogik.

Servicebausteine, die mindestens einen verbindbaren Ausgangs­ punkt besitzen, werden Knoten-Servicebausteine genannt. Sie können jeweils nur einen Nachfolge-Servicebaustein an jedem ihrer Ausgangspunkte aufweisen (Diese Regel zwingt eine Ser­ vicelogik, von oben bis unten (from Top to Bottom) determini­ stisch zu sein.)

Jeder Servicebaustein hat exakt einen Eingangspunkt, der mit wenigstens einem Vorgänger-Servicebaustein oder dem Wurzel­ punkt (Root Point, Starting Point), einer Servicelogik ver­ bunden sein muß.

Die Definition eines Servicebausteins selbst enthält keine Einschränkungen über die Formulierung von Schleifen innerhalb der Servicelogik.

Jeder SIB wird vom Benutzer des SCEs durch die genannten ex­ ternen Schnittstellen festgelegt bzw. konfiguriert. Diese Konfigurierung wird durch ein Schnittstellen-Objekt (abstrakter Datentyp) beschrieben und in einem sogenannten Schnittstellenbeschreibungsfile (Interface Description File) abgelegt, wobei die Beschreibung in einer speziellen Sprache formuliert ist, der sogenannten SIB-Template-Description-Language STL.

Durch das Hinzufügen der Eingangs- bzw. Ausgangs-Parameter in die genannte (Konfigurations-)Beschreibung wird es ermög­ licht, daß anhand einer Pfadanalyse (mit Hilfe eines entspre­ chenden Prüfmittels) festgestellt werden kann, ob alle Ein­ gangs-Parameter (Verbindungsdaten, semipermanente Daten) ei­ nes SIBs durch vorhergehende SIBs befriedigt sind. Das bedeu­ tet, daß neue SIBs ohne zusätzlichen Aufwand geprüft werden können.

Zusätzlich zur Schnittstellen-Beschreibungs-Datei ist einem Servicebaustein eine Quelldatei (Source File) zugeordnet, die die Funktionalität des Servicebausteins beschreibt. Die Sour­ cedatei ist in einer Hochsprache (High Level Language HLL, z. B. Pascal) formuliert.

Fig. 4 zeigt die SIBs einer beispielhaften FSL, deren Parame­ ter und die sich daraus ergebenden möglichen Positionen der SIBs 2, 3 und 4 bezüglich der Ausgangspunkte von SIB1 (ver­ wendete Abkürzungen der Verbindungsdaten: Calling Party Ad­ dress CgPA, Called Party Address CdPA, Closed User Group CUG).

Eine grundlegende Bedingung für die Funktionsfähigkeit einer Servicelogik ist, daß alle am Eingangspunkt eines SIBs benö­ tigten Daten durch vorhergehende Servicebausteine oder den Protokoll-Behandler (er führt den Dialog des SCP mit einem SSP während der Ausführung eines IN-Dienstes) zur Verfügung stehen. Diese grundlegende Bedingung kann anhand der in der Schnittstellen-Beschreibungs-Dateien enthaltenen Information bereits während der Entwurfsphase einer Servicelogik von dem bereits erwähnten Prüfmittel (Komponente des SCEs) geprüft werden.

Das Prüfmittel führt die Prüfung durch, indem es in einer Schleife über die in der Logik (FSL) enthaltenen SIBs (z. B. SIB1 bis SIB4) für jeden SIB den (Verkettungs-)Pfad vom Ein­ gang bis an die Wurzel der Logik verfolgt und dabei (mit Hilfe der Information aus den Schnittstellen-Objekten der SIBs) die Menge der Parameter bildet, die an den Ausgängen der Vorgän­ ger-SIBs vorliegt. Diese Menge wird mit der Menge der notwen­ digen Eingangsparameter des zu prüfenden SIBs verglichen. Wenn die Menge der Eingangsparameter des zu prüfenden SIBs vollständig in der über die Ausgänge der Vorgänger-SIBs ge­ bildeten Menge enthalten ist, wird die Position des zu prü­ fenden SIBs als technisch korrekt bewertet bzw. bezeichnet.

Das Abbruchkriterium für die genannte Schleife ist nicht not­ wendigerweise die Wurzel der FSL, sondern wenn die Teilmen­ genbedingung erfüllt ist. Dadurch, daß alle SIBs in dieser Weise geprüft werden, ist die technische Korrektheit für die gesamte Logik immer sichergestellt. Ein weiterer wesentlicher Vorteil dieser Prüfungsart ist es, daß neu entworfene SIBs ohne zusätzlichen Aufwand geprüft werden können.

Die genannte Prüfung kann auf Veranlassung des Benutzers des SCEs, z. B. nachdem dieser einen Dienst erstellt hat, oder au­ tomatisch erfolgen.

Im folgenden wird der bereits erwähnte Makro-Servicebaustein näher erläutert.

Ein Makro-Servicebaustein ist ein wiederverwendbarer Teil ei­ ner Servicelogik, genauso wie jeder normale Servicebaustein. Im Unterschied zu normalen Servicebausteinen sind Makro-Ser­ vicebausteine aus normalen Servicebausteinen oder anderen Makro-Servicebausteinen zusammengesetzt, die sequentiell aus­ geführt werden können. Durch die Definition eines Makro-Ser­ vicebausteins wird keine neue Funktionalität in eine Ser­ vicelogik eingeführt. Wie ein Servicebaustein ist auch ein Makro-Servicebaustein charakterisiert durch verschiedene Ob­ jekte, die seine Schnittstellen, seine grafische Darstellung und Gebrauch, und optional Hypertexthilfeinformationen be­ schreiben. Im Unterschied zu einem normalen Servicebaustein benötigt ein Makro-Servicebaustein kein funktionales Objekt zu seiner funktionalen Beschreibung, da die Funktionalität des Makrobausteins ja bereits durch die in den normalen Ser­ vicebausteinen enthaltene Funktionalität und deren Verbindun­ gen innerhalb des Makro-Servicebausteins vorhanden ist.

Die Schnittstellenobjekte eines Makro-Bausteins werden aus den Schnittstellenobjekten der im Makro-Baustein enthaltenen Servicebausteine ermittelt.

Fig. 5 zeigt die Struktur eines Makro-Bausteins, die im fol­ genden als Beispiel zur Ermittlung der Schnittstellenobjekte (Eingangs- und Ausgangsparameter) eines Makro-Bausteins her­ angezogen werden.

Das Eingangs-Schnittstellenobjekt des Servicebausteins SIB1 ist definiert durch die Summe all seiner notwendigen Ein­ gangsparameter. Diese Eingangsparameter sind notwendigerweise alle zugleich Eingangsparameter des Makro-Bausteins. Die Ein­ gangsparameter des Servicebausteins SIB2, reduziert durch die Ausgangsparameter an Ausgang 2 des Servicebausteines SIB1 sind notwendigerweise ebenfalls Eingangsparameter des Makro-Bau­ steins. Die Eingangsparameter des Makro-Bausteins werden allgemein aus dem verbleibenden Set von Eingangsparametern eines Servicebausteins und der Schnittmenge der Ausgangspara­ meter des vorhergehenden Servicebausteins ermittelt.

Input(SIB₂) = Input(SIB₂)(Input(SIB₂)∩Output(SIB₁(Exit₂))) (1)

Die zur Gleichung (1) identische Relation ist auch für denje­ nigen Servicebaustein, der direkt mit dem Eingang des Makro-Bau­ steins verbunden ist, gültig, wobei allerdings in diesem Fall kein vorhergehender Servicebaustein vorhanden ist, der mit dem vorhergenannten Servicebaustein eingangsseitig ver­ bunden ist.

Gleichung (2) zeigt wie ganz allgemein die zusätzlichen Ein­ gangsparameter berechnet werden, die für den Makro-Baustein aufgrund eines Servicebausteins SIB_i entstehen.

AdditionalInput(MSIB(SIB₁)) = Input(SIB_i)(Input(SIB_i)∩(Output(SIB_v(Exit_k))∪ . . .) (2)

Die Menge der Eingangsparameter eines Makro-Bausteins ist deshalb ganz allgemein definiert durch die Vereinigungsmenge aller Zusatzmengen von Eingangsparametern der vom Makro-Bau­ stein umfaßten Servicebausteine (s. Gleichung (3)).

Input(MSIB) = AdditionalInput(SIB_i)∪. . . (3)

Die Menge von Ausgangsparametern, die an einem speziellen Ausgang verfügbar sind, wird durch die Pfadanalyse vom Aus­ gang des Makro-Bausteins in Richtung Eingang wie folgt durch­ geführt:

Output₁(MSIB) = Output(SIB₁(Exit₁))∩Output(SIB₁(Exit₂))∩Output(SIB₂(Exit₁)) (4)

Output₂(MSIB) = Output(SIB₁(Exit₂))∩Output(SIB₂(Exit₂))∩Output(SIB₃(Exit₁)) (5)

Output₃(MSIB) = Output(SIB₁(Exit₂))∩Output(SIB₂(Exit₂))∩Output(SIB₃(Exit₂)) (6)

Die Überprüfung der Schnittstellenparameter wird während des Design einer Dienstlogik automatisch vom Entwicklungssystem durchgeführt.

Claims (1)

1. Diensterstellungssystem, mit

• a) Baustein-Objekten (SIB), die jeweils eine Teilfunktion ei­ nes IN-Dienstes beschreiben,
• b) Dienst-Objekten (FSL), die jeweils die Struktur eines IN-Dienstes anhand der genannten SIBs beschreiben,
• c) einem Erstellungsmittel (SD), das die Erstellung eines IN-Dienstes durch Erzeugung der genannten Objekte ermöglicht, gekennzeichnet durch
• d) Schnittstellen-Objekte (STL), die ebenfalls bei der Er­ stellung eines Dienstes erzeugt werden und eine Beschreibung der externen Schnittstellen eines SIBs enthalten, wobei die genannte Beschreibung die jeweiligen Parameter einer externen Schnittstelle umfaßt,
• d) ein Prüfmittel, das die Funktionsfähigkeit eines IN-Dienstes prüft, indem es anhand der genannten Schnittstellen-Ob­ jekte prüft, ob die von einem SIB benötigten (Eingangs-)Pa­ rameter durch vorhergehende SIBs geliefert werden.