DE19919976B4

DE19919976B4 - Verfahren und Vorrichtung zum Übertragen eines eingebetteten Nebenstellensystems auf einen Personalcomputer

Info

Publication number: DE19919976B4
Application number: DE19919976A
Authority: DE
Inventors: Gordon Kanata Lee; Dino Nepean Canton
Original assignee: Mitel Knowledge Corp
Current assignee: Mitel Networks Corp
Priority date: 1998-05-01
Filing date: 1999-04-30
Publication date: 2006-08-10
Anticipated expiration: 2019-05-01
Also published as: GB2336969B; GB2336969A; US6366656B1; CA2236525A1; GB9826478D0; DE19919976A1; CA2236525C

Abstract

Nebenstellenanlage auf PC-Basis, die eine vorher bestehende Anrufsteuerungssoftware (300) enthält, die dazu dient, in einer Berechnungsumgebung zu arbeiten, die nicht auf PC-Basis beruht, wobei die Nebenstellenanlage auf PC-Basis umfaßt:
ein PC-Gestell (250);
eine PC-Hauptplatine (280) innerhalb des Gestells (250);
eine Nebenstellenanlagen-Hauptsteuerungskarte (200) innerhalb des Gestells (250) zum Ausführen der im voraus bestehenden Anrufsteuerungssoftware (300);
eine Telekommunikationskarte (220) innerhalb des Gestells (250), die mit der Nebenstellenanlagen-Hauptsteuerungskarte (200) verbunden ist, um Telephoniekommunikation mit einem öffentlichen Telephonnetz (170) unter der Steuerung der Anrufsteuerungssoftware (300) zu implementieren und
eine DSP-Karte (210) innerhalb des Gestells (250), die mit der Nebenstellenanlagen-Hauptsteuerungskarte (200) verbunden ist, um ein Signalisierungs- und Konferenzfunktionsnetz unter der Steuerung der Anrufsteuerungssoftware (300) zu implementieren,
dadurch gekennzeichnet, daß
die Nebenstellenanlagen-Hauptsteuerungskarte (200) eine Hardwareabstraktionsschicht (305) enthält, um Hardwareelemente zu ersetzen, zu emulieren und einzuführen, die in der Nebenstellenanlage auf PC-Basis fehlen und mit der die im voraus bestehende...

Description

Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich allgemein auf die Computertelephonieintegration (CTI) und insbesondere auf ein Verfahren und eine Vorrichtung für das Übertragen bestehender Nebenstellensoftware und Hardware auf einen Personalcomputer (PC).

Hintergrund der Erfindung

Aus US 5 649 005 ist eine Integration einer Nebenstellenanlagen-Karte (PBX-Karte) mit einem PC bekannt. Hierbei ist die PBX-Karte über einen lokalen PCI-Bus mit dem PC verbunden, während eine Steuerkarte für Telefoniefunktionen (telephony feature control card) über einen synchronen Bus mit dem PC kommuniziert. Hierdurch werden die typischen PC-Aktivitäten weniger stark durch zum Bereitstellen von Telefoniefunktionen in Echtzeit erforderliches Verarbeiten, Speichern und Abrufen von Telefonsignalen gestört.

Die PBX-Karte, die zumindest eine Anrufsteuerung (call Controller) umfaßt, läuft dabei unabhängig vom PC, wobei sogar eine eigene Stromversorgung vorgesehen sein kann.

Herkömmliche Nebenstellenanlagen (PBX = Private Branche Exchange = Nebenstellenanlage) umfassen firmeneigene Hardware und Software, die in einem Gehäuse eingeschlossen sind. Nebenstellenanlagen des Standes der Technik haben sich als wertlos bei der Bereitstellung höherwertiger Anrufsteuerungs- und Nachrichtenfunktionen zwischen lokalen und entfernten Teilnehmern erwiesen. Neuere Fortschritte auf dem Gebiet der CTI haben jedoch die Notwendigkeit dafür geschaffen, daß solche Nebenstellenanlagen des Standes der Technik Anwendungen dritter Parteien leichter unterstützen. In den meisten Nebenstellenanlagen des Standes der Technik können z. B. zusätzliche Anwendungen wie ISDN-Zugriff, CTI-Unterstützung, Ansagevorrichtungen (RADs), Anrufabrechnung und Sprachnachrichtendienst nur unterstützt werden durch Hinzufügen zusätzlicher externer PCs, Schnittstellenhardware und Software.

Die Telekommunikationsindustrie hat die Vorteile der Minimierung der Komplexität und der Kosten der Implementierung zusätzlicher Anwendungen auf Nebenstellenanlagen des Standes der Technik in der obenbeschriebenen Weise erkannt. Die ideale Lösung für das vorangehende Problem ist anscheinend die vollständige Implementierung der Nebenstellenanlagen-Funktionalität auf einer PC-Plattform. Ein wesentliches Hindernis bei der Verwirklichung des Ziels der vollständigen PC-Implementierung der Nebenstellenanlagen-Funktionalität ist jedoch die Schwierigkeit der Übertragung der bestehenden Software und der Architekturen von ihrer herkömmlichen firmeneigenen selbständigen Umgebung auf eine ausschließlich PC-implementierte Umgebung. Genauer hat die Industrie die Vorteile des Vermeidens der Neuentwicklung bestehender Anrufsteuerungssoftware und die Vorteile der Wiederverwendung solcher bestehender Software erkannt, um die Entwicklung und Nutzung bestehender Anrufsteuerungsfunktionen zu beschleunigen. Es ist klar, daß eine Nebenstellenanlage auf PC-Basis, wie oben beschrieben, die Stärken herkömmlicher Nebenstellenanlagensysteme erhält (z. B. Faserverbindung zu Peripheriegeräten, Warmaustausch von Leitungskarten, Merkmalsreichtum, Netzfunktionen etc.) und eine sehr viel offenere Umgebung für die Integration von Anwendungen bietet, als es mit solchen Nebenstellenanlagensystemen des Standes der Technik möglich ist.

Zusammenfassung der Erfindung

Gemäß der vorliegenden Erfindung werden ein Verfahren und eine Vorrichtung geschaffen zum Übertragen bestehender eingebetteter Nebenstellenanlagen-Hardware und Softwareelemente auf einen PC, wodurch eine vollständige funktionale Nebenstellenanlage auf PC-Basis entsteht. Die Nebenstellenanlage auf PC-Basis gemäß der vorliegenden Erfindung enthält eine Hauptfasersteuerungskarte zum Bereitstellen von Echtzeit-Diensten einschließlich der Nachrichten- und Schaltungsvermittlung und einer peripheren Verbindung auf Faserbasis für die Unterstützung von Sprache und Signalisierungs informationen zwischen der Nebenstellenanlage auf PC-Basis und einem oder mehreren vorhandenen Peripheriegeräten. Eine Hardware-Abstraktionsschicht wird über der bestehenden Anrufsteuerungssoftware hinzugefügt, um einer solchen Software zu ermöglichen, in der PC-Umgebung zu arbeiten, anstatt in der herkömmlichen firmeneigenen Nebenstellenanlagen-Umgebung. Gemäß der bevorzugten Ausführungsform der Erfindung werden andere Merkmale wie z. B. ein Emulatorlauf in Windows-NT für die Ausführung bestehender Nebenstellenanlagen-Anrufsteuerungssoftware geschaffen, die dazu dienen, auf einer Nicht-Windows-NT-Plattform zu laufen; ein SCSI-Emulator zum Abbilden von SCSI-Anrufen von dem bestehenden Nebenstellenanlagen-Dateisystem auf ein Windows-NT-Dateisystem, das alle bestehenden Nebenstellenanlagen-Dateien darstellt, und eine Digitalsignalprozessor-(DSP)-Karte zum Bereitstellen von Ton/Konferenz-Funktionalität.

