DE69733893T2

DE69733893T2 - System und verfahren zur kontrollierten medienumstezung in einem intelligenten netzwerk

Info

Publication number: DE69733893T2
Application number: DE69733893T
Authority: DE
Inventors: Arne Bo ÄSTRÖM; Arne Björn SVENNESSON; Gulamabbas Sumar; Johannes Robert SCHMERSEL
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 1996-08-30
Filing date: 1997-08-21
Publication date: 2006-05-24
Anticipated expiration: 2017-08-22
Also published as: DE69733893D1; WO1998009422A2; AU718548B2; CA2264264A1; JP2000517127A; JP4138010B2; EP0922364A2; WO1998009422A3; CN1235735A; AU3874397A; EP0922364B1

Description

1. Technisches Gebiet der Erfindung
Die Erfindung bezieht sich auf die Bereitstellung von zusätzlichen Telekommunikationsdiensten, und weiter insbesondere auf ein System und Verfahren zum Ermöglichen der Umwandlung von Nachrichten, die in einem Medium empfangenen werden, in ein anderes Medium.
2. Beschreibung des zugehörigen Stands der Technik
Die Kundenanforderung für kundenspezifische Telekommunikationsdienste ist immer schneller angewachsen. Bestimmte Teilnehmermerkmale, wie wartender Anruf, Anruf-Weiterleitung, abgekürztes Wählen usw., werden zunehmend wichtig für einzelne Teilnehmer aufgrund der zusätzlichen Annehmlichkeit, die sie bieten, und genau so für Telekommunikationsdienstanbieter als Quellen für zusätzliche Einnahmen. Derartige Dienste werden im Allgemeinen durch besonderes Programmieren in der Software der Haupt-Vermittlungsstelle, die einem bestimmten Teilnehmers dient, bereitgestellt. Das bedeutet, dass die Software der Ortsvermittlungsstellen gesondert programmiert wird, um besondere Dienstmerkmale für die daran angeschlossenen Teilnehmer bereitzustellen. Häufig müssen sowohl die Hardware als auch die Software einer Vermittlungsstelle aufgerüstet werden, um die Bereitstellung von besonderen Teilnehmerfunktionalitäten zu ermöglichen.
Wenn ein Anruf eine Zusammenschaltung von zwei an verschiedene Vermittlungsstellen angeschlossene Parteien bedingt, wird sie über eine so genannte Transit- oder Tandem- Durchgangsvermittlungsstelle vervollständigt, die Teil von einem Netzwerk, das die einzelnen Haupt-Schaltstellen miteinander verbindet, ausmacht. In solchen Fällen ist die Transit-Durchgangsvermittlungsstelle für die zwei Parteien des Anrufs vollständig transparent und stellt einfach eine Sprachverbindung zwischen den zwei Endbüros dar. Irgendein besonderes Dienstmerkmal, das von einer der beiden Parteien aufgerufen wird, wurde herkömmlich durch das Endbüro, an das der Teilnehmer angeschlossen ist, unabhängig von der Netzwerkverbindung zwischen den zwei Parteien bereitgestellt.
In den meisten Telekommunikationssystemen, die schlichten herkömmlichen Telefondienst (Englisch: Plain Old Telephone Service, POTS) bereitstellen, ist die Kommunikationsverbindung zwischen einer anrufenden Partei (A-Partei) und der angerufenen Partei (B-Partei) unter der Steuerung der A-Partei. Daher bleibt die Kommunikationsverbindung zwischen der A-Partei und der B-Partei bestehen bis das Telefoniegerät der A-Partei "aufgelegt" wird, in welchem Fall das System die Kommunikationsverbindungen und die Endbüros der beiden Parteien und jede beliebige Transitvermittlungsstelle, die zum Zusammenverbinden der Endbüros verwendet worden ist, unterbricht. Wenn die B-Partei im Begriff steht, sein oder ihr Telefoniegerät aufzulegen, hat dies zunächst wenig Effekt, bis nach Ablauf einer Zeitdauer von einigen Minuten, wenn ein Zeitgeber die Trennung der Schaltungen zwischen der anrufenden und der angerufenen Partei auslöst. In neueren Typen von Telekommunikationsdiensten, wie dem dienstintegrierenden digitalen Netzwerk (Englisch: Integrated Services Digital Network, ISDN), wird das Freischalten der B-Partei eingesetzt, jedoch sind die Mechanismen für dessen Ausführung wesentlich verschieden von denen in herkömmlichen POTS-Netzwerken.
Das Bereitstellen von besonderen Teilnehmerdiensten innerhalb herkömmlicher Telekommunikationsvermittlungsstellen erfordert eine erhebliche Aufrüstung der Software von jeder einzelnen, individuellen Vermittlungsstelle, die ihren Kunden derartige besondere Dienste bereitstellen soll. Ein derartiges Aufrüsten von Vermittlungsstellen ist häufig besonders aufwendig und von einem Kosteneffizienzstandpunkt hinsichtlich der zusätzlichen Einkünfte, die durch die zusätzlichen Teilnehmerdienste bereitgestellt werden, nahezu unerschwinglich teuer. Diese Beobachtung trifft um so mehr zu in kleinen Städten oder in ländlichen Gebieten, wo die Nachfrage für besondere Teilnehmerdienste relativ gering ist, und wo die bestehenden Vermittlungsstellen bereits für eine beträchtliche Zeitdauer etabliert sind und die grundlegenden Telekommunikationsbedürfnisse einer Mehrheit der Teilnehmer in diesem Gebiet weiterhin angemessen bedienen.
Das Telekommunikationsgeschäft ist mit wachsendem Wettbewerbsdruck konfrontiert. Die Pro-Minute-Einkünfte von Telekommunikationsbetreibern ist aufgrund einer Anzahl von Faktoren allenthalben ständig geringer geworden. Die Deregulierung der Telekommunikationsdienste hat die Anzahl der Wettbewerber in dem Geschäft vergrößert. Des Weiteren ermöglichen es Neuerungen bzw. Innovationen, wie Rückrufdienste und Telefonkarten, den Benutzern, Kursunterschiede in bilateralen Anrufgebühren zwischen Länderpaaren auszunutzen. Auch haben Kabelfernsehfirmen nun begonnen, über ihre Kabelnetzwerke Telefondienste anzubieten. Schließlich hat innovative Software zwischenzeitlich Vollduplex-Anrufe von hoher Qualität über das Internet möglich gemacht.
Verbesserungen in der Technologie haben auch die Kosten zum Bereitstellen grundlegender Telefondienste verringert. Die Telekommunikationsfirmen können die relativ hohen Tarife, die sie für die Bereitstellung von grundlegenden Telefondiensten erhoben haben, nicht länger rechtfertigen. Verbes serungen der Technologie haben die tatsächlichen Kosten zum Bereitstellen eines Telefonanrufs auf nahezu Null verringert. In wirtschaftlichen Begriffen formuliert können grundlegende Telefondienste als ein Geschäft mit Null Grenzkosten angesehen werden. Die Vorteile, die das Preis-Leistungs-Verhältnis von Desktop-Computern in den letzten Jahren erhöht haben, führen auch zu einer Vergrößerung der Zuverlässigkeit und der Effizienz von modernen Telefonvermittlungsstellen.
Die gleiche Situation trifft auf Wechselverbindungen zu. Aufgrund der Verwendung von Lichtleitfasern wurde den Telefonnetzwerken Kapazität in wesentlichem Umfang hinzugefügt. Es scheint, dass die Bandbreite nicht mehr die knappe Ressource ist, die sie noch vor einigen Jahren war, und in der Tat ist sie eine Handels- bzw. Massenware geworden, die häufig in Großhandelsmengen gekauft und verkauft wird.
Verbesserungen in der Technologie haben auch die Einflüsse des geografischen Abstands zwischen einer anrufenden Partei und einer angerufenen Partei als einen bedeutsamen Faktor in den Kosten zum Bereitstellen eines Telefonanrufs verringert oder eliminiert. Es ist argumentiert worden, dass es hinsichtlich der Netzwerkressourcen nicht mehr kostet, von Stockholm nach Dallas anzurufen (ein Abstand von etwa 8.000 Kilometern), als es kostet von Dallas nach Austin anzurufen (ein Abstand von etwa 300 Kilometern).
Das explosive Anwachsen des Internets ist zu einem großen Teil zuzuschreiben an die Ausnutzung der Tatsache, dass es sein zu Grunde liegendes TCP/IP-Protokoll ermöglicht, dass die Mail-Nachrichten verschickt werden und Dateiübertragungen unabhängig von den dabei beteiligten Übertragungsabständen ausgeführt werden können.
Trotz der Tatsache, dass die Bereitstellung eines Ferndienstes nicht viel mehr kostet als die von lokalen grundlegenden Telefondiensten, berechnen die Telekommunikationsbetreiber weiterhin für Telefon-Fernanrufe mehr als für lokale Anrufe. Die Zunahme des Wettbewerbs in der Telekommunikationsindustrie wird diese Situation sehr wahrscheinlich zunehmend untragbar machen. Weil Ferngespräche traditionell eine bedeutende Quelle der Betriebsgewinne der Telekommunikationsfirmen gewesen sind, ist es zunehmend offensichtlich geworden, dass die Telekommunikationsfirmen neue Quellen von Einnahmen finden müssen.
Ein Weg, mit dem die Telekommunikationsbetreiber die Einnahmen bzw. Gewinne vergrößern können, ist durch das Anbieten an die Teilnehmer von weiterentwickelnden Diensten, für die die Teilnehmer bereit wären, eine Prämie zu bezahlen. Wie oben beschrieben, machte das Hinzufügen von neuer Funktionalität zu einem Netzwerk in den Netzwerkarchitekturen der Vergangenheit es notwendig, dass die Kern-Software der Vermittlungsstelle umgeschrieben werden musste – ein aufwendiger und langwieriger Vorgang, der auch das zusätzliche Risiko des Einbringens von neuen Fehlern in das System mit sich brachte. Weiterhin muss jede Vermittlungsstelle in dem Netzwerk mit der neuen Software aufgerüstet werden, was die Kosten zum Einführen neuer Dienste weiter vergrößert bzw. erhöht. Die Telekommunikationsbetreiber sind nicht länger bereit, einen derartigen Zustand zu tolerieren. Es gibt große Geschäftschancen für einen Hersteller von Telekommunikationsgeräten, der ein Produkt als erster auf den Markt bringen kann.
Telekommunikationsbetreiber haben einen Bedarf für schnellere und weniger teure Verfahren für die Einführung von neuen Diensten in ihre Telekommunikationsnetzwerke ausgedrückt. Weiterhin haben sie gewünscht, dass der Einfluss von neuer Funktionalität auf nur eine oder nur einige weni ge Vermittlungsstellen begrenzt sein sollte. Es ist auch als wünschenswert empfunden worden, dass Dienstverwaltungsaufgaben, wie die Installation, dazu fähig sein sollten, von einer zentralen Verwaltungseinrichtung aus durchgeführt zu werden.
Es ist auch gewünscht worden, dass der Entwurf und die Einführung der neuen Dienste von den Telekommunikationsbetreibern anstatt von den Geräteherstellern ausgeführt werden sollte. Dies würde es den Telekommunikationsbetreibern ermöglichen, rasch auf wahrgenommene Marktanforderungen zu reagieren und würde ihren Kunden effektiver und effizienter dienen. Es ist auch als wünschenswert empfunden worden, eine größere Intelligenz in die Vermittlungsstellensoftware einzubauen, um zu ermöglichen, dass mehrere Dienste mit den Teilnehmern interagieren. Auf diese Weise kann das Telefongerät zu einer weiterentwickelten Schnittstelle mit dem Telekommunikationsnetzwerk werden.
Das Intelligente Netzwerk (IN) ist als eine Lösung vorgeschlagen worden, um den obigen Anforderungen zu entsprechen. Die IN-Technologie ist so entworfen, dass sie es einem Telekommunikationsbetreiber ermöglicht, seinen eigenen Satz von besonderen bzw. unikalen Diensten zu entwerfen oder um bestehende Dienste an bestimmte Kundenanforderungen anzupassen. Ferner erlaubt es die IN-Architektur, den Einfluss der Installation von neuen Diensten auf einige Steuerknoten zu beschränken.
Ein anderes Entwurfsmerkmal der IN-Architektur ist seine zentrale Verwaltung der Dienste. Dies verbessert die Antwortzeit und verringert den Personal-Overhead, der zum Betreiben des Netzwerks erfordert wird. Weiterhin erlaubt die IN-Architektur die Kundensteuerung von einigen kundenspezifischen Daten.
Beispielsweise bieten einige Telekommunikationsbetreiber "persönliche Nummer"-Dienste. Der persönliche Nummerndienst bezieht das Herausgeben einer spezifischen Telefonnummer an jeden Teilnehmer mit ein, normalerweise eine, der eine "Ortsvorwahl" von 500 vorangestellt ist. Die Entwurfsphilosophie hinter dem persönlichen Nummerndienst ist es, die Unmenge von Kontaktnummern für jeden Teilnehmer durch nur eine einzige Telefonnummer zu ersetzen. Dann wird, wenn jemand die persönliche Nummer eines Teilnehmers wählt, die Vermittlungsschaltstelle eine zentrale Datenbank abfragen und eine Liste von all denjenigen Telefonnummern, unter denen ein Teilnehmer möglicherweise erreicht werden kann, einholen. Die Schaltstelle wird dann jede dieser Nummern in einer vorbestimmten Reihenfolge anrufen, bis der Anruf beantwortet wird.
In einer Variante dieses Dienste kann einem Teilnehmer die Möglichkeit bereitgestellt werden, die Kontaktnummern-Datenbank von jedem beliebigen Telefongerät dynamisch zu aktualisieren. Eine derartige Kundensteuerung kann es einem Teilnehmer ermöglich, die Nummer eines Hotels oder eines anderen Ortes, wo er oder sie sich vorübergehend aufhalten möchte, hinzuzufügen.
Die Entwurfsphilosophie hinter der IN-Architektur ist es, die Produkteinführungszeit für die Bereitstellung von neuen Diensten zu verringern, die Kosten für die Entwicklung und Verwaltung zu reduzieren, und die sich aus der Bereitstellung von Premiumdiensten ableitenden Gewinne zu erhöhen. Das klassische Beispiel eines IN-Dienstes ist die Verwendung einer einzigen gewählten Nummer (der B-Nummer) von Kunden, die ein großes geografisches Gebiet überdecken, wobei die Nummer zu einer aus einer Vielzahl von regionalen Dienstzentren umgeleitet wird. So kann ein Pizzafranchise eine einzige Telefonnummer zum Bestellen von Pizzas bekannt machen. Wenn ein Kunde die bekannt gemachte Nummer wählt, kann der IN-Dienst auf der Grundlage der Nummer des wählenden Teilnehmers (der A-Nummer) den Anruf zum nächstgelegenen Franchisenehmer umlenken.
Eine kurze Vorgeschichte des IN
Das Konzept für das Intelligente Netzwerk entstand in den Vereinigten Staaten. Die ursprüngliche Absicht war es, eine zentrale Datenbank bereitzustellen für die Übersetzung einer einzigen gewählten Nummer in eine andere abschließende bzw. Anschluss-Nummer. Eine der frühesten Anwendungen von IN-Diensten war das Bereitstellen von gebührenfreien Anrufen ("Free Phone").
Gebührenfreie Nummern entsprechen nicht direkt einer physikalischen Telefonleitung, sondern müssen in einen tatsächliche Anschluss bzw. eine Anschlussnummer übersetzt werden. Die Übersetzung kann vom Ort des Anrufers und von der Tageszeit abhängig sein.
Ein neues Signalisierungssystem, genannt Signalisierungssystem Nr. 7 (SS7) wurde zum Ermöglichen von Hochgeschwindigkeitskommunikation zwischen Telefonvermittlungsstellen vor und während des Anrufaufbaus entwickelt. Das SS7-Protokoll ermöglichte zum ersten Mal die schnellen Abfragen in der Datenbank, die für die Einführung des gebührenfreien Anrufens benötigt werden. Nach der Entwicklung der SS7-Technologie wurde es möglich, Daten nahezu unverzögert über ein Telefonnetzwerk auszutauschen. Das war der Ursprung des Intelligenten Netzwerks.
Der nächste Schritt in der Revolution des IN war es, von statischen Datenbanken überzugehen auf dynamische, die die Kundensteuerung von kundenspezifischen Daten erlaubten. Zusätzliche Interaktivität konnte ermöglicht werden, als Teilnehmer den Ablauf eines Anrufs durch Tastenfeld-Interaktion vom Gerät des Teilnehmers steuern konnten. Ein derartiges interaktives IN wird in den Vereinigten Staaten als das weiterentwickelte Intelligente Netzwerk (Englisch: Advanced Intelligent Network, AIN) bezeichnet.
Die heutige Entwicklung und das Interesse an der IN-Architektur wird durch einige Anwendungen im großen Rahmen getrieben. Zwei derartige Anwendungen sind der universelle persönliche Nummern- (Englisch: Universal Personal Number, UPN) Dienst und der virtuell persönliche Netzwerk- (Englisch: Virtual Private Network, VPN) Dienst. In dem UPN-Dienst wird eine einzigartige Nummer für jedes Individuum anstatt für ein Telefongerät zugewiesen. Die UPN-Nummer kann verwendet werden, um einen Teilnehmer zu erreichen unabhängig von seinem oder ihrem Ort oder dem Netzwerktyp (ob fest oder mobil).
Der VPN-Dienst ermöglicht, dass ein privates Netzwerk unter Verwendung öffentlicher Netzwerkressourcen aufgebaut werden kann. So könnte ein Unternehmen ein Konzern-Telefonnetzwerk aufweisen, das es jedem seiner Angestellten ermöglicht, mit jedem anderen zu kommunizieren, ohne in die für die Bereitstellung eines physikalischen privaten Netzwerks benötigte Hardware oder Software zu investieren. Durch Implementierung eines VPN-Dienstes unter Verwendung des öffentlichen Netzwerks kann ein Firmenkunde auch die Kosten zur Unterhaltung eines physikalischen Netzwerks vermeiden.
Unzulänglichkeiten des derzeitigen IN-Systems
Die Verwendung der intelligenten Netzwerk (IN)-Architektur wurde als eine Lösung zum Beschleunigen der Aufnahme und Auslagerung von neuen Netzwerkmöglichkeiten und Netzwerkdiensten vorgeschlagen. Die derzeitigen festgelegten Stan dards zum Implementieren von IN-Konzepten leiden unter einer Anzahl von Mängeln.
Beispielsweise können Teilnehmer ankommende, nicht-Anrufbezogene Nachrichten, wie elektronische Post (E-Mail), Papiernachrichten, Nachrichten im Kurznachrichtendienst(Englisch: Short Message Service, SMS) Format, usw. empfangen. Herkömmlich wurde jede dieser Nachrichtentypen unterschiedlich behandelt und sie wurden an den beabsichtigten Empfänger durch eine für diesen Nachrichtentyp spezifische Mailbox ausgeliefert. Daher muss ein Teilnehmer eine Facsimile Nachrichten-Mailbox kontrollieren um zu ermitteln, ob irgendwelche Facsimile Nachrichten empfangen worden sind und seiner Aufmerksamkeit bedürfen, und davon unabhängig zusätzlich seine Mailbox für elektronische Postnachrichten überprüfen, um festzustellen, ob irgendwelche E-Mail Nachrichten ungelesen verbleiben, etc.
Dienstanbieter haben herausgefunden, dass es Teilnehmer wünschen würden, dass einlaufende Nachrichten, die in einer Vielzahl von erlaubten Eingabeformaten empfangen werden, vor der Auslieferung an den Teilnehmer von einem Medium in ein anderes übersetzt oder umgewandelt werden. Jeder Teilnehmer kann eine andere Präferenz bzw. Priorität bezüglich des Formats, in dem seine oder ihre einlaufenden Nachrichten ausgeliefert werden sollten, aufweisen. So möchte beispielsweise ein Teilnehmer A jedes Mal eine E-Mail Benachrichtigung empfangen, wenn er oder sie eine Facsimile-Übertragung empfängt oder möchte den Inhalt der Facsimile-Übertragung für ihn vorgelesen haben oder in seiner Sprach-Mailbox für eine spätere Abfrage und Durchsicht gespeichert haben.
Wenn ein Telekommunikationsdienstanbieter in der Lage wäre, die Benachrichtigungs- und Auslieferungs-Präferenzen eines jeden Teilnehmers zu speichern und vielleicht selbst die interaktive Auswahl eines bevorzugten Empfangsformats durch einen Teilnehmer zu ermöglichen, dann wäre der Dienstanbieter in der Lage, dem Teilnehmer zusätzlichen bzw. verbesserten Wert bereitzustellen und so zusätzliche Einkünfte zu erlangen.
Es ist daher in hohem Maße wünschenswert, in der Lage zu sein, einige Mittel innerhalb eines intelligenten Netzwerksystems bereitzustellen, zum Umwandeln von Nachrichten, die in einem Medium empfangen werden, in ein anderes Medium, auf der Grundlage von abgespeicherten Kundenpräferenzen oder interaktiven Dialogen mit einem Teilnehmer. Dies wiederum erfordert ein System und ein Verfahren zum Empfangen, Speichern, Umwandeln und Weiterleiten von nicht-Anrufbezogenen Nachrichten von einem Medium in ein anderes.
Ein Beispiele aus dem Stand der Technik ist beispielsweise die Publikation HOCHREUTER: "ISDN-TK-System integriert Telefax-, Teletex und PC-Kommunikation", NTZ NACHRICHTEN TECHNISCHE ZEITSCHRIFT, Ausgabe 45, Nr. 5, Mai 1992 BERLIN DE, Seiten 340–347, XP000300863, in der integrierte Hicom-Telekommunikationsdienste, TCS, beschrieben werden. Es werden Merkmale von TCS besprochen, einschließlich Zwischenspeicherung von Telefax und Teletex Dokumenten, Verwendung von Telefax-Endgeräten für Teletex Funktionen, garantierte Sicherheit für ankommende Information durch Zwischenspeicherung in persönlichen Mailboxen usw. Auch werden TCS-Server-Eigenschaften und Anwendung für Telefax, Teletex und PC-Kommunikation über neutrale Datenkommunikationsschnittstellen beschrieben. Der Server befähigt Standard-PCs zum Senden und Empfangen von Telefax- und Teletex-Dokumenten unter Verwendung des Telefon-Endgeräts.
Zusammenfassung der Erfindung
Es ist daher eine primäre Aufgabe der vorliegenden Erfindung, die leichte Umwandlung einer Nachricht, die in einem Medium empfangen wird, in ein zweites Medium zu ermöglichen. Eine Ausführungsform der vorliegenden Erfindung ist in einem IN (Intelligentes Netzwerk) Telekommunikationssystem umfassend eine Vielzahl von IPs (Intelligente Peripheriegeräte), die über ein Netzwerk an ein SCP (Dienststeuerungsknoten, Englisch: Service Control Point) angeschlossen sind. Die Vielzahl von IPs ist ferner jeweils miteinander verbunden.
In einer Ausführungsform der vorliegenden Erfindung wird eine erste Nachricht in einem ersten Medium von einem Empfänger-IP empfangen. Diese empfangene erste Nachricht wird dann von dem Empfänger-IP zu einem Umwandlungs-IP transportiert. Die transportierte erste Nachricht wird danach in dem Umwandlungs-IP in eine zweite Nachricht in einem zweiten Medium umgewandelt. Die umgewandelte zweite Nachricht wird dann über den Telekommunikationsbackbone zu einem Lieferungs-IP transportiert.
Schließlich wird die umgewandelte zweite Nachricht an den beabsichtigten Empfänger der Nachricht in dem zweiten Medium beliefert.
Kurze Beschreibung der Zeichnungen
Ein vollständigeres Verständnis des Verfahrens und des Systems nach der vorliegenden Erfindung kann durch Verweis auf die folgende ausführliche Beschreibung der bevorzugten Ausführungsform im Zusammenhang mit den beigefügten Zeichnungen erhalten werden. Für die Zeichnungen gilt:
1 ist ein veranschaulichendes Schaubild, das ein konzeptuelles Modell eines standardmäßigen Intelligenten Netzwerks (IN) zeigt;
2 zeigt die Komponenten eines beispielhaften einfachen Intelligenten Netzwerks;
3 zeigt den Aufbau eines dienstunabhängigen Funktionsbausteins (Englisch: Service Independent Building Block, SIB);
4 zeigt die Zuordnung der verschiedenen IN-Funktionseinheiten zu physikalischen Einheiten;
5 zeigt ein Beispiel einer IN-Implementierung mit Dienstknotenpunkten auf einer Transitstufe;
6 zeigt die bevorzugte Methodologie zum Implementieren verschiedener Dienste in dem konzeptuellen IN Modell;
7 veranschaulicht die zwei Herangehensweisen zum Implementieren eines API;
8 zeigt ein Verfahren zum Definieren von persönlichen Agenten, die Dienstlogikprogramme (Englisch: Service Logic Programs, SLPs) benutzen;
9 zeigt eine Ausführungsform des netzwerkenden IP (NIP)-Systems und Verfahren nach der vorliegenden Erfindung;
10 ist ein Übersichtsablaufdiagramm, das den Fluss von Nachrichten zwischen den verschiedenen logischen Einheiten nach der vorliegenden Erfindung veranschaulicht;
11 ist ein Abfolgediagramm, das den Ablauf des "Mailbox Status Bericht"-Befehls veranschaulicht;
12 ist ein Abfolgediagramm, das den Ablauf des "Mailbox Status Abfrage"-Befehls, wenn der SCP eine kurze Information über den Mailboxstatus abfragt, veranschaulicht;
13 ist ein Abfolgediagramm, das den Ablauf des "Mailbox Status Abfrage"-Befehls veranschaulicht, wenn der SCP ausführliche Information über den Mailboxstatus abfragt;
14 ist ein Abfolgediagramm, das den Ablauf des "Mailbox Status Abfrage"-Befehls veranschaulicht, wenn ein Teil nehmer eine kurze Information über den Mailboxstatus abfragt;
15 ist ein Abfolgediagramm, das den Ablauf des "Mailbox Status Abfrage"-Befehls veranschaulicht, wenn ein Teilnehmer ausführliche Information über den Mailboxstatus abfragt;
16 zeigt das Abfolgediagramm, wenn der SCP einen IP anweist, eine Nachricht zur Umwandlung zu holen;
17 zeigt das Abfolgediagramm, wenn der SCP einen Umwandlungs-IP anweist, eine Nachricht umzuwandeln;
18 zeigt das Abfolgediagramm, wenn der SCP den Lieferungs-IP anweist, eine umgewandelte Nachricht vom Umwandlungs-IP zu holen;
19 zeigt das Abfolgediagramm, wenn der SCP den IP anweist, eine umgewandelte Nachricht an einen Teilnehmer zu liefern;
20 zeigt den endlichen Automaten für den SCP während des Funktionsablaufs nach der vorliegenden Erfindung; und
21 zeigt den endlichen Automaten für den IP während des Funktionsablaufs nach der vorliegenden Erfindung.
Ausführliche Beschreibung
Die vorliegende Erfindung stellt eine Lösung bereit für eine Reihe von Problemen im Zusammenhang mit der Umwandlung und Lieferung von Nachrichten, die in einem Medium, wie Elektronische Post (E-Mail) Nachrichtenformat, Facsimile-Format oder im SMS (Kurznachrichtendienst, Englisch: Short Message Service)-Format an Teilnehmer, die wünschen, die Nachrichten in einem anderen Format zu empfangen, geliefert werden. Die Erweiterungen des IN-Konzepts, die in dieser Anmeldung offenbart und beschrieben werden, können auch in anderen Telekommunikationskontexten eingesetzt werden, und können auch die Bereitstellung von damit zusammenhängenden zusätzlichen Teilnehmerdiensten ermöglichen.
Intelligente Netzwerk (IN)-Architektur
Ein Intelligentes Netzwerk ist eine Telekommunikationsnetzwerkarchitektur, die Flexibilität bereitstellt zum Erleichtern der Einführung von neuen Möglichkeiten und Diensten in ein Netzwerk, wie das öffentliche geschaltete Fernsprechnetz (Englisch: Public Switched Telecommunications Network, PSTN) oder ein öffentliches Landmobilfunknetzwerk (Englisch: Public Land Mobile Network, PLMN). Beispiele derartiger neuer Fähigkeiten und Dienste umfassen das gebührenfreie Anrufen ("Free Phone"), Kreditkartendienste und virtuelle private Netzwerke (Englisch: Virtual Private Networks, VPN).
IN verkörpert die Träume des ungebündelten Netzwerks der Zukunft, in dem den Dienstanbietern und den Benutzern eine Freiheit gegeben wird, um die Netzwerkdienste unabhängig von Zugang, Vermittlungs- bzw. Schaltungstechnologie und Netzwerkanbietern, zu personalisieren. Eine Ansicht eines internationalen Konsens von IN wird in den ITU-TS-Empfehlungen Q.1200 beschrieben.
Die Einzelheiten der IN-Architektur sind in den ITU-Empfehlungen I.312/Q.1201 der internationalen Telekommunikationsunion spezifiziert worden, die auch eine verbale Erklärung des konzeptuellen Modells des IN (INCM, Englisch: IN-conceptual model) enthalten, wie in 1 gezeigt. Das konzeptuelle Modell von ITU's IN analysiert und systematisiert die verschiedenen, mit der Anrufbearbeitung zusammenhängenden Aufgaben und Abläufe sowie die Bereitstellung von Diensten in vier Ebenen: eine Diensteebene 101, eine allgemeine Aufgabenebene 102, eine verteilte Aufgabenebene 103 und eine physikalische Ebene 104.
Bisher wurde IN konzentriert auf eine Gruppe von Diensten, die im folgenden als Nummerndienste bezeichnet werden, beispielsweise gebührenfreies Anrufen ("Free Phone"), Kreditkartenanrufen, persönliche Nummerndienste, Televoting usw. Ein Schlüsselmerkmal all dieser Dienste ist, dass sie Dienste an Nummern, die von den Netzwerkanschlüssen in den Anschluss- bzw. Zugangsknoten entbündelt sind, anbieten. Jeder beliebige Knoten in dem Telekommunikationsnetzwerk kann durch die Hinzufügung einer Dienstschaltungsfunktion (Englisch: Service Switching Function, SSF) und/oder besonderer Ressourcenfunktionen (Englisch: Special Resource Function, SRF), beide unter Steuerung einer Dienststeuerungsfunktion (Englisch: Service Control Function, SCF) über eine Dienst-unabhängige Protokollschnittstelle, zu einem Dienstknoten gemacht werden. Die SCF wird unterstützt durch eine Dienstdatenfunktion (Englisch: Service Data Function, SDF), die physikalisch von dem Knoten entbündelt sein kann.
Die Hauptfunktionsbausteine des IN sind die SSF, die SCF, die SDF und die SRF. Die SRF wird im Folgenden auch als das logische Intelligente Peripheriegerät (logisches IP) bezeichnet. Jeder dieser Funktionsbausteine ist eine gesonderte logische Einheit, die physikalisch, logisch oder in anderer Weise mit den anderen Einheiten des Telefonnetzwerks integriert sein kann, aber nicht muss. Die physikalischen und logischen Einheiten werden in der folgenden Beschreibung der bevorzugten Ausführungsform austauschbar als eine angesprochen.
Die IN-Architektur unterteilt den grundsätzlichen Anrufprozess in diskrete, streng definierte Schritte, die den Telekommunikationsdienstanbietern und -Teilnehmern die Möglichkeit zum Beeinflussen des Anrufablaufs geben. Die Komponenten eines einfachen Intelligenten Netzwerks 200 wird in 2 dargestellt. Die Standardarchitektur des Intelligen ten Netzwerks weist definierte, verschiedene Komponenten des IN sowie die Schnittstellen zwischen den einzelnen Komponenten auf.
Wenn ein Anruf für einen IN-Dienst getätigt wird, wird der Anruf zunächst zu einem besonderen Knoten in dem Netzwerk geleitet, der der Dienstschaltungspunkt (Englisch: Service Switching Point, SSP) genannt wird. Wenn der SSP den ankommenden Anruf als einen IN-Anruf erkennt, dann wird die gesamte weitere Verarbeitung des Anrufs unterbrochen, während der SSP den Dienststeuerungspunkt (SCP), einen anderen Knoten im IN-System, darüber informiert, dass ein IN-Anruf empfangen worden ist.
Der SCP stellt in dem "Intelligenten Netzwerk" die "Intelligenz" bereit. Der SCP steuert alles, was mit einem IN-Anruf passiert und trifft alle Entscheidungen bezüglich der Anrufbearbeitung. Wenn der SCP die angemessene Aktionen, die mit dem Anruf ausgeführt werden sollen, bestimmte, dann schreibt der SCP dem SSP vor, die notwendigen Aktionen auszuführen.
Die Dienststeuerungsfunktion (SCF) enthält die Logik eines IN-Diensts und trägt die vollständige Verantwortlichkeit für das Treffen von Entscheidungen, die mit einem diesen Dienst einbeziehenden Anruf zusammenhängen. Diese Dienstlogik kann auf jeder beliebigen Telekommunikationsplattform (z.B. Ericsson's AXE-Plattform oder UNIX) ablaufen. Der Knoten (d.h. die physikalische Hardware und die Software), die die SCF enthalten, wird Dienststeuerungspunkt (Englisch: Service Control Point, SCP) 201 genannt.
Die für den jeweiligen Dienst benötigten Daten (z.B. die Liste der Teilnehmertelefonnummern) wird von der Dienstdatenfunktion (Englisch: Service Data Function, SDF) bereit gestellt. In einer Implementierung der IN-Architektur, werden die für die Dienste benötigten Daten in dem SCF selbst gespeichert. Formal wird die Funktion des Speicherns der mit dem Dienst zusammenhängenden Daten der SDF zugewiesen, die Daten auf Anfrage der SCF bereitstellt. In einer typischen IN-Implementierung kann das SDF eine UNIX-Maschine sein, die ein kommerziell erhältliches Datenbankprogramm, wie Sybase, laufen lässt. Der physikalische Knoten, der die SDF enthält, wird als Dienstdatenpunkt (Englisch: Service Data Point, SDP) 202 bezeichnet.
Die normalen Anrufbehandlungs- und Überwachungsfunktionen einer Vermittlungsstelle werden durch die Anrufsteuerungsfunktion (Englisch: Call Control Function, CCF) ausgeführt. Während die CCF nicht formal Teil der Standard IN-Architektur ausmacht, stellt die CCF dem IN Information über Anrufe zur Verfügung und führt auch Anweisungen, die von der SSF empfangen worden sind, aus.
Die Dienstschaltungsfunktion (SSF) interpretiert die von dem SCF gesendeten Anweisungen und leitet die auszuführenden Befehle an die CCF weiter. Die SSF empfängt von dem CCF auch Anrufereignis-Daten (z.B. den Aufgelegt/Abgehoben-Status eines Teilnehmers oder eine Teilnehmerlinie, die besetzt ist) und leitet die Daten zu der SCF. Der physikalische Knoten (d.h. die Schnittstellenhardware und – software), die das SSF enthalten, werden als Dienstschaltungspunkte (Englisch: Service Switching Point, SSP) 204 und 205 bezeichnet.
Die spezialisierte Ressourcenfunktion (Englisch: Special Resource Function, SRF) stellt bestimmte Ressourcen für die Verwendung in IN-Diensten bereit, beispielsweise DTMF (Englisch: Dual Tone Multiple Frequency, Multifrequenz-Dualton) -Zahlenempfang, -Ankündigungen und Spracherkennung. In den ITU IN-Empfehlungen kommuniziert die SRF direkt mit der SCF. In einer anderen Implementierung des IN kann die Funktionalität der SRF am gleichen Ort wie die SSF angeordnet sein. In diesem Fall kommuniziert die SRF nicht direkt mit der SCF, sondern über die SSF. Die SRF ist in 2 nicht gezeigt.
Die Dienstverwaltungsfunktion (Englisch: Service Management Function, SMF) 207 verwaltet die Wartung der IN-Dienste, z.B. das Hinzufügen oder Entfernen von Daten oder die Installation oder die Revision von Diensten. Die Diensterzeugungumgebungsfunktion (Englisch: Service Creation Environment Function, SCEF) 207 ermöglicht, dass ein IN-Dienst entwickelt, getestet und in die SMF eingegeben werden kann. In einer Implementierung des IN sind die SMF und die SCEF in einer Einheit kombiniert und werden Dienstverwaltungsanwendungssystem (Englisch: Service Management Application System, SMAS) genannt. Die SMAS-Anwendung ist Teil der TMOS-Familie und läuft unter dem UNIX-Betriebssystem. Sie ermöglicht, dass Dienste unter Verwendung einer graphischen Schnittstelle entworfen werden können, und stellt geeignete Formulare für die Eingabe von Service- bzw. Dienstdaten bereit.
2 zeigt einen beispielhaften SCP 201, der mit einem SDP 202 und SSPs 204 und 205 verbunden ist. Der SCP ist auch mit einem SMF/SCEF 207 verbunden. All diese Verbindungen, die von und zu dem SCP 201 laufen, werden in 2 als gestrichelte Linien gezeigt, um anzudeuten, dass diese keine Sprachverbindungen sind. Die SDP 202 ist auch mittels einer Nicht-Sprach-Verbindung mit dem SMF/SCEF 207 verbunden. Die SSP 204 ist mit zwei lokalen Vermittlungsstellen (Englisch: Local Exchanges, LEs) 223 und 224 und mit einer Transitvermittlungsstelle (Englisch: Transit Exchange, TE) 211 verbunden. Die Transitvermittlungsstelle 211 ist ihrerseits mit zwei anderen lokalen Verbindungsstellen 221 und 222 verbunden. Der SSP 205 ist mit der lokalen Vermitt lungsstelle 225 verbunden. Die lokalen Vermittlungsstellen 223 und 224 sind in 2 so gezeigt, dass sie mit einem beispielhaften, Anruf-erzeugenden Teilnehmer T-A 231 sowie mit einem beispielhaften, Anruf-erhaltenden Teilnehmer T-B 232 verbunden sind.
Wenn jede der logischen Funktionsbausteine des IN auch physikalische Einheiten sind, werden in der vorher beschriebenen Notation die entsprechenden physikalischen Knoten als Dienstschaltungspunkt (SSP), als Dienststeuerungspunkt (SCP), als Dienstdatenpunkt (SDP) und als physikalisches Intelligentes Peripheriegerät (IP) bezeichnet. Wie oben gesagt, wird in der folgenden Darstellung der Ausdruck IP allgemein benutzt, um sowohl eine logische IP als auch eine physikalische IP zu bezeichnen.
Der Benutzeragent wird in der SCF identifiziert durch die Nummer der anrufenden oder der angerufenen Partei, und wird mit einbezogen, wenn ein ausgestatteter Einsatzpunkt in dem Dienstknoten getroffen wird. Signalisierungsdaten und Anrufzustandsdaten können durch den Benutzeragenten eingestellt bzw. bearbeitet werden. Die SRFs sind fähig zu In-Band-Kommunikation mit den Benutzern oder miteinander, um die Beschränkungen in den herkömmlichen Signalisierungssystemen zu überwinden.
Derzeitige IN-Standards nehmen an, dass der besuchte Ort und der Heimatort eines Teilnehmers am gleichen Ort angeordnet und von dem Netzwerk-Zugangsknoten und dem Dienstknoten möglicherweise entbündelt sind. Obwohl die Trennung der Netzwerkanschluss- und der Dienstknotenfunktionen die Kosten für die Diensteinführung verringern, resultiert dies in möglicherweise nicht gewollten Interaktionen zwischen den Netzwerkanschlussdiensten und den Nummern-basierten Diensten. Eine Verbesserung der Zugangsknoten für einen Dienstknoten wird daher benötigt, um beim Entwurf von Diensten Flexibilität bereitzustellen.
Eine Alternative wäre es, zwei entfernte, tauschbare persönliche Telekommunikationskategorien zu den Netzwerkanschlussknoten hinzuzufügen – wobei einer dem Dienstknoten eine unbedingte bzw. bedingungslose Hot-Line-Verbindung für abgehende Anrufe, und der andere dem Dienstknoten eine unbedingte bzw. bedingungslose Anruf-Weiterleitung für auflaufende Anrufe verleiht. Es erscheint längerfristig notwendig, die Funktion des besuchten Orts und des Heimat orts zu trennen, wie in zellularen Netzwerken, wenn die Kosten verringert und die Kapazität verbessert werden soll.
Eine der einzigartigen Merkmale von IN ist, dass Dienste auf der IN-Dienstplattform, auf der Grundlage ihre dienstunabhängigen Funktionsbaueinheiten (SIBs) und nicht direkt in den Netzwerkknoten implementiert werden. Die SIBs sind Teil der SCP. 3 zeigt den Aufbau eines SIB. Jeder SIB 301 ist ein elementares logisches Element in einer Dienstlogik, die die Implementierung vor dem Programmierer versteckt. Wenn bestehende SIBs eine neue Anforderung nicht erfüllen können, werden neue SIBs definiert. Wie gezeigt, empfängt die SIB 301 eine logische Eingabe 311, erzeugt logische Ausgaben 312, empfängt SIB-Unterstützungsdaten 321 und empfängt und erzeugt Anrufvorgangsdaten 322.
In IN-Produkten führen die SIBs 301 Funktionen aus, wie die Analyse von Signalisierungsinformation, Kontrolle der Verbindungstopologie, Interaktion mit dem Benutzer, Lesen und Schreiben von Daten, Sammeln und Ausgabe von Anrufdaten etc. Andere SIBs sind reine Sprachelemente, wie Sprünge, Gehe-zu-Unterprogramme, Schleifen, Übergaben, usw. Jeder SIB 301 ist in der Dienstplattform verfügbar. Dienstlogikprogramme (SLPs) werden von den SIBs 301 gebaut und verweisen auf diese durch ihre Namen. Dienstlogik kann unter Ver wendung einer Diensterzeugungs-Umgebungsfunktion (Englisch: Service Creation Environment Function, SCEF) entworfen werden. Die SIBs 301 werden dem SCEF durch eine systemunabhängige Anwendungsprogrammierungs-Schnittstelle (Englisch: Application Programming Interface, API) zur Verfügung gestellt.
Die Abbildung der verschiedenen funktionellen Einheiten des IN in physikalische Einheiten oder Entitäten wird in 4 gezeigt, wo die Erfindung bzw. der Suffix "F" für die verschiedenen funktionalen Entitäten und der Suffix "P" für physikalische Entitäten steht. In 4 bezeichnet das Akronym SMF die Dienstverwaltungsfunktion und das Akronym CCF die Anrufsteuerfunktion.
Ein Beispiel einer IN-Implementierung mit Dienstknoten auf dem Transitlevel ist in 5 veranschaulicht. Der in 5 gezeigte Dienstknoten kann von jedem Netzwerkzugangsknoten, z.B. einer lokalen Schaltstelle in PSTN oder ISDN oder einem MSC in einem öffentlichen Landmobilfunknetzwerk (PLMN)-System erreicht werden. Der Dienstknoten kann sowohl persönlicher Telefonie als auch anderen Nummer-basierten Diensten dienen. Benutzeridentitäten und Authentifizierungsinformation kann In-Band zu dem SRF übertragen werden oder in Nummernfeldern der anrufenden oder angerufenen Partei in den Signalisierungssystemen eingebettet sein.
Der persönliche Agent weist Komponenten auf in der Anrufsteuerungsfunktion, CCF (d.h. die Triggerpunkt-Daten), die Dienststeuerungsfunktion, SCF (d.h. die Dienstlogik), und in der Dienstdatenfunktion (SDF) (d.h. die Dienstdaten) auf. Die in 5 veranschaulichten IN-Plattform-Komponenten können entweder in den Netzwerkzugangsknoten integriert sein oder in getrennten Dienstknoten implementiert werden.
Die Rolle der Dienstschaltfunktion (SSF) ist es, zu erkennen, dass ein Anruf einen IN-Dienst hervorruft und dann mit dem SCF zu kommunizieren, um Anweisungen darüber zu empfangen, wie der Anruf abzuarbeiten ist. Die SCF ist, wo sich die Intelligenz des IN befindet, weil sie die zum Ausführen verschiedener Dienste benötigte Logik enthält. Die SDF ist ein Datenbanksystem, das die für die datenintensiven zusätzlichen Dienste benötigten Datenspeicherkapazität bereitstellt. Das IP ist das Netzwerkelement, das die Ressourcen für Benutzerinteraktion, wie Sprach-Ankündigungen und -Dialoge, Multifrequenz-Dualton (DTMF)-Empfang und Spracherkennung, bereitstellt.
Die Anwendungsprogrammierungs-Schnittstelle (API) des IN
Das in 1 gezeigte konzeptuelle Modell von ITU's IN definiert auch die Methodik zum Implementieren verschiedener Dienste. Dies ist in 6 gezeigt. Um einen Dienst oder ein Merkmal 601 zu implementieren, werden die Dienstanforderungen zunächst übersetzt in SIB-Strukturen bei 602. Die resultierenden SIBs 603 werden bei 604 verschiedenen funktionalen Einheiten 605 zugeordnet. Die funktionalen Einheiten 605 werden wiederum bei 606 einer oder mehreren physikalischen Einheiten 607 zugeordnet.
Es sei angemerkt, dass anders als in der Praxis aller Nicht-IN-Standards, im IN die Dienstanforderungen nicht direkt in Netzwerkfunktionalität übersetzt werden. Stattdessen werden die Dienstanforderungen in Dienstplattform-Elemente (d.h. SIBs) übersetzt, die wiederum nach dem IN-Drei-Stufen-Modell so implementiert werden, dass sie in dem Telekommunikationsnetzwerk wiederverwendbare Fähigkeiten und Protokollelemente werden.
Es gibt wenigstens zwei mögliche Ansätze zur Implementierung der Anwendungsprogrammschnittstelle (API), die dem in 1 gezeigten konzeptuellen Modell von ITU's IN entsprechen. Ein Ansatz wäre, die Dienstlogik in zwei Teile aufzuspalten: einen festen, logischen Teil und einen flexiblen, logischen Teil. Die SIBs werden dann verlinkt zum Bilden von Entscheidungsdiagrammen, die als Unterprogramme von der festen Logik aufgerufen werden. Die feste Logik kann in einer Standardprogrammiersprache wie C oder C++, usw. ausgedrückt und dann kompiliert werden, und in eine Standardausführungsumgebung geladen werden. Der flexible logische Teil besteht im Gegensatz dazu nur aus austauschbaren Daten.
Der zweite Ansatz wäre, ein Dienst-API zu definieren, welches vollständige Steuerung über alle Aspekte der Logik verleiht, in dem SIBs zum Erzielen der gewünschten Funktion miteinander kombiniert werden. Nach diesem Ansatz kann jeder SIB mit jedem beliebigen anderen SIB verlinkt werden. Einige SIBs führen eine Telekommunikationsfunktion aus, während andere lediglich Elemente in der Logik verlinken. Die gesamte Logik wird ausgedrückt als Daten, die beschreiben, welche SIBs verwendet werden sollen, wie sie verlinkt werden und welche Daten jeder SIB verwenden soll zum Ausüben seiner Funktion. Alle Einzelheiten der Implementierung sind daher für den Dienstprogrammierer versteckt. Dies ist der prinzipielle Ansatz, der in Ericsson's IN-Produkten gewählt wurde.
Die beiden Ansätze zur Implementierung der API sind in 7 veranschaulicht. Der SIB-Plattform-Ansatz ist in 7A gezeigt, und der Dienstlogik-Ausführungsumgebungs (Englisch: Service Logic Execution Environment, SLEE)-Ansatz ist in 7B gezeigt. Der SIB-Ansatz von 7A drückt die gesamte Dienstlogik aus als eine Kombination von elementaren SIB-Funktionen, die in der Dienstplattform zum Bilden von flexiblen Dienstprofilen (Englisch: Flexible Service Profiles, FSPs) zur Verfügung stehen. Der in 7B gezeigte SLEE-Ansatz betrachtet die SIBs als Unterprogramme für die feste Logik, ausgedrückt in einer Programmiersprache wie C, C++, Dienstlogikprogrammen (SLPs), usw. Der kompilierte Code verwendet Plattformprimitive, wie INAP (Intelligente Netzwerkanwendungsabschnitte, Englisch: Intelligent Network Application Parts)-, Operationen- und Datenbankprimitive.
Wenn dieselbe Datendarstellung für die gesamte Logik und Daten verwendet wird, können persönliche Agenten mittels der flexiblen Dienstprofile (FSPs) wie in 8 gezeigt definiert werden. Diese Anordnung bietet eine Anzahl von Vorteilen, beispielsweise zum Ermöglichen, dass verschiedene Logikelemente geladen und ohne den Dienst zu unterbrechen aktiviert werden, und dass im Fall eines Fehlers in einem persönlichen Agenten die betroffenen Zonen nur beschränkt werden auf Anrufe, die die Fehlerfunktion aktivieren.
Die Interaktion von Merkmalen ist bei der Entwicklung von IN-Systemen ein Haupthindernis gewesen. Dieses Problem rührt von der Tatsache her, dass jedes Merkmal normalerweise von anderen Merkmalen abhängt. Es besteht ein Bedarf, derartige Wechselwirkungen aufzulösen, jedoch wurde bisher noch keine Lösung übereingekommen. In der Praxis wurde gefunden, dass Implementierungen bestehender Merkmale häufig betroffen sind und dass viele neu gestaltet oder vollständig blockiert werden müssen, wenn neue Merkmale eingeführt werden sollen. Es sei angemerkt, dass dieses Problem von zwei Ansichtspunkten betrachtet werden kann: vom Netzwerkzentrierten Standpunkt und vom Benutzer-zentrierten Standpunkt bezüglich IN-Systemen.
Die herkömmliche Netzwerk-zentrierte Sicht betrachtet das IN als eine Ergänzung zu anderen Technologien, indem es zusätzliche Dienste zu einem bestehenden Repertoire hinzufügt. Merkmalsinterkation war und ist weiterhin das Hindernis, das verhindert, dass diese Sichtweise eine realistische Alternative darstellt. Jeder neue zusätzliche Dienst ist aus einem festen Dienstlogikteil und möglicherweise einem flexiblen Logikteil zusammengesetzt. Personalisierung ist daher beschränkt auf das, was durch Kombination einer Anzahl von vordefinierten, zusätzlichen Diensten oder Features miteinander erzielt werden kann. Das Hinzufügen eines neuen Dienstes kann langwierige und teure Entwicklungen erfordern, nicht anders als in den Prä-IN-Erfahrungen in PSTN, PLMN und ISDN. Die zentrale Frage bei dieser Sichtweise ist nicht der Entwurf eines neuen Merkmals, sondern liegt bei der Aufgabe der Integration eines neuen Merkmals mit anderen, vorher bestehenden Merkmals.
Im Gegensatz dazu richtet sich die Benutzer-zentrierte Sicht des IN auf die Benutzer, anstatt auf die Merkmale. Im Prinzip wird angenommen, dass die Bedürfnisse von individuellen Benutzern einzigartig sind, wobei der Dienstanbieter in vollständiger Steuerung der gesamten Dienstlogik ist. Der FSP-Ansatz wird angewendet, und das Ergebnis ist, dass dann eine Reihe von einzigartigen Dienstprofilen erzeugt werden kann, indem SIBs wieder benutzt werden, anstatt, dass Merkmale wieder benutzt werden. Dies bedeutet, dass Merkmalsinteraktion aufhört, ein Problem darzustellen, weil keine individuellen Merkmale implementiert werden. In dieser Sichtweise begründet die Wechselwirkung zwischen den SIBs die Dienstlogik.
Wechselwirkung zwischen Dienstprofilen ist bei dieser Ansicht gelöst durch offene Signalisierungsschnittstellen nach dem Halb-Anruf (Englisch: Half-Call) -Modell. Bevor eine vollständige Steuerung von den schrittweise entwickel ten IN-Plattformen in einer wirtschaftlich machbaren Weise bereitgestellt werden kann, ist es als notwendig erachtet worden, einige der bestehenden zusätzlichen Dienste zu verwenden. Es sollte berücksichtigt werden, dass dies ein Kurzweg ist, der zu Wechselwirkungsproblemen führen kann, was in der Zukunft die Verbesserung der IN-Plattformen erfordert.
Das prinzipielle Ziel der Benutzer-zentrierten Sichtweise ist es, die SIBs standardisiert auszuführen, so dass sowohl Dienst-Unabhängigkeit als auch System-Unabhängigkeit und Technologie-Unabhängigkeit erzielt werden. Wenn dies erreicht worden ist, kann ein SIB-basiertes Dienstprofil auf jeder beliebigen kompatiblen Plattform ausgeführt werden, unabhängig davon ob dies ein Schaltprozessor, ein eigenständiger Personal-Computer oder eine Work-Station ist. Das alte Paradigma, allen Teilnehmern die gleichen Merkmale bereitzustellen, wird ersetzt durch Merkmalstransparenz für jeden individuellen Teilnehmer, unabhängig von seinem Zugang.
IN-Signalisierung
Das Intelligente Netzwerkanwendungsabschnitt (INAP)-Protokoll wird zum Signalisieren in IN-Systemen verwendet. Das INAP-Signalisierungsprotokoll ist sowohl durch das Europäische Telekommunikationsstandardinstitut (ETSI) und die Internationale Telekommunikationsunion (ITU) standardisiert worden und umfasst das CCITT-Signalisierungssystem Nr. 7 (CCS7), welches eines, jedoch nicht das einzige Netzwerkprotokoll darstellt, das zur Unterstützung von INAP verwendet werden kann.
Einer der Nachteile des Kerns von INAP, so wie es derzeit spezifiziert (d.h. der IN CS-1 Standard), ist, dass die Kommunikationsmöglichkeiten zwischen den SCF und den IPs lediglich auf Sprache beschränkt sind. Andere Medien wie E-Mail, Facsimile, Daten usw. werden von dem CS-1-Standard derzeit nicht unterstützt. Daher sind nicht-Anruf-bezogene und nicht-Echtzeit-Anruf-bezogene Dienste in dem derzeitigen CS-1-Standard nicht mit eingeschlossen.
Die Implementierung von Netzwerkenden IP (NIP), von der die vorliegende Erfindung ein Teil ausmacht, kann als eine Erweiterung der INAP, die die Abwicklung und Verarbeitung von Nicht-Sprachmedien und die Bereitstellung von nicht-Anrufbezogener Kommunikation zwischen den SCF und den IPs mit einschließt, gekennzeichnet werden. NIP ermöglicht, dass die SCF in vollständiger Steuerung ist von allen Speichern- und-Weiterleiten (d.h. Datentransfer) -Diensten wie Voice Mail, E-Mail, SMS-Nachrichten usw.. Das für die NIP-Implementierung verwendete Protokoll wird im folgenden als NIP-INAP bezeichnet. Das NIP-INAP ist eine Ericssonspezifische Erweiterung des IN CS-1-Standards.
Vernetzte IPs
9 zeigt eine Ausführungsform des vernetzten IP (NIP)-Systems nach der vorliegenden Erfindung. Ein vernetztes IP-System umfasst einen SCP 901, der mit einer Vielzahl von intelligenten Peripheriegeräten (IPs) 911–914 kommunizieren kann. Jedes dieser logischen IPs stellt, wie oben angemerkt, in IN-Terminologie ein SRF dar. Zur veranschaulichenden Vereinfachung werden in 9 nur vier IPs gezeigt: Ein Empfänger-IP, IP_r 911; ein Umwandlungs-IP, IP_c 912; ein Lieferungs-IP, IPd 913 und ein beispielhaftes zusätzliches IP, IP_o 914. Die IPs 911–914 kommunizieren untereinander jeweils über ein Telekommunikations-Backbone-Netz 910, das ein beliebiges Protokoll, beispielsweise TCP/IP, X.25 usw. verwendet.
9 stellt auch eine Übersicht der Funktionsablaufs einer Ausführungsform der vorliegenden Erfindung bereit. Wenn eine erzeugende Einheit 920 über eine optionale Schnittstelle 921 eine Nachricht an das empfangende IP_r 911 schickt, speichert IP_r 911 die empfangene Nachricht und benachrichtigt SCP 901, wie durch den Pfeil 931 gezeigt. Die SCP bestätigt die Benachrichtigung bei 932.
In einer alternativen Ausführungsform der vorliegenden Erfindung fragt der SCP 901 IP_r 911 ab über den Status der Mailbox eines Teilnehmers, wie bei 933 gezeigt, und empfängt von IP_r 911 eine Antwort, wie durch den Pfeil 934 angedeutet. Wenn der SCP 901 Vorkenntnis über die Lieferungspräferenzen bzw. Lieferprioritäten eines Teilnehmers 922 besitzt, dann weist er ein Umwandlungs-IP_c 912 an, die Nachricht von dem Empfänger-IP_r 911 zu holen, wie bei 941 gezeigt. Das Umwandlungs-IP_r 912 kommuniziert dann mit dem Empfänger-IP_r 911 über das Backbone-Netzwerk 910 und ruft die gespeicherte Nachricht ab. Das Umwandlungs-IP_c 912 bestätigt dem SCP 901 die Ausführung des Holen-Befehls bei 942.
Das SCP 901 gibt dann eine Umwandlungs-Anweisung an das Umwandlungs-IP_c 912 bei 943. Das Umwandlungs-IP 912 wandelt dann, basierend auf der Teilnehmerpriorität, die Nachricht aus dem Modus, in dem sie empfangen wurde, um in den Modus, in dem ein Teilnehmer 922 wünscht, dass die Nachricht geliefert wird. Wenn die Umwandlung vollständig ist, benachrichtigt das Umwandlungs-IP_c 912 das SCP 901, wie bei 942 gezeigt.
Nachdem er benachrichtigt worden ist, dass das Medium der Nachricht umgewandelt worden ist, weist das SCP dann das Lieferungs-IP_d 913 an, die umgewandelte Nachricht von dem Umwandlungs-IP_c 912 zu holen, wie bei 951 gezeigt. Das Lieferungs-IP 913 ruft die Nachricht über das Backbone-Netz 910 von dem Umwandlungs-IP_c 912 ab und bestätigt dem SCP 901 die Vervollständigung des Vorgangs, wie bei 952 gezeigt.
Das SCP 901 weist dann das Lieferungs-IP_d 913 an, die Nachricht an den Teilnehmer 922 zu liefern, wie bei 953 angedeutet. Wenn der Teilnehmer aktiv und erreichbar ist, liefert das Lieferungs-IP, IP_d 913 die Nachricht dann aus, wie bei 926 gezeigt. Die Lieferung der Nachricht wird auch dem SCP 901 bestätigt, wie bei 952 gezeigt.
10 ist ein Übersichtsablaufdiagramm, das den Fluss der Nachrichten zwischen den verschiedenen logischen Einheiten nach der vorliegenden Erfindung veranschaulicht. Wie in 10 gezeigt, umfasst der Umwandlungsprozess drei Phasen. In der ersten Phase berichtet das Empfänger-IP, IP_r 911 den Empfang einer Nachricht an das SCP. In der zweiten Phase weist das SCP das Umwandlungs-IP, IP_c 912 an, die Nachricht von dem Empfänger-IP, IP_r 911 abzurufen und die Nachricht von einem Medium in ein anderes umzuwandeln. In der dritten Phase weist das SCP das Lieferungs-IP, IP_d 913 an, die umgewandelte Nachricht von dem Umwandlungs-IP, IP_c 912 abzurufen und sie dem Teilnehmer zu liefern.
Die Kommunikationen zwischen dem SCP und den verschiedenen IPs 911–913 wird in 10 gezeigt unter Verwendung der Notation des Transaktionsleistungsfähigkeitsanwendungsabschnitts (Englisch: Transaction Capabilities Application Part, TCAP), wobei der Nachrichtentyp unterhalb des Pfeils gezeigt wird und die Komponenten der TCAP-Nachricht und die Parameter oberhalb eines jeden Pfeils gezeigt sind. In der ersten Phase, nach dem Empfang einer Nachricht, benachrichtigt IP_r 911 so das SCP 901 unter Verwendung des " Mailbox Status Bericht" (Englisch: Mailbox Status Report") -Befehls bei 1001. Dies wird bei 1002 dem IP_r 911 durch den SCP zurück bestätigt.
In der zweiten Phase, der Nachrichtenumwandlungsphase, gibt das SCP 901 einen "Holen" (Englisch: "Fetch"-) -Befehl an das Umwandlungs-IP, IP_c 912 bei 1003. Das Umwandlungs-IP, IP_c 911 ruft die Nachricht von IP_r 911 ab, wie bei 1004 und 1005 gezeigt, unter Verwendung eines beliebigen Protokolls, das in dem die verschiedenen IPs verbindenden Netzwerk zugelassen ist, beispielsweise TCP/IP, X.25, usw. Bei 1006 signalisiert IP_c 912 an SCP 901 die Vervollständigung des Nachrichtenabrufvorgangs. Das SCP gibt dann den "Umwandeln" (Englisch: "Convert") -Befehl an IP_c 912 bei 1007. Das IP_c bestätigt dem SCP die Vervollständigung des Umwandlungsvorgangs bei 1008, woraufhin das SCP 901 den Dialog mit IP_c 912 abschließt, wie bei 1009 gezeigt.
In der dritten Phase gibt das SCP einen "Holen"-Befehl an das Auslieferungs-IP, IP_d 913 bei 1010, woraufhin das Auslieferungs-IP die umgewandelte Nachricht von IP_c 912 abruft, wieder unter Verwendung eines beliebigen auf dem IP-Netzwerk als gültig angesehenen Protokolls, wie bei 1011 und 1012 gezeigt. IP_d benachrichtigt das SCP, wenn die umgewandelte Nachricht von IP_c geholt worden ist, wie bei 1013 gezeigt. Bei oder vor dem Herstellen der Kommunikation mit dem Teilnehmer gibt das SCP dann einen "Sende-Nachricht" (Englisch: "Send Message") -Befehl an das Auslieferungs-IP, IP_d, wie bei 1014 gezeigt. Das IP_d liefert die Nachricht dem Teilnehmer aus und bestätigt dem SCP diese Tatsache bei 1015, woraufhin das SCP den Dialog mit IP_d abschließt, wie bei 1016 gezeigt.
Ein IN-Teilnehmer kann sich für mehrere Speicher-und-Weiterleitungsdienste, wie E-Mail, Facsimile-Mail, SMS, Voice Mail, usw. anmelden und kann wünschen, dass die Lieferung dieser verschiedenen Nachrichtentypen koordiniert wird. Die verschiedenen Nachrichten, die sich auf die verschiedenen angemeldeten Dienste beziehen, werden in dem IN-Netzwerk gewöhnlich unter verschiedenen physikalischen oder logischen IPs gespeichert. Derzeit sind Umwandlungslösungen zum Ermöglichen, dass verschiedene, an verschiedenen Knoten gespeicherte Nachrichtentypen abgerufen, umgewandelt und in einer verteilten Art geliefert werden, basierend auf einer Teilnehmer-spezifizierten Umwandlungs- und Lieferungspriorität nicht allgemein verfügbar.
Die vorliegende Erfindung stellt eine Lösung bereit zum Umwandeln einer Nachricht von einem Speicher-und-Weiterleiten Medium in ein anderes, und konsequenterweise zum Verschieben von umgewandelten und nicht umgewandelten Nachrichten zwischen verschiedenen IPs, so dass ein Teilnehmer wählen kann, alle oder Teile von seinen oder ihren Nachrichten in einem oder mehreren bevorzugten Medien geliefert zu bekommen.
In einer Ausführungsform der vorliegenden Erfindung werden verschiedene neue Prozeduren bzw. Abläufe in das INAP eingeführt, um die Ausführung der Umwandlung einer Nachricht von einem Speicher-und-Weiterleiten Medium in ein anderes zu unterstützen bzw. assistieren. Derartige neue Prozeduren umfassen: den "Holen"-Befehl, der das SCP befähigt, ein IP anzuweisen, eine Nachricht von einem anderen IP im selben Netzwerk zu holen; den "Umwandeln"-Befehl, der das SCP befähigt, ein IP anzuweisen, eine Nachricht von einem Medium in ein anderes umzuwandeln; und den "Sende Nachricht"-Befehl, der ein SCP befähigt, ein IP anzuweisen, eine identifizierte Nachricht (hier auch eine umgewandelte Nachricht) an einen spezifizierten Zielort zu liefern.
Mailboxen können für mehrere verschiedene Medien existieren, beispielsweise Voice Mail, Facsimile-Mail, E-Mail, SMS usw. In der vorliegenden Offenbarung wird jedes Medium und seine zugeordnete Mailbox als ein logisches IP bezeichnet. Um die von einem Teilnehmer in seiner Mailbox empfangenen Nachrichten zu steuern und um die Benachrichtigung des SCP oder des Teilnehmers, wenn sich der Status der Mailbox ei nes Teilnehmers verändert, zu ermöglichen, ist es für das SCP normalerweise nützlich, über den Status der Mailboxen eines Teilnehmers informiert zu sein.
Derzeit können integrierte Datenübertragungsdienste, die auf verschiedenen physikalischen Knoten implementiert sind, nicht leicht bereitgestellt werden. Eine Ausführungsform der vorliegenden Erfindung stellt eine vernetzte Lösung basierend auf der IN-Architektur bereit, in der ein Protokoll zum Implementieren vereinheitlichter Mail-Lösungen definiert wird.
Ein anderer Aspekt der vorliegenden Erfindung befähigt das SCP, über den Status der Mailboxen eines Teilnehmers laufend auf den neuesten Stand gebracht zu werden. Für diesen Zweck sind neue Prozeduren bzw. Verfahrensabläufe in das NIP-INAP eingeführt worden: der "Mailbox Status Bericht"-(Englisch: "Mailbox Status Report") -Befehl, der ein IP befähigt, das SCF zu benachrichtigen, wenn der Status einer bestimmten Mailbox sich verändert hat; und der "Mailbox Status Abfrage" (Englisch: "Mailbox Status Enquiry") – Befehl, der das SCP befähigt, ein IP über den Status der Mailbox eines bestimmten Teilnehmers in einem bestimmten Medium zu pollen oder abzufragen.
Erweiterungen der INAP-Prozeduren
Wir werden im folgenden die ausführliche Funktion der verschiedenen neuen Prozeduren, die in das NIP-INAP zur Implementierung der bevorzugten Ausführungsform der vorliegenden Erfindung eingefügt worden sind, betrachten. Bevor ein SCP ein IP anweisen kann, eine Nachricht von einem Format in ein anderes umzuwandeln, werden Prozeduren benötigt zum Erleichtern der Benachrichtigung des SCP, wenn eine Nachricht von einem IP empfangen worden ist, und ebenso, um einem SCP zu ermöglichen, den Status der Mailbox eines Teilnehmers positiv festzustellen.
Die "Mailbox Status Report"-Nachricht
Der spontane Bericht eines IP über die Veränderung des Mailboxstatus eines Teilnehmers wird implementiert durch Verwendung des "Mailbox Status Bericht"-Befehls. Wie in 11 gezeigt wird ein Mailbox Status Report von einem Empfänger-IP, IP_r 911 an das SCP 901 bei jeder beliebigen Veränderung des Mailboxstatus gesendet, insofern die Veränderung des Status nicht durch das SCP initiiert oder gesteuert war. Wenn jedoch eine Nachricht in einer Mailbox abgeliefert wird (d.h. sie wird von dem zum Empfangen von Nachrichten in einem bestimmten Medium designierten IP empfangen), dann erzeugt das Empfänger-IP eine "Mailbox Status Bericht"-Nachricht, selbst wenn das SCP sich in Steuerung befindet.
Es sei angemerkt, dass zum Zeitpunkt des Herausgebens dieser Benachrichtigung durch das Empfänger-IP, IP_r 911, ein laufender Dialog zwischen dem SCP 901 und IP_r 911 vorhanden oder nicht vorhanden sein kann. Damit das IP_r 911 diese Nachricht an das SCP herausgibt, muss sich der Status der Mailbox eines Teilnehmers verändern. Nach Empfang dieses Befehls durch das SCP 901 liegt der weitere Ablauf im Ermessen des SCP. Falls gewünscht, kann das SCP ausführliche Information über den Status verschiedener Nachrichten unter Verwendung des unten besprochenen "Mailbox Status Abfrage"-Befehls erhalten.
Die "Mailbox Status Abfrage"-Nachricht
Im Gegensatz zu der "Mailbox Status Bericht"-Nachricht, die von einem IP spontan nach jeder beliebigen Veränderung des Mailboxstatus erzeugt wird, wird die "Mailbox Status Abfrage" (Englisch: "Mailbox Status Enquiry") -Nachricht nur durch positive Aktionen des SCP oder durch positive Abfragen des Teilnehmers über den Status von seiner oder ihrer Mailbox getriggert. Die 12 und 13 zeigen das Ablaufdiagramm, wenn ein SCP ein IP über den Status der Mailbox eines Teilnehmers abfragt. Wenn IP_r 911 eine Veränderung im Mailboxstatus an das SCP 901 unter Verwendung der "Mailbox Status Bericht"-Nachricht, wie oben besprochen, berichtet hat und wenn das SCP 901 wünscht, mehr oder ausführliche Information über die Mailbox oder Mailboxen eines Teilnehmers zu erhalten, dann gibt es zwei mögliche Ergebnisse, wie in 12 und 13 gezeigt.
Eine Abfrage durch das SCP 901 über den Status der Mailbox eines Teilnehmers kann in einem oder zwei Formaten sein, die im folgenden entweder als eine Anfrage für kurze Information oder eine Anfrage für ausführliche Information bezeichnet werden. Eine beispielhafte Anfrage für kurze Information über den Mailboxstatus eines Teilnehmers wäre eine Abfrage von Information über die gesamte Anzahl von neuen Nachrichten in der Mailbox. Eine beispielhafte Abfrage für ausführliche Information über den Mailboxstatus eines Teilnehmers wäre eine Abfrage nach dem Datum, der Zeit und der Länge von jeder Nachricht in der Mailbox.
Wenn das SCP 901 IP_r 911 eine kurze Information über den Mailboxstatus abfragt, wie bei 1201 gezeigt, dann kann IP_r 911 dem SCP 901 das gewünschte Ergebnis ohne Segmentierung des Ergebnisses zurückgeben, wie bei 1202 gezeigt. Ebenso gibt, wenn das SCP IP_r 911 eine ausführliche Information über den Mailboxstatus abfragt und wenn keine ausführliche Information verfügbar ist oder wenn Segmentierung unnötig oder nicht gewünscht ist, das IP_r 911 das Ergebnis in einer einheitlichen (d.h. nicht segmentierten) Nachricht an SCP 901 zurück, wie bei 1202 gezeigt.
Andererseits wenn das SCP 901 IP_r 911 eine ausführliche Information über den Mailboxstatus abfragt und wenn Segmentierung notwendig ist, und wenn derartige Information verfügbar ist, dann sendet IP_r 911 die Information in mehreren Segmenten an SCP 901, wie in 13 gezeigt. Der Vorgang beginnt damit, dass das SCP eine ausführliche Anfrage an das IP_r 911 richtet, bei 1301. Als Antwort sendet IP_r 911 einen Teil des Ergebnisses an das SCP bei 1302 und zeigt (wahlweise) an, dass noch mehr Information verfügbar bleibt. Daraufhin fragt das SCP die verbleibende Information bei 1303 ab. IP_r stellt ein weiteres standardisiertes Rückgabeergebnissegment bei 1304 bereit und zeigt (wahlweise) an, dass noch weitere Information verfügbar bleibt.
Dieser Vorgang wird sukzessive wiederholt, wobei das SCP 901 das IP_r um mehr und mehr Information fragt, wie bei 1305 angedeutet, bis IP_r eine Rückgabe-Ergebniskomponente an das SCP zurückgibt, wie bei 1306 gezeigt, und so anzeigt, dass keine weitere Information über den Mailboxstatus verfügbar ist. Wenn das SCP die verschiedenen Segmente des von dem IP_r zurückgegebenen Ergebnis erhalten, zusammengestellt und analysiert hat, liegen alle weiteren Aktion auf seiner Seite in seinem eigenen Ermessen.
In einer anderen Ausführungsform der vorliegenden Erfindung kann das SCP eine Nachricht an einen bestimmten Empfänger senden oder einen Mailboxbesitzer von den Ergebnissen des "Mailbox Status Abfrage"-Befehls über seine Mailbox benachrichtigen.
Der "Mailbox Status Abfrage"-Befehl kann auch verwendet werden, um einem Teilnehmer zu bedienen, der den Status von seinem oder ihren Mailbox oder Mailboxen abfragt. Dies ist in 14 veranschaulicht für den Fall, dass das zurückgegebene Ergebnis nicht segmentiert ist, und in 15 für den Fall, dass das zurückgegebene Ergebnis segmentiert ist.
Wie in 14 dargestellt gibt, wenn ein Benutzer den Status seiner Mailbox wissen möchte, das SCP einen "Mailbox Status Abfrage"-Befehl an das IP_r 911 heraus, wie bei 1401 gezeigt, wobei kurze oder ausführliche Informationen abgefragt werden, wie jeweils anwendbar. Falls bei 1401 nur eine kurze Information abgefragt worden war, falls ausführliche Informationen abgefragt, jedoch nicht verfügbar waren, oder falls ausführliche Informationen abgefragt waren und Segmentierung nicht notwendig ist, dann gibt IP_r 911 das Ergebnis der Abfrage ohne Segmentierung des Ergebnisses an das SCP zurück, wie bei 1402 gezeigt. Danach liegen weitere Aktionen im Ermessen des SCP 901.
15 zeigt ein Ablaufdiagramm, wenn ein Benutzer eine ausführliche Abfrage über den Status seiner Mailbox macht. Beim Empfang der Abfrage gibt SCP 901 einen "Mailbox Status Abfrage"-Befehl an IP_r 911, wie bei 1501 gezeigt, wobei ausführliche Informationen über eine bestimmte Mailbox oder Mailboxen abgefragt werden. IP_r 911 segmentiert das zurückzugebende Ergebnis und sendet das erste Segment an das SCP zurück, wie bei 1502 gezeigt, und zeigt an, dass weitere Information verfügbar bleibt. In Antwort darauf ruft das SCP den "Mailbox Status Abfrage"-Befehl bei 1503 ein zweites Mal auf, wobei einige oder Teile der verbleibenden Informationen abgefragt werden. Das IP_r 911 antwortet, indem es die zweite Rückgabe-Ergebniskomponente an das SCP zurückgibt, wie bei 1504 gezeigt, wobei es darauf hinweist, dass immer noch weitere Information verfügbar ist.
Wie oben im Zusammenhang mit der Beschreibung des in 13 gezeigten Ablaufdiagramms besprochen, gibt das SCP 901 wiederholt den "Mailbox Status Abfrage"-Befehl an IP_r 911, wie bei 1505 gezeigt, bis IP_r 911 eine Rückgabe-Ergebniskomponente überträgt, wie bei 1506 gezeigt, wobei sie darauf hinweist, dass keine weitere Information mehr verfügbar ist. Das SCP stellt dann die segmentierten Rückgabe-Ergebniskomponenten zusammen und analysiert sie, und führt weitere Aktionen in seinem eigenen Ermessen aus.
Die "Mailbox Status Bericht"- und "Mailbox Status Abfrage"-Befehle machen es möglich, eine Warnung an einen Teilnehmer zu initiieren, wenn sich der Status seiner Mailbox oder Mailboxen verändert hat, und um zentral alle verschiedenen Typen von Mailboxen des Teilnehmers zu steuern, ungeachtet der Tatsache, dass sie auf logisch verschiedenen IPs lokalisiert sind.
Wir betrachten als nächstes die IN-gesteuerten Medien-Umwandlungsdienste (Englisch: Media Conversion Services) in weiterer Ausführlichkeit. Die gegenseitige Umwandlung von Nachrichten, die in verschiedenen, in verschiedenen IPs lokalisierten Medien gespeichert sind, ist von den Teilnehmern und Telekommunikationsdienstanbietern schon lange gewünscht worden. Wie oben aufgezeigt, gab es innerhalb der derzeitig definierten IN-Architektur keine Prozeduren, die die gegenseitige Umwandlung von in verschiedenen Medien gespeicherten und auf verschiedenen IPs lokalisierten Nachrichten ermöglicht.
Der Funktionsablauf einer Ausführungsform der vorliegenden Erfindung ermöglicht die gegenseitige Umwandlung von Nachrichten und verschiedenen Medien, die auf verschiedenen IPs gespeichert sind, indem neue Prozeduren eingefügt werden: Der "Holen"-Befehl, der das SCP befähigt, ein IP anzuweisen, eine Nachricht von einem anderen IP zu holen; der "Umwandeln"-Befehl, der ein SCP befähigt, ein IP anzuweisen, eine Nachricht von einem Medium in ein anderes umzuwandeln; und der "Sende Nachricht"-Befehl, der ein SCP befähigt, ein IP anzuweisen, eine bestimmte, umgewandelte Nachricht zu einem identifizierten Ort zu übertragen.
In den unten dargestellten Ablaufdiagrammen ist ein bestimmtes IP, das als das Umwandlungs-IP, IP_c, bezeichnet wird, für die gegenseitige Umwandlung von in verschiedenen Medien gespeicherten Nachrichten verwendet. Es sei jedoch betont, dass die tatsächliche Umwandlung (oder jede belie bige andere analoge SRF-Funktionalität) entweder in dem Umwandlungs-IP, in jedem beliebigen IP, das das gewünschte Medium unterstützt, oder in jedem beliebigen anderen IP, das die notwendige Verarbeitungsleistungsfähigkeit und Systemressourcen umfasst, stattfinden kann. Weiterhin ist, wie oben erläutert, jede der Funktionseinheiten des IN, wie das SRF (das logische IP), eine gesonderte logische Einheit, die mit den anderen Einheiten des Telefonnetzwerks physikalisch, logisch oder in anderer Weise integriert sein kann, jedoch nicht damit integriert sein muss.
Der "Holen"-Befehl
16 zeigt das Ablaufdiagramm, wenn ein SCP ein IP anweist, eine Nachricht für eine Umwandlung zu holen. SCP 901 weist dann ein Umwandlungs-IP, IP_c 912 an, eine Nachricht zur Umwandlung von einem anderen IP_r 911 unter Verwendung des Backbone-Netzwerks zu holen. Das SCP gibt einen "Holen"-Befehl an das Umwandlungs-IP_c, wie bei 1601 gezeigt, wenn eine Nachricht in der Mailbox eines Teilnehmers abgeliefert worden und das SCP darüber durch eine "Mailbox Status Bericht"-Nachricht von dem Empfänger-IP_r 911 informiert worden ist. Beim Empfangen des "Holen"-Befehls holt das Umwandlungs-IP die Nachricht von dem Empfänger-IP, IP_r, über das NIP Backbone-Netz, wie bei 1602 und 1603 gezeigt. Wenn der Abruf der Nachricht erfolgreich abgeschlossen worden ist, signalisiert IP_c dieses an das SCP, wie bei 1604 angezeigt.
Der "Umwandeln"-Befehl
17 zeigt das Ablaufdiagramm, wenn das SCP 901 ein Umwandlungs-IP_c 912 anweist, eine Nachricht umzuwandeln. Der Vorgang beginnt wie bei 1701 gezeigt, indem das SCP einen "Umwandeln"-Befehl an IP_c 912 herausgibt. IP_c 912 wandelt die Nachricht von dem abgerufenen Medium um in das gewünschte Medium basierend auf einer in dem SCP abgelegten Präferenz bzw. Priorität oder basierend auf einem vom Teilnehmer aktivierten Umwandlungsmodusdialog, der von und mittels des SCP geführt wird. Nachdem die Umwandlung vervollständigt ist, benachrichtigt IP_c das SCP, wie bei 1702 gezeigt, woraufhin das SCP den Dialog mit dem Umwandlungs-IP abschließt, wie bei 1703 gezeigt.
Nachdem die Umwandlung vervollständigt ist, weist dann das SCP 901 das Lieferungs-IP_d 913 an, die umgewandelte Nachricht von dem Umwandlungs-IP_c 912 zu holen. Wie in 18 gezeigt beginnt der Vorgang damit, dass bei 1801 das SCF den "Holen"-Befehl an das IP_d herausgibt, woraufhin IP_d die umgewandelte Nachricht vom IP_d über das Backbone-Netz holt, wie bei 1802 und 1803 angedeutet. Wenn die Nachricht vollständig abgerufen worden ist, benachrichtigt IP_d das SCP, wie bei 1804 gezeigt.
Der "Sende Nachricht"-Befehl
Schließlich weist, wie in 19 gezeigt, das SCP 901 das IP_d an, die umgewandelte Nachricht an einen Teilnehmer zu liefern. Diese Phase beginnt, wie bei 1901 gezeigt, damit, dass das SCP einen "Sende Nachricht"-Befehl an das IP_d herausgibt, woraufhin das IP_d die umgewandelte Nachricht an den Teilnehmer liefert und dieses an das SCP 901 bestätigt, wie bei 1902 gezeigt. Der Vorgang endet damit, dass das SCP den Dialog mit IP_d abschließt, wie bei 1903 gezeigt.
Das oben beschriebene System und Verfahren befähigt ein SCP, die Umwandlung von in einem Medium empfangene Nachrichten in ein anderes Medium zu steuern, und die Lieferung einer umgewandelten Nachricht anzuweisen. Dies macht es möglich, die Präferenzen bzw. Prioritäten eines jeden Teilnehmers hinsichtlich des Mediums, in dem Nachrichten an einem zentralen Ort abgeliefert werden sollten, zu speichern. Ein zusätzlicher Vorteil des Funktionsablaufs nach einer Ausführungsform der vorliegenden Erfindung ist, dass sie es ermöglicht, dass ein Teilnehmer das Auslieferungsmedium für jede Nachricht interaktiv vorschreiben kann oder das Ergebnis einer früheren Mediumumwandlungsanweisung verändern kann.
Endliche Maschinen für SCP und IP
Die 20 und 21 zeigen die endlichen Maschinen für das SCP 901 und verschiedene IPs 911–914 nach einer Ausführungsform der vorliegenden Erfindung. In den 20 und 21 sind die Zustände der Maschinen mit einem Oval symbolisiert, während die Zustandsübergänge auslösende Ereignisse durch kontinuierliche Pfeile gezeichnet sind. Funktionen werden innerhalb gestrichelter Rechtecke dargestellt, während von den Funktionen angewiesene Aktionen durch gestrichelte Pfeile angedeutet werden.
20 zeigt den endlichen Automaten für das SCP. Wie zu sehen ist, weist das SCP drei Zustände auf: den Ruhezustand 2001, den Aktivzustand 2002 und den Holen-bei-Umwandlung-Zustand 2003. Das SCP geht von dem Ruhezustand 2001 über in den Holen-bei-Umwandlung-Zustand 2003 bei der Herausgabe des "Holen"-Befehls an das SCP, wie bei 2010 gezeigt. Der umgekehrte Zustandsübergang tritt auf, wenn der Dialog durch das IP verlassen wird oder wenn die Operation abgebrochen wird, wie bei 2011 gezeigt.
Das SCP geht von dem Holen-bei-Umwandlung-Zustand 2003 über in den Aktivzustand 2002, wenn die Ergebnisse des Holens von dem IP empfangen werden, wie bei 2012 gezeigt. Das SCP läuft in einer Schleife, (d.h. verbleibt) im Aktivzustand 2002 ohne jeglichen Zustandsübergang beim Senden einer "Umwandlungs"-Nachricht an IP_c, dem Empfang der Umwandlungsergebnisse vom IP_c, dem Senden des "Sende Nachricht"-Auslieferungsbefehl IP_d und beim Empfang der Benachrichtigung der Vervollständigung desselben, wie bei 2014 gezeigt. Wie bei 2013 gezeigt, geht das SCP vom Aktivzustand 2002 über in den Ruhezustand 2001 bei normaler Beendigung des Dialogs zwischen dem SCP und den IPs, wenn ein Dialog aufgrund der Anwesenheit von unzulässigen Komponenten zurückgewiesen wird, wenn ein Dialog von der anderen Seite verlassen wird oder wenn die Operation abgebrochen wird.
21 zeigt die endliche Maschine von der IP-Seite. Die IPs weisen drei Hauptzustände auf: den Ruhezustand 2101, den Aktivzustand 2102 und den Holen-bei-Umwandlung-Zustand 2103. Es gibt auch zwei zusätzliche Quasi-Zustände: das bei 2121 gezeigte Abrufen-von-Nachrichten über das Datenkommunikations-Backbone-Netz sowie den Nachrichten-Umwandlungs-Zustand 2122.
Wie in 21 gezeigt, geht das IP vom Ruhezustand 2101 über in den Holen-bei-Umwandlung-Zustand 2103 beim Empfangen des "Holen"-Befehls von dem SCP 901, wie bei 2110 gezeigt. Der umgekehrte Zustandsübergang tritt auf, wenn das IP den Dialog verlässt, wie bei 2111 gezeigt.
Das IP geht vom Holen-bei-Umwandlung-Zustand 2103 über in den Aktivzustand 2102, wenn die Ergebnisse des "Holen"-Befehls an das SCP 901 gesendet werden, wie bei 2112 gezeigt. Wenn ein IP den "Holen"-Befehl empfängt, wird der Übergang vom Ruhezustand 2101 in den Holen-bei-Umwandlung-Zustand 2103 zusätzlich durch das Abrufen der Nachricht über das Datenkommunikations-Backbone-Netz, wie bei 2115 gezeigt, sowie die Bestätigung der Vervollständigung der Aufgabe, wie bei 2116 gezeigt, begleitet.
Ein IP läuft in einer Schleife (d.h. verbleibt) im Aktivzustand 2102 beim Empfangen oder Bestätigen des "Sende Nachricht"-Befehls vom oder zum SCP 901. Ein IP verbleibt auch in dem Aktivzustand 2102 beim Empfangen des "Umwandeln"-Befehls vom SCP und beim Zurückgeben der Ergebnisse der Umwandlung an das SCP.
Jedesmal, wenn ein IP zusätzlich zum Verbleiben einen "Umwandeln"-Befehl vom SCP in den Aktivzustand erhält, dann bewirkt dies, dass es einen Quasi-Zustandsübergang in den Nachrichten-Umwandlungs-Zustand 2122 ausführt, wie bei 2117 gezeigt. Wenn Nachrichten-Umwandeln abgeschlossen ist, endet der Quasi-Zustandsübergang und das IP kehrt vom Nachrichten-Umwandeln-Zustand 2122 zurück in den Aktivzustand 2102.
Ein IP-Übergang vom Aktivzustand 2102 zum Ruhezustand 2101 tritt auf beim normalen Beenden des Dialogs durch das SCP oder beim Zurückweisen eines von dem SCP angebotenen Ergebnisses oder bei einem Verlassen des Dialogs zwischen einem SCP und dem IP durch eine der beiden Seiten.

Claims

Ein Verfahren zum Kommunizieren in einem Intelligenten Netzwerk-, abgekürzt als IN, Telekommunikationssystem mit einer Vielzahl von Intelligenten Peripheriegeräten (911–914), abgekürzt als IPs, verbunden mit einem Dienststeuerungsknoten (901), abgekürzt als SCP, über ein Netzwerk, wobei die Vielzahl von IPs (911–914) ferner miteinander über ein ausgeprägtes Telekommunikations-Backbone-Netz (910) verbunden ist, wobei das Verfahren den Schritt umfasst von Umwandeln einer in einem ersten Format geformten Nachricht einer empfangenen Form in eine in einem zweiten Format geformte Nachricht einer umgewandelten Form, wobei das Verfahren ferner durch die Schritte gekennzeichnet ist: Empfangen der in dem ersten Format geformten Nachricht einer empfangenen Form bei einem Empfänger-IP (911); Transportieren unter Steuerung des SCP (901) der Nachricht einer empfangenen Form von dem Empfänger-IP (911) zu einem Umwandlungs-IP (912); Umwandeln der Nachricht einer empfangenen Form bei dem Umwandlungs-IP (912) in die in dem zweiten Format geformte Nachricht einer umgewandelten Form; Transportieren unter Steuerung des SPC (901) der Nachricht einer umgewandelten Form zu einem Lieferungs-IP (913); und Liefern der in dem zweiten Format geformten Nachricht einer umgewandelten Form zu dem gewünschten Empfänger der Nachricht.
Das Verfahren nach Anspruch 1, wobei mindestens zwei der Empfänger-IP (911), denen die Nachricht einer empfangenen Form bereitgestellt wird, das Umwandlungs-IP (912), zu dem die Nachricht einer empfangenen Form transportiert wird, und das Lieferungs-IP (913), zu dem die Nachricht einer empfangenen Form transportiert wird, gemeinsam untergebracht sind.
Das Verfahren nach Anspruch 1, wobei die über ein Telekommunikations-Backbone-Netz (910) verbundenen IPs (911–914) miteinander unter Verwenden des TCP-IP Kommunikationsprotokolls kommunizieren.
Das Verfahren nach Anspruch 1, wobei die über ein Telekommunikations-Backbone-Netz (910) verbundenen IPs (911–914) mineinander unter Verwendung des X.25 Kommunikationsprotokolls kommunizieren.
Das Verfahren nach Anspruch 1, wobei die Nachricht einer empfangenen Form eine Nicht-Anruf-bezogene Nachricht umfasst.
Das Verfahren nach Anspruch 1, wobei die Nachricht einer empfangenen Form kompatibel ist mit Diensten zum Speichern und Weiterleiten.
Das Verfahren nach Anspruch 1, wobei das erste Format und das zweite Format aus der Gruppe ausgewählt werden, die aus Voice-Mail-Nachrichten, E-Mail-Nachrichten, Fax-Mail-Nachrichten, Nachrichten im Kurznachrichtendienst-, abgekürzt SMS, Format besteht.
Das Verfahren nach Anspruch 1, den weiteren Zwischenschritt umfassend eines Benachrichtigens (931, 1001) des SCP (901) durch das Empfänger-IP (911) einer Statusänderung einer Mailbox eines Benutzers, und wobei der Schritt des Transportierens der Nachricht einer empfangenen Form von dem Empfänger-IP (911) zu dem Umwandlungs-IP (912) durchgeführt wird als Antwort (932, 1002) auf eine Benachrichtigung des SCP (901) während des Schritts des Benachrichtigens.
Das Verfahren nach Anspruch 1, den weiteren Schritt des Abfragens (1201, 1301) des Empfänger-IP (911) bezüglich eines Status einer Mailbox eines Benutzers umfassend, und wobei der Schritt des Transportierens der Nachricht einer empfangenen Form von dem Empfänger-IP (911) zu dem Umwandlungs-IP (912) durchgeführt wird als Antwort auf die Abfrage (1201, 1301) von dem SCP (901) während des Schritts des Abfragens.
Das Verfahren nach Anspruch 1, wobei der Schritt des Transportierens der empfangenen ersten Nachricht von dem Empfänger-IP (911) zu dem Umwandlungs-IP (912) unter Verwenden eines HOLEN-Befehls (942, 1601) durchgeführt wird.
Das Verfahren nach Anspruch 1, wobei der Schritt des Umwandelns der Nachricht einer empfangenen Form in die Nachricht einer umgewandelten Form durchgeführt wird in Übereinstimmung mit einer Umwandlungs- und Lieferungspriorität eines Teilnehmers.
Das Verfahren nach Anspruch 1, wobei der Schritt des Umwandelns der Nachricht einer empfangenen Form in die Nachricht einer umgewandelten Form durchgeführt wird unter Verwenden eines UMWANDELN-Befehls (943, 1007, 1701).
Das Verfahren nach Anspruch 1, wobei der Schritt des Lieferns der in dem zweiten Format geformten zweiten Nachricht einer umgewandelten Form zu dem gewünschten Empfänger der Nachricht durchgeführt wird unter Verwenden eines NACHRICHT-SENDEN-Befehls (953, 1014, 1901).
Eine Vorrichtung zum Umwandeln einer in einem ersten Format geformten und von einem Urheber abstammenden Nachricht einer empfangenen Form in eine in einem zweiten Format geformte Nachricht einer umgewandelten Form, wobei die Nachricht einer umgewandelten Form zu einem Teilnehmer (922) geliefert werden soll, dadurch gekennzeichnet, dass die Vorrichtung umfasst: ein Intelligentes Peripheriegerät (911), abgekürzt als IP, eines Empfängers zum Empfangen der von einem Urheber abstammenden Nachricht einer empfangenen Form; ein an das Empfänger-IP (911) gekoppeltes Umwandlungs-IP (912), wobei das Umwandlungs-IP (912) zum Umwandeln der durch das Empfänger-IP (911) empfangenen Nachricht einer empfangenen Form in die Nachricht einer umgewandelten Form vorgesehen ist; ein an das Empfänger-IP (911) gekoppeltes Lieferungs-IP (913), wobei das Lieferungs-IP (913) zum Liefern der Nachricht einer umgewandelten Form zu dem Teilnehmer (922) vorgesehen ist; und ein Dienststeuerungsknoten (901), abgekürzt als SCP, der an das Empfänger-IP (911), das Umwandlungs-IP (912), und das Lieferungs-IP (913) gekoppelt ist, wobei der SCP (901) zum Steuern jeweils des Transports der Nachricht einer empfangenen Form und der Nachricht einer umgewandelten Form zwischen jeweils dem Empfänger-IP (911), Umwandlungs-IP (912), und Lieferungs-IP (913) vorgesehen ist und zum Steuern der durch das Umwandlungs-IP (912) durchgeführten Umwandlungen vorgesehen ist.
Die Vorrichtung nach Anspruch 14, wobei der SCP (901) ein Holen-Befehl erzeugt zum Einleiten eines Transports der Nachricht einer empfangenen Form von dem Empfänger-IP (911) zu dem Umwandlungs-IP (912).
Die Vorrichtung nach Anspruch 14, wobei der SCP (901) einen Umwandeln-Befehl erzeugt zum Einleiten einer Umwandlung durch das Umwandlungs-IP (912) der Nachricht einer empfangenen Form in die Nachricht einer umgewandelten Form.
Die Vorrichtung nach Anspruch 14, wobei der SCP (901) einen Hol-Befehl (942, 1601) erzeugt zum Einleiten eines Transports der Nachricht einer umgewandelten Form von dem Umwandlungs-IP (912) zu dem Lieferungs-IP (913).
Die Vorrichtung nach Anspruch 14, wobei der SCP (901) einen Nachricht-Senden-Befehl (953, 1014, 1901) erzeugt zum Einleiten einer Lieferung durch das Lieferungs-IP (913) der Nachricht einer umgewandelten Form zu dem Teilnehmer (922).
Die Vorrichtung nach Anspruch 14, wobei die in dem ersten Format geformte Nachricht einer empfangenen Form eine erste Ausgewählte umfasst von einer Voice- Mail-Nachricht, einer E-Mail-Nachricht, Fax-Mail-Nachricht, und einer Kurznachrichtendienst-, abgekürzt als SMS, Nachricht, und wobei das Umwandlungs-IP (912) die von der ersten Ausgewählten geformte Nachricht einer empfangenen Form in eine zweite Ausgewählte von der Voice-Mail-Nachricht, der E-Mail-Nachricht, und der SMS-Nachricht umwandelt.
Die Vorrichtung nach Anspruch 14, ferner eine durch den SCP (901) zugängliche Teilnehmerprioritäts-Speicherungsvorrichtung umfassend, wobei die Teilnehmerprioritäts-Speichervorrichtung zum Speichern von Angaben eines bevorzugten Formats vorgesehen ist, das der Teilnehmer zum Liefern der Nachricht einer umgewandelten Form bevorzugt, wobei der SCP (901) ferner vorgesehen ist zum Zugreifen auf die Teilnehmerprioritäts-Speicherungsvorrichtung zum Zugreifen auf die darin gespeicherten Angaben und zum Anweisen des Umwandlungs-IP (912) zum Umwandeln der Nachricht einer empfangenen Form in die Nachricht einer umgewandelten Form, wobei die Nachricht einer umgewandelten Form in dem bevorzugten Format geformt ist.