-
TECHNISCHES
GEBIET
-
Die
vorliegende Erfindung bezieht sich auf einen Aufzeichnungsmechanismus
in einem Telekommunikationssystem, und insbesondere auf eine Datenstruktur,
die ein einfaches Aufzeichnen nötiger Daten
in einem Verkehrssteuerungsprozess für eine Telekommunikationsanwendung
ermöglicht.
-
HINTERGRUND
DER ERFINDUNG
-
Während einer
Verarbeitung eines Anrufs in einem Telekommunikationssystem muss
eine große Menge
an Daten gehandhabt oder gesammelt werden. Solche anrufbezogenen
Daten unterscheiden sich zwischen Anrufen in Abhängigkeit davon sehr, welche
Art von Diensten bei dem spezifischen Anruf verwendet wird, welche
Protokolle zum Kommunizieren mit den umgebenden Netzwerken verwendet werden,
etc. Daten enthalten Information, die für unterschiedliche Arten von
Anwendern des Telekommunikationssystems nützlich ist. Ein Netzwerk/Service-Provider kann wünschen,
Rechnungsaufzeichnungen zu erzeugen, während ein anderer wünscht, Statistiken
unterschiedlicher Arten zu erzeugen. Wenn der Verkäufer wünscht, unabhängig davon
zu sein, welche Daten der Anwender bzw. Nutzer zu verwenden wünscht, und
noch neue Daten zusammen mit einem neuen Service hinzufügen kann,
ohne eine bereits existierende Software ändern zu müssen, müssen diese anrufbezogenen Datenaufzeichnungen
auf eine neue effiziente Weise gehandhabt werden.
-
Es
existiert eine Anzahl von möglichen
Lösungen
zum Handhaben der anrufbezogenen Daten. Eine offensichtliche Art
besteht im Verwenden einer herkömmlichen
Datenbank zum Sammeln der Information, was schnell zu Kapazitätsproblemen
führt. Eine
weitere Lösung
besteht in einer Auswahl einer Deklarationslösung, wobei eine Deklaration
der Inhalte gemacht wird (z.B. Vergleiche eine Aufzeichnung in Pascal).
Der Nachteil einer Deklarationslösung,
wie eine Pascal-Aufzeichnung,
besteht darin, dass sie nicht die erwünschte Flexibilität zeigt.
Ein weiterer Ansatz besteht im Senden der Daten zwischen den Objekten
herum, wann immer es nötig
ist, was eine Duplizierung von Daten erzeugt.
-
Im
Stand der Technik werden mehrere Konzepte in Bezug auf objektorientierte
Softwarestrukturen zur Verarbeitung in einem modernen Telekommunikationssystem
gefunden. EP-0 524 089 A1 mit dem Titel "Structure de logiciel pour systeme de
traitement de donnees, nontamment pour systeme de telecommunications" beschreibt ein System
mit logischer Struktur zum Verarbeiten von Daten, und zwar insbesondere
für Telekommunikationssysteme.
Die Struktur vereinfacht insbesondere die Echtzeitkommunikation
zwischen den Objekten gemäß den CCITT-Regeln
X 200. EP-0 524 077 A1 mit dem Titel "Structure de logiciel pour systeme de
traitement d'informations" beschreibt eine
Struktur, die die Hardware- und
Software-Systemmerkmale zu den Anwendungsprogrammen versteckt.
-
EP-0
470 415 A2 beschreibt ein Verfahren zum Versorgen einer Anzahl von
Anwendungsprozessoren bei einem Telefonsystemzugriff auf anrufbezogene
Information in einer gemeinsamen Datenbank. Die Information wird
mit einem Tag bzw. einer Kennung versehen und solange temporär als Aufzeichnung
in der Datenbank gespeichert, wie die Kommunikation dauert. Die
Information wird insbesondere diesbezüglich geführt, dass sie zur Überwachung
in einem bedienergesteuerten Vermittlungssystem auf einem Anzeigegerät direkt
angeschaut wird.
-
Das
US-Patent US-A-5218632 offenbart ein Rechnungsaufzeichnungs-Softwaresystem,
das dafür
verwendet wird, zu entscheiden, ob eine Belastungs- bzw. Rechnungsaufzeichnung
für einen
Anruf erzeugt werden sollte oder nicht.
-
ZUSAMMENFASSUNG
DER ERFINDUNG
-
Daher
gibt es bei einem Telekommunikationssystem eine Forderung, einen
Anrufaufzeichnungsmechanismus zu erzeugen, der es möglich macht,
das System mit neuen Diensten und Daten zu erweitern, ohne eine
bereits existierende Betriebssoftware eines Systems zu beeinflussen,
und zwar unter Verwendung des Prinzips eines halben Anrufs.
-
Eine
erste Aufgabe gemäß der vorliegenden Erfindung
besteht darin, in einer Session eines Ausführens einer Anrufverarbeitung
das lokal temporäre Speichern
von Daten mittels Speicherzeigern in Aufzeichnungen bzw. Datensätzen durchzuführen, die zu
einer jeweiligen ausgeführten
Session gehören, wobei
der Zeiger weiterhin mit einem Tag- bzw. Kennungselement kombiniert
ist, mittels welchem lokal gespeicherte Daten eindeutig identifiziert
werden und während
der Dauer einer Session durch eine Aufzeichnungsansicht-Objektfunktion selektiv
aufgerufen und in einer Datenbank für eine nachfolgende Verarbeitung
gespeichert werden können.
-
Eine
zweite Aufgabe gemäß der vorliegenden
Erfindung besteht darin, dass die spezifische Session eine Sessionaufzeichnung
und eine Transaktionsaufzeichnung zum jeweiligen Speichern von Zeigern
und Tags bzw. Kennungen von Objekten und Daten in der Session verwendet,
und dass es von diesen Aufzeichnungen möglich sein wird, alle Objekte
und Daten innerhalb der Session zu lokalisieren, wenn das Tag-Element
bekannt ist, unter welchem die erwünschte Dateninformation gespeichert ist.
-
Eine
dritte Aufgabe gemäß der vorliegenden Erfindung
besteht darin, dass bei der Anrufverarbeitung ein Verkehrsfallumfang
definiert wird, der eine ähnliche
Struktur wie ein Sessionumfang hat, und eine Verkehrsfallaufzeichnung
erzeugt wird und auf diese von der Session Bezug genommen wird,
um ausführende
Objekte eines Anrufs zu speichern, und es zusätzlich in der Verkehrsfallaufzeichnung
eine Transaktionsaufzeichnung gibt, die Daten speichert, die zu
dem Verkehrsfall gehören.
-
Eine
vierte Aufgabe gemäß der vorliegenden Erfindung
besteht darin, dass Dienste zu irgendeinem Zeitpunkt durch einfache
Modifikation einer Tag-Liste geändert
werden können,
die in einer lokalen Datenbank gespeichert ist, ohne mit dem existierenden
Betriebs-Organisationssystem zu interferieren bzw. dieses zu stören.
-
Eine
fünfte
Aufgabe gemäß der vorliegenden Erfindung
besteht darin, dass das Tag-Element durch eine ganze Zahl realisiert
wird, und zwar vorzugsweise als Binärwort, die jedem ausführenden
Objekt oder Datenobjekt, das in einer Session verwendet wird, eindeutig
zugeordnet ist.
-
Diese
Aufgaben werden gemäß den beigefügten Ansprüchen 1–8 erreicht.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Die
Erfindung, zusammen mit weiteren Aufgaben und Vorteilen davon, kann
am besten durch Bezugnahme auf die folgende Beschreibung, genommen
zusammen mit den beigefügten
Zeichnungen, verstanden werden, wobei:
-
1 eine
Darstellung einer Session mit einer Sessionsteuerung SC ist, die
mehrere Verkehrsfälle
handhabt, einschließlich
für jeden
Verkehrsfall einen jeweiligen entstehenden Anruf bzw. Aufruf OC in
Kommunikation mit anderen Verkehrsfällen, einschließlich eines
jeweiligen Beendigungsanrufs TC;
-
2 zeigt
eine Sessionsteuerung SC, die gemäß dem Verfahren und dem System
der vorliegenden Erfindung eine Sessionaufzeichnung zum Speichern
von Referenzen auf ausführende
Objekte und eine Transaktionsaufzeichnung zum Speichern von Referenzen
zu Datenobjekten verwendet;
-
3 Sammlungen
gemäß dem Verfahren und
dem System der vorliegenden Erfindung zum Speichern eines Verkehrsfallobjekts
innerhalb eines entstehenden Anrufs OC zeigt;
-
4 eine
Demonstration von Objekten ist, die den Datenfluss in einer Session
steuern;
-
5 ein
Beispiel zeigt, bei welchem Daten für eine (Gebühren-)Belastungsbasis aus einer
Session extrahiert werden;
-
6 in
einem einfachen Beispiel die Beziehung zwischen erzeugten gemanagten
Objekten zeigt;
-
7 die
vollständige
statische Ansicht gemäß dem einfachen
Beispiel der 6 zeigt;
-
8 ein
einfaches Ablaufdiagramm einer Anrufdatensammlung in einer Transaktionsaufzeichnung
während
einer Anrufverarbeitung ist; und
-
9 ein
einfaches Ablaufdiagramm einer Spezifikation von Daten ist, um in
einer Ausgabe enthalten zu sein.
-
GRUNDSÄTZLICHES
-
Um
den Gegenstand der vorliegenden Anmeldung auf effiziente Weise handhaben
zu können, wird
es praktisch sein, zuerst eine Anzahl von technischen Ausdrücken zu
definieren, die in der gesamten folgenden Beschreibung nützlich sein
werden.
-
Eine
allgemeine Weise zum Strukturieren von Software in einem Anrufverarbeitungs-Vermittlungssystem
für Telefonie
besteht im Aufteilen der Steuerung des Anrufs in zwei Hälften, nämlich einen Halbanruf
A und einen Halbanruf B. Die Software, die einen Halbanruf steuert,
führt in
einem Prozess aus, der Session genannt wird. Eine Session kann einen oder
mehrere Verkehrsfälle
gleichzeitig handhaben (beispielsweise in einer Mehrfachanrufsituation).
Der Verkehrsfall definiert die Funktionsfähigkeit und Daten, die einen
Anruf in einer Session handhaben. Es ist auch zu beachten, dass
ein Anruf von drei Parteien durch zwei Verkehrsfälle in einer Session gehandhabt
wird, und zwar durch einen für
jede Anrufverbindung bzw. jedes Anrufbein.
-
Der
Einfachheit halber wird die Session in unterschiedlichen Umfängen strukturiert
und daher wird der Sessionumfang und der Verkehrsfallumfang eingeführt. Der
Sessionumfang wird durch die Basisablauf-Sessionsteuerung SC gesteuert.
Die Hauptaufgabe für
die Sessionsteuerung besteht im Handeln als Befehlsinterpretierer
gegenüber
dem Zugriffsprotokoll ACP und im Durchführen einer Dienstanalyse bzw.
Serviceanalyse in Bezug auf diese Befehle (Nachrichten). Dies enthält dann beispielsweise
ein Initiieren und ein Beenden neuer Verkehrsfälle, ein Verteilen von Information
von dem Zugriffsprotokoll zu dem richtigen Verkehrsfall, ein Initiieren
neuer Dienste, etc.
-
Jeder
Verkehrsfall innerhalb der Session wird durch einen Basisablauf
gesteuert. Ein solcher Basisablauf kann entweder ein entstehender
Anruf OC oder ein beendender Anruf TC sein. Die Hauptaufgabe für diesen
Basisablauf besteht im Sorgen für die
Basisanrufhandhabung. Dies enthält
beispielsweise ein Aufbauen/Trennen eines Anrufs (einschließlich eines
Handhabens des Telekommunikationsdienstprotokolls TSP zwischen den
Anrufhälften), ein
Beauftragen einer Bildung/Trennung von Verbindungen (beispielsweise
einer Sprachverbindung) und ein Beauftragen einer Adresseninformationsanalyse,
etc.
-
Zum
Unterstützen
der unterschiedlichen Umfänge
und der innerhalb von diesen arbeitenden Steuerlogik gibt es eine
Notwendigkeit nach einer ähnlichen
Datenstruktur. Somit müssen
die Daten auf eine bestimmte Weise strukturiert sein, um es möglich zu
machen, die Anwendungen zu implementieren und aufrechtzuerhalten.
Dementsprechend existieren zwei unterschiedliche Typen von Objekten,
die in dieser Beschreibung mit ausführende Objekte und Datenobjekte
bezeichnet sind.
-
Ein
ausführendes
Objekt wird in der Session ausführen,
wie z.B. Steuerobjekte, Protokollobjekte, Betriebsmittelobjekte,
etc. Ein reines Datenobjekt wird Daten enthalten, die beispielsweise
von einer Teleserviceprotokollnachricht empfangen sind. Es soll
auch möglich
sein, eine Ausgabe von diesem Typ von Daten für Abrechnungszwecke oder statistische Zwecke
zu veranlassen. Die zwei Typen von Objekten haben eine unterschiedliche
Semantik und sind in der Session in unterschiedlichen Aufzeichnungen
gespeichert. Eine solche Aufzeichnung wird Sessionaufzeichnung genannt
und wird zum Speichern von Zeigern zu Protokollobjekten und Betriebsmittelobjekten
verwendet, die innerhalb der Session durch Steuer- und Betriebsmittelobjekte
durch ein Beispiel dargelegt sind. Die in einer Sessionaufzeichnung
gespeicherten Objekte sind für
die gesamte Session gemeinsam. Zum Speichern von Referenzen zu reinen Datenobjekten
wird eine Transaktionsaufzeichnung verwendet. Auf ähnliche
Weise wie die Sessionaufzeichnung Zeiger zu Objekten speichert,
wird die Transaktionsaufzeichnung (die auch Anrufaufzeichnung genannt
wird) zum Speichern von Zeigern zu reinen Datenobjekten verwendet,
die durch Steuer-, Protokoll- und Betriebsmittelobjekte innerhalb
der Session oder einen Verkehrsfall, der in der Session ausführt, durch
ein Beispiel dargelegt sind.
-
Eine
Anwenderansicht einer Sessionaufzeichnung wird Sessionaufzeichnungsansicht
genannt und gibt dem Anwender eine Schnittstelle zu der Sessionaufzeichnung
auf einer Ebene hoher Abstraktion. Gleichermaßen wird eine Anwenderansicht einer
Transaktionsaufzeichnung Transaktionsaufzeichnungsansicht genannt
und gibt dem Anwender eine Schnittstelle zu der Transaktionsaufzeichnung auf
einer hohen Abstraktionsebene.
-
Schließlich wird
auch eine Verkehrsfallaufzeichnung gefunden, die eine Aufzeichnung
ist, wo Zeiger zu Objekten, die zu einem Verkehrsfall gehören, gespeichert
sind. Nur Zeiger zu Protokollobjekten und Betriebsmittelobjekten
sind in dieser Aufzeichnung gespeichert. Zum Speichern von reinen Datenobjekten
sollte Transaktionsaufzeichnung verwendet werden. Eine Anwenderansicht
einer Verkehrsfallaufzeichnung wird Verkehrsfallaufzeichnungsansicht
genannt und gibt dem Anwender eine Schnittstelle zu der Sessionaufzeichnung
auf einer hohen Abstraktionsebene.
-
DETAILLIERTE
BESCHREIBUNG DES BEVORZUGTEN AUSFÜHRUNGSBEISPIELS
-
Um
die unterschiedlichen Umfänge
und eine entsprechende Steuerlogik für einen Anrufzeichnungsmechanismus
in einem Telekommunikationssystem zu unterstützen, benötigen wir eine geeignete Datenstruktur.
Daten müssen
strukturiert sein, um es möglich
zu machen, die Anwendungen zu implementieren und aufrechtzuerhalten.
Wir führen
daher zwei unterschiedliche Typen von Objekten, nämlich die ausführenden
Objekte bzw. die Datenobjekte, ein, um sie in einer Session zu verfolgen.
Diese zwei Ausdrücke,
die bereits oben definiert wurden, haben eine unterschiedliche Semantik
und sind in unterschiedlichen Aufzeichnungen in der erzeugten Session
gespeichert. Beim Speichern eines Objekts in einer Sammlung ist
es nur eine Frage eines Speicherns eines Zeigers zu dem Objekt,
dass zu speichern ist, und folglich wird in einem solchen Schritt
keine Duplizierung bzw. Kopie des Objekts selbst durchgeführt. Dies
impliziert auch, dass es für
eine solche Zeigerspeicherung tatsächlich keine Notwendigkeit
gibt, die Größe des bestimmten
Objekts zu kennen.
-
1 ist
eine verallgemeinerte Ansicht eines Sessionumfangs, der durch die
Sessionsteuerung SC gesteuert wird. Die Sessionsteuerung handelt
als Befehlsinterpretierer gegenüber
dem Zugriffsprotokoll ACP, welches der allgemeine Ausdruck ist,
der für
die Teilnehmer- oder Netzwerkzugriffe verwendet wird. Wie es aus 1 offensichtlich
ist, enthält
die Session einen oder mehrere Verkehrsfälle, und hier enthält die bestimmte
Session zwei Verkehrsfälle,
die beide von dem OC-Typ (entstehender Anruf) sind. Jeder einzelne
der zwei Verkehrsfälle
vom Typ OC wird mittels des jeweiligen Verkehrsfalls zu einem weiteren
Verkehrsfall vom Typ TC (beendender Anruf) durch ein handhabendes
Telekommunikationsdienstprotokoll TSP gebildet.
-
Wie
es in 2 gezeigt ist, gibt es im Sessionumfang eine Sessionaufzeichnung
SR, die zum Speichern eines Zeigers PTR zu jedem ausführenden
Objekt, wie beispielsweise zu einem sogenannten Sessionagenten,
verwendet werden soll. Die Sessionaufzeichnung ist mittels anderer
Zeiger die Wurzel für
die Datenstruktur in jeder Session. Die Datenobjekte der gesamten
Session werden mittels ihrer jeweiligen Zeiger PTR in der Transaktionsaufzeichnung
gefunden. Jeder Eintrag in der Sessionaufzeichnung hat einen bestimmten
Namen oder Schlüssel
TAG, der es möglich
macht, irgendein Objekt innerhalb des Sessionumfangs zu lokalisieren, wenn
der bestimmte Systembetreiber den bestimmten Namen oder das TAG
kennt.
-
3 ist
eine verallgemeinerte Ansicht eines Verkehrsfallumfangs, der hier
einen Typ eines entstehenden Anrufs OC enthält, aber ein Typ eines beendenden
Anrufs TC würde
die entsprechende Struktur haben. Dieser Umfang muss eingeführt werden, wenn
die Anwendung eine Notwendigkeit hat, eine beliebige Anzahl von
parallelen Verkehrsfällen
in der Session auszuführen.
Die Struktur des Verkehrsfallumfangs ist somit ähnlich bzw. gleich derjenigen
des Sessionumfangs. Für
jeden Verkehrsfall in einer Session wird eine Verkehrsfallaufzeichnung
erzeugt, um ausführende
Objekte zu speichern. Wie in der Sessionaufzeichnung wird ein Name
oder TAG und ein Zeiger PTR verwendet. Auf die Verkehrsfallaufzeichnung
wird demgemäß von der
Sessionaufzeichnung aus Bezug genommen. Um Datenobjekte zu speichern,
die zu dem Verkehrsfall gehören,
wird folglich eine Transaktionsaufzeichnung TR verwendet, die eine
Tabelle für
die Datenobjekte auf dieser Verkehrsfallebene erzeugt.
-
Jeder
Anwender einer Session oder einer Verkehrsfallaufzeichnung hat ein
eigenes Ansichtsobjekt, durch welches auf die gespeicherten ausführenden
Objekte oder Datenobjekte zugegriffen werden kann.
-
4 zeigt
den Datenablauf durch eine Session detaillierter, die einen entstehenden
Anruf OC ausführt.
Der Datenablauf startet, wenn einige Daten durch einen Zugriffsagenten
oder den Eingabeagenten empfangen werden. Die empfangenen Daten werden
in eine interne AXE-Darstellung umgewandelt. Die umgewandelten Daten
werden dann in der Transaktionsaufzeichnung TR gespeichert. Das
Datenobjekt wird mit einem Tag gespeichert. Das Tag ist eine ganze
Zahl, die für
dieses bestimmte Datenobjekt reserviert ist. Andere Anwender, wie
z.B. eine Anwendungsanalyse, die das Datenobjekt benötigen, können es
aus der Transaktionsaufzeichnung mittels des Tags und durch Verwenden
eines Transaktionsaufzeichnungsansichtsobjekts TR View. Das obige
Beispiel stellt auch dar, wenn Daten durch den Ausgabeagenten über das
Telekommunikationsdienstprotokoll TSP zu dem anderen Halbanruf gesendet
werden. Daten werden in einem Parameter gesendet, der neben den
Daten das Tag enthält,
das sie identifiziert.
-
Wie
es oben angegeben ist, wird ein Datenobjekt in der Transaktionsaufzeichnung
(ein Synonym für
eine Transaktionsaufzeichnung ist auch Anrufaufzeichnung) gespeichert.
Auf die Transaktionsaufzeichnung TR wird, wie es bereits angegeben
ist, immer über
ein Ansichtsobjekt zugegriffen. Das Ansichtsobjekt gibt dem Anwender
eine Schnittstelle hoher Ebene zu der TR, die nachfolgend weiter
beschrieben werden wird. Jedes Datenobjekt, das in der Transaktionsaufzeichnung
gespeichert ist, wird semantisch durch einen Namen oder einen Schlüssel identifiziert,
der TAG genannt wird. Das TAG ist eine ganze Zahl, und zwar bei
einem beispielhaften Ausführungsbeispiel
ein 16-Bit-Wort, die für
ein bestimmtes Datenobjekt reserviert worden ist. Durch Verwenden
einer dynamischen Speicherung, wie beispielsweise der Transaktionsaufzeichnung,
wo die Datenobjekte mit Tags gespeichert werden, wird es möglich sein,
einen sehr flexiblen Ausgabemechanismus zu unterstützen. Anders
ausgedrückt,
wird es extrem einfach, ohne Einflussnahme auf den allgemeinen Betrieb
des Telekommunikationssystems, zu irgendeiner bestimmten Zeitperiode
irgendwelche ausgewählten
Datenobjekte auf eine Anforderung des Anwenders hin für eine spätere Analyse
zu extrahieren. Eine Folge davon ist, dass es extrem einfach werden
wird, zusätzliche
Dienste in ein System hinzuzufügen,
das gemäß einer
solchen strukturierten Betriebsweise arbeitet.
-
Es
soll angenommen sein, dass der Agent den Parameter "Nummer der anrufenden
Partei" mit dem
Protokoll ACP empfängt.
Die Daten werden zu einer internen AXE-Darstellung umgewandelt und zusammen
mit einem bestimmten Tag "AppCallingPartyNumberTag" in der TR gespeichert
werden. Andere Anwender der TR, die die Nummer der anrufenden Partei
benötigen,
können
sich dann der TR zuwenden und nach dem Datenobjekt fragen, das mit dem
TAG "AppCallingPartyNumberTag" gespeichert ist.
Eine Schnittstelleanwendungsplattform-Tag-Schnittstelle ATI (= Application
Platform Tags Interface) enthält
die Anzahl von Tags, die durch die Funktionen verwendet werden.
ATI enthält
auch die Regeln, die dann zu befolgen sind, wenn neue Tags reserviert
werden.
-
Wie
es bereits angegeben ist, wird auf die TR immer über ein Ansichtsobjekt zugegriffen.
Das Ansichtsobjekt hat zwei Hauptaufgaben. Die erste besteht im
Präsentieren
einer kundenangepassten Schnittstelle zu der TR. Jeder Anwender
der TR sollte eine bestimmte Schnittstele zu den Inhalten in der TR
haben. Die zweite Aufgabe besteht im Handeln als Handhabungsobjekt
zu der TR, wobei die Handhabung sicherstellt, dass die TR nicht
entfernt wird, bis alle Handhabungen gelöscht sind.
-
Ansichtsobjekte
werden auch zum Zugreifen auf die Inhalte der anderen zwei Typen
von Aufzeichnungen verwendet, die existieren, nämlich die Sessionaufzeichnung
und die Verkehrsfallaufzeichnung. Wie es oben angegeben ist, besteht
eine Aufgabe des Ansichtsobjekts im Versorgen des Anwenders mit
einer kundenangepassten Schnittstelle auf einer hohen Abstraktionsebene
zu einer Aufzeichnung. Die Kundenanpassung bedeutet, dass die Schnittstelle den
Anwendern einen Zugriff nur zu den Objekten zuteilt, auf die zugegriffen
werden muss, welche nur ein Teil der gesamten Inhalte in einer Aufzeichnung
sein können.
-
Die
zweite Hauptaufgabe der Ansichtsobjekte zu der Transaktionsaufzeichnung
und der Verkehrsfallaufzeichnung besteht darin, dass sie als Handhabungen
handeln. Solange wie eine Aufzeichnung eine Handhabung hat, kann
sie nicht gelöscht werden.
Wenn eine letzte Handhabung zu einer Aufzeichnung entfernt ist,
wird die Aufzeichnung und alle ihre Inhalte auch von dem lokalen
Speicher entfernt. Es ist offensichtlich, dass dies ein sehr angenehmes Management
für einen
lokalen Speicher erzeugt.
-
Der
Anrufaufzeichnungs-Ausgabemechanismus, der bereits angegeben ist,
wird zum Ausgeben von Teilen des Inhalts einer Transaktionsaufzeichnung
für eine
Nachverarbeitung verwendet. Es sollte in Erinnerung gehalten werden,
dass die Inhalte der Sessionaufzeichnung und einer Verkehrsfallaufzeichnung
und einer Transaktionsaufzeichnung nur während der Dauer dieser bestimmten
Session existieren und verschwinden werden, wenn die Session beendet
wird. Der Ausgabemechanismus wird um eine Anzahl von gemanagten
Objekten gebildet, die Tag-Listen enthalten. Beim Betreiben eines
Telekommunikationssystems gibt es beispielsweise eine Notwendigkeit,
Gebührenzahlungsdaten
zu sammeln, um bei den unterschiedlichen Teilnehmern richtig abzurechnen.
In 5 ist beispielhaft gezeigt, was in einer Session
stattfinden kann. Ein Steuerobjekt "Gebührenzahlung" hat ein Objekt Cro_Typ
geöffnet. Dieses
bestimmte Objekt Cro_Typ enthält
eine Tag-Liste, die von der Datenbank geholt ist, welche die Datenobjekte
bezeichnet, die von der Transaktionsaufzeichnung zu extrahieren
sind. Cro_Typ wird dann beauftragt, einen Bericht zu kompilieren,
der aus den Datenobjekten besteht, die durch die Tag-Liste identifiziert
sind, die in der Datenbank gespeichert ist. Das Steuerobjekt verwendet
dann die Schnittstelle Cro_Typ zum Beauftragen von ihr, die Daten
während
des Vorhandenseins der bestimmten Session zu sammeln. Die Daten
können
in einen Datenbereich gepackt werden, der dann zu einem Nachverarbeitungsknoten
gesendet werden wird. Folglich kann eine Gebührenzahlungsbasis aufgrund von
erweiterten Diensten zu jedem Zeitpunkt durch einfache Modifikation
der Tag-Liste geändert
werden, ohne überhaupt
das existierende System zu stören, das
eine Struktur gemäß der vorliegenden
Erfindung hat.
-
Das
effektive Ergebnis davon besteht darin, dass selbst dann, wenn die
Inhalte der unterschiedlichen Sessions als lokale Daten definiert
sind, es möglich
ist, gleichzeitig erwünschte
Teile des Inhalts zu verwenden, als ob sie globale Daten bilden.
Ein Unterschied zwischen lokalen und globalen Daten besteht beispielsweise
darin, dass die letzteren notwendigerweise normalerweise bei vorbestimmten Speicherstellen
zugeteilt sein müssen,
damit auf sie durch andere Anwender zugegriffen werden kann.
-
Bei
dem illustrativen Ausführungsbeispiel verwenden
wir der Typen von gemanagten Objekten zum Bewirken des hier beschriebenen
flexiblen Ausgabemechanismus. Sie sind bezeichnet als CroDienstSchablone
bzw. CroServiceTemplate, CroTyp und CroKundenSchablone bzw. CroCustomerTemplate.
Der erste gemanagte Objekttyp, nämlich
CroServiceTemplate, wird für
eine Spezifikation dessen verwendet, welche Datenobjekte zum Extrahieren
für einen
spezifischen Basis- oder Zusatzdienst möglich sind. CroServiceTemplate
enthält
ein Attribut, mögliche
TAGs, das bezeichnet, welche Daten zum Extrahieren von der Transaktionsaufzeichnung
TR für
einen bestimmten Dienst möglich
sind, wie beispielsweise in diesem Zusammenhang ein "Basisanruf" oder ein "Dreiparteienanruf".
-
Der
zweite gemanagte Objekttyp ist ein CroTyp, welcher für eine Spezifikation
eines bestimmten Ausgabetyps verwendet wird. Jeder Fall von CroTyp ist
mit einem oder mehreren Fällen
von CroServiceTemplate verbunden. Die Vereinigung bzw. Verbindung
von Daten in diesen CroServiceTemplates bestimmt, welche Daten zum
Ausgeben für
einen spezifischen CroTyp möglich
sind.
-
Der
dritte und letzte Management-Objekttyp ist CroCustomerTemplate,
welcher ein gemanagtes Objekt ist, das die Information über Daten
zum Extrahieren für
einen spezifischen Kunden bei einem spezifischen Ausgabetyp, CroTyp,
hält.
-
6 zeigt
ein kleines Beispiel mit den folgenden Bedingungen:
- – Es
gibt zwei Kunden A und B.
- – Es
gibt zwei Dienste "Basisanruf" und "Dreiparteienanruf".
- – Es
gibt zwei CroTypen, nämlich
den CroTyp 1 und den CroTyp 2.
-
Weil
es zwei Dienste gibt, benötigen
wir zwei CroServiceTemplates:
- – CroServiceTemplate
Basisanruf, welcher die Tags 1, 2, 5 und 8 enthält.
- – CroServiceTemplate
Dreiparteienanruf, der die Tags 1, 2, 6 und 9 enthält.
-
Dies
bedeutet, dass wird für
den "Basisanruf" die in der TR gespeicherten
Daten mit den Tags 1, 2, 5 und 8 ausgeben können, während wir für den Dienst "Dreiparteienanruf" die unter den Tags
1, 2, 6 und 9 gespeicherten Daten ausgeben können.
-
Wir
definieren dann zwei Ausgabetypen, nämlich CroTyp 1, der so entworfen
ist, dass er Daten in Bezug auf beide Dienste ausgeben kann, und
den CroTyp 2, der so entworfen ist, dass er Daten in Bezug auf den
Basisanruf ausgeben kann. In 6 ist die
Basisstruktur und die Beziehung zwischen dem erzeugten gemanagten
Objekt visualisiert.
-
Ein
CroCustomerTemplate ist für
jeden Kunden und den CroTyp erforderlich, um zu veranlassen, dass
der Ausgabemechanismus "Anrufaufzeichnungsausgabe" CRO Ausgaben von
allen CroTypen zu allen Kunden durchführen kann. Dies resultiert
in diesem Beispiel in einer Gesamtheit von vier CroCustmerTemplates.
In 7 ist die resultierende Struktur gezeigt. Der
Kunde A fordert alle möglichen
Tags vom CroTyp 1 und die Tag-Nr. 1 und 2 vom CroTyp 2 und der Kunde
B erfordert alle Tags mit niedrigerer Zahl als 8 von allen CroTypen.
Wir haben dann eine Endstruktur, die der Ausgabemechanismus CRO
benötigt,
um eine geeignete Verteilung durchzuführen. Wir haben spezifiziert,
welche Datenfelder alle unterschiedlichen Kunden von allen unterschiedlichen CroTypen
benötigen.
-
Ein
Endteil des Datenablaufs in 4 beschreibt,
wenn die Daten zu dem anderen Halbanruf gesendet werden sollen.
Die Halbanrufe kommunizieren mittels des Telekommunikationsdienstprotokolls
TSP. Das TSP trägt
selbstidentifizierende Parameter. Ein Parameter enthält ein Datenobjekt
und wird durch ein Tag identifiziert. Der Empfänger kann durch Schauen auf
das Tag bestimmen, welche Daten empfangen werden. Das Tag, das zum
Identifizieren eines Parameters bei dem TSP verwendet wird, ist
dasselbe Tag, das zum Identifizieren von in der TR gespeicherten
Daten verwendet wird.
-
In 8 ist
durch eine Anzahl von Schritten in einem einfachen Ablaufdiagramm
eine Anrufdatensammlung in einer Transaktionsaufzeichnung während einer
Anrufverarbeitung zusammengefasst. Eine solche Verarbeitung wird
in einem Schritt 100 gestartet. Im ersten wirklichen Schritt 101 des
Prozesses wird eine Nachricht über
ein externes Protokoll empfangen. Sie wird in einem Protokollagenten innerhalb
eines dynamischen Prozesses innerhalb des Systems empfangen. Als
nächstes
werden in einem Schritt 102 die Daten von einer externen
Darstellung zu einer internen Darstellung umgewandelt. Ein Datenobjekt
wird innerhalb des Prozesses erzeugt. Dieses Datenobjekt enthält dann
die interne Darstellung der empfangenen Daten.
-
In
einem dritten Schritt 103 wird das Datenobjekt unter einem
eindeutigen Tag-Element in einer Transaktionsaufzeichnung gespeichert.
Während Anrufverarbeitungsdaten
in einem vierten Schritt 104 von der Transaktionsaufzeichnung
unter Verwendung eines Transaktionsaufzeichnungs-Ansichtobjekts
geholt werden, wird dann das Tag-Element dazu verwendet, den richtigen
Zeiger PTR zum Auslesen bzw. Wiedergewinnen der spezifizierten Daten
zu bekommen.
-
Wenn
der Anruf endet oder wenn eine Ausgabe von Anrufdaten für statistische
oder Gebührenzahlungszwecke
erwünscht
ist, wird die Funktion Anrufaufzeichnungsausgabe in einem fünften Schritt aufgerufen.
Diese Funktion greift auf die Datenbank zu, um herauszufinden, welche
Daten auszugeben sind. Als Ergebnis bekommt die Funktion eine Liste von
Tag-Elementen. Die erwünschten
Daten werden im Schritt 104 von der TR gesammelt und in
einen Ausgabepuffer gelegt. Dieser Puffer kann dann zu einem externen
Medium ausgegeben werden. Die Daten können später nachverarbeitet werden,
um beispielsweise eine Abbuchungsinformation, etc. zu erzeugen.
-
Schließlich ist
in 9 mittels dreier Schritte ein einfaches Ablaufdiagramm
für eine
Spezifikation von Daten gezeigt, die in einer Ausgabe enthalten sein
sollen. Die Prozedur startet in einem Schritt 200. In einem
Schritt 201 entscheidet der Serviceprovider oder irgendein
anderer Betreiber, der das System verwaltet, darüber, welche Daten für unterschiedliche Anruftypen
auszugeben sind. Diese unterschiedlichen Ausgabetypen werden in
einem zweiten Schritt 202 durch Auffüllen von Schablonen bzw. Templates mit
Listen von Tags zur Ausgabe spezifiziert. In einem schließlichen
Schritt bzw. Endschritt 203 werden diese Templates in einer
Datenbank durch beispielsweise Eingeben der Liste von Tags mittels
eines separaten Endgeräts
und/oder einer Tastatur gespeichert. Auf diese eingegebene Liste
von Tags wird später
während
der Anrufverarbeitung zugegriffen. Ein Eingeben der Liste von Tags
wird die allgemeine Anrufverarbeitung im Telekommunikationssystem zum
Initiieren und Beenden von Verkehrsfällen, zum Verteilen von Information
von dem Zugriffsprotokoll zu dem richtigen Verkehrsfall, zum Initiieren
neuer Dienste, etc. nicht stören,
aber dann, wenn sie eingegeben ist, wird sie darüber entscheiden, welche Daten
in der Datenbank für
eine Nachverarbeitung zu speichern sind.
-
Es
wird von Fachleuten auf dem Gebiet verstanden werden, dass verschiedene
Modifikationen und Änderungen
an der vorliegenden Erfindung ohne Abweichung von deren Schutzumfang
durchgeführt werden
können,
welcher durch die beigefügten
Ansprüche
definiert ist.