Kurzbeschreibung der Zeichnungen
Eine genaue Beschreibung des Standes der Technik und der bevorzugten Ausführungsform der vorliegenden Erfindung wird im folgenden mit Bezug auf die folgenden Zeichnungen gegeben, in welchen:
1 ein herkömmliches Nebenstellenanlagen-System zeigt, das mit mehreren Anwendungs-Servern gemäß dem Stand der Technik konfiguriert ist;
2 ein Blockschaltbild der Hardwarekomponenten einer Nebenstellenanlage auf PC-Basis gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung ist;
3 ein Blockschaltbild ist, das die Softwarekomponenten der Nebenstellenanlage auf PC-Basis der 2 zeigt;
4 ein Blockschaltbild ist, das die Softwarearchitektur einer Hauptfaserkarte der Nebenstellenanlage auf PC-Basis gemäß der bevorzugten Ausführungsform zeigt;
5 ein Hochebene-Schaubild eines 68K-Emulators ist, der eine der in 3 gezeigten Softwarekomponenten bildet;
6 die Hauptsoftwareblöcke und Schnittstellen zeigt, die in einem SCSI-Emulator verwendet werden, der eine der in 3 gezeigten Softwarekomponenten bildet;
7 eine schematische Darstellung eines Polling-Betriebsmodus für den SCSI-Emulator der 6 ist;
8 eine schematische Darstellung einer Unterbrechungs-Betriebsart für den SCSI-Emulator der 6 ist;
9 eine schematische Darstellung dreier unterschiedlicher Schichten ist, die eine C-Schnittstellenarchitektur definieren, um eine Windows-NT-zu-Emulator-Schnittstelle gemäß der vorliegenden Erfindung zu schaffen;
10 eine schematische Darstellung einer Sprache/LAN-Management-Kommunikation gemäß der vorliegenden Ausführungsform ist;
11 eine schematische Darstellung eines Nachrichten-Untersystems gemäß der bevorzugten Ausführungsform ist;
12 ein Blockschaltbild ist, das eine Hardware- und Softwarearchitektur für einen Ton/Konferenz-DSP-Dienst gemäß der bevorzugten Ausführungsform zeigt;
13 ein Schichtmodell für den Ton- und Konferenzdienst der 12 zeigt; und
14 eine schematische Darstellung der Verbindung zwischen der Anrufsteuerungsmaschine des 68K-Emulators und einer oder mehreren CTI-Server-Anwendungen gemäß der bevorzugten Ausführungsform ist.
Genaue Beschreibung des Standes der Technik und der bevorzugten Ausführungsform
In 1 ist ein herkömmliches Nebenstellenanlagensystem gemäß dem Stand der Technik gezeigt, das mit mehreren Anwendungs-Servern konfiguriert ist. Das dargestellte Nebenstellenanlagensystem umfaßt ein Hauptsteuerungsgehäuse 100, das verbunden ist mit einem Peripheriegehäuse 110, einem Digitaldiensteinheits-(DSU)-Gehäuse 115 und einem Netztor 120; ein Anwendungstor 125; einen Netzmanagement-Server 130, einen Sprachpost-Server 135; einen Anrufzentralmanagement-Server 140 und einen Anrufabrechnungs-Server 145. Das dargestellte Nebenstellenanlagen-System ist für den Stand der Technik beispielhaft. Ein Industriefachmann erkennt, daß zahlreiche andere Konfigurationen möglich sind.
Das Hauptsteuerungsgehäuse 100 enthält die physikalische Hardware und die Nebenstellenanlagen-Kernsoftware, die wohlbekannte Nebenstellenanlagen-Anrufsteuerfunktionen implementiert. Die Hardwarekomponenten umfassen typischerweise eine Hauptsteuerungskarte und mehrere Faserschnittstellenmodule (FIMs), die in eine Zeitbereich-Multiplexing-(TDM)-Rückwandplatine für das Multiplexing von Sprach- und Signalisierungskanälen über Faserverbindungen zum Peripheriegehäuse 110, DSU-Gehäuse 115, Netzwerktor 120 und dem Anwendungstor 125 eingesteckt sind. Die (nicht gezeigte) Hauptsteuerungskarte enthält typischerweise eine Zentraleinheit (CPU), eine TDM-Rückwandplatine zum Transportieren der Sprach- und Signalisierungsinformationen zwischen den FIMs und den internen Nachrichten- und Schaltvermittlungsmatrizen, eine Schaltvermittlungsmatrix zum Bereitstellen einer Verbindung von Sprachkanälen, eine Nachrichtenvermittlungsmatrix zum Bereitstellen von Signalisierungsinformationsrouten zwischen intelligenten Systemknoten, eine SCSI-Steuervorrichtung zum Steuern von Plattenlaufwerkoperationen, einen oder mehrere DSPs zum Bewerkstelligen der Konferenz- und Tonerfassung, RS232-Anschlüsse, die für Kundendateneingabe, das Drucken und die Bereitstellung genauer Anrufabrechnungsaufzeichnungen verwendet werden können, eine Ethernet-LAN-Schnittstelle zum Bereitstellen eines Zugriffs auf ein Firmen-LAN-Netz 150 und eine Steuerungsbetriebsmittelkarte, die die RS232-Anschlüsse, eine Echtzeit-Uhr und einen System-ID-EPROM enthält, der jedes System eindeutig identifiziert.
Die Hauptsoftwarekomponenten, die innerhalb eines Hauptsteuerungsgehäuse 100 ausgeführt werden, umfassen die Anrufsteuerung zum Verwalten aller Anrufmerkmale, die auf dem Nebenstellenanlagensystem verfügbar sind, eine Datenbank zum Speichern der Nebenstellenanlagen-Programmierungsinformation in strukturierten Datensätzen, ein Dateisystem zum Bereitstellen einer Einrichtung zum Speichern und Wiedergewinnen von Dateien, eine Kundendateneingabeschnittstelle, die eine graphische Benutzerschnittstelle (GUI) zum Programmieren des Nebenstellenanlagensystems ist, ein Nachrichtenvermittlungsuntersystem zum Bereitstellen von Kommunikationsverbindungen zwischen intelligenten Knoten im System, die über eine Faser verbunden sind, ein Schaltvermittlungsuntersystem, das der Schaltvermittlungsmatrix Dienste zur Verfügung stellt, um Sprachkanäle zu vermitteln, und eine Wartungssoftware zum Überwachen und Prüfen von Komponenten im Nebenstellenanlagensystem.
Das Peripheriegehäuse 110 bietet Leitungs- und Hauptleitungskartenschnittstellen für die Verbindung analoger Telephongeräte 155 und Ansagevorrichtungen (RADs) 160 über ONS-Anschlüsse, digitaler Telephongeräte 165 über Digitalnetz- Schnittstellenschaltungs-(DNIC)-Leitungen und des öffentlichen Telephonnetzes (PSTN) über interne Hauptleitungskarten. Die RAD 160 bietet die Möglichkeit zum Abspielen von im voraus aufgezeichneten Ansagen bei der Unterstützung von Merkmalen wie z. B. automatisierten Bedienungsvorrichtungen. Das Peripheriegehäuse 110 enthält ferner einen (nicht gezeigten) Peripherieprozessor zum Unterstützen von Echtzeit-Softwarefunktionen wie z. B. Leitungs- und Hauptleitungstreibern und DSPs für den DTMF-Empfang. Wie oben angegeben, ist das Peripheriegehäuse 110 über ein Faserkabel, das sowohl Sprach- als auch Signalisierungsverkehr führt, mit dem Hauptsteuerungsgehäuse 100 verbunden.
Das DSU-Gehäuse 115 ist über ein Faserkabel, das Signalisierungs- und Sprachverkehr führt, mit der Hauptsteuerung 100 verbunden. Die DSU 115 unterstützt eine CEPT- und DSI-Formatiererkarte. Die (nicht gezeigte) CEPT-Karte bietet Unterstützung für ein digitales Privatnetz-Signalisierungssystem-(DPNSS)-Hauptleitungsprotokoll, während der DSI-Formatierer sowohl SPNSS- als auch das T1/D4-Signalisierungsprotokoll unterstützt.
Das Netzwerktor 120 bietet eine ISDN-Primärraten-Verbindung mit dem PSTN über eine Hauptleitung mittels einer (nicht gezeigten) T1/E1-Karte. Das Netzwerktor 120 ist über eine Faserverbindung zum Führen von Signalisierungs- und Sprachverkehr mit dem Hauptsteuerungsgehäuse 100 verbunden, wie oben angegeben ist.
Das Anwendungstor 125 unterstützt Computertelephonieschnittstellen, wie z. B. TAPI, um Anwendungsentwicklern einer dritten Partei zu ermöglichen, Nebenstellenanlagenfunktionen innerhalb des Systems zu überwachen und zu steuern. Das Anwendungstor 125 ist ferner über eine Faserverbindung mit dem Hauptsteuergehäuse 100 verbunden und nutzt die Host-Befehlsschnittstelle (HCI), um Informationen bei Bedarf zu und von der Nebenstellenanlage zu übertragen. Die Anwendungen, die die CTI-Schnittstelle verwenden, befinden sich im (nicht gezeigten) Anwendungs-Server, der über eine Ethernet-Verbindung über das LAN 150 mit dem Anwendungstor 125 kommuniziert.
Der Netzmanagement-Server 130 bietet Anwendungen zum Verbessern der Managementfähigkeiten des Nebenstellenanlagensystems in einer selbständigen oder netzabhängigen Umgebung. Der Server 130 kommuniziert über das Ethernet-LAN 150 mit dem Hauptsteuerungsgehäuse 100.
Der Sprachdienst-Server 135 ist wie gezeigt über ONS-Anschlüsse mit dem Peripheriegehäuse 110 verbunden und bietet Sprachpostunterstützung in wohlbekannter Weise.
Der Anrufzentralmanagement-Server 140 ist über den RS232-Anschluß mit dem Hauptsteuerungsgehäuse 100 und ferner mit dem LAN 150 verbunden und bietet Statistiken und Echtzeit-Überwachungsfunktionen für Anrufzentraloperationen unter Verwendung des Nebenstellenanlagensystems in einer Weise, die im Stand der Technik wohlbekannt ist.
Der Anrufabrechnungs-Server 145 ist ebenfalls über eine RS323-Leitung mit dem Hauptsteuerungsgehäuse 100 verbunden und bietet eine genaue Anrufabrechnung aller Anrufe, die vom Nebenstellenanlagensystem verarbeitet werden, zum Zweck der Rechnungserstellung.
Wie oben unter der Überschrift "Hintergrund der Erfindung" beschrieben worden ist und wie mittels der obigen Beschreibung mit Bezug auf 1 weiter erläutert worden ist, sind Nebenstellenanlagensysteme des Standes der Technik in einer komplexen Weise konfiguriert, die zu einer Verteuerung mit Bezug auf die Anzahl der erforderlichen PC-Plattformen beiträgt und zu einer geschlossenen Umgebung für die Anwendungsentwicklung führt.
Die 2 zeigt ein Hardware-Blockschaltbild einer Nebenstellenanlage auf PC-Basis gemäß der bevorzugten Ausführungsform, die versehen ist mit einer Hauptfasersteuerungskarte (MFC) 200, einer Ton- und Konferenzkarte 210, einer Dual-T1/E1-Karte 220, einer Sprachpostkarte 230 und einer RAD-Karte 240, die innerhalb eines PC-Gestells 250 montiert sind. Außerdem ist eine LAN-NIC 260 für die Kommunikation mit einer LAN-Nabe 270 vorgesehen, sowie eine PC-Hauptplatine 280 und andere herkömmliche Hardware, wie z. B. Plattenlaufwerke, CD-ROMs, E/A-Anschlüsse und dergleichen (nicht gezeigt).
Die MFC 200 wird verwendet, um Echtzeit-Dienste zu unterstützen, einschließlich eines Nachrichtenvermittlungssystems und eines Schaltvermittlungssystems, die im folgenden genauer beschrieben werden. Die MFC-Karte 200 bietet ferner ein Faserschnittstellenmodul (FIM), das eine Verbindung mit einem Peripheriegehäuse 110 über ein Faserkabel erlaubt, und sowohl Sprach- als auch Signalisierungsinformationen zu transportieren. Die MFC-Karte 200 enthält einen Mehrfachlieferanten-Integrationsprotokoll-(MVIP)-Busverbinder, der verwendet wird, um Sprachkanäle von der E1- oder T1-Digitalhauptleitung 220 und der Tonkonferenzkarte 210 zur MFC-Karte 200 zu transportieren, wo solche Kanäle schaltungsvermittelt werden, um eine Kommunikation zu ermöglichen. Die MFC 200 ersetzt die Schalt- und Nachrichtenvermittlungsfunktionalität, die in der Hauptsteuerungskarte des Gehäuses 100 in Nebenstellenanlagensystemen des Standes der Technik der 1 zur Verfügung gestellt wird.
Die Ton/Konferenz-DSP-Karte 210 bietet eine Tonerfassungs-, Tonerzeugungs- und Konferenzfunktionalität und ersetzt die Funktionen, die von den DSPs auf der Hauptsteuerungskarte des Steuerungsgehäuses 100 im Nebenstellenanlagensystem des Standes der Technik der 1 zur Verfügung gestellt werden. Der Ton/Konferenz-DSP 210 enthält ferner einen MVIP-Busverbinder, der verwendet wird, um DSP-Kanäle zur MFC 200 zu übertragen, wenn eine Kanalvermittlung durchgeführt wird.
Die Dual-T1/E1-Karte 220 wird verwendet, um eine Digitalhauptleitungsverbindung mit dem PSTN 170 oder mit anderen (nicht gezeigten) Nebenstellenanlagen bereitzustellen, die miteinander verbunden werden können, um ein Privatnetz zu bilden. Der MVIP-Bus wird verwendet, um Kanäle zur MFC 200 zu transportieren, wenn die Hauptleitungskanäle schaltungsvermittelt sind. Auf der T1/E1-Karte 220 können verschiedene Protokolle laufen, einschließlich DPNSS-, T1/D4- und PRI-ISDN-Hauptleitungsprotokollen.
Die Sprachpostkarte 230 bietet ONS-Anschlüsse, die mit den ONS-Karten im Peripheriegehäuse 110 verbunden sind. Die ONS-Schaltungen transportieren Sprachpostaufzeichnungen zu und von der Karte 230.
Die RAD-Karte 240 bietet ebenfalls ONS-Anschlüsse, die mit ONS-Schaltungen im Peripheriegehäuse 110 verbunden sind. Diese Schaltungen werden verwendet, um aufgezeichnete Grüße für Anrufer abzuspielen, die typischerweise in automatischen Bedienungsanwendungen verwendet werden.
In 3 ist die Softwarearchitektur gemäß der vorliegenden Erfindung genauer gezeigt.
Wie oben mit Bezug auf 1 beschrieben ist, wird die Hauptanrufsteuerungssoftware innerhalb einer Hauptsteuervorrichtung 100 ausgeführt, um eine Anrufsteuerung, eine Datenbank, ein Dateisystem, eine Benutzerdateneingabe, ein Nachrichtenvermittlungs-Untersystem, ein Schaltvermittlungs-Untersystem und eine Wartungsmöglichkeit zur Verfügung zu stellen. Gemäß der vorliegenden Erfindung wird diese identische Software, die in 3 mit 300 bezeichnet ist, in einer Windows-NT-Umgebung implementiert. Um die Hauptsteuerungssoftware 300 von einer Nicht-Windows-NT-Umgebung auf die PC-Plattform auf NT-Basis der vorliegenden Erfindung zu übertragen, wird eine Hardware-Abstraktionsschicht 305 eingesetzt, um Hardware-Register und Systemantworten und Verhaltensweisen zur Verfügung zu stellen, die von der Software 300 in ihrer herkömmlichen Nebenstellenanlagen-Umgebung erwartet werden. Die Hardware-Abstraktionsschicht 305 gemäß der vorliegenden Erfindung minimiert die Änderungen, die an der Hauptsteuerungssoftware 300 vorgenommen werden müssen, um die Software in einem Windows-NT-Betriebssystem zu implementieren.
Ein 68K-Emulator 310 ist ebenfalls vorgesehen, der sich genau wie ein 68000-Mikroprozessor (Motorola) verhält und der Hauptsteuerungssoftware 300 erlaubt, in ihrem natürlichen 68000-Binärcode zu laufen. Dies stellt sicher, daß die von der Hauptsteuerungssoftware 300 zur Verfügung gestellten Funktionen sich auf der PC-Plattform in derselben Weise verhalten wie in der natürlichen Nebenstellenanlagen-Umgebung.
Eine NT/68K-Emulaturschnittstelle 315 bietet eine Einrichtung für die Kommunikation zwischen dem NT-Betriebssystem und dem McKernel-Betriebssystem, das unter dem 68K-Emulator 310 läuft, wie im folgenden genauer beschrieben wird.
Ein Nachrichten-Untersystem 320 ist vorgesehen, das die Funktion des Nachrichtenvermittlungssystems des Standes der Technik in der Nebenstellenanlage der 1 ersetzt, und bietet eine größere Flexibilität beim Zulassen von Intervorgang- und Interprozeß-Kommunikation, als es gemäß dem Nachrichtensystem des Standes der Technik der Nebenstellenanlage der Fig. möglich ist. Trotzdem erhält das Nachrichten-Unter system 320 dasselbe Nachrichtenformat und Adressierungsschema wie das im Hauptsteuergehäuse 100 der 1 implementierte Nachrichtenvermittlungssystem.
Die Netzmanagement-Anwendung 325 kommuniziert mit der Hauptsteuerungssoftware 300 über das Nachrichten-Untersystem 320, um die Kommunikation mit einem Unternehmens-LAN 93 zu steuern, wie im folgenden genauer beschrieben wird.
In ähnlicher Weise kommuniziert die CTI-Server-Anwendung 330 mit der Hauptsteuerungssoftware 300 über ein Nachrichten-Untersystem 320, um mit zusätzlichen CTI-Anwendungen in Verbindung zu treten, wie im folgenden genauer beschrieben wird.
Die PRI-ISDN-Anwendung 335 kommuniziert ebenfalls mit der Hauptsteuerungssoftware 300 über das Nachrichten-Untersystem 320, um die Dual-T1/E1-Karte 220 über die T1/E1-(ISDN-PRI)-Hauptleitungsschnittstelle 340 zu steuern.
Die Anrufzentralmanagement-Anwendung 345 ist eine Dritte-Partei-Anwendung (in der bevorzugten Ausführungsform ein Paar von Anwendungen aus der Task-Technologie mit dem Titel "Call Center Management Tools" und "Call Casting") zum Weiterleiten von SMDR-Aufzeichnungen und Echtzeit-ACD-Berichten. In ähnlicher Weise ist die Sprachpostanwendung 350 eine Dritte-Partei-Anwendung, die unter dem Windows-NT-Betriebssystem läuft (in der bevorzugten Ausführungsform ein System, erzeugt vom Applied Voice Technology mit dem Titel "Call-Xpress"). Sowohl die Anwendungen des Anrufzentralmanagements 345 als auch der Sprachpost 350 kommunizieren mit der Sprachpostkarte 230 und der RAD-Karte 240 über eine ONS-Sprachkartenschnittstelle 355.
Die DSP-Kartenschnittstelle 360 bietet eine Kommunikationsschnittstelle zur Ton/Konferenz-DSP-Karte 210, während eine MFC-Schnittstelle 365 eine Kommunikationsschnittstelle zur MFC-Karte 200 bietet.
Die Implementierung der DPNSS- und T1/D4-Hauptleitungsprotokolle gemäß der vorliegenden Erfindung wird bewerkstelligt durch Übertragen der bestehenden DSU-Software von den CEPT- und T1-Karten der Nebenstellenanlage des Standes der Technik (1) und Laufenlassen derselben auf der Dual-T1/E1-Karte 220 auf PC-ISA-Basis. Da die Karte 220 auf einem PC beruht, ist die Hauptleitungsschnittstelle 370 für die Kommunikation mit der Hauptleitungskarte über einen NT-Treiber erforderlich.
Ein UART-Emulator 375 wird verwendet, um den von den URRT-Treibern in der Hauptsteuerungssoftware 300 erzeugten Strom von UART-Zeichen (zum Bereitstellen eines VT100-Anschlußzugriffes für Fehlerbeseitigungs- und Managementanwendungen) über die Anwendung 380 zu einem Telnet-Server 385 umzuleiten, um einen Fernzugriff auf die Hauptsteuerungssoftware 300 über ein lokales Netz (z. B. mittels eines LAN-NIC 260) zu erlauben.
Das Dateisystem für die Hauptsteuerungssoftware 300 des Standes der Technik unterstützt ein SCSI-Plattenlaufwerk. Um die Hauptsteuerungssoftware 300 auf eine PC-Umgebung zu übertragen, wird ein SCSI-Emulator 393 verwendet, um SCSI-Aufrufe vom Dateisystem der Hauptsteuerungssoftware 300 auf ein flaches NT-Dateisystem 370 zu übertragen, das alle Dateien innerhalb der Hauptsteuerungssoftware 300 darstellt.
Ein erfolgreicher Prototyp der vorliegenden Erfindung wird im folgenden mit Bezug auf die 4-14 beschrieben, der auf einer SX2000-Anrufverarbeitungs-Nebenstellenanlage des Standes der Technik beruht, die vom Einreicher der vorliegenden Anmeldung hergestellt wird. Die SX2000-Hauptsteuerungssoftware läuft auf einer Motorola-68000-Plattform und kommuniziert mit verschiedenen Hardwarevorrichtungen in einer Konfiguration, wie sie in 1 gezeigt ist.
Wie oben beschrieben worden ist, führt die Hauptfasersteuerungskarte 200 zwei Hauptfunktionen aus: die Schaltvermittlung und die Nachrichtenvermittlung. Um wie eine Nebenstellenanlage zu arbeiten, enthält die MFC-Karte 200 eine 16×16-Schaltvermittlungsmatrix 400. Um mit dem Peripheriegehäuse 110 zu kommunizieren, enthält die Nebenstellenanlage der vorliegenden Erfindung auf PC-Basis eine Nachrichtenvermittlung 410. Eine 2-Anschluß-Schnittstelle 420 behandelt Nachrichten, die über einen ISA-Bus des PC-Gestells 250 vorn Nachrichten-Untersystem 320 geleitet werden. Eine Nachrichtenleitvorrichtung 430 ist vorgesehen, um die von der MFC-Karte 200 empfangenen Nachrichten zu sortieren und zur beabsichtigten Prozessoranwendung umzuleiten. Gemäß der vorliegenden Erfindung können Nachrichten zur Nachrichtenvermittlung 410, zur Schaltvermittlung 400 oder zum Peripheriegehäuse 110 geleitet werden.
Wie oben beschrieben worden ist, ist die Nachrichtenvermittlung 410 verantwortlich für das Unterstützen des Nachrichtenverbindungsprotokolls des Standes der Technik innerhalb der Hauptsteuerungssoftware 300 mit dem Peripheriegehäuse 110. Die Nachrichtenvermittlung 410 ist ferner verantwortlich für das Herunterladen, Zuweisen einer Steuervorrichtungsnummer und Informieren der Hauptsteuerungssoftware über den aktuellen Status der Peripherienachrichtenverbindung.
Ein wichtiger Aspekt der vorliegenden Erfindung ist der Entwurf des 68K-Emulators 310 zum Verarbeiten von Programmen, die für den Prozessor 68000 von Motorola geschrieben worden sind, auf der Intel-80×86-Mikroprozessorplattform der bevorzugten Ausführungsform und die Wiederverwendung bestehenden Anrufverarbeitungscodes (d. h. der Hauptsteuerungssoftware 300) auf der Windows-NT-Plattform.
Die 5 zeigt die Hauptunterbereiche und die Interaktionen zwischen dem 68K-Emulator 310 gemäß der vorliegenden Erfindung.
Die sechs Hauptunterbereiche sind: der 68K-Emulator 310, der Ausnahmebehandler 500, die C-Schnittstelle 510 (synchron und asynchron), der SX2000-Code 520, der Unterbrechungsbehandler 530 und ein gemeinsam genutzter Speicher 540.
Während der Anlaufsequenz des Emulators 310 wird der SX2000-Code 520 aus der Datei geladen und im Speicher 540 gespeichert. Der reservierte Speicher enthält ausreichend Raum für den Systemhauptspeicher, einen Erweiterungs-DRAM, eine EPROM-Ladung und Raum für gemeinsam genutzten Speicher und Hardwareverbindungen. Der Raum ist aus der Sicht des 2000-Codes 520 durchgehend. Der Speicher muß physikalisch nicht durchgehend sein, jedoch führt das Windows-NT eine Hintergrundarbeit durch, um sicherzustellen, daß der vom Emulator 310 gesehene virtuelle Speicherraum nicht als ein durchgehender Abschnitt erscheint und sich so verhält. Die SX2000-Laufdatei wird unter Verwendung eines S-Aufzeichnungsformats gespeichert. Dieses Format spezifiziert, wo innerhalb des Speichers jeder Abschnitt der Ladung anzuordnen ist. Die S-Aufzeichnung (oder die Aufzeichnungen, wenn eine für die Hauptladung und eine für den EPROM und dergleichen vorgesehen ist) wird direkt als Datei gelesen.
Die Hauptfunktion des Emulators 310 besteht darin, den bestehenden SX2000-Code 520 (der so beschaffen ist, daß er die Motorola-68000-Prozessorarchitektur vorteilhaft ausnutzt, und somit sehr eng an diese Architektur gekoppelt ist) anzunehmen und diese auf einer Intel-80×86-Plattform laufen zu lassen. Aufgrund der unterschiedlichen Prozessorstruktur (Registerstruktur, Befehlssatz und dergleichen) wird jeder 68K-Befehl in eine Serie von 80×86-Befehlen übersetzt und emuliert. Der Emulationscode wird in einer großen Tabelle angeordnet, die mit dem 16-Bit-68K-Befehscode indiziert wird. Dies erzeugt eine Tabelle mit ungefähr 47.000 Einträgen von jeweils zwischen fünf und zehn Zeilen. Insgesamt sind 65.000 verfügbar, jedoch entsprechen einige ungültigen Bitmustern, die zum Zeitpunkt der Einreichung dieser Patentanmeldung von Motorola nicht verwendet werden. Um ein Programm laufen zu lassen, nimmt der 68K-Emulator 310 jeden 68K-Befehl (liest ihn aus dem Speicher), greift auf die Tabelle zu, um den Emulationscode (Serie von Befehlen) zu finden, und führt den Emulationscode aus. Der 68K-Emulator 310 und die Befehle sind in der 80×86-Assemblersprache geschrieben, um die Effizienz und Geschwindigkeit zu maximieren. Sobald ein Befehl verarbeitet worden ist, führt der Emulator 310 automatisch den nachfolgenden Befehl aus. Dieser Prozeß wird unendlich fortgesetzt, solange keine Ausnahmebehandlung 500 eine zu verarbeitende Unterbrechung erfordert.
Ausnahmen (Software und Unterbrechungen) werden innerhalb der Assemblerschleife des 68K-Emulators 310 behandelt. Diese umfassen sowohl Hardwareunterbrechungen (die wie im folgenden beschrieben extern gesetzt werden) oder Sortwareausnahmen (der SX2000-Code 520 beruht auf den dazwischen enthaltenen Hantierern, wie z. B. denjenigen zum Unterstützen der Niedrigebene-Fehlerbeseitigungsfunktion LDD). Ausnahmen können extern ausgelöst werden, um den Ausführungsablauf zu verfolgen, oder können intern ausgelöst werden, um anzuzeigen, daß eine externe Verarbeitung erforderlich ist.
Die C-Schnittstelle 510 unterstützt die Übertragung zwischen der emulierten Verarbeitung und der ursprünglichen Verarbeitung. Wenn eine "C"-Funktion (ursprüngliche Funktion, die außerhalb der emulierten 68K-Umgebung geschrieben worden ist) ausgeführt werden muß, wird eine spezielle Ausnahme ("Ausgangsemulator") vom Emulator 310 ausgelöst (im SX2000- Code 520 codiert). Die Ausnahme verschiebt den Operationsablauf aus dem 68K-Emulator 310 heraus, wo der Ausnahmebehandler 500 feststellt, welcher Typ von Ausnahme aufgetreten ist. Im Fall einer Fehlerbedingung werden Korrekturmaßnahmen ergriffen. Für eine Ausnahme "verlasse Emulator" wird der auszuführende numerierte Funktionstyp wiedergewonnen (der in einem speziellen Register mittels der SX2000-Funktion, die die Ausnahme anfordert, gespeichert worden ist) und die entsprechende Funktion wird gestartet. Die Funktionen sind in den "C"- und 68K-Umgebungen (beginnend von einer einzigen Datei) identisch numeriert, um sicherzustellen, daß die richtige Funktion ausgeführt wird.
Die ausgewählte Funktion kann entweder in ihrer Eigenschaft synchron oder asynchron sein. Für synchrone Funktionen wird die Steuerung von der Funktion bis zu ihrem Abschluß zurückgehalten, wobei zu diesem Zeitpunkt die Steuerung (gemeinsam mit irgendwelchen berechneten/gesammelten Daten) an den 68K-Emulator 310 zurückgegeben wird. Asynchrone Funktionen (wie z. B. eine lange Eingabe/Ausgabe) bilden einen separaten Vorgang 550 in der NT-Umgebung, innerhalb der die Verarbeitung fortgesetzt wird, und geben sofort die Steuerung an den 68K-Emulator 310 zurück.
Innerhalb des SX2000-Codes blockiert der McKernal (d. h. das Betriebssystem/der Einteiler) den Prozeß (aus der Bereitschaftswarteschlange entnommen) und setzt die Ausführung mit anderen Prozessen fort. Es ist zu beachten, daß es zwei preemptive Betriebssysteme auf Prioritätsbasis gibt, die gleichzeitig laufen – McKernel innerhalb eines Windows-NT-Vorgangs. Nach dem Abschluß setzt die erzeugte Aufgabe eine Unterbrechung und plaziert irgendwelche Rückgabedaten im gemeinsam genutzten Speicher 540. Die Verarbeitung der Unterbrechung mittels des 68K-Emulators 310 veranlaßt den McKernel, die Daten wiederzugewinnen und den blockierten Prozeß in die Bereitschaftswarteschlange zurückzustellen.
Die Routinen der C-Schnittstelle 510 und des Unterbrechungsbehandlers 530 erlauben dem SX2000-Code 520, mit einer Codeausführung zu kommunizieren, die NT entspricht.
Ein wichtiger Aspekt des Emulators 310 ist die Verteilung der Funktionalität innerhalb von Aufgaben und die Einteilung der Priorität derselben. Die CPU-Betriebsmittel müssen unter verschiedenen Anwendungen aufgeteilt werden (d. h., den vielen von der Nebenstellenanlage auf PC-Basis benötigten Aufgaben und anderen Prozessen, die ebenfalls in der NT-Plattform vorhanden sind, wie z. B. die CTI-Server-Anwendung 330). Es wird angenommen, daß anfangs die Hauptsteuerungssoftware 300 ungefähr 70 % der gesamten CPU-Betriebsmittel benötigt, wobei die restlichen 30 % von allen anderen Anwendungen verwendet werden sollen (z. B. der Netzmanagementanwendung 325, der CTI-Server-Anwendung 330 und dergleichen).
Die Hauptsteuerungssoftware 300 und somit auch der Emulator 310 führen zeitkritische Aufgaben aus und werden somit in regelmäßigen Zeitintervallen eingeteilt. Die Zeitsteuerung wird bewerkstelligt mittels (nicht gezeigten) Multimedia-Zeitgebern, mit einer verfügbaren Auflösung von bis zu 1 ms. Die Einteilung soll die im folgenden angegebenen Kriterien erfüllen:

