DE69900658T2

DE69900658T2 - Teilnehmerüberprüfung bei handvermittelten Gesprächen mit einem Schnittstellenprotokoll für ein intelligentes Netzwerk

Info

Publication number: DE69900658T2
Application number: DE69900658T
Authority: DE
Inventors: Jorge Augusto Aguilar; Yigang Cai; John Tzong-Yang Hwang; Katherine Anne Koenig; Timothy Gwen Rinker; Kenneth Jerome Scheppele; Steve Wutien Tsai
Original assignee: Lucent Technologies Inc
Current assignee: Nokia of America Corp
Priority date: 1998-05-14
Filing date: 1999-05-04
Publication date: 2002-08-08
Anticipated expiration: 2019-05-05
Also published as: JP2000069166A; EP0957623B1; EP0957623A2; EP0957623A3; CA2266964A1; KR19990088217A; KR100639518B1; DE69900658D1

Description

Technisches Gebiet

Die Erfindung betrifft ein Verfahren zur Bearbeitung von handvermittelten Verbindungen und insbesondere die Bereitstellung von Teilnehmer-Vorabfrage unter Verwendung einer netzbasierenden Teilnehmerdatenbank in einem Vermittlungssteuerungspunkt und unter Verwendung von Merkmalen eines ETSI-INAP-Schnittstellenprotokolls.

Beschreibung des Standes der Technik

Das am 7. November 1995 M. S. Chiller et al. erteilte US-Patent Nr. 5,465,293 zeigt ein Verfahren und eine Vorrichtung zum Vorabfragen eines kommenden R-Gesprächs aus dem Ausland an einem Handvermittlungsplatz mittels einer Vorabfrage-Datenbank von Rufnummern, die nicht für R-Gespräche belastet werden können. Dieses bekannte System wird in einer Knotenvermittlung betrieben, die das internationale R-Gespräch übermittelt. Die Abfrage der Datenbank vom. Handvermittlungsplatz geschieht durch bestehende C7-Zeichengabe über eine festzugeordnete Fernverbindungsleitung. Durch die festzugeordnete Fernverbindungsleitung wird die Abfrage und die Antwort darauf beschleunigt.
Bei einigen vorbekannten Systemen ist es erforderlich, daß ihre vermittlungsbasierenden Teilnehmerdatenbanken Genehmigungslistenüberprüfungen bereitstellen. Andere vorbekannte Systeme erfordern, daß ihre LAN-Einrichtungen und die Unterhaltung ihrer OSPS-Teilnehmer- Vorabfrage über das GSMS-(Global Service Management System)System bereitgestellt wird.
Es besteht daher in der Technik ein Bedarf an einer OSPS-Teilnehmer-Vorabfrage, die die entsprechenden Datenbanken schnell und nach einem standardmäßigen Schnittstellenprotokoll abfragen kann.

Zusammenfassung der Erfindung

Kurz gefaßt wird nach einem Aspekt der Erfindung das obenerwähnte Problem dadurch überwunden, daß ein Merkmal bereitgestellt wird, das Teilnehmer-Vorabfrage für handvermittelte Verbindungen unter Verwendung der netzbasierenden Teilnehmerdatenbank in einem Dienstesteuerungspunkt über ein Schnittstellenprotokoll eines intelligenten Netzes ermöglicht. Dieses Teilnehmer- Vorabfragemerkmal zapft eine gemeinsame netzbasierende Teilnehmerdatenbank unter Verwendung des Schnittstellenprotokolls des intelligenten Netzes an. Das Schnittstellenprotokoll des intelligenten Netzes erlaubt, daß mehr Informationen zwischen dem Handvermittlungsplatz und der netzbasierenden Teilnehmerdatenbank übermittelt werden und stellt dadurch eine Teilnehmer-Vorabfrage bereit, die zuverlässiger, flexibler und wirkungsvoller ist.
Nach einem weiteren Aspekt der Erfindung wird das obenerwähnte Problem durch Bereitstellen eines Verfahrens zur Teilnehmer-Vorabfrage für eine von einem ersten Teilnehmer eingeleitete, an eine gerufene Nummer gerichtete handvermittelte Verbindung überwunden. Das Verfahren schließt folgende Schritte ein: Abfragen einer Teilnehmerdatenbank in einem Vermittlungssteuerungspunkt betreffs eines Teilnehmers, der die handvermittelte Verbindung einleitet, unter Verwendung eines Schnittstellenprotokolls eines intelligenten Netzes; Empfangen von Informationen betreffs des Teilnehmers, dem die handvermittelte Verbindung in Rechnung gestellt wird, von der netzbasierenden Teilnehmerdatenbank im Vermittlungssteuerungspunkt unter Verwendung des besagten Schnittstellenprotokolls des intelligenten Netzes; und Bestimmen, ob die handvermittelte Verbindung zustandegekommen ist oder nicht, auf der Grundlage der besagten empfangenen Informationen. Durch dieses Verfahren wird eine hochintegrierte Handvermittlungsplatz-Schnittstelle bereitgestellt, die leicht zu bedienen ist, und Betrug und menschlichen Fehler verhindert.

Kurze Beschreibung der Zeichnung

Fig. 1 ist ein Blockschaltbild eines Beispiels eines Systems, das Teilnehmer-Vorabfrage als Reaktion auf einen Telefonanruf durchführt.
Fig. 2 ist ein logisches Flußdiagramm eines Verfahrens zur Bereitstellung von Teilnehmer-Vorabfrage als Reaktion auf einen Anruf.
Fig. 3 ist ein Verbindungs-Flußdiagramm einer handvermittelten Verbindung nach der vorliegenden Erfindung.

Ausführliche Beschreibung