• Sollte McKernel in seine Leerlauf schleife eintreten, werden die CPU-Betriebsmittel für andere Vorgänge innerhalb der Hauptsteuerungssoftware 300 freigegeben (d. h. das Ereignis löst die primären Aufgaben aus, um die Vorgangsausführung des 68K-Emulators zurückzustellen).
• Sollte die Hauptsteuerungssoftware 300 ihre Aufgabe vor dem Ablauf ihrer zugewiesenen Zeitspanne abschließen, stellt der Prozeß irgendwelche restlichen Betriebsmittel anderen Prozessen zur Verfügung.
• Sollten andere Anwendungen ihren Bedarf an CPU-Betriebsmitteln vor Abschluß ihrer zugewiesenen Zeitspanne aufgeben, werden die Betriebsmittel der Hauptsteuerungssoftware 300 angeboten.
• Innerhalb des Systems ist dem Emulator 310 die höchste Priorität zugewiesen, mit folgenden Ausnahmen: der Unterbrechungsvorgang 530 muß fähig sein, Informationen innerhalb des Emulators 310 einzuschieben, und die Zeitgeberfunktion muß in Echtzeit durchgeführt werden.

Wie oben beschrieben, arbeitet das Emulatorprogramm 310, um jeden 68000-Befehl durch einen Satz von Intel-Befehlen zu ersetzen, die eine identische Aufgabe ausführen und motorola-ähnliche Register unterstützen. Gemäß einem weiteren Aspekt der Erfindung werden die 45.000 Routinen automatisch von einem Generatorprogramm vorbereitet, wie in der anhängigen Anmeldung Nummer –, eingereicht am –, mit dem Titel "Emulation System Including Emulator Generator" beschrieben ist.
Obwohl der 68K-Emulator 310 eine volle Emulation des Motorola-68000-Chips bietet, bietet die Nebenstellenanlage auf PC-Basis der vorliegenden Erfindung keine echte Hardware, die der SX2000-Code 520 normalerweise erwartet, um mit dieser zu kommunizieren. Wie oben kurz beschrieben worden ist, ist somit eine Hardware-(HW)-Abstraktionsschicht 305 vorgesehen, um die fehlende Hardware zu emulieren und einzuführen (d. h. eine identische Funktion mit einer anderen Schnittstelle zu bieten, während eine Schnittstelle für den bestehenden Code so ähnlich wie möglich gehalten wird), um dieselbe Funktion in der Software durchzuführen, ohne Einzelheiten der Hardware zu emulieren. Zum Beispiel wird die LLD-Ausgabe der Zeichen auf einem CRT-Bildschirm auf dem System der 1 über eine UART bewerkstelligt. Statt das UART-Protokoll für die Übertragung von Zeichen zu emulieren, gibt die HW-Abstraktionsschicht 305 die Zeichen direkt in ein Fenster aus, unter Verwendung des Standardverfahrens zum Drucken von Zeichen auf dem Bildschirm. Der Abschnitt des SX2000-Codes 520, der die fragliche Hardware manipuliert, wird entfernt. Insbesondere die Schnittstelle zwischen dem Emulator 310 und dem C-Code 520 wird von der Assembler-Datei aufgerufen, wobei die Funktion anschließend im C-Code implementiert wird. Der prinzipielle Vorteil dieses Verfahrens ist die Geschwindigkeitssteigerung, die erhalten wird durch Ersetzen einer langsamen und häufig ineffizienten Hardwareemulation des Assembler-Gerätetreiber-Codes durch einen ursprünglichen C-Code, der für die ursprüngliche Plattform gebildet worden ist.
Um den Code 520 auf dem Motorola-68000-Emulator 310 auszuführen, ist es notwendig, die Speicherabbildung für das zu emulierende System anzupassen. Diese Abbildung wird mit mehreren C-Strukturen auf der Windows-NT-Plattform überlagert, um die Schnittstelle zum emulierten SX2000 von C so einfach wie möglich zu machen.
Einige der Hardwareabstraktionen der Komponenten sind wie folgt implementiert:
Vernunft-Zeitgeber
Der Vernunft-Zeitgeber wird im gesamten Code 520 verwendet, und wird aus diesem Grund bei der Implementierung der Anruf-Server-Architektur gemäß der Erfindung beibehalten. Diese Hardware wird emuliert, so daß keine Änderungen an irgendeinem Code erforderlich sind, der diesen Zeitgeber nutzt.
Programmierbarer Zeitgeber
Die programmierbaren Zeitgeber werden meist von McKernel benutzt, um die Aufgaben und andere Betriebssystemfunktionen einzuteilen. Diese Zeitgeber müssen für die Operation des SX2000-Anrufservers zur Verfügung gestellt werden. Windows-NT bietet mehrere Multimedia-Zeitgeber, die eine Millisekundenauflösung besitzen, die für diese Aufgabe geeignet ist.
Echtzeituhr
Die Echtzeituhr wird in verschiedenen Anwendungen des Anrufservers verwendet, einschließlich der Zeitstempelung von Dateien. Die Systemuhr des PC wird verwendet, um irgendwelche Rücksprünge von Aufrufen an die Echtzeituhr zurückzugeben.
EPROM-Chip
Der EPROM ist implementiert unter Verwendung eines Segments der Hauptspeichermatrix des Emulators 310.
Hauptspeicher
Wie oben beschrieben worden ist, ist der Hauptspeicher als eine Matrix implementiert, die im Speicherraum des Emulatorprozesses liegt.
SX2000-Register
Die Register, wie z. B. das Unterbrechungsursachenregister und das Statusregister, sind für die Kompatibilität mit dem bestehenden SX2000-Code 520 implementiert und sind an festen Stellen am Ende der Hauptspeichermatrix angeordnet. Um die Stellen der Hardwareregister zu ändern, wurden Änderungen an den Hardwareadreßtabellen vorgenommen, die vom SX2000 verwendet werden.
Die SCSI-Hardware der Nebenstellenanlage des Standes. der Technik der 1 wird vom Treiber der physikalischen Schicht gesteuert. Der Treiber empfängt die SCSI-Anfragen vom Massenspeicher-Untersystem (MSS-Schicht 600), das mit vielen SX2000-Komponenten in Verbindung steht, die dargestellt werden durch "Rest der Welt" 610. Die Hauptsoftwareblöcke und Schnittstellen sind in 6 gezeigt. Der SCSI-Emulator 392 wird geschaffen durch Umleiten von SCSI-Anfragen, die von der MSS-Schicht 600 (an die physikalische Schicht 630) ausgegeben werden, zur NT-Umgebung. Zwei Betriebsarten werden im SX2000-System verwendet (auf Polling-Basis und auf Unterbrechungsbasis). Dementsprechend werden zwei Sätze von Funktionen emuliert.
Zusätzlich zur Anfragenabbildung findet eine Plattformumsetzung (Intel – Motorola) für jeden Parameter statt, der zwischen den Umgebungen weitergeleitet wird.
Die Initialisierung des SX2000-Systems verwendet den Polling-Modus, während die angeforderte Operation abgeschlossen sein muß, bevor das SX2000-System die Ausführung des nächstem Maschinenbefehls fortsetzt, wie in 7 gezeigt ist.
Jede synchrone E/A-Anfrage wird durch eine Funktion ersetzt, die Parameter an Register weiterleitet und anschließend eine Ausnahme erzeugt. Die Ausnahme führt die Anfrage aus. Sobald die E/A abgeschlossen ist, wird der Rücksprungstatus zum SX2000-Code 520 zurückgegeben. Die Ausführung fährt mit dem nächsten Befehl innerhalb derselben SX2000-Aufgabe fort. Während des Normalbetriebs (d. h. Mehrfachverarbeitung) wird der Unterbrechungsmodus verwendet, so daß die SX2000-Aufgabe eine Operation einleitet und sich selbst zurückstellt, bis die Operation abgeschlossen ist. Sobald die angeforderte E/A abgeschlossen ist, wird die zurückgestellte SX2000-Aufgabe wieder aufgenommen, wie in 8 gezeigt ist.
Jede asynchrone E/A-Anforderung wird durch eine Funktion ersetzt, die Parameter an Register weiterleitet und eine Ausnahme erzeugt. Die Ausnahme leitet die Anfrage an den E/A-Vorgang weiter und kehrt zurück. Die aktuelle SX2000-Aufgabe wird zurückgestellt. Sobald die E/A in der NT-Umgebung abgeschlossen ist, setzt der E/A-Vorgang den Unterbrechungsstatus im gemeinsam genutzten Speicher. Der Emulator liest den Unterbrechungsstatus und, falls dieser gesetzt ist, fährt mit der zurückgestellten Aufgabe fort.
Wie in 9 gezeigt, gibt es drei unterschiedliche Schichten, die in der C-Schnittstellenarchitektur definiert sind. Die SX2000-Schicht 900 enthält die C-Schnittstelle-API 902 und eine Generatorfalle 904, die den Einsprungpunkt für die C-Schnittstelle vom SX2000-Coderaum 520 definieren. Die C-Schnittstellenschicht 910, die eine Token-Leitvorrichtung 915 enthält, ermittelt, zu welchem Element ein Token weiterzuleiten ist, während die Knotenschicht 920 Entwicklerelemente (Knoten) enthält, die benutzerdefinierte C-Schnittstellen-Tokens (CTIs) behandeln. Gemäß der bevorzugten Ausführungsform ist die Funktionalität in einzelnen Knoten 930 gruppiert, statt über Knoten verteilt zu sein. Zum Beispiel sind alle Dateisystemfunktionen in einem Dateisystemknoten gruppiert, wobei Unterknoten-Leitinformationen innerhalb der Nutzlast des CIT zur Verfügung gestellt werden, statt im CIT-Vorspann.
Die C-Schnittstellenarchitektur der 9 zeigt eine "Einbahnfunktion" in dem Sinne, daß Tokens konzeptionell vom SX2000-Coderaum 520 gesendet und empfangen werden. Ein Entwickler kommuniziert mit der C-Schnittstelle vom SX2000-Raum 520 unter Verwendung der Standard-C-Schnittstellen-APIs 902. Die CI-APIs 902 erzeugen eine TRAP, um den Windows-NT-Raum zum Zweck der Weiterleitung des Zeigers auf eine CIT, die im SX2000-Raum 520 definiert ist, im Windows-NT-Raum zu codieren. Die TRAP-Behandlungsvorrichtung 904 nimmt den Zeiger auf die CIT und setzt diesen in das Windows-NT-Speicherzeiger-Äquivalent um und leitet den neuen Zeiger an die C-Schnittstellenleitvorrichtung 915 weiter, wodurch das Token weitergeleitet wird. Die C-Schnittstellenleitvorrichtung 915 untersucht anschließend den Vorspann, um zu ermitteln, welcher Knoten 930 das Token empfangen soll. Um die C-Schnittstelle zu verwenden, müssen Entwickler ein benutzerdefiniertes Token im SX2000-Speicherraum zur Verfügung stellen und freie Funktionen vom erzeugten Knoten 930 exportieren, der das Token behandelt. Die drei Funktion sind klassifiziert als Initialisierungs-, Deinitialisierungs- und Tokenweiterleitungsfunktionen.
Das System der vorliegenden Erfindung erleichtert die DX-Nachrichtenweiterleitung zwischen der bestehenden SX2000-Software 300, die in einer 68K-Emulatorumgebung 310 läuft, und NT-Vorgängen (siehe 5) sowie Erbschaft-SX2000-Peripherieknoten 110. Auf der SX2000-Seite bietet die bestehende SX2000-DX-Nachrichtensystemschnittstelle verschiedene DX-Nachrichtenlieferdienste, die wiederverwendet werden, um die Stabilität der bestehenden SX2000-Software sicherzustellen. Auf der NT-Seite werden dieselben DX-Nachrichtenlieferdienste den NT-Vorgängen zur Verfügung gestellt, so daß die NT-Vorgänge richtig über die DX-Nachrichten mit den SX2000-Prozessen kommunizieren. Die DX-Nachrichtenlieferdienste auf der NT-Seite werden über einen Satz von Nachrichtensystem-ABIs zur Verfügung gestellt, die im folgenden genauer beschrieben werden.
Die Erbschaft-SX2000-Nachrichtenweiterleitungsdienste für McKernel-Anwendungen sind folgende:

1. Die reguläre Nachrichtenweiterleitung läuft über eine 32-Byte-DX-Nachricht. Im SX2000-Nachrichtensystem werden Funktionen, wie z. B. Send, Send_Reply, Receive_Any, Receive_Specific, Receive_Reply, verwendet, um reguläre Nachrichten weiterzuleiten.
2. Die Langnachrichtenweiterleitung läuft über lange Nachrichten mit 120 Bytes. Send_Long und Receive Long werden zum Weiterleiten langer Nachrichten verwendet.
3. Die Weiterleitung superlanger Nachrichten läuft über eine superlange Nachricht, die 403 Bytes umfaßt. Super_Send_Long und Super_Receive_Long werden verwendet, um superlange Nachrichten weiterzuleiten.

Die Hauptsteuerungssoftware 300 kommuniziert mit der Netzmanagementanwendung 325 unter Verwendung des Nachrichtenmechanismus, der vom Nachrichtenuntersystem 320 zur Verfügung gestellt wird. Die 10 bietet eine Hochebene-Ansicht der Kommunikationssoftware, die in der Nebenstellenanlage auf PC-Basis der vorliegenden Erfindung vorhanden ist, sowie deren Wechselwirkung mit der Netzmanagementanwendung 325.
Die MNMS-Kommunikationseinrichtung bietet einen Mechanismus für Client-Anwendungen 1200 auf der Netzmanagementanwendung 325 zum Austauschen von Netzmanagementinformationen mit einer Server-Anwendung 1205 auf einem entfernten Anrufserver 1210. Es können mehrere Instanzen der MNMS-Kommunikationseinrichtung vorhanden sein (oder der MNMS-Leitung), da die Netzmanagementanwendung 325 konkurrierende Verbindungen zu mehreren unterschiedlichen Netzelementen halten kann. Jede Leitung kann von den Anwendungen zu dem Netzelement ihrer Wahl geschaltet werden. Die Leitung erlaubt ferner eine gemeinsame Nutzung, so daß mehrere Netzmanagementanwendungen 325 gleichzeitig über die Leitung zu entsprechenden Peer-Anwendungen auf der Nebenstellenanlage kommunizieren können. Die Kommunikation wird über eine zuverlässige TCP/IP-Sockelverbindung zwischen der Netzmanagementstation und ihrem Peer-Anrufserver über eine OPS-Managerkommunikation-API 1201, ein Nachrichtensystem 1202, ein Einfachsockelwerkzeug 1203 (SSU) und einen Ethernet-Anschluß 1204 auf der Netzmanagementseite geführt. Auf der Anrufserverseite wird die Kommunikation über den Ethernet-Anschluß 260, das SSU 1206 und das Nachrichtensystem 320 geführt.
Die UDT-Kommunikationseinrichtung (oder UDT-Leitung) erlaubt Client-Anwendungen 1215 auf dem entfernten Anrufserver 1210, eine Ereignisanzeige zu einer Serveranwendung 1220 auf der Netzmanagementanwendung 325 zu senden. Die Verbindung wird auf Anforderung eingerichtet, wenn eine Client-Anwendung auf dem Anrufserver eine Ereignisanzeige zu ihrer Peer-Anwendung auf der Netzmanagementanwendung senden muß. Wie bei der MNMS-Leitung wird die UDT-Leitungskommunikation über eine zuverlässige TCP/IP-Sockelverbindung geführt.
Die Telnet-Einrichtung bietet einen Fernzugriff auf einen Wartungsanschluß am Fern-Anrufserver 1210. Dieser Dienst erlaubt einer beliebigen Telnet-Client-Anwendung 380, entweder mit dem Wartungsanschluß oder dem Fehlerbeseitigungsanschluß Verbindung aufzunehmen. Eine gemeinsame Nutzung ist auf dieser Leitung ebenfalls zulässig.
Die Dateiübertragungseinrichtung bietet einen Mechanismus für Anwendungen 1225 auf dem entfernten Anrufserver 1210 zum Heraufladen und Herunterladen einzelner oder mehrerer Dateien zu/von einem FTP-Server 1230 auf der Netzmanagementanwendung 325. Dieser Dienst nutzt das wohlbekannte FTP-Protokoll.
In 11 ist das Nachrichtenuntersystem 320 genauer gezeigt. Die Anwendungen müssen sich mit dem Nachrichtenuntersystem registrieren. Während der Registrierung weist das Nachrichtenuntersystem jedem Vorgang 1307 Nachrichtenwarteschlangen zu. Wenn der Vorgang für den Nachrichtenuntersystemprozeß (z. B. Proxy 1309) nicht lokal ist, wird an schließend das SSU 1206 verwendet, um eine Sockelverbindung zwischen zwei Prozessen 1301 und 1309 einzurichten. Wenn Nachrichten gesendet werden, stellt das Nachrichtenuntersystem 320 die Nachricht in die Hauptwarteschlange 1300 oder die SX2000-Warteschlange 1305, in Abhängigkeit vom Ziel. Das Nachrichtenuntersystem sortiert anschließend die Nachrichten und liefert diese an die Anwendungswarteschlange.
Die DSP-Dienste für die Nebenstellenanlage auf PC-Basis der vorliegenden Erfindung werden von einer PCI-DSP-Karte 210 zur Verfügung gestellt, die DSP-Betriebsmittel und eine lokale Vermittlungsmöglichkeit bietet. Die DSP-Karte 210 bietet die folgenden Betriebsmittel für die Nebenstellenanlage: Tonerzeugung, Tonerfassung, Konferenz und DTMF-Empfänger. Die Karte 210 bietet eine lokale Vermittlung für den MVIP-Bus und unterstützt bis zu vier DSP/ASIC-Paare.
Ein DSP-Gerätetreiber 360 ist vorgesehen, der den Satz der Normen folgt, die für generische Gerätetreiber in der Windows-NT-Umgebung definiert sind.
Um die DSP-Betriebsmittel zu managen, die von der PCI-DSP-Karte 210 zur Verfügung gestellt werden, werden mehrere Module benötigt. Dies sind die DSP-API-Schicht 1400, der DSP-Betriebsmittelmanager 1402, der DSP-Manager 1404, der Ton-Subervisor 1406, der Kadenz-Manager 1408, der DSP-Klassentreiber 1410 und der DSP-Treiber 1412.
Die DSP/Konferenz-Architektur der 12 kann ebenfalls mittels eines Schichtmodells mit fünf unterschiedlichen Schichten dargestellt werden, wie in 13 gezeigt ist: die DSP-Dienst-Anforderer-Schicht 1500, die DSP-API-Schicht 1400, die Betriebsmittelmanagementschicht 1505, die Gerätetreiberschicht 1510 und die physikalische Schicht 1515. Die DSP-Dienst-Anfordererschicht 1500 umfaßt alle Clients für die DSP-Dienste. Die DSP-API-Schicht 1400 empfängt alle Anfragen von der DSP-Dienst-Anforderer-Schicht 1500 und leitet diese an die Betriebsmittelmanagementschicht 1505 weiter. Die Gerätetreiberschicht 1510 ist die Schicht, die direkt mit den physikalischen Vorrichtungen in Wechselwirkung tritt. Die physikalische Schicht 1515 definiert die physikalischen Vorrichtungen auf der PCI-DSP-Karte 210. Der E/A-Manager 1520, der ein Teil von Windows-NT ist, ist im Schichtmodell der 13 der Vollständigkeit halber enthalten.
Der Client für die DSP-Dienste benötigt kein Wissen über irgend etwas unterhalb der DSP-API-Schicht 1400. Somit werden irgendwelche Änderungen der Schichten unterhalb der API-Schicht vom Client der DSP-Dienste gekapselt, was die Robustheit des DSP-Algorithmus deutlich verbessert. Die Gerätetreiberschicht 1510 entspricht dem Windows-NT-Treibermodell.
Die virtuelle Konferenzkarte 1414 ist ein Teil des Nachrichtensystems. Ihre Funktion besteht darin, die Konferenz-DSU-Nachrichtenschnittstelle zu unterstützen und sie für den Konferenz-DSP (einen der DSPs 1417) zu übersetzen. In der Nebenstellenanlage auf PC-Basis der vorliegenden Ausführungsform wird die Konferenzfunktion von der PCI-DSP-Karte 210 behandelt. Jede Konferenz, die angefordert wird, wird über das Nachrichtensystem 320 an den DSP-Manager 1404 weitergeleitet, der für das Managen aller DSP-Betriebsmittel verantwortlich ist.
Eine virtuelle ATD-Karte 1416 ist als Teil des Nachrichtensystems vorgesehen. Ihre Funktion ist, die ATD-DSU-Nachrichtenschnittstelle zu unterstützen und diese für den Ton-Detektor-DSP (einen der DSPs 1417) zu übersetzen. In der Nebenstellenanlage auf PC-Basis der bevorzugten Ausführungsform wird die Tondetektorfunktion von der PCI-DSP-Karte 210 behandelt. Alle DTMF/Ton-Detektoranfragen werden an den DSP- Manager 1404 weitergeleitet, der für das Managen aller DSP-Betriebsmittel verantwortlich ist.
Die DSP-API-Schicht 1400 bietet eine Abstraktionsschicht für die DSP-Dienste. Diese Schicht sammelt alle Ton- oder Betriebsmittelanforderungen und leitet diese an den Ton-Supervisor 1406 bzw. den Betriebsmittelmanager 1402 weiter. Die Betriebsmittelanfragen werden in zwei Kategorien unterteilt: Anfragen für DSP-Betriebsmittel und Anfragen zum Steuern eines FMIC-Chips 1418 auf der PCI-DSP-Karte 210. Der Zweck der DSP-API-Schicht 1400 ist, alle hardwarespezifischen Informationen vom Betriebsmittelanforderer zu kapseln. Somit kann eine beliebige Anwendung die DSP-Karte 210 nutzen, indem sie einfach mit der geeigneten API in Wechselwirkung tritt. Dieses Merkmal verbessert die Übertragbarkeit der DSP-Karte 210 erheblich.
Der Ton-Supervisor 1406 ist verantwortlich für die Behandlung aller Tonanfragen, die von der API-Schicht 1400 weitergeleitet werden. Während der Systeminitialisierung prüft der Ton-Supervisor auf irgendwelche reinen Töne, die permanent auf den Übertragungskanälen erzeugt werden sollen. Der Supervisor 1406 fordert anschließend alle diese reinen Töne vom DSP 210 an. Die Frequenz der reinen Töne und die ST-Verbindungskanäle, auf denen diese reinen Töne erzeugt werden, sind in der Tabelle innerhalb des Ton-Supervisors 1406 gespeichert. Wenn eine Tonanfrage zu einem späteren Zeitpunkt empfangen wird, durchläuft der Ton-Supervisor 1406 die Tabelle, um den ST-Verbindungskanal zu lokalisieren, auf dem die Reintonkomponente erzeugt wird. Der Ton-Supervisor 1406 ist ferner verantwortlich für das Anweisen des Kadenz-Managers 1408, um Tonkadenzen auf einem gegebenen Kanal zu erzeugen. Die Tonkadenz wird erzeugt durch Verbinden und Trennen eines gegebenen Kanals auf dem MVIP-Bus mit einem der Reintonkanäle auf einer der vier ST-Verbindungen gemäß einem gegebenen Tonplan. Die Verbindung und Trennung der Kanäle wird bewerkstelligt über die FMIC 1418 auf der DSP-Karte 210 mittels eines FMIC-Gerätetreibers 1409.
Der Kadenzmanager 1408 dient zum Managen der Kadenz der Töne. Die Kadenz der Töne wird erzeugt durch Freigeben und Sperren eines Tons auf einem gegebenen Kanal durch Verbinden und Trennen dieses gegebenen Kanals mit dem Tonkanal. Wie oben beschrieben, werden die vier ST-Verbindungen, die die Tonkanäle enthalten, über die FMIC 1418 mit dem MVIP-Bus auf der PCI-DSP-Karte 210 verbunden. Somit wird die Verbindung zwischen dem Tonkanal und dem MVIP-Buskanal innerhalb der FMIC wiederholt hergestellt und unterbrochen, um eine Tonkadenz auf einem gegebenen MVIP-Buskanal zu erzeugen. Um eine Verbindung mit der FMIC 1418 herzustellen und zu unterbrechen, sendet der Kadenzmanager 1408 eine Verbinde/Trenne-Nachricht zum FMIC-Gerätetreiber 1409. Der Kadenzmanager 1408 baut die Kadenzzeitsteuerung auf einer periodischen Hardwareunterbrechung alle 50 ms auf. Immer wenn diese periodische Unterbrechung auftritt, weckt der Unterbrechungsbehandler 1420 den Kandenzmanager 1408 auf, um die Tonkadenz auf einem Kanal zu erzeugen, der die Kadenzwarteschlange ist. Wenn keine weiteren Tonkadenzen zu erzeugen sind, maskiert der Kadenzmanager diese periodische Unterbrechung aus, bis eine neue Tonkadenzanforderung empfangen wird. Die Vorgangspriorität des Kandenzmanagers 1408 ist auf den höchstmöglichen Pegel gesetzt, um eine kritische Zeitsteuerung in der Tonkadenz sicherzustellen.
Der DSP-Betriebsmittelmanager 1402 enthält Informationen über die Verfügbarkeit aller DSP-Betriebsmittel auf der PCI-DSP-Karte 210. Während der Karteninitialisierung erzeugt der Betriebsmittelmanager 1402 alle Instanzen des DSP-Managers 1404, die zum Managen aller DSPs auf der PCI-DSP-Karte 210 gemäß der Betriebsmitteltabelle erforderlich sind. Die Anzahl der DSP-Managerinstanzen 1404, die benötigt werden, ist in der Betriebsmitteltabelle im Betriebsmittelmanager 1402 definiert. Die Betriebsmitteltabelle weist alle verfügbaren Betriebsmittel von jedem DSP-Manager 1404 aus. Wenn eine Betriebsmittelanforderung von der API-Schicht 1400 empfangen wird, nutzt der Betriebsmittelmanager 1402 die Betriebsmitteltabelle, um zu ermitteln, welche Instanz des DSP-Managers 1404 auf die empfangene Anforderung antworten soll. Der Betriebsmittelmanager 1402 sendet anschließend eine Anfrage zum DSP-Manager. Wenn die Anfrage gewährt wird, entfernt der Betriebsmittelmanager 1402 dieses Betriebsmittel aus den verfügbaren Betriebsmitteln in der Betriebsmitteltabelle für die entsprechende DSP-Managarinstanz 1404, bis das Betriebsmittel wieder freigegeben wird. Die Verwendung von Betriebsmittelanfragen zwischen dem Betriebsmittelmanager 1402 und dem DSP-Manager 1404 ergibt eine Flexibilität hinsichtlich der dynamischen Betriebsmittelzuweisung. Wenn somit ein DSP-Manager 1404 die Betriebsmittelanforderung zurückweist, durchläuft der Betriebsmittelmanager 1404 die Betriebsmitteltabelle, um einen Dienst vom nächsten DSP-Manager 1404 in der Leitung anzufordern. Der DSP-Betriebsmittelmanager 1402 liegt im Kernraum der Windows-NT-Umgebung, um eine häufige Kommunikation über einen E/A-Manager zu vermeiden.
Jede Instanz des DSP-Managers 1404 ist verantwortlich für das Managen der Nutzung eines einzelnen DSP 1417. Während der Initialisierung des DSP definiert der Manager 1404, welche Art von Betriebsmittel und wieviele Betriebsmittel vom DSP verfügbar sind. Anschließend managt der DSP-Manager 1404 den Betriebsmittelstatus auf dem DSP. Der Status des DSP selbst wird ebenfalls vom DSP-Manager gemanagt. Immer wenn der Status des DSP wechselt, informiert der DSP-Treiber 1412 den DSP-Manager 1404. Eine Anfrage für ein DSP-Betriebsmittel wird auf der Grundlage sowohl des Status der DSP-Betriebsmittel als auch des Status des DSP selbst gewährt. Der DSP-Manager 1404 liegt als Nachrichtentreibervorgang vor, der nur dann aufwacht, wenn eine Betriebsmittelan forderung vom DSP-Betriebsmittelmanager 1402 empfangen wird, oder wenn eine Nachricht vom Gerätetreiber als Antwort auf eine Betriebsmittelanforderung empfangen worden ist, oder um den DSP-Manager über Änderungen im DSP zu informieren. Der DSP-Manager 1404 wird ferner mit den Definitionen für alle Anrufvorgangstöne während der Initialisierung heruntergeladen. Alle Kommunikationsvorgänge für den DSP-Gerätetreiber 1412 werden über dem DSP-Manager 1404 bewerkstelligt.
Der DSP-Klassentreiber 1410 ist verantwortlich für die gesamte generische Funktionalität und Intelligenz im DSP-Gerätetreiber. Einige der Klassentreiberfunktionen verwenden die Nachrichtenkommunikation mit dem DSP-Manager 1404 und dem Minianschlußtreiber 1412 sowie die Nachrichteninterpretation. Immer wenn eine Änderung des Status in einem DSP 1417 vorliegt (d. h. von BEREITSCHAFT zu ÜBERLAUF), erzeugt der DSP eine Unterbrechung für den Unterbrechungsbehandler 1420, der seinerseits den DSP-Gerätetreiber 1412 und den Klassentreiber 1410 benachrichtigt. Der Treiber interpretiert die Informationen von der Unterbrechung und erzeugt eine geeignete Nachricht, um den DSP-Manager 1404 über diese Statusänderung im DSP 1417 zu informieren.
Der DS-Minianschluß-Treiber 1412 ist verantwortlich für die Behandlung von Aktivitäten, die für den DSP-Chip und den auf der PSC-DSP-Karte 210 verwendeten ASIC 1417 spezifisch sind. Einige dieser Aktivitäten verwenden das Lesen und Schreiben von PC-Bus-Registern und dergleichen. Der Minianschlußtreiber wird verwendet, um Hardwareänderungen im Klassengerätetreiber 1410 zu kapseln.
Der Zweck des FMIC-Gerätetreibers 1409 besteht darin, den FMIC-Chip 1418 zu steuern, um Kanäle auf den ST-Verbindungen mit denjenigen auf dem MVIP-Bus zu verbinden und zu trennen.
Die Unterbrechungbehandlungsvorrichtung 1420 antwortet auf alle Unterbrechungen von der DSP-Karte 210. Diese Unterbrechungen können vom ASIC 1417 oder vom FMIC 1418 erzeugt werden. Obwohl mehr als eine Komponente auf der DSP-Karte 210 vorhanden ist, die Unterbrechungen erzeugen kann, werden alle Unterbrechungen von derselben Unterbrechungsleitung abgeleitet. Ein Statusregister ist vorgesehen, das einen Wert enthält, der anzeigt, wo die Unterbrechung erzeugt worden ist. Wenn die Unterbrechungbehandlungsvorrichtung 1420 eine Unterbrechung von der DSP-Karte 210 empfängt, bewertet die Behandlungsvorrichtung den Wert des Statusregisters und ermittelt das geeignete Modul, das zum Bedienen der Unterbrechung aktiviert werden muß.
Die Verbindung zwischen der Anrufsteuermaschine 310 und den CTI-Anwendungen 1525 wird durch den CTI-Anwendungsserver 330, den Kommunikationsprozessor 1530 und das Nachrichtenuntersystem 320 erleichtert, wie in 14 gezeigt ist. Nachdem die Kommunikation zwischen den kommunizierenden Komponenten eingerichtet ist, akzeptiert der CTI-Anwendungsserver 330 Anfragen von der Client-Anwendung 1525 und informiert diese anschließend über den Zustand der ausgegebenen Anfragen. Das HCI-Protokoll wird verwendet für die Kommunikation zwischen dem CTI-Anwendungsserver 330 und der Anrufsteuermaschine 310. Eine Schlüsselkomponente ist der Q2000-zu-HCI-Protokoll-Übersetzer 1535.
Der CTI-Anwendungsserver 330 verwendet eine Leitung, um mit dem Kommunikationprozessor 1530 zu kommunizieren, und einen Sockel, um mit seinen Clientanwendungen 1525 zu kommunizieren. Die Anwendung 1525 muß mit einer Bibliothek verbunden werden, um Zugriff auf den CTI-Anwendungsserver 330 zu erhalten.
Zusammengefaßt wird gemäß der vorliegenden Erfindung eine Nebenstellenanlage auf PC-Basis geschaffen, die eine beste hende Anrufsteuerungssoftware nutzt, die so beschaffen ist, daß sie in einer Windows-NT-Umgebung funktioniert, unter Verwendung einer Hardware-Abstraktionsschicht und eines 68K-Emulators. Das System gemäß der vorliegenden Erfindung bietet eine verbesserte Flexibilität hinsichtlich einer Anwendungsentwicklung einer dritten Partei, während die Notwendigkeit zum Erzeugen einer robusten Anwendungssteuerungs- und Merkmalsfunktionalitätssoftware vermieden wird.
Alternative Ausführungsformen und Änderungen der Erfindung sind möglich. Zum Beispiel wird angenommen, daß der MVIP-Bus verwendet werden kann, um Sprache für die RAD-Karte 240 und die Sprachpostkarte 230 zu transportieren, wodurch die Notwendigkeit von ONS-Leitungen beseitigt wird. Zusätzliche Abwandlungen und Änderungen sind innerhalb des Umfangs der vorliegenden Erfindung, wie sie von den beigefügten Ansprüchen definiert wird, möglich.