Nunmehr Bezug nehmend auf Fig. 1 ist eine repräsentative Anordnung zur Ausübung der Erfindung dargestellt. Eine Vermittlung 20 wie beispielsweise eine 5ESS® von Lucent Technologies Inc. weist eine Handvermittlungsplatzstelle (OSPS - Operator Service Position Station) auf, um verschiedene OSPS-Funktionen und/oder Dienste und insbesondere die auf Teilnehmer- Vorabfrage bezogenen bereitzustellen. In dieser Darstellung leitet ein inländischer Anrufer eine Verbindung entweder von der Stelle 100 über die mit der Vermittlung 20 verbundene Ortsvermittlung 110 oder von einer mit der Vermittlung 20 verbundenen Nebenstellenanlage 120 ein. Als Alternative leitet ein ausländischer Anrufer 140 eine Handvermittlungsverbindung über das ausländische Netz 142 und die Auslandskopfvermfttlungsstelle 144 zur Vermittlung 20 und der OSPS 22 ein. Die handvermittelte Verbindung kann für eine mit der Vermittlung 20 (Ortsvermittlung 110) oder mit einer ähnlichen Vermittlung 50 wie beispielsweise der Nebenstelle 150 verbundene Teilnehmerstelle wie beispielsweise die Stelle 104 oder für Teilnehmerstelle 170 über Ortsvermittlung 160 bestimmt sein. In jedem Fall wird durch OSPS 22 irgendeine Art von Teilnehmer-Vorabfragedienst durchgeführt.
Der Teilnehmer-Vorabfragedienst der vorliegenden Erfindung wird über die Zusammenarbeit eines Dienstesteuerungspunktes (SCP - service control point) 180 wie beispielsweise des SCP2000 von Lucent Technologies Inc., der OSPS 22, des Vermittlungsdienstepunkts (SSP - switch service point) 24 und eines intelligenten Netzes (IN) einer Telekommunikationsvermittlung 20 wie beispielsweise einer Vermittlung 5ESS bereitgestellt. Für eine handvermittelte Verbindung leitet die OSPS 22, wenn die erforderlichen Informationen für die Vorabfrage eingesammelt worden sind, automatisch eine Teilnehmer-Vorabfrageabfrage durch Melden aller Vorabfrageinformationen an das IN ein. Das IN baut dann eine Operation ETSI INAP Initial-DP mit den Vorabfrageinformationen und einer Anzeige OSPS LD/ILD-Verbindung (eine handvermittelte inländische oder ausländische Fernverbindung) auf und sendet die Operation zum SCP 180. Der SCP 180 wird auf die zutreffende Dienstelogik (Service Logic) für die OSPS LD/ILD-Verbindung zugreifen. Wenn die Dienstelogik die Verbindung zuläßt, antwortet der SCP 180 dem IN-System in der Vermittlung 20 mit einer Operation "Connect call" (Ruf verbinden). Ansonsten antwortet der SCP 180 mit einer Operation "Release call" (Ruf freigeben). In beiden Fällen gibt das IN die Ergebnisse der Vorabfrage an die OSPS 22 weiter, wo die Ergebnisse angezeigt werden und entsprechende Beschränkungen zur Verhinderung eines möglichen Betrugs an die Verbindung angelegt werden.
Diese netzbasierende OSPS-Teilnehmer-Vorabfrage über SCP-Merkmal ist für Einzelabfrage-Gebührenzulässigkeitsvorabfrage bestimmt, ohne zusätzliche Abfrage zu erfordern, beispielsweise für Authentifizierungscodeüberprüfung. Der zugrundeliegende allgemeine Mechanismus in der Vermittlung 20 läßt sich jedoch entwickeln, um zukünftige Erweiterungen der Teilnehmer- Vorabfrage-Funktionalität im GSMS-SCP 190 aufzunehmen - beispielsweise die Ursprungsleitung-Vorabfrage (OLS - Originating Line Screening) oder die Abschlußcode-Vorabfrage (TCS - Terminating Code Screening). Für eine Erweiterung, die eine zusätzliche Abfrage erfordert wie beispielsweise für die Authentifizierungscodeüberprüfung müssen zusätzlich zu diesem Merkmal einige zusätzliche INAP-Operationen eingeführt werden, wie noch unten erläutert wird.
Nunmehr Bezug nehmend auf Fig. 1 und 2 ist eine besondere Ausführungsform eines Verfahrens 200 nach der Erfindung dargestellt. Das Verfahren 200 beginnt mit der Handlung 202, wo in der Vermittlung 20 mit SAC als Vermittlungskraft eine Verbindung von einem inländischen Anrufer oder ausländischen Anrufer empfangen wird, Nach Empfang der Verbindung schreitet das Verfahren 200 zur Handlung 204 fort. In der Handlung 204 sammelt OSPS 22 die CLI-(calling line identification-)Nummer, die gerufene bzw. Zielnummer, entweder inländisch oder ausländisch, und fragt den Kunden nach dem gewünschten Dienst und der gewünschten Vergebührungsanordnung. Beispiele des gewünschten Dienstes sind Sprechstelle zu Sprechstelle, Voranmeldungsgespräch und R-Gespräch. Beispiele von Vergebührungsanordnungen sind bezahlt abgesendet (sent paid), R-Gespräch und Rechnung an Dritten. Nach der Handlung 204 schreitet das Verfahren 200 zur Handlung 206 fort. In der Handlung 206 gibt eine die handvermittelte Verbindung einleitende Vermittlungskraft (entweder ein Mensch oder ein entsprechend ausgerüstetes automatisiertes System) Daten in das Nummernfeld des inländischen oder ausländischen gerufenen Teilnehmers (TO#/ITO#), das Nummernfeld des inländischen oder ausländischen rufenden Teilnehmers (FM#/IFM#) und das Datenfeld der Rechnungsnummer wie beispielsweise Rechnung an den rufenden Teilnehmer, Rechnung an den gerufenen Teilnehmer oder Rechnung an einen Dritten, ein. Sobald die entsprechenden Einträge in diese Datenfelder von der Vermittlungskraft getätigt worden sind, werden diese Informationen an SSP 24 weitergeleitet, der einen Systemvorgang des intelligenten Netzes (IN-SP - intelligent network system process) beginnt, in dem eine Datenbankabfrage vorbereitet wird, und das Verfahren 200 schreitet zur Handlung 208 fort. In der Handlung 208 überträgt der SSP 24 die Datenbankabfrage zum SCP 180 zur Vorabfrage mit den folgenden Datenfeldern: OSPS-Dienstschlüssel, CGPN, DCPN und AdditionalCallingPartyNumber (das die Rechnungsnummer enthält). Die Ergebnisse dieser Vorabfrage werden gesendet an, und das Verfahren 200 schreitet fort zu Bestimmung 210.
Bestimmung 210 bestimmt, ob die handvermittelte bestehende Verbindung zuzulassen oder zu verweigern ist. Der SCP 180 führt diese Bestimmung nach Durchführung von Vorabfrageüberprüfungen in seiner Datenbank durch und liefert das Ergebnis Zulassen oder Verweigern an SSP 24. Wenn das Ergebnis eine Verweigerung ist, dann wird auch ein Ursachencode für die Verweigerung an SSP 24 geliefert, und das Verfahren 200 schreitet zur Bestimmung 212 fort. Wenn das Ergebnis eine Zulassung der Verbindung so wie sie strukturiert ist, schreitet das Verfahren 200 zur Handlung 220 fort.
Die Bestimmung 212 überprüft den Verweigerungs- Ursachencode vom SCP 180, um zu bestimmen, ob dieser bestimmte Verweigerungs-Ursachencode in eine der Kategorien Trotzdem Zulassen von OSPS 22 fällt, und wenn ja, dann schreitet das Verfahren 200 zur Handlung 220 fort. Zwei derartige Kategorien sind:
Behandlung Für Rechnungsnummer Nicht Gefunden, was voreingestellt sein kann, um an der OSPS 22 eine Verbindung zuzulassen, deren Rechnungsnummer nicht am SCP 180 gefunden wurde, für Behandlung für Rechnungsnummer Nicht Gefunden nicht gefunden wurde, und
Unbestimmter Ruf Zulässig, was einen unbestimmten Zustand und einen Parameter Relativ neu, veränderlich (Recent Changeable) im System anzeigt, die zusammen voreingestellt sein können, um unbestimmte Verbindungen zuzulassen.
Wenn in der Bestimmung 212 OSPS 22 bestimmt, daß der Verweigerungsursachencode nicht in eine der Kategorien Trotzdem Zulassen fällt, schreitet das Verfahren 200 zur Bestimmung 214 fort.
Die Bestimmung 214 bewirkt, daß OSPS 22 die Verweigerung zu dem die handvermittelte Verbindung einleitenden Teilnehmer überträgt und diesen Teilnehmer fragt, ob eine andere Gebührenklasse (COC - class of charge) für die Vergebührung gewünscht wird und dann bestimmt, ob die Antwort des Teilnehmers Ja oder Nein ist. Wenn die Antwort Nein ist, dann schreitet das Verfahren 200 zur Handlung 216 fort, wo weiterer Fortschritt des Verfahrens 200 für diesen rufenden Teilnehmer anhält, und wenn die Antwort Ja ist, dann schreitet das Verfahren 200 zur Handlung 218 fort. In der Handlung 218 fragt die (menschliche oder automatisierte) Vermittlungskraft, welche Art anderer Vergebührung gewünscht wird und gibt die Rechnungsnummerdaten ein, die der Antwort des Ursprungsteilnehmers entsprechen, und überträgt alle Informationen zum SSP 24 und tritt wieder in die Handlung 208 ein. Die Schleife von Handlung 208, Bestimmungen 210, 212, 214 und Handlung 218 können solange wiederholt werden, bis die Anhaltehandlung 216 erreicht wird oder eine Zulassung entweder bei Bestimmung 210 oder 212 das Verfahren 200 zur Handlung 220 sendet. Die Handlung 220 wird dann erreicht, wenn die handvermittelte Verbindung zugelassen wird und in der Handlung 220 sendet der SSP 24 die Zulassungsantwort zur OSPS 22 und die OSPS bearbeitet den Ruf, um ihn mit dem gerufenen Teilnehmer zu verbinden. Damit endet das Verfahren 200 der Vorabfrage einer handvermittelten Verbindung.
Nach einer weiteren Ausführungsform der Erfindung enthält ein Verfahren zur Bereitstellung eines handvermittelten Rufs das Eingeben durch eine Vermittlungskraft von Informationen in ein oder mehrere der folgenden Felder: eine Nummer eines inländischen oder ausländischen gerufenen Teilnehmers (TO#/ITO#), eine Nummer eines inländischen oder ausländischen rufenden Teilnehmers (FM#/IFM#) und eine Gebührenklasse (COC - Class of Charge) PAID (Rechnung an rufenden Teilnehmer), COLLECT (Rechnung an gerufenen Teilnehmer) oder die Nummer eines Dritten für Vergebührung.
Diese Felder werden in bezug auf eine Teilnehmerdatenbank in SCP 180 vorabgefragt, ehe die Verbindung zur Herstellung zugelassen wird. Diese Felder werden zusammen Felder von Vorabfragedaten (Screening Data) genannt. Ein handvermittelter Ruf kann beispielsweise folgendes sein: (1) ein Quasiruf; (2) eine Sofortverbindung; (3) ein CLI-Bailout-Ruf, (4) ein kommender Ruf oder (5) ein Ruf von einem Abruf eines Datensatzes hergestellter Verbindungen (CCR - Completed Call Record). Wenn die Nummer des rufenden Teilnehmers eine gebührenfreie Rufnummer ist, wird jedoch keine Vorabfrage angewandt.
Wenn eines der Vorabfragedatenfelder eingetragen (bzw. abgeändert) und validiert worden ist, wird automatisch eine Teilnehmer-Vorabfrage-Abfrage eingeleitet, wenn die übrigen Vorabfragedaten zur Verfügung stehen und Ruflückenbildung nicht auf den Ruf anwendbar ist (Ruflückenbildung wird unten besprochen). Die Abfrage wird mit folgenden Abfrageinformationen an das IN gesendet:
1. einem Service Key (Dienstschlüssel);
2. einer Rufnummer des Anrufers,
3. einer Zielrufnummer, und
4. einer Rechnungsnummer.
Die Rechnungsnummer kann die Rufnummer des Anrufers, die Zielrufnummer oder die Rufnummer eines Dritten sein, wenn die COC PAID, COLLECT bzw. die Rufnummer eines Dritten zur Vergebührung ist. Für jede Rufnummer ist auch eine Anzeige der Art der Adresse (NOA - Nature of Address), entweder NATIONAL oder INTERNATIONAL enthalten. Zusätzlich wird ein Service Key von OSPS LD/ILD benutzt, um anzuzeigen, daß diese Abfrage für eine OSPS LD/ILD-Verbindung ist. Dadurch kann der SCP 180 die Verbindung auf bestimmte Weise für OSPS LD/ILD- Verbindungen behandeln.
Sobald eine Teilnehmer-Vorabfrage-Abfrage eingeleitet worden ist, wird ein Abfrageantwortzeitgeber gesetzt, um auf die Antwort zu warten. Während des Wartens auf die Antwort wird der Vermittlungskraft eine Anzeige Teilnehmer-Vorabfrage Läuft angezeigt und einige der Tasten an dem intelligenten Kommunikationsarbeitsplatz- Endgerät sind blockiert, hauptsächlich um in der Zwischenzeit irgendeine Abänderung der Vorabfragedaten und Verbindungsherstellung zu verhindern. Die Anzeige und die Tastenblockierung werden bei einer Antwort auf die Abfrage oder einem Zeitablauf am Abfragezeitgeber aufgehoben.
Wenn ein Ruf als zulässig erachtet wird, wird ein Anzeiger wie beispielsweise ein Haken neben die Rechnungsnummer gesetzt und wird entsprechend der gegenwärtigen Funktionalität angezeigt, um die Vermittlungskraft über ein positives Ergebnis zu informieren. Die Rechnungsnummer ist die Nummer des rufenden Teilnehmers, die Zielrufnummer oder die Nummer eines Dritten, wenn die COC PAID oder COLLECT bzw. die Rufnummer eines Dritten zur Vergebührung ist. Auf Grundlage der Anzeige kann die Vermittlungskraft mit der Herstellung der Verbindung fortfahren oder die Vorabfragedaten je nach Anforderung des Anrufers abändern. Wenn irgendwelche Vorabfragedaten abgeändert und validiert werden, wird der Anzeiger-Haken gelöscht und erneut eine neue Teilnehmer-Vorabfrage-Abfrage eingeleitet. Ein Ruf wird als zulässig erachtet entweder
1. wenn eine Abfrageantwort Connect (Verbinden) empfangen wird, oder
2. wenn eine Abfrageantwort Release-Call (Ruf Freigeben) mit einer Freigabeursache, die Rechnungsnummer Nicht Gefunden anzeigt, empfangen wird und ODD (Office Dependent Data) Behandlung Für Rechnungsnummer Nicht Gefunden auf Zulassung der Verbindungen voreingestellt ist, oder
3. wenn eine Abfrageantwort Release-Call mit einer Freigabeursache, die einen unbestimmten Zustand anzeigt, empfangen wird und ein Parameter Recent Changeable Unbestimmter Ruf Zulässig im System voreingestellt ist, um unbestimmte Verbindungen zuzulassen.
In den letzteren zwei Fällen wird eine Beschwerdenachricht angezeigt, um die Vermittlungskraft über den Zustand zu informieren. Die Beschwerdenachricht wird von einer Nachrichtentabelle Recent Changeable Complaint auf Grundlage der in der Abfrageantwort empfangenen Freigabeursache geholt. Die Freigabeursache wird in dem Feld Reason (Grund) angezeigt, das in dem für die Verbindung erzeugten AMA-Datensatz gespeichert wird. Die möglichen unbestimmten Zustände sind
1. SCP 180 trifft auf einen Fehler;
2. Zeitablauf für die Abfrageantwort oder INAP-Protokoll trifft auf einen Fehler beim Kommunizieren mit dem SCP 180, und
3. Ruflückenbildung ist auf die Verbindung anwendbar.
Wenn ein Ruf als verweigert angesehen wird, wird eine Beschwerdenachricht wie im vorherigen Abschnitt beschrieben angezeigt, um die Vermittlungskraft über die Beschaffenheit des Problems zu informieren, eine Beschränkungsnachricht wird angezeigt, um die Beschränkung aufzuzeigen, und es wird kein Verbindungsherstellungsversuch zugelassen. Eine Verbindung wird als verweigert angesehen, wenn eine Abfrageantwort Release Call empfangen wird und
1. die zugehörige Freigabeursache eine Rufabweisung anzeigt, oder
2. die Freigabeursache einen Zustand Rechnungsnummer Nicht Gefunden wie im vorhergehenden Abschnitt beschrieben anzeigt, aber der Parameter Behandlung Für Rechnungsnummer nicht Gefunden auf Verweigerung der Verbindung voreingestellt ist, oder
3. die Freigabeursache einen unbestimmten Zustand wie im obigen Abschnitt
beschrieben anzeigt, aber der Parameter Unbestimmter Zustand Verbindung Zulässig auf Verweigerung von unbestimmten Verbindungen voreingestellt ist.
Die Beschränkungsnachricht wird von einer Nachrichtentabelle Recent Changeable Restriction auf Grundlage der Freigabeursache geholt. Die Freigabeursache selbst wird in dem Feld Reason (Grund) angezeigt. Die Vermittlungskraft kann dann die Verbindung so wie sie ist abbrechen oder die Vorabfragedaten je nach Anforderung des Anrufers abändern. Wenn der Ruf abgebrochen wird, wird der Grund im AMA-Datensatz gesichert. Wenn irgendwelche Vorabfragedaten abgeändert und validiert werden, werden das Feld Reason und die Beschränkungsnachricht vor erneuter Einleitung einer neuen Teilnehmer-Vorabfrage- Abfrage gelöscht.
Ruflückenbildung ist eine existierende Netzmanagementfähigkeit zur Abfragenüberlastbehandlung, siehe untenstehende Beschreibung. Vor Einleitung einer Teilnehmer- Vorabfrage-Abfrage für eine Verbindung wird die Anwendbarkeit von Ruflückenbildung (Call Gapping) an die Verbindung mit dem Netzmanagementsystem überprüft. Wenn sie anwendbar ist, wird die Teilnehmer-Vorabfrage nicht eingeleitet, um Überlast zu vermeiden. Der Ruf wird so behandelt, als wenn eine Abfrage-Antwort Release Call mit einer einen unbestimmten Zustand anzeigenden Freigabeursache empfangen würde. Es wird ein Reason- Code zugewiesen und im Feld Reason angezeigt, und es wird eine mit der Ruflückenbildung verbundene Beschwerdenachricht angezeigt. Danach wird der Parameter Unbestimmter Ruf Zulässig überprüft, um zu bestimmen, ob der Ruf zulässig ist oder nicht.
1. Wenn der Ruf zulässig ist, wird ein Haken gemacht und neben der Rechnungsnummer dargestellt, und die Herstellung der Verbindung wird zugelassen, oder
2. wenn der Ruf verweigert wird, wird eine Beschränkungsnachricht angezeigt und jeder Verbindungsherstellungsversuch blockiert.
Der Reason-Code wird gegebenenfalls in dem für die Verbindung erstellten AMA-Datensatz gespeichert.
Bei Empfang einer Abfrage von der OSPS sendet der IN-SP (IN System Process) eine Operation Initial-DP in einer Nachricht TCAP BEGIN zum SCP 180. Die Operation Initial-DP hat folgende Parameter, die die OSPS- Abfrageinformationen wie untenstehend enthalten:

Tabelle 1. - Parameter der Initial-DP-Operation

Initial-DP-Parameter OSPS-Abfrageinformationen
Dienstschlüssel OSPS LD/ILD
Rufnummer des rufenden FM#
Teilnehmers
Zielrufnummer TO#
Zusätzliche Rufnummer des rufenden Teilnehmers Rechnungs-Nr.
Die Anzeige NOA in FM#, TO# und Rechnungs-# von OSPS wird ebenfalls in das NOA-Feld in entsprechenden Parametern der Initial-DP-Operation abgebildet.
Bei Senden der Operation Initial-DP registriert IN-SP eine Zählung "Anzahl von Anfragen an SCP" und setzt einen Abfrageantwortzeitgeber.
Als Ergebnis der Operation Initial-DP kann IN-SP eine Operation Connect (Verbinden) oder eine Operation Release-Call (Ruf Freigeben) von SCP 180 empfangen. In beiden Fällen wird der Abfrageantwortzeitgeber gelöscht.
Bei Empfang einer Operation Connect vom SCP 180 sendet IN-SP eine Abfrageantwort Connect zur OSPS.
Bei Empfang einer Operation Release-Call vom SCP 180 sendet IN-SP eine Abfrageantwort Release-Call mit dem Freigabeursachenwert in der Operation Release-Call zur OSPS und stößt einen weiteren Meßzähler zur Erhöhung der Zählung der "Number of Calls Failed by SSP because of SCP Instructions or Failure at SSP" (Anzahl von durch SSP abgewiesenen Verbindungen wegen SCP-Anweisungen oder Fehler am SSP) an.
Bei Empfang der Operation CallGap (Ruflückenbildung) vom SCP 180 (wie unten erläutert) formatiert IN-SP eine Anforderung mit den Lückenkriterien, den Lückenzeigern (einschließlich Lückendauer und Lückenintervall), der Steuerungsart (wahlfrei) und den Lückenbehandlungs- (wahlfrei)Informationen in der Operation Call-Gap, und sendet die Anforderung zum Netzmanagement zum Aufbauen des Ruflückenbildungs-Bestimmungsmechanismus.
Sollte entweder die Zeit ablaufen oder Protokollfehler in INAP auftreten, sendet IN-SP eine Abfrageantwort Release-Call zur OSPS mit einem Freigabeursachen- Vorgabewert (0) für Zeitablauf bzw. Fehlerzustandsbehandlung.
SCP-Teilnehmer-Vorabfrage beginnt, wenn eine Abfrage am SCP 180 ankommt, die autonome Logik führt eine Nachschlagung in der Dienstbestimmungsnetztabelle (SDNT - Service Determination Network Table) unter Verwendung des Dienstschlüsselparameterwertes als Schlüssel durch. Die SDNT weist die autonome Logik an, entweder zuerst die Netzlogik (CAL-Logik) auszuführen oder direkt zur Durchführung einer Nachschlagung in der entsprechenden Umsetzungstabelle fortzuschreiten. Die Netzlogik würde nur für Dienste aufgerufen werden, die Sonderbehandlung vor dem Nachschlagen in der Umsetzungstabelle benötigen, und abschließende Ausführung der auch als Kundenanwendungssprache (CAL - customer application language) (CAL-Logik) bekannten Dienstlogik.
Hinsichtlich der Kundenanwendungssprache-(CAL-)Logik und Netztabellen wird Logik zur Durchführung eines Nachschlagens in einer Umsetzungstabelle benutzt, das Nachschlagen ergibt die auszuführende Kontennummer. Autonome Logik führt dann die Dienstlogik innerhalb dieses Kontos aus (ein Konto enthält typischerweise Dienstlogik (Service Logik) und Dienstdaten).
Wenn Network Logic (Netzlogik) ausgeführt wird, führt sie jede benötigte Sonderbehandlung durch und führt dann ein Nachschlagen in der entsprechenden Umsetzungstabelle durch. Das Nachschlagen in der Umsetzungstabelle ergibt die auszuführende Kontonummer. Netzlogik führt dann die Dienstlogik in diesem Konto aus. Wenn jedoch keine Kontonummer im Umsetzungstabellennachschlagen gefunden wird, wird die Verarbeitung Vacant Code (Leerer Code) durchgeführt.
Der SCP 180 empfängt eine Nachricht BEGIN mit einer Operation Initial-DP, wenn die OSPS eine Teilnehmer- Vorabfrage-Abfrage einleitet. Die Operation Initial-DP enthält die OSPS-Abfrageinformationen wie in der Tabelle 1.
Eine Dienstbestimmungsnetztabelle (SDNT - service determination network table), die Teil des SCP 180 ist, enthält einen neuen Eintrag für den Wert des Dienstschlüssels "OSPS LD/ILD". Die SDNT weist weiterhin die autonome Logik an, Netzlogik für diesen Dienstschlüsselwert auszuführen.
Für eine von einer OSPS eingeleiteten ETSI-Abfrage greift der SCP 180 auf die Service Logic im vom GSMS 190 bereitgestellten LD/ILD-Konto zu. Dies ist dasselbe Konto, auf das von einer nicht durch eine OSPS eingeleitete bzw. direkt gewählte LD/ILD-Verbindung zugegriffen wird (d. h. es gibt nur ein LD/ILD-Konto). Die Netzlogik von SCP 180 muß daher sicherstellen; daß die Dienstlogik im LD/ILD-Konto des GSMS für die von der OSPS eingeleitete Abfrage ausgeführt wird.
Die Netzlogik erkennt den Dienstschlüsselwert "OSPS LD/ILD" und führt folgende Aufgaben für diesen Dienstschlüsselwert durch.
1. Netzlogik muß die im Parameter AdditionalCallingPartyNumber (zusätzliche Rufnummer eines rufenden Teilnehmers) der Operation Initial-DP empfangene Rechnungsnummer als Schlüssel in die Umsetzungstabelle der Rufnummer des rufenden Teilnehmers (Calling Party Number Translation Table) benutzen.
2. Netzlogik muß den Wert der als ServiceType (Dienstart) vordefinierten Variablen als CGPN einstellen. Diese vordefinierte Variable wird intern vom SCP 180 für Netzmanagement benutzt.
Wenn die als Schlüssel in die Calling Party Number Translation-Tabelle benutzte Rechnungsnummer nicht in der Calling Party Number Translation-Tabelle gefunden wird, wird Vacant Code-Verarbeitung durchgeführt.
Das Konto Vacant Code (Leerer Code) erkennt den Dienstschlüsselwert von "OSPS LD/ILD". Für diesen Dienstschlüsselwert führt Leerer Code eine Anweisung "EXIT < ft_index> " durch. Die CAL-Anweisung "EXIT < ft_index> " bewirkt, daß eine Operation Release-Call zur Vermittlung 20 gesendet wird. Die Operation Release-Call enthält einen Ursachenwert, der dem mit dem zur EXIT- Anweisung weitergegebenen Parameter "ft_index" verbundenen Wert in der Schlußbehandlungstabelle (Final Treatment Table) gleichwertig ist. Die Vermittlung 20 erkennt, daß ein Ursachenwert "1" "Ruf verweigert, da Konto nicht gefunden" bedeutet. Das Netzversorgungssystem (Network Care), das die Schlußbehandlungstabelle (Final Treatment Table) bereitstellt, sollte den Index 19 der Schlußbehandlungstabelle mit dem Ursachenwert 1 in Verbindung bringen. Die Service Logic benutzt daher die Anweisung "EXIT 19" für diesen Fall.
Die Service Logic von LD/ILD des GSMS muß den Wert "OSPS LD/ILD" für die Dienstschlüsselvariable erkennen und folgende Aufgaben für diesen Dienstschlüssel durchführen. Anders gesagt, muß folgendes bereitgestellt werden:
1. Die LD/IL D-Dienstlogik muß den Wert in der vordefinierten Variablen IncomingACGPNo zur Durchführung des Nachschlagens der Teilnehmervorabfragedaten im LD/ILD-Konto benutzen. Im Direktwählfall erwartet die Dienstlogik, daß die vordefinierte Variable CGPNoIn die Nummer enthält, die belastet wird, oder die Rufnummer des Teilnehmers (d. h. direkt gewählte Rufe sind immer Sent-Paid (bezahlt gesendet) Rufe). Sie benutzt daher die vordefinierte Variable CGPNoIn als Schlüssel zur Bestimmung der Teilnehmer-Vorabfrage. Im von der OSPS eingeleiteten Abfragefall ist jedoch die Rufnummer, die belastet wird, oder die Rufnummer des Teilnehmers in der vordefinierten Variablen IncomingACGPNo enthalten. Die Dienstlogik muß daher diese Nummer zur Bestimmung der Teilnehmer-Vorabfragen benutzen.
2. Wenn die GSMS-Dienstlogik bestimmt, daß der Ruf zulässig ist, führt sie einen Makro #ANIConnect (benötige. Eingabe über alle benutzte Parameterwerte) durch. Das bewirkt das Rücksenden einer Operation Invoke-Connect zur Vermittlung 20 (es wird kein Makro #ANIBilling durchgeführt).
3. Wenn die GSMS-Dienstlogik bestimmt, daß der Ruf verweigert wird, führt sie eine CAL-Anweisung "EXIT ft_index" aus. Die CAL-Anweisung "EXIT ft_index" bewirkt das Senden einer Operation Release-C all zur Vermittlung 20. Die Operation Release-Call (Verbindung freigeben) enthält einen Ursachenwert, der dem mit dem zur EXIT- Anweisung weitergegebenen Parameter ft_index verbundenen Schlußbehandlungstabellenwert gleichwertig ist. Die Vermittlung 20 erkennt, daß ein Ursachenwert "21" "Ruf verweigert aufgrund Vorabfrage" bedeutet. Das die Schlußbehandlungstabelle bereitstellende Network Care System sollte den Index 20 der Schlußbehandlungstabelle mit dem Ursachenwert 21 in Verbindung bringen. Die Dienstlogik sollte daher die Anweisung "EXIT 20" für den Verweigerungsfall benutzen.
Für Fehlerbearbeitung sendet die Anwendung, wenn SCP 180 einen internen Fehler antrifft, eine Operation Release-Call zum SSP 24. Der Ursachenparameter in der Operation Release-Call ist gleich dem mit dem Index 16 verbundenen Wert in der Schlußbehandlungs-Netztabelle.
Wenn SCP 180 versucht, das Konto Vacant Code auszuführen und das Konto nicht besteht (d. h. nicht bereitgestellt worden ist), wird eine Operation Release-Call zum SSP 24 gesendet. Der Ursachenparameter in der Operation Release-Call wird gleich dem mit dem Index 17 verbundenen Wert in der Schlußbehandlungs-Netztabelle sein.
Wenn der SCP 180 nicht den Dienstschlüsselwert in der SDNT findet, wird eine Operation Release-Call zum SSP 24 gesendet. Der Ursachenparameter in der Operation Release-Call wird gleich dem mit dem Index 18 verbundenen Wert in der Schlußbehandlungs-Netztabelle sein.
Wenn der SCP 180 den Dienstschlüsselwert in der SDNT findet, aber die angezeigte Umsetzungstabelle nicht besteht, wird eine Operation Release-Call zum SSP 24 gesendet. Der Ursachenparameter in der Operation Release-Call wird gleich dem mit dem Index 18 verbundenen Wert in der Schlußbehandlungs-Netztabelle sein.
Es gibt keine neuen SCP 180-Zählungen, die mit dem OSPS netzbasierenden Teilnehmer-Vorabfragemerkmal verbunden sind. Wie gegenwärtig geschieht wird die DSIQRYR- Zählung angestoßen, wenn der SCP 180 die BEGIN- Nachricht mit einer. Initial-DP-Operation empfängt. Wie ebenfalls gegenwärtig geschieht wird die DSIRTPN- Zählung angestoßen, wenn eine Connect-Operation gesendet wird.
An der SCP-180-Datensammlung für OSPS-netzbasierende Teilnehmer-Vorabfrage werden keine Änderungen durchgeführt. Die in der Operation Initial-DP empfangene Rufnummer des rufenden Teilnehmers (CallingPartyNumber) wird in den Feldern Calling Party Number der binären Meldungen ATTEMPT und SUMMARY benutzt. Gleichfalls wird die im Parameter AdditionalCallingPartyNumber der Operation Initial-DP empfangene Rechnungsnummer in den Feldern Additional Calling Party Number der Binärmeldungen ATTEMPT und SUMMARY benutzt.
Obwohl das OSPS-netzbasierende Teilnehmer-Vorabfrage- Merkmal unter Verwendung des ETSI INAP-Protokolls implementiert wird, gibt es keine neuen Netzmanagementfähigkeiten, die mit diesem Merkmal verbunden sind. Der folgende Abschnitt ist eine Beschreibung darüber, wie bestehende Fähigkeiten auf die von der OSPS eingeleitete Abfrage angewandt werden.
Durch die OSPS 22 eingeleitete Abfragen kommen in den SCP 180 auf denselben Zeichengabestrecken wie alle direkt gewählten Abfragen. Die Abfragen werden auch in dieselben "kommenden Warteschlangen" wie alle direkt gewählte Abfragen plaziert. Eine OSPS-Abfrage kann aus der Warteschlange entfernt werden, wenn ihre Zeit in der Warteschlange die zulässige Höchstzeit überschreitet, genau wie eine direkt gewählte Abfrage entfernt werden kann.
Wenn die SCP 180-Anwendung bestimmt, daß sie sich in einem Überlastungszustand befindet (auf Grundlage des Prozentsatzes an Verbindungen, die aus den Warteschlangen "kommende Nachrichten" entfernt werden), schließt sie in die Nachricht, die sie zur Vermittlung 20 sendet, eine Call-Gap-Operation ein. Die Lückenkriterien (GapCriteria) in der Call-Gap-Operation sind CallingAddressandService. Der CallingAddress-Wert enthält den Wert der Rufnummer des rufenden Teilnehmers (CallingPartyNumber) von der Initial-DP-Operation. Der Dienstschlüssel enthält den Wert von "CSPS LD/ILD".
In der Annahme, daß eine handvermittelte Verbindung möglich ist, wird in Fig. 3 ein Verbindungsablauf nach der vorliegenden Erfindung dargestellt. Die Fig. 3 zeigt ein Beispiel einer bestimmten OSPS/IN-Schnittstelle für Teilnehmer-Vorabfrage durch interne Nachrichten- und standardisierte ETSI-INAP-Operationen der Vermittlung 20. Der in Fig. 1 und 3 dargestellte Verbindungsablauf beginnt mit Einleiten einer Verbindung durch den rufenden Teilnehmer, die an der OSPS 22 ankommt (dem entweder von einer menschlichen Person oder einem automatisierten System betriebenen Handvermittlungsplatz). Im vorliegenden Beispiel wird die Zielrufnummer (COLLECT) als die Rechnungsnummer (BN - Billing Number) benutzt und die SCP/GSMS-Dienstlogik bestimmt, daß BN ein schlechtes Konto oder Leercode- Konto ist und der Ruf verweigert werden sollte. Als nächstes sammelt die Vermittlungskraft erneut vom rufenden Teilnehmer eine weitere Rechnungsnummer (die Rufnummer des rufenden Teilnehmers, bzw. PAID) und sendet eine nachfolgende Abfrage zum IN. Einzelheiten des Verbindungsablaufs werden unten beschrieben.
Als Reaktion auf das Einleiten einer handvermittelten Verbindung durch einen rufenden Teilnehmer sammelt die OSPS 22 die Rufnummer des rufenden Teilnehmers, die Zielrufnummer und die Rechnungsnummer vom rufenden Teilnehmer. Der Anzeiger des rufenden Teilnehmers zeigt an, daß dies beispielsweise ein COLLECT-Ruf (R- Gespräch) ist und die Vermittlungskraft trägt daher die Rechnungsnummer mit der Zielrufnummer ein. Als nächstes sendet die OSPS 22 eine interne Vermittlungs- Abfragenachricht (mgACP-QRY) an SSP 24 (IN-SP) mit Dienstschlüssel (OSPS LD/ILD), der Rufnummer des rufende n Teilnehmers, der Zielrufnummer und der Rechnungsnummer ab. Als nächstes bildet der SSP 24 den Dienstschlüssel (OSPS LD/ILD), die Rufnummer des rufenden Teilnehmers, die Zielrufnummer und die Rechnungsnummer in zugehörige Parameter in der Initial- DP-Operation ab (die Rechnungsnummer wird in den Parameter AdditionalCallingPartyNumber abgebildet); und sendet dann die Initial-DP-Operation zum SCP 180.
Bei Empfang der Initial-DP-Operation führt der SCP 180 die Vorabfrage auf Grundlage der Rechnungsnummer durch. Die Dienstlogik bestimmt, daß die Rechnungsnummer (die Zielrufnummer) ein schlechtes Konto oder ein Leercodekonto ist, der SCP 180 sendet eine Operation ReleaseCall mit dem Ursachenwert zum SSP 24. Als nächstes sendet der SSP 24 eine Abfrageantwortnachricht (mgACP-RTE) vermittlungsintern zur Vermittlung 20 mit dem Verweigerungsgrund zur OSPS 22.
Die OSPS 22 betrachtet den Verweigerungsgrund und entscheidet sich, den rufenden Teilnehmer neu aufzufordern, wenn eine andere Gebührenklasse für die Vergebührung gewünscht wird und die Rechnungsnummer neu zu sammeln, sobald der rufende Teilnehmer gewillt ist, die Rufnummer des rufenden Teilnehmers als die neue Rechnungsnummer (PAID) zu benutzen.
Die OSPS 22 füllt die Rechnungsnummer mit der Rufnummer des rufenden Teilnehmers (PAID) und sendet eine neue vermittlungsinterne Abfragenachricht (mgACP-QRY) zum SSP 24 (IN-SP) mit Dienstschlüssel (OSPS LD/ILD), der Rufnummer des rufenden Teilnehmers, der Zielrufnummer und der Rechnungsnummer. Der SSP 24 bildet wieder den Dienstschlüssel (OSPS LD/ILD), die Rufnummer des rufenden Teilnehmers, die Zielrufnummer und die Rechnungsnummer in zugehörige Parameter in einer DP- Operation ab (die Rechnungsnummer wird in den AdditionalcallingPartyNumber-Parameter abgebildet); und sendet dann die Initial-DP-Operation zum SCP 180.
Beim Empfang dieser Initial-DP-Operation führt der SCP 180 wieder die Vorabfrage auf Grundlage der Rechnungsnummer durch. Die Dienstlogik bestimmt wieder, ob die Rechnungsnummer (diesmal die Rufnummer des rufenden Teilnehmers) gültig ist. Wenn sie gültig ist, dann sendet der SCP 180 eine Connect-Operation zum SSP 24. Bei Empfang der Connect-Operation-Antwort vom SCP 180 läßt der SSP 24 alle in der Connect-Operation enthaltenen Parameter außer Acht und sendet eine Connect-Abfrage-Antwortnachricht (mgACP-RTE) vermittlungsintern zur Vermittlung 20 mit einer Anzeige der Zulassung des Rufs zur OSPS 22.
Die OSPS 22 und Vermittlung 20 leiten die Verbindung zum gerufenen Teilnehmer. Die gerufene Sprechstelle klingelt, der gerufene Teilnehmer antwortet und das gewünschte Gespräch beginnt und die Rechnungsnummer wird für den Dienst belastet. Diese Verbindung wird abgebrochen, sobald ein Teilnehmer auflegt.

Claims

1. Verfahren zur Bereitstellung von Teilnehmer- Vorabfrage für eine von einem ersten Teilnehmer eingeleitete, an eine gerufene Nummer gerichtete handvermittelte Verbindung mit folgenden Schritten:

Abfragen einer Teilnehmerdatenbank in einem Vermittlungssteuerungspunkt betreffs eines Teilnehmers, der die handvermittelte Verbindung einleitet, unter Verwendung eines Schnittstellenprotokolls eines intelligenten Netzes; und

Empfangen von Informationen betreffs des Teilnehmers, dem die handvermittelte Verbindung in Rechnung gestellt wird, von der netzbasierenden Teilnehmerdatenbank im Vermittlungssteuerungspunkt unter Verwendung des besagten Schnittstellenprotokolls des intelligenten Netzes; und

Bestimmen, ob die handvermittelte Verbindung zustandegekommen ist oder nicht, auf der Grundlage der besagten empfangenen Informationen.

2. Verfahren nach Anspruch 1, wobei das besagte Schnittstellenprotokoll eines intelligenten Netzes ein Schnittstellenprotokoll ETSI INAP ist.

3. Verfahren nach Anspruch 1, wobei die durch das Handvermittlungsplatzsystem über das intelligente Netz zur Teilnehmer-Vorabfrage abgefragten Teilnehmerinformationen auf geographische Teilnehmernummern, und nicht Nummern der Serie 700, 800, 888, 900 begrenzt sind.

4. Verfahren nach Anspruch 1, wobei eine umgesetzte Nummer von einem Dienstesteuerungspunkt nicht die Zielnummer auf einem Handvermittlungsplatzbildschirm ändert und keinen Einfluß auf die Bearbeitung der Verbindung durch den Handvermittlungsplatz hat, wenn die Verbindung durch die Vorabfrage zugelassen wird.

5. Verfahren nach Anspruch 1, wobei die Teilnehmer-Vorabfrage auf mindestens eine von einer Gruppe von Nummern einschließlich einer Nummer des rufenden Teilnehmers, einer Zielnummer und einer Rechnungsnummer angewandt wird.

6. Verfahren nach Anspruch 1, wobei die Teilnehmer-Vorabfrage auf mindestens zwei von einer Gruppe von Nummern einschließlich einer Nummer des rufenden Teilnehmers, einer Zielnummer und einer Rechnungsnummer angewandt wird.

7. Verfahren nach Anspruch 1, wobei die Teilnehmer-Vorabfrage auf alle drei von einer Gruppe von Nummern einschließlich einer Nummer des rufenden Teilnehmers, einer Zielnummer und einer Rechnungsnummer angewandt wird.

8. Verfahren nach Anspruch 1, wobei Ruflückenbildung auf handvermittelte Verbindungen angewandt wird.

9. Verfahren nach Anspruch 1, weiterhin mit folgendem Schritt: wenn ein Dienstesteuerungspunkt eine Operation Ruf Aufschalten und eine Operation Ruf Freigeben zu einem Dienstevermittlungspunkt in einer Nachricht TCAP END zurücksendet, Rücksenden von TCAP END, ohne irgendeine andere Operation einzuschließen.

10. Vorrichtung zur Bereitstellung von Teilnehmer- Vorabfrage für eine von einem ersten Teilnehmer eingeleitete, an eine gerufene Nummer gerichtete handvermittelte Verbindung mit folgendem:

Mitteln zum Abfragen einer Teilnehmerdatenbank in einem Dienstesteuerungspunkt betreffs eines Teilnehmers, der die handvermittelte Verbindung einleitet, unter Verwendung eines Schnittstellenprotokolls eines intelligenten Netzes;

Mitteln zum Empfangen von Informationen betreffs cles Teilnehmers, dem die handvermittelte Verbindung in Rechnung gestellt wird, von der netzbasierenden Teilnehmerdatenbank im Dienstesteuerungspunkt unter Verwendung des besagten Schnittstellenprotokolls eines intelligenten Netzes; und

Mitteln zum Bestimmen, ob die handvermittelte Verbindung zustandegekommen ist oder nicht, auf der Grundlage der besagten empfangenen Informationen.

11. Vorrichtung nach Anspruch 10, wobei die besagten Abfragemittel und besagten Bestimmungsmittel beide Teil einer Telekommunikationsvermittlungsstelle sind.