Claims

Nebenstellenanlage auf PC-Basis, die eine vorher bestehende Anrufsteuerungssoftware (300) enthält, die dazu dient, in einer Berechnungsumgebung zu arbeiten, die nicht auf PC-Basis beruht, wobei die Nebenstellenanlage auf PC-Basis umfaßt: ein PC-Gestell (250); eine PC-Hauptplatine (280) innerhalb des Gestells (250); eine Nebenstellenanlagen-Hauptsteuerungskarte (200) innerhalb des Gestells (250) zum Ausführen der im voraus bestehenden Anrufsteuerungssoftware (300); eine Telekommunikationskarte (220) innerhalb des Gestells (250), die mit der Nebenstellenanlagen-Hauptsteuerungskarte (200) verbunden ist, um Telephoniekommunikation mit einem öffentlichen Telephonnetz (170) unter der Steuerung der Anrufsteuerungssoftware (300) zu implementieren und eine DSP-Karte (210) innerhalb des Gestells (250), die mit der Nebenstellenanlagen-Hauptsteuerungskarte (200) verbunden ist, um ein Signalisierungs- und Konferenzfunktionsnetz unter der Steuerung der Anrufsteuerungssoftware (300) zu implementieren, dadurch gekennzeichnet, daß die Nebenstellenanlagen-Hauptsteuerungskarte (200) eine Hardwareabstraktionsschicht (305) enthält, um Hardwareelemente zu ersetzen, zu emulieren und einzuführen, die in der Nebenstellenanlage auf PC-Basis fehlen und mit der die im voraus bestehende Anrufsteuerungssoftware (300) in Wechselwirkung tritt, wobei die Hardwareabstraktionsschicht (305) die Anrufsteuersoftware (300) auf die PC-Plattform überträgt.
Nebenstellenanlage nach Anspruch 1, wobei die Nebenstellenanlagen-Hauptsteuerungskarte (200) eine Prozessoremulationsschicht besitzt, um die Berechnungsumgebung zu emulieren, in der die im voraus bestehende Anrufsteuerungssoftware (300) arbeitet.
Nebenstellenanlage nach Anspruch 1 oder 2, die ferner mit einer LAN-Karte und einer Netzmanagementsoftware für die Verbindung mit lokalen Netzen versehen ist.
Nebenstellenanlage nach einem der Ansprüche 1 bis 3, die ferner mit einer Sprachpostkarte (230) innerhalb des Gestells (250) zum Implementieren von Sprachpostmerkmalen unter der Steuerung der Anrufsteuerungssoftware (300) versehen ist.
Nebenstellenanlage nach einem der Ansprüche 1 bis 4, die ferner mit einer Ansagevorrichtungskarte innerhalb des Gestells (250) zum Implementieren von Ansagemerkmalen unter der Steuerung der Anrufsteuerungssoftware (300) versehen ist.
Nebenstellenanlage nach einem der Ansprüche 1 bis 5, bei der die Nebenstellenanlagen-Hauptsteuerungskarte (200),. die Telekommunikationskarte (220) und die DSP-Karte (210) so beschaffen sind, daß sie über einen MVIP-Bus kommunizieren.