DE60223575T2

DE60223575T2 - System und verfahren zum steuern der signalverarbeitung in einer sprache-über-pakete-umgebung

Info

Publication number: DE60223575T2
Application number: DE60223575T
Authority: DE
Inventors: Manoj Laguna Hills MEHTA; Saurin Santa Clara SHAH; Dianne Irvine STEIGER; Chris Costa Mesa LAWTON; Anurag Irvine BIST
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2001-09-21
Filing date: 2002-09-18
Publication date: 2008-10-23
Anticipated expiration: 2022-09-19
Also published as: WO2003028338A1; CA2461299A1; EP1430681B1; US20020054588A1; DE60223575D1; ATE378766T1; HK1063254A1; US6928076B2; EP1430681A1

Description

Die Anmeldung beansprucht Vorrang gegenüber der vorläufigen Anmeldung U.S. 60/234,847 , eingereicht am 22. September 2000, und der vorläufigen Anmeldung U.S. 60/234,743 , eingereicht am 22. September 2000.
1. GEBIET
Die vorliegende Erfindung betrifft allgemein das Gebiet der Signalverarbeitung. Insbesondere betrifft eine Ausführungsform der Erfindung ein System und ein Verfahren zum Steuern, Konfigurieren, Überwachen und Kommunizieren mit einem Signalprozessor ohne Kenntnis seiner spezifischen Architektur.
2. ALLGEMEINER HINTERGRUND
DSP-(single chip digital signal processing)-Vorrichtungen sind verhältnismäßig gut bekannt. In der Regel kann ein DSP mit einem allgemein als ein „Hostprozessor" bezeichneten Allzweckmikroprozessor programmiert werden. Vor dem Programmieren der DSP muss ein Softwareprogrammierer heute ein genaues Verständnis der Hardwarearchitektur des DSP haben. Diese erforderliche Kenntnis der DSP-Architektur erhöht die Programmierschwierigkeiten. Außerdem ist eine Schnittstelle der DSP, die die Kommunikation mit dem Hostprozessor ermöglicht und welche manchmal als die „Hostschnittstelle" bezeichnet wird, oft nur zur Unterstützung weniger Arten von Prozessoren konfiguriert. Dies kann dazu führen, dass die DSP für bestimmte Systeme nicht kompatibel ist.
In der WO 99/16271 A1 wird ein Telekommunikationsvermittlungssystem mit einem Hardwareressourcenmanagersystem beschrieben. Der Ressourcenmanager stellt eine Schnittstelle mit Systemfunktionen höherer Ebene, wie beispielsweise der Anrufverarbeitung OA&M, NMS und Systemsteuerfunktionen, sowie mit Hardwarefunktionen niedrigerer Ebene, die als ein Eingabe/Ausgabe-Untersystem (IOSS) ausgeführt sind, welches verschiedene Hardwareressourcen zur Schnittstellenbildung für das Vermittlungssystem zu anderen Gruppen enthalten, bereit. Der Ressourcenmanager steuert alle Interaktionen zwischen der IOSS-Hardware und den Funktionen höherer Ebenen und verbirgt die Hardwareeigenschaften des IOSS, indem er den Funktionen höherer Ebene eine hardwareunabhängige Ansicht der IOSS-Ressourcen gibt. Dadurch können die Funktionen höchster Ebene ohne Modifikation mit einer großen Bandbreite von IOSS Hardwarekonfigurationen funktionieren.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die Merkmale und Vorteile der Erfindung werden aus der folgenden ausführlichen Beschreibung der Erfindung ersichtlich, in denen:
1 eine erste beispielhafte Ausführungsform eines VoP-Untersystems ist.
2 eine zweite beispielhafte Ausführungsform eines VoP-Untersystems ist.
3 eine logische Darstellung einer Ausführungsform eines Signalprozessors des VoP-Untersystems aus 1 oder 2 ist.
4 eine beispielhafte Ausführungsform einer internen Logik ist, die in dem Signalprozessor aus 3 eingesetzt wird.
5 eine beispielhafte Ausführungsform eines RXQ-Managementregistersatzes des DMA-Registers aus 4 ist.
6 eine beispielhafte Ausführungsform eines RXQ-Flusssteuerregistersatzes des DMA-Registers aus 4 ist.
7 eine beispielhafte Ausführungsform eines TXQ-Managementregistersatzes des DMA-Registers aus 4 ist.
8 eine beispielhafte Ausführungsform einer internen Logik in dem Steuerprozessor aus 4 ist.
9 ein beispielhaftes Flussdiagramm einer Ausführungsform der Grundfunktionen, die durch den Signalprozessor bei der Kommunikation mit einem Host ausgeführt werden, ist.
10 eine beispielhafte Ausführungsform der Datenstruktur einer Nachricht ist, die in Übereinstimmung mit dem Nachrichtenprotokoll der Erfindung konfiguriert ist.
11 eine beispielhafte Ausführungsform eines Steuerkopfteils einer Steuernachricht ist, die beim Übertragen von Kommunikationen zwischen dem Signalprozessor und dem Host verwendet wird.
12 eine beispielhafte Auflistung verschiedener Arten von Nachrichtenkatalogen ist, die durch den Signalprozessor unterstützt werden.
13 eine Auflistung beispielhafter Nachrichten ist, die mit dem Vorrichtungssteuerkatalog aus 12 verbunden sind.
14 eine beispielhafte Nutzlast einer Knoteneinrichtungs-(DEV_SET_NODE)-Steuernachricht ist.
15 eine beispielhafte Nutzlast einer Antwort auf die DEV_SET_NODE-Nachricht aus 14 ist.
16 eine beispielhafte Nutzlast einer Antwort auf eine Vorrichtungsinformationsanforderungs-(DEV_INFO)-Befehlsnachricht ist.
17 eine beispielhafte Nutzlast einer Vorrichtungsspeicherpoolinitialsierung-(DEV_POOL_INIT)-Befehlsnachricht ist.
18 eine beispielhafte Nutzlast einer Antwort auf die DEV_POOL_INIT-Befehlsnachricht aus 17 ist.
19 eine beispielhafte Nutzlast einer Vorrichtungsreportkonfigurations-(DEV-REPORT_CONFIG)-Befehlsnachricht ist.
20 eine beispielhafte Nutzlast einer Antwort auf die DEV_REPORT_CONFIG-Befehlsnachricht aus 19 ist.
21 eine beispielhafte Nutzlast einer Vorrichtungs-Heartbeat-(DEV_HEARTBEAT)-Nachricht ist.
22 eine beispielhafte Nutzlast einer Vorrichtungsstatistik-(DEV_STATISTICS)-Nachricht ist.
23 eine beispielhafte Nutzlast einer Seriellen-Port-Einrichten-(SERIAL_PORT_SETUP)-Befehlsnachricht ist.
24 eine beispielhafte Nutzlast einer Antwort auf die SERIAL_PORT_SETUP-Befehlsnachricht aus 23 ist.
25 eine beispielhafte Nutzlast einer Segmentzuweisungs-(SEG_ALLOC)-Befehlsnachricht ist.
26 eine beispielhafte Nutzlast einer Antwort auf die SEG_ALLOC-Befehlsnachricht aus 25 ist.
27 eine beispielhafte Nutzlast einer Antwort auf eine Segment-Aktivieren-(SEG_ACTIVATE)-Befehlsnachricht ist.
28 eine beispielhafte Auflistung von Nachrichten ist, die mit einem Sitzungssteuerkatalog verbunden sind.
29 eine beispielhafte Nutzlast einer Sitzungseinrichtungs-(SESSION_SETUP)-Befehlsnachricht ist.
30 eine beispielhafte Ausführungsform von Codier- und Decodierfunktionsarten ist, die mit der SESSION SETUP-Befehlsnachricht aus 29 verbunden sind.
31 eine beispielhafte Ausführungsform von Echoausblendungseinrichtungoptionen ist, die mit der SESSION_SETUP-Befehlsnachricht aus 29 verbunden sind.
32 eine beispielhafte Ausführungsform eines Testmodusparameters aus 29 ist.
33 eine beispielhafte Ausführungsform gültiger naher und ferner Empfangs-(RX)- und Sende-(TX)-Adressen aus 29 ist.
34 eine beispielhafte Nutzlast einer Antwort auf die SESSION_SETUP-Befehlsnachricht aus 29 ist.
35 eine beispielhafte Nutzlast einer Sitzungsstart-(SESSION_START)-Befehlsnachricht ist.
36 eine beispielhafte Nutzlast einer Antwort auf die SESSION START-Befehlsnachricht aus 35 ist.
37 eine beispielhafte Nutzlast einer Sitzungsstop-(SESSION_STOP)-Befehlsnachricht ist.
38 eine beispielhafte Nutzlast einer Antwort auf die SESSION_STOP-Nachricht aus 37 ist.
39 eine beispielhafte Nutzlast einer Sitzungsabbruch-(SESSION_TEARDOWN)-Befehlsnachricht ist.
40 eine beispielhafte Nutzlast einer Antwort auf die SESSION_TEARDOWN-Nachricht aus 39 ist.
41 eine beispielhafte Nutzlast einer Sitzungsanfrage-(SESSION_QUERY)-Befehlsnachricht ist.
42 eine beispielhafte Nutzlast einer Antwort auf die SESSION_QUERY-Nachricht aus 41 ist.
43A eine beispielhafte Nutzlast einer Sitzungsstatistikanforderungs-(SESSION_STATS_REQUEST)-Befehlsnachricht ist.
43B eine beispielhafte Nutzlast einer Antwort auf die SESSION_STATS_REQUEST-Befehlsnachricht aus 43A ist.
44 eine beispielhafte Auflistung von Nachrichten ist, die mit einem Telefoniedienstekatalog verbunden sind.
45 eine beispielhafte Nutzlast ist, die Echoausblendungs-(EC)-Parameter einer Echoausblendungsparameter-Einstellen-(SET_EC_PARMS)-Befehlsnachricht aufweist.
46 eine beispielhafte Nutzlast einer Antwort auf die SET_EC_PARMS-Befehlsnachricht aus 45 ist.
47 eine beispielhafte Nutzlast einer EC-Parameter-Anfordern-(REQ_EC_PARMS)-Befehlsnachricht ist.
48 eine beispielhafte Nutzlast einer Antwort auf eine REQ_EC_PARMS-Nachricht aus 47 ist.
49 eine beispielhafte Nutzlast einer Echo-Ausblendungs-Statistik-Anfordern-(EC_STAT_REQ)-Befehlsnachricht ist.
50 eine beispielhafte Nutzlast einer Antwort auf die EC_STAT_REQ-Nachricht aus 49 ist.
51 eine beispielhafte Nutzlast einer DTMF-Parameter-Einstellen-(SET_DTMF_PARMS)-Befehlsnachricht ist.
52 eine beispielhafte Nutzlast einer Antwort auf die SET_DTMF_PARMS-Befehlsnachricht aus 51 ist.
53 eine Ausführungsform einer beispielhaften Nutzlast einer REQ_DTMF_PARMS-Befehlsnachricht ist.
54 eine beispielhafte Nutzlast einer Antwort auf die REQ_DTMF_PARMS-Befehlsnachricht aus 53 ist.
55 eine beispielhafte Nutzlast einer DTMF-Ziffern-Erzeugen-(GEN_DTMF_DIGITS)-Befehlsnachricht ist.
56 eine beispielhafte Nutzlast einer Bestätigungssteuernachricht ist.
57 eine beispielhafte Nutzlast einer Antwort auf die GEN_DTMF_DIGITS-Befehlsnachricht aus 55 ist.
58 eine beispielhafte Nutzlast einer DTMF-Report-(DTMF_REPORT)-Befehlsnachricht ist.
59 eine beispielhafte Nutzlast einer Tonfrequenz-Einstellen-(SET_TONE_FREQ)-Befehlsnachricht ist.
60 eine beispielhafte Nutzlast einer EIN-Zeit-für-Tonkadenz-Stellen-(SET_TONE_CADENCE_ON)-Befehlsnachricht ist.
61 eine beispielhafte Nutzlast einer AUS-Zeit-für-Tonkadenz-Einstellen-(SET_TONE_CADENCE_OFF)-Befehlsnachricht ist.
62 eine beispielhafte Nutzlast einer Unteren-Tonschwellwert-Einstellen-(SET_TONE_THRESH_LOW)-Befehlsnachricht ist.
63 eine beispielhafte Nutzlast einer Oberen-Tonschwellwert-Einstellen-(SET_TONE_THRESH_HI)-Befehlsnachricht ist.
64 eine beispielhafte Nutzlast einer Antwort ist, die beim Beantworten auf jede der Ton-Einstellen-Befehlsnachrichten verwendet wird.
65 eine beispielhafte Nutzlast eines REQ_TONE_FREQ_RSP-Befehls ist.
66 eine beispielhafte Nutzlast einer Ton-Erzeugen-(GEN_TONE)-Befehlsnachricht ist.
67 eine beispielhafte Nutzlast einer Antwort auf die GEN_TONE-Befehlsnachricht aus 66 ist.
68 eine beispielhafte Nutzlast einer Ton-Stoppen-(STOP_TONE)-Befehlsnachricht ist.
69 eine beispielhafte Nutzlast einer Antwort auf die STOP_TONE-Befehlsnachricht aus 68 ist.
70 eine beispielhafte Nutzlast einer Ton-Report-(TONE_REPORT)-Befehlsnachricht ist.
71 eine beispielhafte Nutzlast einer Fax-Ton-Report-(FAX_TONE_REPORT)-Befehlsnachricht ist.
72 eine beispielhafte Auflistung von Nachrichten ist, die mit einem Sprach-Dienste-Katalog verbunden sind.
73 eine beispielhafte Nutzlast einer SET_VOICE_PARMS-Befehlsnachricht ist.
74 eine beispielhafte Nutzlast einer Antwort auf die SET_VOICE_PARMS-Befehlsnachricht aus 73 ist.
75 eine beispielhafte Nutzlast einer REQ_VOICE_PARMS-Befehlsnachricht ist.
76 eine beispielhafte Nutzlast einer Antwort auf die REQ_VOICE_PARMS-Befehlsnachricht aus 75 ist.
77 eine beispielhafte Auflistung von Nachrichten ist, die mit einem Fax-Dienste-Katalog verbunden sind.
78 eine beispielhafte Nutzlast einer SET_FAX_PARMS-Befehlsnachricht ist.
79 eine beispielhafte Nutzlast einer Antwort auf die SET_FAX_PARMS-Befehlsnachricht aus 78 ist.
80 eine beispielhafte Nutzlast einer REQ_FAX_PARMS-Befehlsnachricht ist.
81 eine beispielhafte Nutzlast einer Antwort auf die REQ_FAX_PARMS-Befehlsnachricht aus 80 ist.
82 eine beispielhafte Nutzlast einer Report-Fax-Unterbrechen-(REPORT_FAX_DISCONNECT)-Befehlsnachricht ist.
83 eine Auflistung beispielhafter Nachrichten ist, die mit einem Modem-Dienste-Katalog verbunden sind.
84 eine beispielhafte Ausführungsform einer Steuernachrichtensequenz ist, die während der Initialisierungsphase von dem Host und dem Signalprozessor verwendet werden.
85 eine beispielhafte Ausführungsform eines Flussdiagramms der Kontrollnachrichtensequenz ist, die zwischen dem Host und dem Signalprozessor ausgetauscht werden, um eine Telefonverbindungssitzung aufzubauen und zu betreiben.
86 eine beispielhafte Ausführungsform einer Datennachricht ist.
87 eine beispielhafte Ausführungsform von Formaten ist, die von dem in dem Datenkopfteil der Datennachricht aus 86 enthaltenen Nutzlast-Art-Parameter unterstützt werden.
88 eine beispielhafte Nutzlast der Datennachricht aus 86 ist, welche 16-Bit-PCM-Abtastungen unterstützt.
89 eine weitere beispielhafte Nutzlast der Datennachricht aus 86 ist.
BESCHREIBUNG
Die Erfindung betrifft allgemein ein System und ein Nachrichtenprotokoll zum Steuern eines Signalprozessors ohne Kenntnis seiner spezifischen Architektur. In einer Ausführungsform betrifft die Erfindung beispielsweise ein nachrichtenbasiertes Befehl/Antwort-Kommunikationsprotokoll zum Steuern, Konfigurieren, Überwachen und Kommunizieren mit einem Signalprozessor, wie in dem unabhängigen Anspruch 1 definiert. Eine zweite Ausführungsform wird als ein Voice-Over-Packet-Untersystem gemäß dem unabhängigen Anspruch 19 definiert.
In der folgenden Beschreibung wird eine bestimmte Terminologie verwendet, um Merkmale der Erfindung zu beschreiben. Ein „Voice-over-Packet-(VoP)"-Untersystem kann allgemein als eine Logik definiert sein, die Informationen in einem festgelegten Format empfängt, verarbeitet und sendet (zum Beispiel Daten, Adressen, Steuerung, Sprache oder eine Kombination davon). Jedes VoP-Untersystem kann so konfiguriert sein, dass es mehrere Arten von Netzwerken unterstützt.
„Logik" wird als Hardware, Firmware, Software oder jede Kombination davon definiert. Die interne Logik in dem VoP-Untersystem kann beispielsweise einen Prozessor enthalten, bei dem es sich um Hardware handelt, die in Kombination mit Firmware oder Software zur Verarbeitung von Informationen funktioniert. Es gibt verschiedene Arten von Prozessoren wie beispielsweise einen Signalprozessor, der Audio-(zum Beispiel Sprach-) und möglicherweise andere Arten von Informationen verarbeitet.
In der Regel sind sowohl Firmware als auch Software allgemein definiert als eine oder mehrere Anweisungen, die bei Ausführung dazu führen, dass das System eine bestimmte Operation ausführt. Die Anweisungen bilden möglicherweise eine Anwendung, ein kleines Programm, ein Programm oder eine Routine, die in einem maschinenlesbaren Medium gespeichert werden, wobei es sich bei dem Medium um jedes Medium handeln kann, welches Informationen speichern und übertragen kann. Zu Beispielen maschinenlesbarer Medien gehören ohne Einschränkung eine elektronische Schaltung, eine (flüchtige oder nichtflüchtige Halbleiterspeichervorrichtung, eine Datenspeicherdiskette (zum Beispiel mechanisches oder optisches Diskettenlaufwerk)) oder sogar jedes tragbare Speichermedium wie beispielsweise eine Diskette, eine Kompaktdisk oder DVD, ein Tonband oder dergleichen. Das maschinenlesbare Medium kann ferner informationstragende Medien umfassen, wobei es sich um elektrische Leitungen, optische Fasern, Kabel, Bus, Luft in Kombination mit Funksignaltechnologie oder jede Kombination davon handeln kann.
Der Begriff „Paket" ist allgemein definiert als eine Reihe von Informationsbits, die über ein paketvermitteltes Netzwerk gesendet werden. Zu Beispielen von paketvermittelten Netzwerken gehören (ATM) Asynchronous Transfer Mode, frame relay, Internet Protocol (IP). Diese Pakete werden über Kommunikationsstrecken weitergeleitet, welche unter Verwendung informationstragender Medien, wie die oben beschriebenen, gebildet werden. Zu anderen Messungen von Bit- oder Byte-Längen gehört ein Segment, ein Block oder ein Datenelement.
Ein „Parameter" wird hierin allgemein definiert als ein Bitwert, ein Zeiger oder ein anderer Mechanismus, der verwendet wird, um ein Ereignis zu initiieren, wie beispielsweise die Übertragung von Informationen. Ein „Feld" wird allgemein definiert als ein oder mehrere Parameter, die mit spezifischen Byte(s) einer Nachricht verbunden sind.
Die Begriffe „gesetzt" oder „frei" zeigen normalerweise einen logischen Zustand wie eine logische „1" oder eine logische „0" an.
I. ARCHITEKTURÜBERBLICK
Unter Bezugnahme nun auf 1, wird eine erste beispielhafte Ausführungsform eines VoP-Untersystems 100 dargestellt. Das VoP-Untersystem 100 kann in einer großen Bandbreite von Produkten (zum Beispiel Gateway, Vermittlung) implementiert werden und befindet sich in Kommunikation mit verschiedenen Arten von Netzwerken, wie beispielsweise einem öffentlich vermittelten Telefonnetzwerk (PSTN) 110 und einem paketvermittelten Netzwerk 120. Das Paketnetzwerk 120 unterstützt die Übertagung von Sprachpaketen und anderen Paketarten wie beispielsweise Video, elektronischer Mail (e-mail) und dergleichen.
Für diese Ausführungsform enthält das VoP-Untersystem 100 einen Signalprozessor 130, eine Leitungs-/Zeitschlitzeinheit 140 und eine externe Steuerung 150 wie beispielsweise einen Hostprozessor (der im Folgenden als „Host" bezeichnet wird). Natürlich kann der „Host" als eine andere Art von Steuerung konfiguriert sein, wie beispielsweise eine Microsteuerung, eine anwendungsspezifische integrierte Schaltung (ASIC) und dergleichen. Diese logischen Knoten 130, 140 und 150 werden durch eine Vielzahl von Verbindungen miteinander verbunden.
Der Signalprozessor 130 ist so konfiguriert, dass er Sprache über eine erste Kommunikationsstrecke 171 empfängt und sendet und paketierte Informationen über eine zweite Kommunikationsstrecke 172 (siehe auch 4). Insbesondere können Nachrichten von dem Host 150 erzeugt und an den Signalprozessor 130 über die zweite Kommunikationsstrecke 172 weitergeleitet werden. Eine Art von Nachricht ist eine „Steuernachricht", die für das Booten, Initialisieren und Konfigurieren des Signalprozessors 130 sowie für die Überwachung und die Steuerung seiner Laufzeitoperationen verantwortlich ist. Eine weitere Art von Nachricht ist eine „Datennachricht", die beim Transport von Informationen über das PSTN 110 oder Paketnetzwerk 120 verwendet wird.
Von dem PSTN 110 können Informationen an das Paketnetzwerk 120 und umgekehrt weitergeleitet werden. Gemäß einer Ausführungsform ist das PSTN 110 beispielsweise dazu ausgelegt, nicht komprimierte Sprache über die erste Kommunikationsstrecke 171 zu senden. Die erste Kommunikationsstrecke 171 ist so konfiguriert, dass sie gemäß einem ausgewählten Multiplexingschema wie dem gezeigten (TDM) Time Division Multiplexing oder (FDM) Freqency Division Multiplexing betrieben wird. Die nicht komprimierte Sprache kann über eine Vielzahl von Modulationstechniken codiert werden wie beispielsweise (PCM) pulse code modulation. Die nicht komprimierte Sprache wird dann der Leitungs-/Zeitschlitzeinheit 140 bereitgestellt, welche die unkomprimierte Sprache extrahiert und die Sprache in Zeitschlitze platziert, welche von dem Signalprozessor 130 zugreifbar sind.
Danach komprimiert der Signalprozessor 130 die Sprache und konvertiert die komprimierte Sprache in ein oder mehrere Sprachpakete. Die Sprachpakete werden über die zweite Kommunikationsstrecke 172 zu dem Host 150 weitergeleitet. Der Host 150 (möglicherweise ein Hostprozessor 155 alleine oder in Verbindung mit einem Paketprozessor 160 wie gezeigt) fügt entsprechende Kopfteil zu, um die Sprachpakete in Pakete mit einem geeigneten Netzwerkformat (zum Beispiel IP, ATM usw.) zu konvertieren. Der Host 150 überträgt die Netzwerkpakete an das Netzwerk 120. In dieser Ausführungsform handelt es sich bei der zweiten Kommunikationsstrecke 172 um einen gemultiplexten 32-Bit-Multi-Master-Adress-/Daten-Parallelbus, der als eine primäre Schnittstelle sowohl für die Steuer- als auch Datennachrichten wie unten beschrieben fungiert.
Um eingehende Netzwerkpakete in nicht komprimierte Sprache, die über das PSTN 110 übermittelt wird, umzuwandeln, entfernt der Host 150 im Gegensatz dazu bei Empfang der Netzwerkpakete ihre Kopfteil und führt Operationen zum Entfernen von Schwankungen aus. Die verkürzten Pakete werden dann an den Signalprozessor 130 über die zweite Kommunikationsstrecke 172 weitergeleitet. Der Signalprozessor 130 decodiert die paketierte Sprache und führt Echostornierung aus vor der Sendung an die Leitungs-/Zeitschlitzeinheit 140 zur Sendung über das PSTN 110.
Unter Bezugnahme auf 2 wird eine zweite beispielhafte Ausführungsform eines VoP-Untersystems 200 dargestellt. Das VoP-Untersystem 200 enthält eine Kommunikationsstrecke 210, die Kommunikationen zwischen mehreren (N) Signalprozessoren 130₁ –130_N (wobei N > 1) ermöglicht. Wie gezeigt, handelt es sich bei der Kommunikationsstrecke 210 hier um einen TDM-Bus, der eine Vielzahl von zeitlich gemultiplexten Kanälen aufweist. Es wird jedoch berücksichtigt, dass die Kommunikationsstrecke 210 so konfiguriert sein kann, dass sie eine Vielzahl von Frequenz-gemultiplexten Kanälen oder Spreitzspektrum unterstützen kann (zum Beispiel Technologien auf der Basis von „CDMA" (Code Division Multiple Access)). Der Host 150 befindet sich in Kommunikation mit jedem der Signalprozessoren 130₁ –130_N über die Kommunikationsstrecke 172 zur Sendung und zum Empfang von Steuer- oder Datennachrichten zur Konfiguration und Laufzeitoperationen durch die Signalprozessoren 130₁ –130_N .
Unter Bezugnahme nun auf 3 wird eine logische Darstellung einer Ausführungsform eines Signalprozessors 130 des VoP-Untersystems aus 1 oder 2 dargestellt. Der Signalprozessor 130 umfasst drei logische Schnittstellen, nämlich eine leitungsseitige Schnittstelle 300, eine paketseitige Schnittstelle 310 und eine Steuerschnittstelle 320. Sowohl die paketseitige Schnittstelle 310 als auch die Steuerschnittstelle 320 können als eine „Hostschnittstelle" 330 fungieren, welche dem Host die Kommunikation mit dem Signalprozessor 130 gestattet.
Die leitungsseitige Schnittstelle 300 verteilt unkomprimierte Sprache über mehrere Kanäle, während die paketseitige Schnittstelle 310 komprimierte Sprache über mehrere Verbindungen verteilt. Dadurch ist der Signalprozessor 130 dazu ausgelegt, Sprache, die über die leitungsseitige Schnittstelle 300 empfangen wurde, zu codieren (zum Beispiel zu komprimieren) und die codierte Sprache über die paketseitige Schnittstelle 310 auf einer Kanalbasis weiterzuleiten. Analog ist der Signalprozessor 130 dazu ausgelegt, Sprache, die über die paketseitige Schnittstelle 310 empfangen wurde, zu decodieren (zum Beispiel zu dekomprimieren) und die decodierte Sprache über die leitungsseitige Schnittstelle 300 weiterzuleiten. Die Steuerschnittstelle 320 fungiert als eine API-(Advanced Programming Interface)-Nachrichtenschnittstelle zur Kommunikation, Steuerung, Konfiguration und Überwachung von Operationen des Signalprozessors 130.
Während der Laufzeit unterstützt der Signalprozessor 130 eine Vielzahl von Kommunikationssitzungen. Eine „Kommunikationssitzung" ist als eine Signalverarbeitungsaktivität an dem Signalprozessor 130 definiert, welche zwei Datenflüsse (oder vier Kanäle) umfasst. In der Regel umfasst eine Kommunikationssitzung (im Folgenden als eine „Sitzung" bezeichnet) den Transfer von Daten zwischen der leitungsseitigen Schnittstelle 300 und der paketseitigen Schnittstelle 310, wie durch Fluss 340 dargestellt. Andere Arten von Sitzungen können jedoch einfach Datenflüsse 350 und 360 über die leitungsseitige Schnittstelle 300 oder die paketseitige Schnittstelle 310 umfassen. Alle Laufzeitoperationen treten über eine Nachrichtenschichtabstraktion über die Hostschnittstelle 330 auf.
Wie in 3 und 4 gezeigt, enthält der Signalprozessor 130 eine Vielzahl von Eingabe-/Ausgabe-(E/A)-Ports, einschließlich serieller Mehrfachports (TDM) 400 und einen Hostport 410. Die logischen Schnittstellen 300, 310 und 320 können auf diese E/A-Ports auf verschiedene Weisen abgebildet werden. Die leitungsseitige Schnittstelle 300 kann beispielsweise physisch auf die seriellen Ports 400 abgebildet werden und die paketseitige Schnittstelle und die Steuerschnittstelle 310 und 320 können physisch auf den Hostport 410 abgebildet werden, wobei sie die Hostschnittstelle 330, wie in 3 gezeigt, bilden. Ein weiteres Beispiel besteht darin, dass die leitungsseitige Schnittstelle 300 auf die seriellen Ports 400 abgebildet wird und die paketseitige Schnittstelle 310 auf den Hostport 410 abgebildet wird und die Steuerschnittstelle 320 auf einen separaten zellenbasierten seriellen Port abgebildet wird, bei dem es sich um einen der seriellen Ports 400 handelt. Noch ein weiteres Beispiel könnte darin bestehen, dass alle drei Schnittstellen 300, 310 und 320 auf den Hostport 410 oder separate serielle Ports 400 abgebildet werden (wobei die leitungsseitige Schnittstelle ein bytebasierter Port ist und die paketseitige Schnittstelle und die Steuerschnittstelle zellenbasierte Ports sind).
Unter Bezugnahme nun auf 4 wird eine beispielhafte Ausführungsform einer internen Logik gezeigt, die in dem Signalprozessor 130 aus 3 eingesetzt wird. Der Signalprozessor 130 weist serielle Ports 400 und insbesondere den Hostport 410 auf, welcher den Empfang und die Sendung von Informationen durch den Host ermöglichen. Die interne Logik in dem Signalprozessor 130 umfasst einen Steuerprozessor 430, DSP-Verarbeitungskerne 435, Schnittstellenregister 440, eine Direktspeicherzugriffs-(DMA)-Steuerung 450, DMA-Register 460, Empfangs-(RX)-Schlangen 470, Sende-(TX)-Schlangen 480 und einen internen Speicher 490.
Insbesondere ermöglichen es Schnittstellenregister 440 dem Host, Besitz der zweiten Kommunikationsstrecke 172 zu erlangen und Informationen in den internen Speicher 490 des Signalprozessors 130 zu übertragen. Diese Register 440 können als Eingabe-/Ausgabe-(E/A)-Speicheradressraum des Signalprozessors 130 konfiguriert sein und sind über den Hostport 410 zugreifbar.
Die RX- und TX-Schlangen 470 und 480 sind spezialisierte Hardware, die mit dem internen Speicher 490 verknüpft sind und durch die DMA-Steuerung 450 gesteuert werden. Die DMA-Steuerung 450 unterstützt die Lieferung eingehender Rahmen, eine Sammlung eines oder mehrerer Pakete an bestimmte RX-Schlangen 470 und das Extrahieren ausgehender Pakete an mindestens einer der TX-Schlangen 480. Die RX-Schlangen 470 und die TX-Schlangen 480 können auf vielfältige Weise zugewiesen werden.
Zum Beispiel kann in einer Ausführungsform eine wesentliche Mehrzahl der RX-Schlangen 470 fest zu empfangspaketierten Daten zugewiesen sein, während mindestens eine verbleibende RX-Schlange fest zu Empfangsteuernachrichten zugewiesen sein kann. Hier werden 509 der 512 RX-Schlangen verwendet, um Datenpakete zu empfangen und mindestens eine RX-Schlange wird verwendet, um Steuernachrichten zu empfangen.
Außerdem kann mindestens eine TX-Schlange fest zugewiesen sein, um Daten, die zur Sendung an den Host eingeteilt sind, temporär zu speichern. Eine oder mehrere andere TX-Schlangen können fest zugewiesen sein, um beispielsweise Steuernachrichten temporär zu speichern.
Die DMA-Register 460 werden von dem Host verwendet, um Flusssteuerstatus zu bestätigen und anzuzeigen, wenn ein Frame vollständig an den Signalprozessor übertragen worden ist. In dieser Ausführungsform enthalten die DMA-Register 460 RX-Schlangen-(RXQ)-Managementregistersätze 461, einen RXQ-Flusssteuerregistersatz 462 und TXQ-Managementregistersätze 463. Der Steuerprozessor 430 initialisiert die DMA-Register 460 beim Booten.
Wie in 5 gezeigt, entspricht jeder der RXQ-Managementregistersätze 461 eindeutig einer der RX-Schlangen 480 aus 4 und kann einem oder mehreren Kommunikationskanälen zugeordnet sein (ein generischer Kanal wird durch den Modifizierer "x" gekennzeichnet). Insbesondere enthält jeder RXQ-Managementregistersatz 461 ein Hostprozessoranforderungsstatus-(HPRQSTAT_x)-Register 500, ein Hostprozessoranforderungsdaten-(HPRQDATA_x)-Register 505 und einen Hostprozessoranforderungsstatus-(HPRQDONE_x)-Register 510.
In einer Ausführungsform fragt der Host den Status des HPRQSTAT_x-Registers 500 ab, um den Flusssteuerstatus der RX-Schlange 470_x zu bestimmen, insbesondere, ob sie voll oder nicht voll ist. Wenn die RX-Schlange 470_x nicht voll ist, was dadurch dargestellt wird, dass das HPRQSTAT_x-Register 500 nicht eingestellt ist, wird beispielsweise ein Paket in das HPRQDATA_x-Register 505 geschrieben. In dieser Ausführungsform wird das Datenpaket, nämlich vier Bytes (oder Oktetts) zugleich geschrieben. Nach dem Schreiben der letzten vier Bytes in das HPRQDATA_x-Register 505 wird das HPRQDONE_x-Register 510 durch den Host eingestellt, um das Ende des Frametransfers anzuzeigen. Wenn die RX-Schlange voll ist, was dadurch angezeigt wird, dass das HPRQSTAT_x-Register 500 eingestellt ist, fährt der Host mit dem Abfragen oder Bedienen anderer Sitzungen fort.
Unter Bezugnahme auf 6 enthält eine Ausführungsform des RXQ-Flusssteuerregistersatzes 462 ein Hostprozessorkanalanforderungsstatus-(HPCRQS)-Bit 515 und ein Hostprozessorkanalanforderungsframe-(HPCRQF)-Bit 520. Das HPCRQS-Bit 515 zeigt einen Flusssteuerungsstatus für alle Kanäle an, die durch den Signalprozessor unterstützt werden. Wenn das HPCRQS-Bit 515 eingestellt ist, sind die RX-Schlangen somit entweder voll oder deaktiviert und ungültig. Wenn das HPCRQS-Bit 515 nicht eingestellt ist, kann der Host jedoch Pakete in eine RX-Schlange zum Senden zu dem internen Speicher 490 weiterleiten. Das HPCRQF-Bit 520 ist eingestellt, wenn ein Frame vollkommen zu einer RX-Schlange übertragen wurde, wodurch der Steuerprozessor hinsichtlich der empfangenen Daten für nachfolgendes Weiterleiten an den internen Speicher 490 unterbrochen wird.
Unter Bezugnahme auf 7 entspricht jeder TXQ-Managementregistersatz 463 eindeutig einer der TX-Schlangen und enthält ein Hostprozessorsendestatus-HPXQSTAT_x)-Register 525, ein Hostprozessorsendedaten-(HPXQDATA_x)-Register 530 und ein Hostprozessorsende-erfolgt-Zähler-(HPXQDCNT_x)-Register 535. Der Host empfängt entweder eine Unterbrechung von dem Signalprozessor, wenn Informationen in eine TX-Schlange platziert werden oder kann die TX-Schlange periodisch abfragen. Für jedes Kommunikationsschema zeigt ein bestimmtes Bit des HPXQSTAT_x-Registers 525, wenn es eingestellt ist, an, wenn Pakete in eine entsprechende TX-Schlange geladen werden. Die verbleibenden Bits werden verwendet, um die Größe des übertragenen Frames, der ausgelesen werden soll (in 32-Bit-Einheiten), anzuzeigen.
Wenn das bestimmte Bit des HPXQSTAT_x-Registers 525 eingestellt ist, wird die in die TX-Schlange geladene Information über das HPXQDATA_x-Register 530 gelesen. Bei der Information kann es sich beispielsweise um Datenpakete, Steuer- und Debug-Nachrichten handeln. Das HPXQDCNT_x-Register 535 stellt Informationen an den Steuerprozessor bereit, um zugewiesenen Speicher zu befreien oder wieder zu verwenden.
Unter Bezugnahme nun auf 8 wird eine beispielhafte Ausführungsform einer internen Logik 600 in dem Steuerprozessor 440 dargestellt. Die interne Logik 600 des Steuerprozessors 430 enthält einen Hostnachrichtendienst 610, der Steuernachrichten von dem Host gemäß einem unten beschriebenen Nachrichtenprotokoll empfängt. Die Steuernachrichten stellen verschiedene Dienste basierend auf der Art von empfangener Steuernachricht bereit. Die von dem Hostnachrichtendienst 610 empfangenen Nachrichtentypen werden normalerweise an die interne Hardwaretreiberlogik 620, einen Sitzungsmanager 630 oder einen Speichermanager 640 bereitgestellt.
Die Hardwaretreiberlogik 620 enthält einen seriellen Porttreiber, der verwendet wird, um Kommunikationskanäle zu aktivieren und einzurichten, über die TDM-(nicht paketierte)-Sprachabtastungen gesendet und empfangen werden. Die Hardwaretreiberlogik 620 enthält ferner einen Hostporttreiber, über den der Hostport gesteuert wird und über den Sprachpakete gesendet und empfangen werden.
Der Sitzungsmanager 630 ist für das Steuern von Sitzungen und des Datenflusses über die Kommunikationskanäle zuständig. In dieser Ausführungsform werden Sitzungen über ein Befehls-/Antwortnachrichtenprotokoll eingerichtet und aktiviert, welches allgemein auf SESSION_SETUP-, SESSION_SETUP_RSP-, SESSION_START- und SESSION_START_RSP-Nachrichten basiert (siehe 29–36 unten). Die Sitzungen werden durch SESSION_STOP-, SESSION_STOP_RSP-, SESSION_TEARDOWN- und SESSION_TEARDOWN_RSP-Nachrichten (siehe 37–40 unten) angehalten und abgeschlossen. Die der Sitzung zugeordneten Parameter und der Verlauf können periodisch unter Verwendung der SESSION_QUERY-Befehlsnachrichten extrahiert werden (siehe 41 und 42 unten).
Der Speichermanager 640 steuert den Einstrom und Ausstrom von Informationen aus RX- und TX-Schlangen sowie den internen Speicher.
II. NACHRICHTENPROTOKOLL
A. ALLGEMEINER ÜBERBLICK
Unter Bezugnahme nun auf 9 wird ein beispielhaftes Flussdiagramm einer Ausführungsform der grundlegenden Operationen gezeigt, welche durch den Signalprozessor in Kommunikation mit einem Host ausgeführt werden. Die Steueroperationen des Signalprozessors werden allgemein in vier Phasen kategorisiert: (1) Boot/POST-Phase 700, (2) Initialisierungsphase 710, (3) Konfigurationsphase 720, und (4) Laufzeitphase 730. Diese Steueroperationen treten über die Hostschnittstelle auf. Da der interne Speicher und die Schnittstellenregister des Signalprozessors im Speicher abgebildet und über die Hostschnittstelle in dieser Ausführungsform sichtbar sind, kann die Boot- und Initialisierungsphase 700 und 710 ausgeführt werden, indem direkt auf den Adressraum für den Speicher in dem Signalprozessor zugegriffen wird. Die Konfigurations- und Laufzeitphase 720 und 730 treten jedoch über eine Nachrichtenschichtabstraktion auf. Während der Laufzeitphase 730 werden eine Einrichtungs- und Aktivierungsphase 740 und 750 verwendet, um Sitzungen während der Laufzeit einzurichten (d. h. Setup), zu starten, anzuhalten und abzuschließen (d. h. Teardown).
1. Bootphase
Nach einem Reset werden alle Prozessorkerne des Signalprozessors in einem RESET-Status gesetzt. Ein POST-(„Power On Self Test")- und Laufzeit-Kernel-Bild werden in den internen Speicher des Signalprozessors geladen. Ein Prozessorkern wird dann aus seinem RESET-Status genommen, um das VoP-Untersystem zu booten und einen POST und eine Diagnose des Signalprozessors auszuführen. Dies umfasst das Testen der selbsttestbaren Logik in dem Signalprozessor einschließlich der Prozessorkerne und das Erzeugen eines Statusberichtes an einem festen Ort des globalen Speichers. Wenn der POST-Vorgang fehlschlägt, wird eine Fehlernachricht gesendet und die Ausführung wird angehalten. Andernfalls fährt der Prozessorkern zu der Initialisierungsphase 710 fort.
2. Initialisierungsphase
Nach einer erfolgreichen Bootphase 700 fängt die Initialisierungsphase 710 an. Die Initialisierungsphase 710 umfasst die Initialisierung von (i) Anwendungssoftware und/oder Firmware in dem Signalprozessor, (ii) der Host- und seriellen Ports, (iii) der Funktionalität des Steuerprozessors und dergleichen. Wenn die Initialisierungsvorgänge fehlschlagen, wird ein Anfangsfehlschlagenfehlercode zusammen mit dem ausführlichen Fehlerstatus an eine vorgeschriebene Stelle im globalen Speicher platziert. Andernfalls lädt der Signalprozessor am Ende der erfolgreichen Initialisierungen Informationen an die Stelle des globalen Speichers, um den Abschluss der Initialisierungsphase 710 anzuzeigen.
3. Konfigurationsphase
Nach erfolgreichem Abschluss der Initialisierungsphase 710 beginnt die Konfigurationsphase 720. Zu der Konfigurationsphase 720 gehört (i) Vorrichtungskonfiguration, (ii) Segmentherunterladen und (iii) Einrichtung der voreingestellten Dienstparameter.
Nach dem Booten wird der Signalprozessor für die Vorrichtungskonfiguration durch den Host unter Verwendung von Vorrichtungssteuernachrichten konfiguriert. Diese Nachrichten werden verwendet, um (a) eine Knotenidentifikation zuzuweisen (die hierin als „Knoten-ID" bezeichnet wird), welche zum Identifizieren des Signalprozessors verwendet wird, (b) Speicherpools zu konfigurieren, die von verschiedenen Anwendungsthreads verwendet werden und (c) die seriellen Ports zu konfigurieren. Das Format der Vorrichtungssteuernachrichten wird in den unten gezeigten 14–22 beschrieben.
Allgemein kann die Konfiguration der Vorrichtung gemäß der folgenden Vorgehensweise ausgeführt werden:
Eine Knoten-Einrichten-(DEV_SET_NODES)-Befehlsnachricht senden, um den Signalprozessor mit einer Knoten-ID zu konfigurieren und Informationen bezüglich des Hosts an den Signalprozessor bereitzustellen. Außer PING- und ECHO-Befehlsnachrichten werden von dem Signalprozessor keine anderen Nachrichten angenommen, bevor diese Nachricht gesendet wird.
Eine Vorrichtungsspeicherpoolinitialisierungs-(DEV_POOL_INIT)-Befehlsnachricht senden, um Speicherpools zu konfigurieren und eine Seriellen-Port-Einrichten-(SERIAL_PORT_SETUP)-Befehlsnachricht senden, um die seriellen Ports zu konfigurieren. Die SERIAL_PORT_SETUP-Befehlsnachricht wird auch dann gesendet, wenn keine TDM-Daten vorliegen.
Software- oder Firmware-Segmente auf den Signalprozessor herunterladen. Jedes Segment ist eine kleine Sammlung von Blöcken oder Datencodes.
Nach Abschluss wird der Signalprozessor alle Steuerbefehlsnachrichten annehmen, mit Ausnahme von DEV_SET_NODES, DEV_POOL_INIT und SERIAL_PORT_SETUP, welche zuvor ausgeführt worden sind.
Die heruntergeladene Software oder Firmware kann in Segmenten oder Code-/Datenblöcken ausgeführt werden, welche bei Bedarf schnell in und aus den DSP-Verarbeitungskernen geladen, ausgeführt und entladen werden können. Jedes Software- oder Firmware-Segment wird in den internen Speicher des Signalsprozessors durch die folgende Vorgehensweise geladen:
Der Host sendet eine Segmentzuweisungs-(SEG_ALLOC)-Nachricht aus 25–26 mit der Größe (in Oktetts) der Software (oder Firmware), die heruntergeladen werden soll. Der Signalprozessor reserviert einen Bereich im internen Speicher, um die Software oder Firmware der angegebenen Größe aufzunehmen und gibt die Startadresse dieses reservierten Bereichs im Speicher zurück. Wenn zu wenig Speicher verfügbar ist, gibt der Signalprozessor einen Fehlercode zurück, der angibt, dass nicht ausreichend Speicher vorliegt.
Der Host schreibt ein oder mehrere binäres) Bild(er) von einem oder mehreren Software- oder Firmware-Segment(en) direkt in den internen Speicher des Signalprozessors beginnend an der angegebenen Startadresse.
Nach Abschluss sendet der Hostprozessor eine Segment-Aktivieren-(SEG_ACTIVATE)-Nachricht aus 27, so dass der Signalprozessor das/die heruntergeladene(n) Segment(e) aktivieren kann.
Für die Einrichtung voreingestellter Dienstparameter gibt es zwei Arten von Parameterblöcken: einen voreingestellten Parameterblock und einen Sitzungsparameterblock. Der Zweck dieses Konfigurationsvorgangs ist es, die voreingestellten Parameter für alle Dienste, auf die für die Anwendung erforderlichen Werte einzustellen.
Hierin ist der „voreingestellte Parameterblock" ein globaler Block, der konfigurierbare Parameter aller Dienste hält. Der voreingestellte Parameterblock wird anfangs mit Werten geladen, die in der Firmware programmiert sind und werkseitige Voreinstellungen genannt werden. Nach der Erzeugung bekommt jede Sitzung eine Kopie von Parametern aus diesem Block. Der Wert eines Parameters in dem voreingestellten Parameterblock kann unter Verwendung verschiedener Steuernachrichten, die unten beschrieben werden, geändert werden. Die Wirkung jeder Änderung an voreingestellten Parametern dauert an, bis sie wieder geändert wird oder bis der Signalprozessor zurückgestellt wird.
Der „Sitzungsparameterblock" enthält Parameter, die für diese Sitzung eindeutig sind. Beim Sitzungsaufbau wird der Sitzungsparameterblock mit Parameterwerten erzeugt, die aus dem voreingestellten Parameterblock kopiert werden. Die Sitzungsparameter können auch über bestimmte Steuernachrichten geändert werden. Die Wirkung dieser Änderung dauert so lange an, wie die Sitzung aktiv ist (bis zum Abbruch). Diese Änderung betrifft nicht die Voreinstellung der Parameter.
4. Laufzeitphase
Nach Abschluss der Konfigurationsphase 720 ist der Signalprozessor zum Betreiben von Sitzungen bereit. Alle Laufzeitvorgänge werden über eine Nachrichtenschichtabstraktion über die Hostschnittstelle erfolgen. Der Host sendet Nachrichten an den Signalprozessor und empfängt Antwortnachrichten davon. Von Zeit zu Zeit erzeugt der Signalprozessor Status-/Ereignisinformationen, die an den Host gesendet werden. Diese Informationen werden über unangeforderte Statusnachrichten asynchron an dem Host ankommen. Ein Beispiel einer Statusnachricht ist eine „DTMF-Ton-erfasst"-Nachricht in einer bestimmten Sitzung.
Wie in 10 gezeigt, werden die Nachrichten hinsichtlich Bytes (oder Oktetts) beschrieben. Von dem Signalprozessor über die Hostschnittstelle empfangene Nachrichten und Daten verwenden einen 32-Bit-Datenbus. Das Format der Nachrichtenbytes in den 32-Bit-Wörtern wird gezeigt, wobei das erste Byte 810 in einer Nachricht 800, die am weitesten rechts (am niedrigsten) stehenden 8-Bits des 32-Bit-Worts einnehmen und das vierte Byte 820 in der Nachricht die am weitesten links (am höchsten) stehenden 8-Bits des 32-Bit-Worts einnehmen.
B. STEUERNACHRICHTEN
Steuernachrichten werden zwischen dem Host und dem Signalprozessor gesendet, um den Signalprozessor zu steuern, zu konfigurieren, zu überwachen und mit ihm zu kommunizieren, ohne Kenntnis seiner spezifischen Architektur. Jede Steuernachricht umfasst einen Steuerkopfteil wie unten beschrieben. Für diese Ausführungsform beträgt die Länge des Steuerkopfteils acht Bytes (Byte 0–7), obwohl anders strukturierte Steuerkopfteil verwendet werden können. In der Regel umfasst jede Steuernachricht ferner eine Nutzlast, um zusätzliche Informationen zu senden. In dieser Ausführungsform beginnt die Nutzlast bei „Oktett 8" der Steuernachricht. Einige Steuernachrichten enthalten jedoch einfach nur einen Steuerkopfteil (zum Beispiel DEV_INFO-Befehlsnachricht).
1. Steuerkopfteil
Unter Bezugnahme nun auf 11 wird eine beispielhafte Ausführungsform eines Steuerkopfteils 900 gezeigt, welcher in Nachrichtenkommunikationen verwendet wird, um den Signalprozessor dazu aufzufordern, eine Steueraufgabe zu initialisieren. Bei dem VoP-Untersystem könnten mehrere Signalprozessor mit einem lokalen Hostbus verbunden sein. Außerdem könnten mehrere logische Kanäle (Steuer, Paket, TDM) auf einem einzigen Bus gemultiplext sein. Der Steuerkopfteil 900 adressiert jeden Knoten eindeutig und demultiplext alle Steuerflüsse zu und von dem Signalprozessor.
Hier umfasst der Steuerkopfteil 900 einen Nachrichtenkopfteilabschnitt, der einen Zielknotenparameter 910, einen Quellknotenparameter 920, einen Prioritätsparameter 930, einen Nachrichtenlängenparameter 940 und einen Nachrichtentypparameter 950 enthält. Der Zielknotenparameter 910 enthält Informationen, die den Zielknoten eindeutig kennzeichnen (zum Beispiel Signalprozessor oder Host, für den die Steuernachricht bestimmt ist. Der Quellknotenparameter 920 enthält Informationen, die den Quellknoten eindeutig anzeigen (zum Beispiel Host oder Signalprozessor), von dem die Steuernachricht ausgeht. Diese Informationen können beim Beantworten einer Befehlsnachricht wertvoll sein.
Der Prioritätsparameter 930 enthält Informationen, die eine Prioritätsebene, die der Nachricht zugeordnet ist, bereitstellen. In dieser Ausführungsform wird die Prioritätsebene durch einen 2-Bit-Wert dargestellt, der eine Kombination von vier Prioritätsebenen angibt. Beispielsweise kann Priorität „00" der untersten Prioritätsebene zugeordnet sein und „11" ist als die höchste Prioritätsebene dargestellt.
Der Nachrichtenartparameter 950 enthält Informationen, die die Nachrichtenart anzeigen. In einer Ausführungsform kann eine Steuernachrichtenart durch „01" definiert sein.
Der Nachrichtenlängenparameter 940 enthält Informationen, die die Gesamtlänge der Steuernachricht in Bytes angeben, ausschließlich des Steuerkopfteils 900. Wie gezeigt, ist die Länge ein 11-Bit-Wert, der eine Höchstnachrichtengröße von 2047 Bytes angibt. Natürlich können andere Bitlängen, als die hierin zur Veranschaulichungszwecken verwendeten, verwendet werden.
Der Steuerkopfteil 900 umfasst ferner einen Steuerkopfteilabschnitt, der einen Steuerlängenparameter 970, einen Katalogparameter 980, einen Codeparameter 990 und möglicherweise einen optionalen Sequenznummerparameter 960 enthält. Der Sequenznummerparameter 960 wird durch den Urheber der Steuernachricht 900 als ein Mittel zur Nachrichtensynchronisierung bereitgestellt. Der Zielknoten würde die Sequenznummer einfach kopieren und in seiner Antwort zurückgeben.
Der Steuerlängenparameter 970 enthält Informationen, die die Länge in Bytes angeben, die dem bestimmten Steuervorgang zugeordnet ist (ausschließlich des Steuerkopfteils). Dadurch wird das Übertragen mehrerer Steuerpakete (die jeweils einem Vorgang zugeordnet sind) in einer einzigen Steuernachricht ermöglicht. Zu diesem Zweck kann die Steuernachricht 900 zusätzliche (mehrere) Steuerkopfteilabschnitte erfordern (zum Beispiel seine eigenen Parameter 960, 970, 980 und/oder 990), die jeweils Steuerpaketen für einen bestimmten Vorgang zugeordnet sind. Eine Steuerlänge von Null ist für Steuernachrichten ohne Nutzlast gültig.
Der Katalogparameter 980 enthält Informationen, die eine bestimmte Klasse der Steuernachricht kennzeichnet. Diese Klassen werden in verschiedene logisch bezogene Nachrichtenkataloge unterteilt. Ein „Vorrichtungssteuerkatalog" enthält beispielsweise Funktionen, die zum Initialisieren, Konfigurieren und Steuern von Laufzeit des Signalprozessors verwendet werden. Der „Sitzungssteuerkatalog" enthält Funktionen, die zum Aufbau, Verwalten und Abbruch von Sitzungen sowie für das Ressourcenmanagement der Sitzungen verwendet werden. Es gibt auch verschiedene Dienstkataloge (zum Beispiel Telefonie, Sprach, Fax, Modem), die Algorithmen, ihre Parameterblöcke und Algorithmenressourcen verwalten. Während eine Ausführungsaufgabe diese Kataloge handhabt, unterstützt die logische Zuordnung die Unterteilung der Steuernachrichten in ein flexibles Rahmenwerk, wobei die Funktionalität einfach zu einer höheren Ebene bewegt werden kann.
Der Codeparameter 990 enthält Informationen, die die bestimmte Art des Vorgangs in dem gegebenen Katalog anzeigen.
2. Nachrichtenkataloge
Unter Bezugnahme nun auf 12 wird eine beispielhafte Auflistung unterschiedlicher Nachrichtenkatalogarten gezeigt, welche durch den Signalprozessor unterstützt werden. Die Nachrichtenkataloge 1000 klassifizieren Steuernachrichten gemäß ausgewählten Funktionsgruppen. Zu den Nachrichtenkatalogarten können ohne Einschränkung Vorrichtungssteuerung 1010, Sitzungssteuerung 1020, Telefoniedienste 1030, Sprachdienste 1040, Faxdienste 1050 und Modemdienste 1060 gehören. Die Steuernachrichten dieser Nachrichtenkataloge umfassen einen Steuerkopfteil (oben beschrieben) und eine Nutzlast. Die Nutzlasten werden unten in den Abschnitten 2a–2f beschrieben.
2a. Vorrichtungssteuerkatalog
Unter Bezugnahme nun auf 13 wird eine Auflistung beispielhafter Nachrichten gezeigt, die mit einem Vorrichtungssteuerkatalog 1010 verbunden sind. Der Vorrichtungssteuerkatalog 1010 kann Nachrichten enthalten, die sich auf die Vorrichtungsinitialisierung, Konfiguration und Echtzeitvorgänge des Signalprozessors beziehen. Die Nachrichtenart wird durch den Inhalt des Codeparameters in einer eingehenden Steuernachricht gekennzeichnet.
Unter Bezugnahme auf 14 wird eine beispielhafte Nutzlast einer Knoten-Einrichten-(DEV_SET_NODE)-Befehlsnachricht 1100 dargestellt. Eine DEV_SET-_NODE-Befehlsnachricht 1100 einschließlich ihres Steuerkopfteils (siehe 11) und ihre Nutzlast wird von dem Host an den Signalprozessor gesendet, um (i) mindestens eine Knoten-ID einzurichten, um diesen Signalprozessor in den Steuernachrichten zu kennzeichnen und (ii) zu kennzeichnen, welcher Host autonome Nachrichten von diesem Signalprozessor empfangen soll.
Die DEV_SET_NODE-Befehlsnachricht 1100 kann an den Signalprozessor unmittelbar nach Abschluss des Hochfahrens gesendet werden, da der Signalprozessor keine anderen Nachrichten, außer PING und ECHO-Testnachrichten annimmt, bis die Knoten-ID konfiguriert wurde.
Insbesondere enthält die Nutzlast der DEV_SET_NODE-Befehlsnachricht 1100 eine Signalprozessor-Knoten-ID 1101, welche in der Steuernachricht, die von dem Host an den Signalprozessor gesendet wird, als der Zielknoten verwendet werden kann. Alternativ kann die Signalprozessor-Knoten-ID 1101 in allen Antwortnachrichten, die von dem Signalprozessor gesendet werden, als der Quellknoten verwendet werden. Die Nutzlast der DEV_SET_NODE-Befehlsnachricht 1100, eine Host-Knoten-ID 1102, welche in dem Steuerkopfteil aller autonomen Nachrichten, die von dem Signalprozessor gesendet werden, als der Zielknoten verwendet wird.
Unter Bezugnahme nun auf 15 wird eine beispielhafte Nutzlast einer Antwort 1105 auf die DEV_SET_NODE-Befehlsnachricht 1100 aus 14 veranschaulicht. Die Antwort, welche als die DEV_SET_NODE_RS-Nachricht 1105 bezeichnet wird, enthält Werte, die den Abschluss der DEV_SET_NODE-Befehlsnachricht 1100 anzeigen. Ein Statusparameter 1106 kann mit Informationen geladen sein, welche den Status des erfolgreichen Abschlusses der DEV_SET_NODE-Befehlsnachricht 1100 anzeigen. Der Statusparameter 1104 kann beispielsweise einen vorgegebenen Statuscodewert enthalten (zum Beispiel x00H). Andere Codewerte können verwendet werden, um einen bestimmten Fehler anzuzeigen.
Unter Bezugnahme nun auf 16 wird eine beispielhafte Nutzlast einer Antwort 1110 auf eine Vorrichtungsinformationsanforderungs-(DEV_INFO)-Befehlsnachricht dargestellt. Die DEV_INFO-Befehlsnachricht (nicht gezeigt) wird von dem Host an den Signalprozessor gesendet, um Informationen, die zu dem Signalprozessor gehören, anzufordern. Die DEV_INFO-Befehlsnachricht enthält nur einen Steuerkopfteil mit ungefähr geladenen Parametern. Die Antwort auf die DEV_INFO-Befehlsnachricht, welche als eine „DEV_INFO_RSP"-Nachricht 1110 bezeichnet wird, wird von dem Host für jede DEV_INFO-Befehlsnachricht zurückgegeben. Die DEV_INFO_RSP-Nachricht 1110 enthält Vorrichtungsinformationen, die zu der Version des Signalprozessors 1111 gehören, der Version der internen Logik 1112 und einer Größe des internen Speichers 1113.
Unter Bezugnahme nun auf 17 wird eine beispielhafte Nutzlast einer vorrichtungsspeicherpoolinitialisierungs-(DEV_POOL_INIT)-Befehlsnachricht 1115 dargestellt. Die DEV_POOL_INIT-Befehlsnachricht 1115 wird von dem Host an den Signalprozessor bereitgestellt und konfiguriert die Speicherpools.
Wie gezeigt, umfasst die Nutzlast der DEV_POOL_INIT-Befehlsnachricht 1115 (i) serielle-Puffer-Konfigurationsparameter 1116, (ii) einen Host-Port-Puffer-Konfigurationsparameter 1117 und (iii) einen dynamischen-Speicher-Puffer-Konfigurationsparameter 1118. Der serielle-Puffer-Konfigurationsparameter 116 enthält Informationen, die die Größe (in Bytes) und die Anzahl der zuzuweisenden seriellen Port-Puffer angibt. Der Host-Port-Puffer-Konfigurationsparameter 1117 enthält Informationen, die die Größe (in Bytes) und die Anzahl der in Verbindung mit RX- und TX-Datenschlangen verwendeten Host-Port-Puffer-Speicher angibt. Der dynamische-Speicher-Puffer- Konfigurationsparameter 1118 enthält Informationen, die die Größe (in Bytes) und Anzahl der zuzuweisenden dynamischen Speicherpuffer angibt (diese Puffer werden für sitzungsdynamische Daten verwendet).
Unter Bezugnahme auf 18 wird eine beispielhafte Nutzlast einer Antwort 1120 auf die DEV_POOL_INIT-Befehlsnachricht aus 17 dargestellt. Die als DEV_POOL_INIT_RSP-Nachricht 1120 bezeichnete Antwort wird von dem Signalprozessor für jede DEV_POOL_INIT-Befehlsnachricht 1115, die von dem Host gesendet wird, bereitgestellt. Die DEV_POOL_INIT_RSP-Nachricht 1120 enthält einen Statusparameter 1121. Der Statusparameter 1121 enthält Informationen, die den erfolgreichen Abschluss der DEV_POOL_INIT-Befehlsnachricht 1115 angeben.
Unter Bezugnahme nun auf 19 wird eine beispielhafte Nutzlast einer Vorrichtungs-Report-Konfigurations-(DEV_REPORT_CONFIG)-Befehlsnachricht 1125 gezeigt. Die DEV_REPORT_CONFIG-Befehlsnachricht 1125 wird von dem Host bereitgestellt und konfiguriert den Signalprozessor, so dass er die DEV_HEARTBEAT- und/oder DEV_STATISTICS-Nachricht wir in 21 und 22 beschrieben, periodisch sendet. Die DEV_REPORT_CONFIG-Befehlsnachricht 1125 wird normalerweise gesendet, nachdem der Signalprozessor seine Bootsequenz abgeschlossen hat und umfasst einen Vorrichtungs-Heartbeat-Frequenzparameter 1126. Dieser Parameter wird auf einen Wert eingestellt, der die ungefähre Periodizität für den Signalprozessor darstellt, um die DEV_HEARTBEAT-Befehlsnachricht zu senden. Die DEV_REPORT_CONFIG-Befehlsnachricht 1125 umfasst ferner einen Vorrichtungs-Statistik-(DEV_STATISTICS)-Frequenzparameter 1127, der auf einen Wert eingestellt wird, der die ungefähre Periodizität zum Senden der DEV_STATISTICS-Befehlsnachricht darstellt. Die Periodizität beim Senden der DEV_HEARTBEAT und/oder DEV_STATISTICS- Befehlsnachricht kann in Intervallen von 10 Millisekunden „ms" konfiguriert sein.
Unter Bezugnahme auf 20 wird eine beispielhafte Nutzlast einer Antwort auf die DEV_REPORT_CONFIG-Befehlsnachricht aus 19 gezeigt. Die hier als DEV_REPORT_CONFIG_RSP-Nachricht 1130 bezeichnete Antwort enthält einen Statusparameter 1131. Der Statusparameter 1131 enthält Informationen, um den erfolgreichen Abschluss der DEV_REPORT_CONFIG-Befehlsnachricht 1125 aus 19 anzuzeigen.
Unter Bezugnahme nun auf 21 wird eine beispielhafte Nutzlast einer Vorrichtungs-Heartbeat-(DEV_HEARTBEAT)-Nachricht 1135 gezeigt. Die DEV_HEARTBEAT-Nachricht 1135 ist eine periodische Nachricht, die von dem Signalprozessor gesendet wird, wenn die DEV_HEARTBEAT-Frequenz in dem DEV_REPORT_CONFIG-Befehl 1125 aus 19 auf einen Wert ungleich Null eingestellt ist. Die DEV_HEARTBEAT-Nachricht 1135 enthält eine Heartbeat-Nummer 1136, bei der es sich in dieser Ausführungsform um einen monotonischen Zählerwert handelt.
Unter Bezugnahme nun auf 22 wird eine beispielhafte Nutzlast einer Vorrichtungs-Statistik (DEV_STATISTICS)-Nachricht 1140 gezeigt. Die DEV_STATISTICS-Nachricht 1140 ist eine periodische Statusnachricht, die von dem Signalprozessor gesendet wird, wenn er über den DEV_REPORT_CONFIG-Befehl 1125 aus 19 aktiviert wird. Diese Nachricht enthält Statistiken des Signalprozessors einschließlich einer oder mehrerer der Folgenden:
Parameter 1141 – die Gesamtanzahl von während der Betriebszeit des Signalprozessors bedienten Sitzungen;
Parameter 1142 – die Anzahl der gegenwärtig aktiven Sitzungen;
Parameter 1143 – die auf Grund von Verarbeitungsanforderungen aller aktiven Sitzungen von allen DSP-Prozessorkernen des Signalprozessors erfahrene Lademenge;
Parameter 1144 – die Gesamtanzahl von während der Laufzeit des Signalprozessors erfahrenen fehlgeschlagenen Einrichtungen;
Parameter 1145 – die Gesamtanzahl, die von während der Laufzeit des Signalprozessors erfahrenen fehlgeschlagenen Starts;
Parameter 1146 und 1147 – TDM-overflows, wobei es sich um die Anzahl neuer Ereignisse (seit dem Hochfahren) handelt, welche in einem seriellen Port platziert worden sind, bevor ein altes Ereignis seine Verarbeitung abgeschlossen hat; TDM-underflows, wobei es sich um die Anzahl von Ereignissen (seit dem Hochfahren) handelt, zu deren Sendung der serielle Port bereit war, aber kein Frame verfügbar war;
Parameter 1148 – schlechte Portereignisse, wobei es sich um die Anzahl von nicht vorhergesehenen Ereignissen handelt, die von einem seriellen- oder Hostport während der Laufzeit erfahren wurden;
Parameter 1149 – Anzahl von Jobs (Frameverarbeitungsereignisse) in der Schlange;
Parameter 1150 – Gesamtjobs, die während der Laufzeit für jeden der Prozessorkerne abgeschlossen wurden.
Unter Bezugnahme auf 23 wird eine beispielhafte Nutzlast einer Seriellen-Port-Einrichten-(SERIAL_PORT_SETUP)-Befehlsnachricht 1155 gezeigt. Die SERIAL_PORT_SETUP-Befehlsnachricht 1155 wird von dem Host an den Signalprozessor gesendet und konfiguriert einen gegebenen seriellen Port. Beispielsweise können die (TDM) seriellen Ports an dem Signalprozessor unkomprimierte PCM-Sprachabtastungen gemäß G.711-Standards empfangen. Um die seriellen Ports zu konfigurieren, sind somit verschiedene Steuerungen und Moden für Takt, Frame Sync, Kanal usw. erforderlich, um mit einer großen Bandbreite externer Hardwarekomponenten korrekt zu funktionieren.
Wie gezeigt, umfasst die SERIAL_PORT_SETUP-Befehlsnachricht 1155 einen Portparameter 1156, ein Empfangs-(RX)-Steuerfeld 1157, ein RX-Kanalsteuerfeld 1158, ein RX-Taktsteuerfeld 1159, ein RX-Frame-Sync-Steuerfeld 1160, ein Sende-(TX)-Steuerfeld 1161, ein TX-Kanalsteuerfeld 1162, ein TX-Taktfeld 1163 und ein TX-Frame-Sync-Steuerfeld 1164. Da die von den Parametern des RX-basierten Felds 1157–1160 unterstützte Funktionalität allgemein gleichwertig zu der Funktionalität ist, die durch die Parameter des TX-basierten Felds 1161–1164 unterstützt wird, werden nur die Funktionen der RX-basierten Parameter ausführlich erörtert. Diese Parameter stellen die Programmierbarkeit der Hardware der seriellen Portschnittstelle des Signalprozessors dar, um mit einer Vielzahl externer Komponenten verbunden zu werden.
Insbesondere enthält der Portparameter 1156 eine serielle Portnummer (SPNUM), die die aufgebaute besondere Portnummer kennzeichnet. Da der Signalprozessor vier serielle Ports in dieser Ausführungsform aufweist, beträgt die serielle Portnummer zwischen 0–3.
Das RX-Steuerfeld 1157 wird zum Steuern der Empfangsfunktionalität der seriellen Portschnittstelle des Signalprozessors verwendet. Das RX-Steuerfeld 1157 enthält einen Frame-Sync-Quell-(FSS)-Parameter 1165, einen Frame-Sync-Polarität-(FSP)-Parameter 1166, einen Datentaktquell-(DCS)-Parameter 1167, einen Datentaktpolarität-(DCP)-Parameter 1168, einen Datenbitverzögerungs-(DBD)-Parameter 1169, einen Datenelementgrößen-(DES)-Parameter 1170, einen Datenelementumkehr-(DER)-Parameter 1171, einen Frame-Sync-Drive-(FSD)-Parameter 1172 und einen Taktdrive-(CKD)-Parameter 1173.
Der FSS-Parameter 1165 enthält Informationen, die verwendet werden, um anzuzeigen, ob ein zugeführter Frame Sync verwendet oder ignoriert werden soll. Wenn der Frame Sync beispielsweise von der externen Quelle bereitgestellt wird, was dadurch dargestellt wird, dass der FSS-Parameter einen logischen Wert von „0" hat, wird der Frame Sync beispielsweise ignoriert. Wenn der Frame Sync von einer internen Quelle bereitgestellt wird, was dadurch dargestellt wird, dass der FSS-Parameter einen logischen Wert von „0" hat, wird der Frame Sync angelegt.
Der FSP-Parameter 1166 zeigt an, ob die Synchronisation an eine Vorderflanke oder Hinterflanke des Signals angelegt wird. Wie gezeigt, wird der FSP-Parameter 1166 frei („0"), wenn die Synchronisation an der Vorderflanke koordiniert wird und eingestellt („1"), wenn die Synchronisation an der Hinterflanke koordiniert wird.
Der DCS-Parameter 1167 zeigt an, ob eine interne oder externe Datentaktquelle verwendet werden soll (extern – logisch „0") oder ignoriert (intern – logisch „1").
Der DCP-Parameter 1168 zeigt an, ob die Taktpolarität auf der Vorderflanke basiert (logisch „0") oder auf der Hinterflanke (logisch „1") des Signals.
Der DBD-Parameter 1169 enthält Informationen, die festlegen, wie viel Bitversatz zu dem Frame Sync hinzugefügt werden soll, um das erste Bit des ersten Datenelements in einem eingehenden Frame zu erfassen. In dieser Ausführungsform sind null Bits oder zwei Bits gültige Werte für den DBD-Parameter 1169.
Der DES-Parameter 1170 enthält Informationen, die festlegen, wie breit jedes Datenelement hinsichtlich der Bitanzahl in dem eingehenden TDM-Frame ist. Ein Frame besteht aus mehreren Datenelementen zwischen Frame-Sync-Signalen. Ein Datenelement eines G.711 ☐-law- oder A-law-Frames ist so konfiguriert, dass es acht (8) Bits enthält und kann durch einen DES-Parameterwert von "00" dargestellt werden. Bei Verwendung von Pulscodemodulation werden 16-Bitdatenelemente verwendet, wie durch den logischen Wert „01" dargestellt.
Der DER-Parameter 1171 enthält Informationen, die festlegen, ob das Datenelement vor der Bereitstellung an die DMA-Steuerung des Signalprozessors Bit umgekehrt werden sollte. Hinsichtlich eines Empfangsports kann der DER-Parameter 1171, wenn er frei ist, darstellen, dass das Bitmuster für das Datenelement nicht umgekehrt werden sollte. Der DER-Parameter 1171 kann jedoch, wenn er eingestellt ist, darstellen, dass das Bitmuster umgekehrt werden sollte. Für einen Empfangsport können logische Werte von „1" oder „0" darstellen, dass das Bitmuster für das Datenelement umgekehrt bzw. nicht umgekehrt werden sollte.
Der FSD-Parameter 1173 enthält Informationen, die festlegen, ob ein interner Frame Sync verwendet werden soll, um eine externe logische Vorrichtung anzutreiben. Ein logischer Wert „0" zeigt beispielsweise an, dass der interne Frame Sync nicht verwendet wird, um die externe logische Vorrichtung anzutreiben, während der logische Wert von „1" anzeigt, dass der interne Frame Sync verwendet wird, um die externe logische Vorrichtung anzutreiben.
Der CKD-Parameter 1173 enthält Informationen, die festlegen, ob eine interne Taktquelle verwendet werden soll, um die externe logische Vorrichtung anzutreiben. Ein logischer Wert von „0" zeigt beispielsweise an, dass die interne Taktquelle nicht verwendet wird, um die externe logische Vorrichtung anzutreiben, während ein logischer Wert von „1" anzeigt, dass die interne Taktquelle verwendet wird, um die externe logische Vorrichtung anzutreiben.
Das RX-Kanalsteuerfeld 1158 stellt Einstellungen des seriellen-Port-RX-Kanals bereit. Das RX-Kanalsteuerfeld 1158 enthält beispielsweise einen Empfangskanal Start-(RCS)-Parameter 1175, welches den Anfangzeitschlitz oder die Kanalnummer in mehrfachen von 4 festlegt, von dem dieser Empfangsport den Empfang von Elementen beginnen sollte. Gültige Nummern sind 0, 4, 8, 12, ... 1020. Das RX-Kanalsteuerfeld 1158 enthält ferner einen Empfangskanalzähler (MAX-RCC) 1176, welcher einen Wert enthält, der die Anzahl von Zeitschlitzen oder Kanälen zum Erfassen des Beginns an der RCS-Stelle enthält.
Das RX-Taktsteuerfeld 1159 stellt Einstellungen des seriellen-Port-RX-Takts bereit. Das RX-Taktsteuerfeld 1159 enthält einen Taktteiler-(DIV)-Parameter 1180, einen Quellmodus-(SM)-Parameter 1181, einen Taktpolaritäts-(SP)-Parameter 1182, einen Taktaktivierungs-(EN)-Parameter 1183 und einen internen-Takt-Sync-(SNC)-Parameter 1184. Insbesondere enthält der DIV-Parameter 1180 Informationen, die das Taktverhältnis bezüglich des Systemtakts festlegen. Der SM-Parameter 1181 enthält Informationen, die die Quelle des internen Takts festlegen, nämlich, ob der interne Takt auf einem externen Takt oder einem Systemtakt beruht.
Zusätzlich enthält der SP-Parameter 1182 Informationen, die festlegen, ob der Taktteiler den Takt an der positiven oder negativen Flanke des internen Takts teilt (zum Beispiel „0"=positive Flanke, „1"=negative Flanke). Der EN-Parameter 1183 aktiviert, wenn er eingestellt ist, die Erzeugung des internen Takts. Der SNC-Parameter 1184 enthält Informationen, die den internen Takt an einem externen Frame Sync synchronisieren (SNC="1") oder er läuft frei (SNC="0").
Das RX-FS-Steuerfeld 1160 stellt Einstellungen des seriellen-Port-RX-Frame-Sync für die Erzeugung des internen Frame Syncs bereit. Das RX-FS-Steuerfeld 1160 enthält einen Frameperioden-(FPER)-Parameter 1185, der die Frameperiode hinsichtlich der Bitanzahl der aktuellen Taktrate festlegt. Das RX-FS-Steuerfeld 1160 enthält ferner einen Erzeugerausgabe-(GO)-Parameter 1186 und einen Frame-Sync-aktivieren-(EN)-Parameter 1187. Der GO-Parameter 1186 aktiviert, wenn er eingestellt ist, den internen Frame-Sync-Erzeuger und überschreibt externe Frame Syncs. Der EN-Parameter 1187 enthält Informationen zum Aktivieren der Frame-Sync-Erzeugung.
Unter Bezugnahme nun auf 24 wird eine beispielhafte Nutzlast einer Antwort 1200 auf die SERIAL_PORT_SETUP-Befehlsnachricht 1155 aus 23 dargestellt. Die als die SERIAL_PORT_SETUP-RSP-Nachricht 1200 bezeichnete Antwort enthält einen Statusparameter 1201 und ein Portfeld 1202. Der Status-Parameter 1201 enthält Informationen, die anzeigen, ob die Operationen der SERIAL_PORT_SETUP-Befehlsnachricht 1155 erfolgreich abgeschlossen worden sind. Wenn dies der Fall ist wird beispielsweise ein ausgewählter Statuscodewert (zum Beispiel logischer Wert von „0") als der Statusparameter 1201 geladen. Andernfalls können andere Codewerte verwendet werden, um einen bestimmten Fehler anzuzeigen.
Das Portfeld 1202 enthält einen Aktivierungs-(EN)-Parameter 1205 und einen seriellen-Port-Zahl-(SPNUM)-Parameter 1206, der äquivalent zu den Werten der EN- und SPNUM-Parameter 1183 und 1156 der SERIAL_PORT_SETUP-Befehlsnachricht 1155 aus 23 ist zur Rückgabe an den Host.
Unter Bezugnahme auf 25 wird eine beispielhafte Nutzlast einer Segmentszugweisungs-(SEG_ALLOC)-Befehlsnachricht 1210 gezeigt. Die SEG_ALLOC-Befehlsnachricht 1210 wird von dem Host an den Signalprozessor gesendet, um anzufordern, dass Speicherraum für ein Bild oder eine Software oder Firmware zum Laden in den Signalprozessor reserviert wird. Ein Speichraumgrößenparameter 1211 enthält Informationen, die die Größe des zu ladenden Bilds (in Bytes) angeben.
Unter Bezugnahme nun auf 26 wird eine beispielhafte Nutzlast einer Antwort 1215 auf die SEG_ALLOC-Befehlsnachricht 1210 aus 25 dargestellt. Die als eine SEG_ALLOC_RSP-Nachricht 1215 bezeichnete Antwort wird von dem Signalprozessor für jede SEG_ALLOC-Befehlsnachricht von dem Host zurückgegeben. Bei Bestimmung, dass er neue Segmente von Software oder Firmware der gegebenen Speichergröße annehmen kann, gibt der Signalprozessor die SEG_ALLOC_RSP-Nachricht 1180 zurück, welche einen Statusparameter 1216 enthält, um den Abschluss der SEG_ALLOC-Befehlsnachricht 1210 anzeigt und einen Speicherstartadressenparameter 1217 enthält. Der Speicherstartadressenparameter 1217 enthält eine Startbyteadresse des Speichergebiets bezüglich der Basisadresse, die dem internen Speicher des Signalprozessors zugeordnet ist.
Unter Bezugnahme nun auf 27 wird eine beispielhafte Nutzlast einer Antwort auf eine Segmentaktivieren-(SEG_ACTIVATE)-Befehlsnachricht dargestellt. Die SEG_ACTIVATE-Befehlsnachricht (nicht gezeigt) wird von dem Host an den Signalprozessor gesendet und fordert die Aktivierung eines Bilds (Software oder Firmware) an, welches zuletzt in den Signalprozessor geladen worden ist. Die Steuernachricht enthält keine Nutzlast, sondern wird nur durch die Auswahl geeigneter Katalog- und Codeparameter identifiziert. Wie gezeigt, bestimmt eine Antwort auf den SEG_ACTIVATE-Befehl, eine SEG_ACTIVATE_RSP-Nachricht 1220, die Genauigkeit der transportierten Daten durch Bestätigung der Größe des Segmenttyps usw. und gibt die Informationen als den Statusparameter 1221 zurück, um eine solche Genauigkeit darzustellen. Wenn ein Fehler während der Verarbeitung dieser Segmentdaten auftritt, befreit der Signalprozessor den Speicher der von der vorherigen SEG_ALLOC-Befehlsnachricht zugewiesen worden ist (siehe 25) und gibt einen Fehlercode in dem Statusparameter 1221 zurück.
Die ECHO- oder PING-Nachrichten werden von dem Host gesendet. Die PING-Befehlsnachricht wird verwendet, um die Kommunikation zwischen dem Signalprozessor und dem Host zu testen. Diese Nachricht hat keine Nutzlast, sondern ihr Steuerkopfteil spezifiziert in dem Katalogparameter „Vorrichtungssteuerung" (0x00) und eine „PING"-Testnachricht (0xEE) in dem Codeparameter. Der Signalprozessor sendet eine identische PING-Nachricht an den Host als Antwort. Die ECHO-Befehlsnachricht wird auch verwendet, um Kommunikationen zwischen dem Signalprozessor und dem Host zu testen. Der Steuerkopfteil für die ECHO-Befehlsnachricht spezifiziert „Vorrichtungssteuerung" (0x00) in dem Katalogparameter und eine ECHO-Testnachricht (0xEF) in dem Codeparameter. Die ECHO-Befehlsnachricht hat außerdem eine Nutzlast unbestimmter Länge und Inhalts mit der Ausnahme, dass die Nachricht nicht länger als die zulässige Höchstlänge sein darf. Der Signalprozessor sendet eine identische Kopie dieser Nachricht zurück an den Host als eine Antwort.
2b. Sitzungssteuerkatalog
Eine beispielhafte Auflistung von Nachrichten, die einem Sitzungssteuerkatalog zugeordnet sind, wird in 28 gezeigt. Der Sitzungssteuerkatalog 1300 enthält Steuernachrichten, die sich auf das Einrichten, Testen und Unterbrechen von Sitzungen beziehen. Der Signalprozessor kann verschiedene Sitzungen gleichzeitig unterstützen. Die Anzahl von Sitzungen, die der Signalprozessor unterstützen kann, hängt von der Kombination von Faktoren ab, wie beispielsweise der verwendeten Codierer-/Decodierer-(Codec)-Typen, der Länge des Echoausblendungs-Tails und anderen Faktoren, die die Berechnung und Speicheranforderungen für die Sitzung beeinflussen.
Allgemein wird eine Sitzung unter Verwendung einer SESSION_SETUP-Befehlsnachricht eingerichtet (was allgemein als ein „Setup" bezeichnet wird). Nach dem erfolgreichen Einrichten einer Sitzung können die voreingestellten Parameter für Telefonie-, Sprach-, Fax- oder Modemdienste über die geeigneten unten beschriebenen Dienstkatalognachrichten geändert werden. Schließlich wird die Sitzung durch eine SESSION START-Befehlsnachricht aktiviert. Dadurch wird der Datenstrom während der Sitzung gestartet.
Nach dem Start einer Sitzung kann sie über eine SESSION_STOP-Befehlsnachricht gestoppt werden und dann unter Verwendung einer anderen SESSION_SETUP-Befehlsnachricht und einer anderen Dienstkatalognachricht rekonfiguriert werden und schließlich unter Verwendung einer SESSION_START-Befehlsnachricht gestartet werden. Dieser Zyklus kann für die Dauer eines Anrufs wiederholt werden, bis die Sitzung schließlich über eine SESSION_STOP- und eine nachfolgende SESSION_TEARDOWN-Befehlsnachricht abgeschlossen wird (was allgemein als „Abbruch" bezeichnet wird).
Unter Bezugnahme nun auf 29 wird eine beispielhafte Nutzlast einer Sitzung-Einrichten-(SESSION_SETUP)-Befehlsnachricht 1305 gezeigt. Die SESSION_SETUP-Befehlsnachricht 1305 wird von dem Host bereitgestellt und initiiert eine Sitzung. Alle Informationen, die notwendig sind, um eine Sitzung vollständig zu beschreiben, sind in dieser Nachricht enthalten. Die Nachricht stellt Dienste (Codierer, Decodierer, Telefonie) für die Sitzung bereit und adressiert nahe-Ende- und ferne-Ende-Kanäle. Jedes Ende hat einen Empfangs-(RX)- und einen Sende-(TX)-Kanal. Eine Sitzung umfasst somit zwei Schlüssel oder vier Endpunkte. Der Klarheit halber handelt es sich bei dem „ferne-Ende-Kanälen" um die Kommunikationsstrecken über ein Netzwerk. Die „nahe-Ende-Kanäle" sind die Kommunikationsstrecken, die lokaler für das VoP-Untersystem sind.
Wie gezeigt, umfasst die SESSION_SETUP-Befehlsnachricht 1305 einen Sitzungs-ID-Parameter 1306, ein Dienst-Einrichten-Feld 1307, ein Telefoniefeld 1308, ein nahe-Ende-Kanäle-Feld 1309, ein ferne-Ende-Kanäle-Feld 1310, ein nahe-Ende-Takt-Parameter 1311 und ein ferne-Ende-Takt-Parameter 1312.
Der Sitzungs-ID-Parameter 1306 enthält eine Sitzungs-ID, nämlich Daten, die von dem Host zugeführt werden, um eine Sitzung an den Signalprozessor eindeutig zu identifizieren. In einer Ausführungsform erzeugt und führt der Host alle Sitzungs-IDs für alle aktiven Sitzungen, die er steuert und stellt die Sitzungs-ID für alle sitzungsbasierten Steuernachrichten bereit. Der Signalprozessor kann die Sitzungs-ID verwenden, um sitzungsbezogene Datenpakete und Steuernachrichten (Antworten und asynchroner Status) zu identifizieren, die er an den Host sendet. Die Sitzungs-ID ist mit zwei Flüssen verbunden, in der Regel einem TDM-Fluss (RX, TX) und einem Paketfluss (RX, TX).
Das Dienst-Einrichten-Feld 1307 enthält Codierer- und Decodierer-Dienstparameter 1315 und 1316. Der Codierer-Dienstparameter 1315 enthält Informationen bezüglich der Art der Codierfunktion, die zwischen dem nahen-Ende-Empfangskanal und dem fernen-Ende-Sendekanal verwendet werden. Der Decodierer-Dienstparameter 1316 enthält Informationen bezüglich der Art von Decodierfunktionen, die zwischen dem fernen-Ende-Empfangskanal und dem nahen-Ende-Sendekanal verwendet wird. Die Arten der Codierer- und Decodiererfunktionen werden in 30 gezeigt.
Unter Bezugnahme wieder auf 29 enthält das Telefonie-Dienst-Feld 1308 Parameter 1320–1329, die Telefoniecharakteristiken des VoP-Untersystems konfigurieren. Eine Charakteristik ist das spezifische TDM-Datenformat für empfangene und gesendete TDM-Sprache. Das spezifische TDM-Datenformat kann durch Laden eines bestimmten Werts in dem TDM-Typparameter 1320 aus 29 ausgewählt werden. Das TDM-Datenformat kann beispielsweise ein linearer 16-Bit-PCM (00), 8-Bit-G.711-☐-Law(01) oder 8-Bit-G.711-A-Law (10) sein.
Eine weitere Charakteristik bezieht sich auf die Echoausblendung-Einrichtung, die durch Zuweisen eines Werts entsprechend den Echoausblendungs-Einrichtungsoptionen in den Parameter 1321, wie in 31 gezeigt, ausgewählt werden kann. Noch eine weitere Charakteristik ist die Auswahl eines spezifischen Testmodus für die Sitzung durch Programmieren des Testmodusparameters 1322, der in 32 gezeigt wird.
Zu anderen Charakteristiken gehört das Aktivieren oder Deaktivieren verschiedener Tonerfassungen oder -erzeugungen wie beispielsweise (1), die „DTMF"-(Dual Tone Modulated Frequency)-Erfassung (DTD), (2) „CP" (Call Progress), Fax, Modemtonerfassung (TD), (3) DTMF-Erzeugung (DTG) und (4) CP, Fax und Modemtonerzeugung (TG). In dieser Ausführungsform kann jeder dieser Tonerfassungs- oder -erzeugungsmechanismus durch Einstellen seiner entsprechenden DTD-, TD-, DTG- und TG-Parameter 1323–1326 aktiviert werden.
Der Muteparameter 1327 enthält Informationen, die festlegen, ob erfasste Ton- oder DTMF-Stellen als Telefoniepakete weitergeleitet werden sollten. Der Sprachaktivitätserfassungs-(VAD)-Parameter 1328 enthält Informationen, die festlegen, ob Sprachaktivitätserfassungsalgorithmen verwendet werden sollten. Der in-Band/außer-Band-(IBOB)-Parameter 1329 steuert, ob Berichte eines erfassten Ereignisses an den Host als eine Steuernachricht sowie ein Sendedatenpaket gesendet werden.
Unter Bezugnahme wieder auf 29 werden die "nahe-Ende-" und „ferne-Ende"-Taktparameter 1311 und 1312 von dem Host zugewiesen und werden verwendet, um Paketdatenflüsse zu identifizieren. Für Datenpakete, die über den Hostport gesendet werden, fügt ein Prozessorkern das entsprechende Tag in den Datenpaketkopfteil ein. Datenpakete, die an dem nahen Ende empfangen oder gesendet werden, sollten das nahe-Ende-Tag 1311 enthalten; Datenpakete, die an dem fernen Ende empfangen oder gesendet werden sollen, sollten das ferne-Ende-Tag 1312 enthalten.
Die nahen-und-fernen-Empfangs-(RX)-und-Sende-(TX)-Adressen 1330–1333 sind die angeforderten physischen Kanaladressen hinsichtlich des TDM-Zeitschlitzes (Port-Nr., Schlitz-Nr.) oder die Hostportkanal-ID für den gegebenen Fluss. Ein Beispiel von Adresstypen wird in 33 umrissen.
Unter Bezugnahme auf 24 wird eine beispielhafte Nutzlast einer Antwort 1335 auf die SESSION SETUP-Befehlsnachricht 1305 aus 29 dargestellt. Die Antwort, die als eine SESSION_SETUP_RSP-Nachricht 1335 bezeichnet wird, wird von dem Signalprozessor für jeden SESSION_SETUP-Befehl 1305, der von dem Host empfangen wird, gesendet. Hierin umfasst die Nutzlast einen Statusparameter 1336, einen Sitzungs-ID-Parameter 1337, ein nahe-Ende-Kanalfeld 1338, ein ferne-Ende-Kanal-Feld 1339 und einen Sitzungs-Last-Parameter 1340.
Der Statusparameter 1336 enthält Informationen, um anzuzeigen, ob die SESSION_SETUP-Befehlsnachricht 1305 aus 29 erfolgreich abgeschlossen worden ist. Der Sitzungs-ID-Parameter 1337 enthält die Sitzungs-ID, die von dem Host bereitgestellt wurde. Der Sitzungs-Last-Parameter 1340 enthält die Gesamtsitzungslast für alle Sitzungen, die aufgebaut worden (MIPs·100).
Sowohl das nahe-Ende- als auch das ferne-Ende-Kanalfeld 1338 und 1339 enthalten Parameter, die die Empfangs-(RX)- und Sende-(TX)-Adressen 1341–1344 spezifizieren. Diese Adressen 1341–1344 sind die tatsächlichen physischen Kanaladressen hinsichtlich des TDM-Zeitschlitzes (Port-Nr., Schlitz-Nr.) oder der Hostpaketkanal-ID für den gegebenen Fluss, vorausgesetzt, dass der Statusparameter 1336 den erfolgreichen Abschluss der SESSION_SETUP-Befehlsnachricht 1305 anzeigt. Andernfalls sind die Parameter nicht gültig.
Wenn der Host die RX- und TX-Adressen 1330–1333 bereitstellt (siehe 29) und sie für den Signalprozessor akzeptabel sind, dann werden sie unter Verwendung dieser Nachricht reflektiert. Wenn der Host Teiladressen bereitstellt, werden sie von dem Signalprozessor zugewiesen und an den Host über diese Parameter 1341–1344 zurückgegeben.
Unter Bezugnahme nun auf 35 wird eine beispielhafte Nutzlast einer Sitzungsstart-(SESSION_START)-Befehlsnachricht 1345 dargestellt. Die SESSION_START-Befehlsnachricht 1345 wird von dem Host an den Signalprozessor gesendet und zum Aktivieren der Sitzung verwendet. Die SESSION_START-Befehlsnachricht 1345 enthält eine Sitzungs-ID 1346 zum Identifizieren dieser Sitzung. Nach Empfang dieses Befehls, steuert der Signalprozessor den Eingang und Ausgang von Datenflüssen und beginnt das Bedienen der RX- und TX-Schlangen.
Unter Bezugnahme nun auf 36 wird eine beispielhafte Nutzlast einer Antwort 1350 auf die SESSION_START-Befehlsnachricht 1345 aus 35 dargestellt. Die hierin als SESSION_START_RSP-Nachricht 1350 bezeichnete Antwort wird von dem Signalprozessor als Antwort auf jede SESSION_START-Befehlsnachricht 1345 bereitgestellt, die von dem Host empfangen wurde. Wie gezeigt, umfasst die SESSION_START_RSP-Nachricht 1350 einen Statusparameter 1351 und einen Sitzungs-ID-Parameter 1352. In dieser Ausführungsform enthält der Statusparameter 1351 Informationen, die den Abschluss der SESSION_START-Befehlsnachricht 1345 anzeigen. Beispielsweise können Codes verwendet werden, um einen Erfolg anzuzeigen (zum Beispiel „0") sowie bestimmte Arten von Fehlern. Der Sitzungs-ID-Parameter 1352 enthält die von dem Host bereitgestellte Sitzungs-ID.
Unter Bezugnahme auf 37 wird eine beispielhafte Nutzlast einer Sitzungsstopp-(SESSION_STOP)-Befehlsnachricht 1355 gezeigt. Die SESSION_STOP-Befehlsnachricht 1355 wird von dem Host an den Signalprozessor bereitgestellt und verwendet, um die Sitzung anzuhalten oder zu unterbrechen. Die Sitzungs-ID 1356 wird bereitgestellt, um die Sitzung zu identifizieren. Bei Empfang dieses Befehls kann der Signalprozessor die Informationsflüsse zeitweilig anhalten und die Sitzung unterbrechen, welche neu gestartet oder abgebaut werden kann.
Unter Bezugnahme nun auf 38 wird eine beispielhafte Nutzlast einer Antwort 1360 auf die SESSION_STOP-Nachricht aus 37 dargestellt. Die hierin als die SESSION_STOP_RSP-Nachricht 1360 bezeichnete Antwort wird von dem Signalprozessor als Antwort auf jede SESSION_STOP-Befehlsnachricht 1355 bereitgestellt, die von dem Host empfangen wird. Die SESSION_STOP_RSP-Nachricht 1360 umfasst einen Statusparameter 1361, der Informationen enthält, die den erfolgreichen Abschluss der SESSION_STOP-Befehlsnachricht 1355 anzeigen. Die SESSION_STOP_RSP-Nachricht 1360 enthält ferner eine Sitzungs-ID 1362, die von dem Host bereitgestellt wurde, um die Sitzung zu identifizieren.
Unter Bezugnahme nun auf 39 wird eine beispielhafte Nutzlast einer Sitzungsabbruch-(SESSION-TEARDOWN)-Befehlsnachricht 1365 dargestellt. Die SESSION-TEARDOWN-Befehlsnachricht 1365 wird von dem Host an den Signalprozessor bereitgestellt, um die Sitzung abzubrechen (das heißt, abzubauen). Der Host stellt die Sitzungs-ID 1366 für die Sitzung bereit. Nach Empfang der SESSION-TEARDOWN-Befehlsnachricht 1365 beendet der Signalprozessor die Sitzung durch Abbrechen des Informationsflusses gemäß dieser Sitzung und Neuzuweisen von Speicherressourcen.
Unter Bezugnahme nun auf 40 wird eine beispielhafte Nutzlast einer Antwort 1375 auf die SESSION-TEARDOWN-Nachricht 1365 aus 39 dargestellt. Die hierin als die SESSION-TEARDOWN_RSP-Nachricht 1375 bezeichnete Antwort wird von dem Signalprozessor als Antwort auf jede SESSION-TEARDOWN-Befehlsnachricht 1365 bereitgestellt, die von dem Host empfangen wurde. Die SESSION-TEARDOWN_RSP-Nachricht 1370 umfasst einen Statusparameter 1371, der Informationen enthält, die den erfolgreichen Abschluss der SESSION-TEARDOWN-Befehlsnachricht 1365 anzeigen und eine Sitzungs-ID 1372, die von dem Host bereitgestellt wurde, um die Sitzung zu identifizieren.
Unter Bezugnahme auf 41 wird eine beispielhafte Nutzlast einer Sitzungsanfrage (SESSION_QUERY-Befehlsnachricht 1375 gezeigt. Die SESSION_QUERY-Befehlsnachricht 1375 wird von dem Host gesendet und fragt beim Signalprozessor nach Informationen an, die den Status der Sitzung betreffen, die durch die darin enthaltene Sitzungs-ID 1376 identifiziert wurde. Bei Empfang der SESSION_QUERY-Befehlsnachricht 1375 stellt der Signalprozessor Sitzungsinformationen an den Host bereit, wenn die Sitzung begründet wurde.
Unter Bezugnahme nun auf 42 wird eine beispielhafte Nutzlast einer Antwort 1380 auf die SESSION QUERY-Nachricht aus 41 dargestellt. Die hierin als SESSION_QUERY_RSP-Nachricht 1380 bezeichnete Antwort enthält einen Schnappschuss von Sitzungsinformationen an dem Signalprozessor zu dem Host, wenn die Sitzung lokalisiert wurde. Der Inhalt der SESSION_QUERY-RSP-Nachricht 1380 enthält einen Statusparameter 1381, der Informationen enthält, die den erfolgreichen Abschluss der SESSION_QUERY-Befehlsnachricht 1375 anzeigen. Außerdem sind verschiedene Informationen, die von der SESSION_SETUP-Befehlsnachricht 1305 aus 29 für diese Sitzung bereitgestellt wurden, in der SESSION_QUERY_RSP-Nachricht 1380 wie gezeigt enthalten.
Unter Bezugnahme auf die 43A und 43B, wird eine beispielhafte Nutzlast einer Sitzungs-Statistik-Anforderungs-(SESSION_STATS_REQUEST)-Befehlsnachricht 1385 gezeigt. Die SESSION_STATS_REQUEST-Befehlsnachricht 1385 wird von dem Signalprozessor empfangen und fordert Statistiken für eine spezifizierte Sitzung, die von der Sitzungs-ID 1386 identifiziert wurde, an. Als Antwort sendet der Signalprozessor eine SESSION_STATS_REQUEST_RSP-Nachricht 1390, welche diese Sitzungs-ID 1391 zurückgibt, auf die sich der Bericht gerichtet hat, einen Statusparameter 1392 (der Informationen enthält, die den erfolgreichen Abschluss der SESSION_STATS_REQUEST-Nachricht 1385 anzeigen), sowie verschiedene Statistiken 1393 bezüglich der bestimmten Sitzung. Zu diesen Statistiken gehören (1) ein Frame-Zähler-Parameter 1394, der die Anzahl von für diese Sitzung verarbeiteten Frames spezifiziert; (2) einen Bad-Frame-Zähler-Parameter 1395, der Informationen enthält, der die Anzahl von Malen spezifiziert, bei denen ein Frame zum Verarbeiten bereit war, aber kein Frame für die Sitzung verfügbar war und (3) RX/TX-Overflow- und Underflow-Parameter 1396–1399 zum Anzeigen der Overflow- und Underflowbedingungen für diese Sitzung.
2c. Telefoniedienstekatalog
Eine beispielhafte Auflistung von Nachrichten, die mit einem Telefoniedienstekatalog verbunden sind, wird in 44 dargestellt. Der Telefoniedienstekatalog 1400 weist allgemein Steuernachrichten, wie Befehls-, Antwort- und Statusnachrichten auf, die von den Telefoniefunktionen des Signalprozessors unterstützt werden. Diese Funktionen enthalten die DTMF-Erfassung und -Erzeugung, die Tonerfassung und -erzeugung und die Echoausblendung.
Die mit dem Telefoniedienstekatalog 1400 verbundenen Nachrichten funktionieren an einer aufgebauten Sitzung, mit Ausnahme von SET_TONE_YYY- und REQ_TONE_YYY-Nachrichten, die alle Sitzungen betreffen. Die Nomenklatur „YYY" wird verwendet, um jeden „Ton einstellen"- oder „Ton anfordern"- Vorgang darzustellen. Jede der Telefonienachrichten ist so konfiguriert, dass sie eine gültige Sitzungs-ID enthält, um die zu steuernde Sitzung zu identifizieren.
Es wird in Betracht gezogen, dass Telefonie-Einrichten-Befehle durch voreingestellte Telefoniewerte unterstützt werden, so dass das Senden von „Ton einstellen"-Nachrichten nicht erforderlich ist, wenn die voreingestellten Telefoniewerte für diese Sitzung akzeptabel sind. Um diese voreingestellten Werte zu ändern, ist die Sitzungs-ID jedoch auf einen vorgeschriebenen Wert eingestellt (zum Beispiel 0xFFFF). Andernfalls wird der Befehl auf die jeweilige Sitzung angelegt.
Unter Bezugnahme auf 45 wird eine beispielhafte Nutzlast dargestellt, die Echoausblendungs-(EC)-Parameter aufweist, welche in einer Echoausblendungsparameter-einstellen-(SET_EC_PARMS)-Befehlsnachricht 1405 dargelegt sind. Die EC-Parameter 1406, die in dieser SET_EC_PARMS-Befehlsnachricht 1405 definiert sind, haben globale voreingestellte Werte. Diese Nachricht kann verwendet werden, um die voreingestellten Werte per Sitzung zu modifizieren. Die SET_EC_PARMS-Befehlsnachricht 1405 kann jederzeit gesendet werden, nachdem eine Sitzung eingerichtet wurde. Wenn die Sitzung bereits gestartet wurde, wird jede Änderung der Parameter wirksam, wenn der nächste Frame verarbeitet wird.
Durch Einstellen des Sitzungs-ID-Parameters 1407 auf einen vorgegebenen Wert (zum Beispiel 0xFFFF) wird die Änderung der voreingestellten Telefoniewerte auf die in der SET_EC_PARMS-Befehlsnachricht 1405 festgelegten Werte ermöglicht. Es wird jedoch berücksichtigt, dass einige EC-Parameter ohne Anhalten der Sitzung und Senden einer neuen Sitzungs-Einrichten-Nachricht nicht geändert werden können (zum Beispiel EC-Tail-Länge und eine Framegröße).
Wie in 45 gezeigt, umfasst die SET_EC_PARMS-Befehlsnachricht 1405 eine Vielzahl von Echoausblendungsparametern 1406 einschließlich ohne Einschränkung eines oder mehrerer der Folgenden: einen Echoausblendungsaktivierungs-(EC)-Parameter 1410, einen nicht linearen Prozessoraktivierungs-(NLP)-Parameter 1411, einen Komfortrauschenaktivierungs-(CNG)-Parameter 1412 und einen Echorückgabeverlust-(ERL)-Parameter 1413. Die EC-, NLP- und CNG-Parameter 1410–1412 werden eingestellt oder bleiben frei, um die Aktivierung oder Deaktivierung von Echoausblendung nicht linearer Verarbeitung bzw. Komfortrauschen zu ermöglichen. Der ERL-Parameter 1413 enthält Informationen zur Einstellung des Echorückgabeverlustes. Die Platzierung eines logischen Werts von „00" in den ERL-Parameter 1413 stellt beispielsweise den Echorückgabeverlust ungefähr gleich 0 Dezibel (dB). Analog können logische Werte von "01" und „10" den Echorückgabeverlust auf –3 dB bzw. –6 dB einstellen.
Unter Bezugnahme nun auf 46 wird eine beispielhafte Nutzungslast einer Antwort 1415 auf die SET_EC_PARMS-Befehlsnachricht aus 45 dargestellt. Die als die SET_EC_PARMS_RSP-Nachricht 1415 bezeichnete Antwort wird von dem Signalprozessor als Antwort auf jede von dem Host gesendete SET_EC_PARMS-Befehlsnachricht 1405 bereitgestellt. Die SET_EC_PARMS_RSP-Nachricht 1415 umfasst einen Statusparameter 1416, der Informationen enthält, die den erfolgreichen Abschluss der SET_EC_PARMS-Befehlsnachricht 1405 anzeigen. Die SET_EC_PARMS_RSP-Nachricht 1415 umfasst ferner eine Sitzungs-ID 1417, die von dem Host bereitgestellt wurde, um die Sitzung zu identifizieren.
Der Telefoniedienstekatalog 1400 ermöglicht die Anforderung von gegenwärtig von dem Signalprozessor verwendeten EC-Parametern durch eine Sendung einer EC- Parameter-anfordern-(REQ_EC_PARMS)-Befehlsnachricht 1420, wie in 47 gezeigt. Die REQ_EC_PARMS-Befehlsnachricht 1420 enthält die Sitzungs-ID 1421 zur Identifizierung der Sitzung. Als Antwort werden, wie in 48 gezeigt, der EC-Parameter 1406, der in der SET_EC_PARMS-Befehlsnachricht 1405 zusammen mit der Sitzungs-ID 1421 identifiziert wurde, an den Host über eine Antwort-(REQ_EC_PARMS_RSP)-Nachricht 1425 zurückgegeben. Die REQ_EC_PARMS_RSP-Nachricht 1425 umfasst ferner einen Statusparameter 1426, der, wenn er auf einen vorgegebenen Wert eingestellt ist, den erfolgreichen Abschluss der REQ_EC_PARMS-Befehlsnachricht 1420 anzeigt.
Unter Bezugnahme auf 49 wird eine beispielhafte Nutzlast einer Echoausblendungsstatistikanforderungs-(EC_STAT_REQ)-Befehlsnachricht 1430 dargestellt. Die Nutzlast enthält eine Sitzungs-ID 1431. Als Antwort gibt der Signalprozessor eine Echoausblendungsstatistikanforderungsantwort-(EC_STAT_REQ_RSP)-Nachricht 1435 an den Hostprozessor, wie in 50 dargelegt, zurück.
Wie in 50 gezeigt, zeigen die Parameter in der EC_STAT_REQ_RSP-Nachricht 1435 den ausführlichen Status der Echoausblendungsfunktion für die Sitzung an. Diese Parameter werden von Fachleuten der Echoausblendungsvorgänge verwendet, um den Status und die Leistung des Echoaufhebers während einer Verbindung auszuwerten. Der EC_OFF-Parameter 1436 zeigt beispielsweise an, ob der Echoaufheber aktuell deaktiviert ist. Der LMS_Init-Parameter 1437 zeigt an, dass die Koeffizienten und der Filterverlaufzwischenspeicher des Echoaufhebers vor der Verarbeitung eines Frames gelöscht werden. Der LMS-Up-Parameter 1438 zeigt an, dass Aktualisierungen des Filterkoeffizienten des Echoaufhebers aktiviert sind. Die RinDet- und SinDet-Parameter 1439 und 1440 zeigen an, dass die Rin- oder Sin-Signale erfasst worden sind. Der DTDet-Parameter 1441 zeigt an, dass der Doppelsprechstatus erfasst wurde. Die DTRms- und DTDs-Parameter 1442 und 1443 stellen mehr Informationen über den Doppelsprechzustand bereit. Der NLPST-Parameter 1444 zeigt an, dass der Echoaufheber in dem nicht linearen Verarbeitungszustand ist. Der FE_Prev-Parameter 1445 zeigt an, dass der Sprecher am fernen Ende in dem vorherigen Zustand aktiv war. Der RIN-Parameter 1446 zeigt an, dass der Frame des fernen Endes von dem Echoaufheber erfasst worden ist. Der RESU-Parameter 1447 zeigt an, ob die Resteingabe des Echoaufhebers unter einem festgelegten Schwellwert liegt. Die Tailx0-, Tailx1- und Tailx2-Parameter 1448–1450 werden verwendet, um die maximale Echolänge anzuzeigen, auf die der Echoaufheber achten sollte. Der Rin-Status-Parameter 1451, nämlich Rin Ave Max Energy, Rin Ave Energy, Rin Energy Peak Decay und Rin Hang Over stellen Verlaufsinformationen über das Rinsignal bereit. Die Sin-Status-Parameter 1452 stellen die selben Signalverlaufsinformationen für das Sinsignal bereit. Die Sout-Status-Parameter 1453, nämlich Sout Ave Max Energy und Sout Ave Energy stellen Energieverlaufsinformationen für das Echoausblendungs-Sout-Signal bereit. Der Doppelsprech-Hang-Over-Parameter 1454 zeigt die Zeit an, seitdem der Doppelzustandsstatus erfasst worden ist.
Unter Bezugnahme nun auf 51 wird eine beispielhafte Nutzlast einer DTMF-Parameter-einstellen-(SET_DTMF_PARMS)-Befehlsnachricht 1460 dargestellt. Die SET_DTMF_PARMS-Befehalsnachricht 1460 wird von dem Host gesendet und umfasst eine Reihe von Parametern einschließlich einer Sitzungs-ID 1461, einer Pulszeit (in Intervallen von 5 Millisekunden „ms") 1462, einer Schutzzeit (in Intervallen von 5 ms) 1463, einer Zwischenzahlenzeit (in Intervallen von 5 ms) 1464 und des Volumens 1465. Der Pulszeitparameter 1462 enthält Informationen, die die EIN-Zeit für jeden DMTF-Puls festlegen. Für diese Ausführungsform reicht diese Zeit von 5 ms bis zu 1,25 Sekunden. Der Schutzzeitparameter 1463 legt die Ruhedauerzeit fest, die der ersten DTMF-Zahl vorangeht und der letzten Zahl folgt. Der Zwischenzahlenzeitparameter 1464 enthält Informationen, die die Zeitdauer zwischen Zahlen in einem Zahlenstring festlegen. Der Volumenparameter 1465 enthält Informationen zum Einstellen des Audiograds, der durch die Aktivierung eines DTMF-Pulses erzeugt wurde. Bei dieser Ausführungsform beträgt der Bereich von 0 bis –63 dBm0.
Unter Bezugnahme auf 52 wird eine beispielhafte Nutzlast einer Antwort 1470 auf die SET_DTMF_PARMS-Befehlsnachricht 1460 aus 51 dargestellt. Diese Antwort wird an den Host zurückgegeben und als SET_DTMF_PARMS_RSP-Nachricht 1470 bezeichnet und enthält einen Statusparameter 1471, einschließlich von Informationen, die einen erfolgreichen Abschluss der SET_DTMF_PARMS-Befehlsnachricht 1330 anzeigen. Die Sitzungs-ID 1472, die mit der Sitzung verbunden ist, ist außerdem ein Parameter der SET_DTMF_PARMS_RSP-Nachricht 1470.
Der Telefoniedienstekatalog 1400 ermöglicht die Anforderung der gegenwärtig von dem Signalprozessor verwendeten DTMF-Parameter durch eine Sendung einer REQ_DTMF_PARMS-Befehlsnachricht 1475 wie in 53 dargestellt. Die REQ_DTMF_PARMS-Befehlsnachricht 1475 enthält eine Sitzungs-ID 1476 zum Identifizieren der Sitzung, für die die DTMF-Parameter angefordert wurden. Wie in 54 gezeigt, werden die in der SET_DTMF_PARMS-Befehlsnachricht 1460 aus 52 identifizierten DTMF-Parameter zusammen mit der Sitzungs-ID 1481 und dem Statusparameter 1482 an den Host über eine Antwortnachricht (REQ_DTMF_PARMS_RSP) 1480 zurückgegeben.
Unter Bezugnahme nun auf 55 wird eine beispielhafte Nutzlast einer DTMF-Zahlen-erzeugen-(GEN_DTMF_DIGITS)-Befehlsnachricht 1485 dargestellt. Außer der Sitzungs-ID 1486 signalisiert die GEN_DTMF_DIGITS-Befehlsnachricht 1485, die Erzeugung eines Strings von DTMF-Zahlen (zum Beispiel eine oder mehrere DTMF-Zahlen) durch den Signalprozessor. Die Länge des DTMF-Zahlenstrings wird durch einen Zahlenstringlängenparameter 1487 bereitgestellt. Der Identifizierer (ID) jeder DTMF-Zahl in dem String wird durch Zahlen-ID-Parameter 1488 bereitgestellt. Das Benachrichtigenbit 1489 der GEN_DTMF_DIGITS-Befehlsnachricht 1485 wird, wenn es eingestellt ist, verwendet, um anzufordern, dass eine Bestätigungssteuernachricht gesendet wird, nachdem die DTMF-Zahlenstringerzeugung abgeschlossen wurde. Die Nutzlast der Bestätigungssteuernachricht 1490 wird in 56 dargelegt.
Unter Bezugnahme nun auf 57 wird eine beispielhafte Nutzlast einer Antwort 1495 auf die GEN_DTMF_DIGITS-Befehlsnachricht 1485 aus 55 dargestellt. Die als eine GEN_DTMF_DIGITS_RSP-Nachricht 1495 bezeichnete Antwort wird von dem Signalprozessor als Antwort auf jede von dem Host gesendete GEN_DTMF_DIGITS-Befehlsnachricht 1485 bereitgestellt. Die GEN_DTMF_DIGITS_RSP-Nachricht 1495 umfasst einen Statusparameter 1496, der Informationen enthält, die den erfolgreichen Abschluss der GEN_DTMF_DIGITS-Befehlsnachricht 1485 anzeigen und eine Sitzungs-ID 1497, die von dem Host bereitgestellt wurde, um die Sitzung zu identifizieren.
Unter Bezugnahme nun auf 58 wird eine beispielhafte Nutzlast einer DTMF-Report-(DTMF_REPORT)-Befehlsnachricht 1500 dargestellt. Die DTMF_REPORT-Befehlsnachricht 1500 wird immer dann gesendet, wenn die DTMF-Erfassung aktiviert ist und eine DTMF-Zahl vorliegt. Die DTMF_REPORT-Befehlsnachricht 1500 wird einmal bei Beginn der Zahlenerfassung und dann wieder bei Ende der Zahlenerfassung gesendet.
Wie gezeigt, umfasst die Nutzlast eine Sitzungs-ID 1501, einen Endeparameter 1502, einen Zahlen-ID-Parameter 1503 und einen DTMF-Dauerparameter 1504. Der Endeparameter 1502 ist eingestellt („1"), wenn die Nachricht mit dem Frame verbunden ist, indem die DTMF-Zahl geendet hat. Andernfalls ist das Ende-Parameter-Bit frei („0"). Der Zahlen-ID-Parameter 1503 weist einen Wert der erfassten DTMF-Zahl auf. Jede DTMF-Zahl wird zuvor einem eindeutigen vorgegebenen Bitwert zugewiesen. Der DTMF-Dauerparameter 1504 enthält Informationen, die die kumulative Zeit anzeigen, in welcher die DTMF-Zahl vorlag. Wenn der Endeparameter auf „1" eingestellt ist, zeigt dieser Parameter nun die Gesamt-EIN-Zeit der DTMF-Zahl an.
Hier sind bestimmte Parameter zur Unterstützung von programmierbarer Tonerzeugung und -erfassung verfügbar. In dieser Ausführungsform kann der Nutzer bis zu 15 Frequenzen aus einer Gruppe von 37 zu versendenden bei der Tonerzeugung und -erfassung auswählen. Unter Verwendung dieser 15 ausgewählten Frequenzen können bis zu 16 unterschiedliche Töne erzeugt oder erfasst werden. Jeder definierte Ton kann aus einer einfachen Frequenz oder mehreren Frequenzen bestehen. Die EIN-Zeit, AUS-Zeit, obere Frequenz, untere Frequenz, sowie der hohe und niedrige Schwellwert können separat für jeden definierten Ton festgelegt werden.
Unter Bezugnahme nun auf 59 wird eine beispielhafte Nutzlast einer Tonfrequenz-einstellen-(SET_TONE_FREQ)-Befehlsnachricht 1510 gezeigt. Die SET_TONE_FREQ-Befehlsnachricht 1510 umfasst einen oder mehrere der folgenden Parameter: Frequenzindices 1511, ein ersten Frequenzindexverzeichnis 1512, ein zweites Frequenzindexverzeichnis 1513, einen Mindestschwellwert 1514 und einen Twist 1515. Die Frequenzindices 1361 sind ein Index von Frequenzen, die von 350 Hertz (Hz) bis ungefähr 4000 Hz beispielsweise reichen.
Hierbei kann der Nutzer bis 15 zu erfassende Frequenzen festlegen. Der erste Frequenzindexverzeichnisparameter 1512 enthält einen Index (0–14) der niedrigen Frequenzkomponente eines Tons. Dieser Index wird aus den 15 Frequenzindices ausgewählt. Der zweite Frequenzindexverzeichnisparameter 1513 enthält einen Index (0–14) der höheren Frequenzkomponente des Tons. Der Index wird aus den 15 Frequenzindices ausgewählt. Frequenz 1- oder Frequenz 2-Komponenten können durch einen vorgeschriebenen Codewert dargestellt werden.
Der Mindestschwellwertparameter 1514 enthält Informationen, die zum Einrichten eines Schwellwerts verwendet werden, wobei nur Signale mit einer Energie, die oberhalb dieses Schwellwerts liegt, zur Erfassung verarbeitet werden. Der empfohlene Schwellwert ist –45 dBm, aber der aktuelle Wert hängt von der Signalquelle ab.
Der Twistparameter 1515 enthält Informationen, die ein maximal zulässiges Verhältnis zwischen den Energien der Komponenten des Tonpaarsignals anzeigen. Der empfohlene Wert ist 10 dBm, aber aktuelle Werte hängen von der Signalquelle ab.
Unter Bezugnahme auf 60 wird eine beispielhafte Ausführungsform einer Nutzlast einer EIN-Zeit-für-Tonkadenz-einstellen-(SET_TONE_CADENCE_ON)-Befehlsnachricht 1520 gezeigt. Die SET_TONE_CADENCE_ON-Befehlsnachricht 1520 stellt die EIN-Zeitdauer für jeden erzeugten Ton ein. Analog stellt eine SET_TONE_CADENCE_OFF-Befehlsnachricht 1525, wie in 61 gezeigt, die AUS-Zeitdauer für jeden erzeugten Ton ein.
Unter Bezugnahme nun auf 62 wird eine beispielhafte Nutzlast einer unteren-Tonschwellwerteinstellen-(SET_TONE_THRESH_LOW)-Befehlsnachricht 1530 gezeigt. Für jeden Ton, der erzeugt werden kann, wird eine Frequenzkomponente des Tons mit einer Energie unterhalb dieses Schwellwerts zurückgewiesen. Der empfohlene Wert ist –35 dBm, aber der aktuelle Wert hängt von der Quelle sowie von der Streckendämpfung ab. Wie in 63 gezeigt, bewirkt eine hohen-Tonschwellwert-einstellen-(SET_TONE_THRESH_HI)-Befehlsnachricht 1535, dass eine einzelne Frequenzkomponente des Tons mit einer Energie oberhalb dieses Schwellwerts zurückgewiesen wird. Der empfohlene Wert ist 0 dBm, aber der aktuelle Wert hängt von der Quelle sowie von der Streckendämpfung ab.
Unter Bezugnahme nun auf 64 wird eine beispielhafte Nutzlast einer Antwort 1540 gezeigt, welche beim Beantworten jeder der „TON-EINSTELLEN"-Befehlsnachrichten aus 59–63 verwendet wird. Bei Bereitstellung durch den Signalprozessor an den Host umfasst jede Antwort einen Statusparameter 1541, der Informationen enthält, welche den erfolgreichen Abschluss dieser entsprechenden „Ton-Einstellen"-Befehlsnachricht anzeigen.
Die aktuellen Einstellungen für die Tonparameter können erhalten werden, indem die geeignete REQ_TONE_FREQ-, REQ_TONE_CADENCE_ON-, REQ_TONE_CADENCE_OFF-, REQ_TONE_THRESH_LOW-, REQ_TONE_THRESH_HI-Befehlsnachricht (die generisch als „REQ_TONE_YYY-Befehlsnachrichten" bezeichnet werden) gesendet wird. Die REQ_TONE_YYY-Befehlsnachricht weist den Steuerkopfteil (keine Nutzlast) auf, der mit dem Katalogparameter des Steuerkopfteils konfiguriert ist, welcher die „Telefoniedienste" festlegt und mit dem Codeparameter, um diese bestimmte „Tonanfordern"-Nachricht anzuzeigen.
Als Antwort auf die REQ_TONE_YYY-Befehlsnachricht wird von dem Signalprozessor an den Host eine generisch als eine „REQ_TONE_YYY_RSP"-Nachricht bezeichnete Antwort zurückgegeben. Wie in 65 gezeigt, weist der REQ_TONE_FREQRSP-Befehl 1545 beispielsweise eine Nutzlast auf, die einen 4-Byte-Statusparameter 1546 enthält, welcher den Informationen vorangeht, die von der SET_TONE_FREQ-Nachricht aus 59 bereitgestellt werden.
Unter Bezugnahme auf 66 wird eine beispielhafte Nutzlast einer Ton-erzeugen-(GEN_TONE)-Befehlsnachricht 1550 dargestellt. Die GEN_TONE-Befehlsnachricht 1550 umfasst einen Sitzungs-ID-Parameter 1551 zum Identifizieren der bestimmten Sitzung, sowie einen Ton-ID-Parameter 1552, einen Volumenparameter 1553 und einen Tondauerparameter 1554.
Der Ton-ID-Parameter 1552 enthält Informationen, die die Art des zu erzeugenden Tons identifizieren (zum Beispiel DTMF usw.). Der Volumenparameter 1553 enthält Informationen, um das Audiovolumen des Tons von 0 dBm0 bis zu –63 dBm0 festzulegen. Der Tondauerparameter 1554 enthält Informationen, die die Dauer des Tons festlegen (wobei „0" kontinuierlich bedeutet und die Dauer äquivalent zu der binären Darstellung ist, die mit 15 ms multipliziert ist (so dass „000A" äquivalent zu einer Tondauer von 150 ms ist)).
Unter Bezugnahme nun auf 67 wird eine beispielhafte Nutzlast einer Antwort 1555 auf die GEN_TONE-Befehlsnachricht 1550 aus 66 dargestellt. Die als GEN_TONE_RSP-Nachricht 1555 bezeichnete Antwort wird von dem Signalprozessor als Antwort auf jede GEN_TONE-Befehlsnachricht 1550 bereitgestellt, die von dem Host gesendet wird. Die GEN_TONE_RSP-Nachricht 1555 umfasst einen Statusparameter 1556, der Informationen enthält welche den erfolgreichen Abschluss der GEN_TONE- Befehlsnachricht 1550 anzeigen. Die GEN_TONE_RSP-Nachricht 1555 umfasst auch eine Sitzungs-ID 1557, die von dem Host bereitgestellt wurde, um die Sitzung zu identifizieren und der Ton-ID-Parameter 1652 identifiziert den Tontyp.
Unter Bezugnahme auf 68 wird eine beispielhafte Nutzlast einer Ton-stoppen-(STOP_TONE)-Befehlsnachricht 1560 gezeigt. Die STOP_TONE-Befehlsnachricht 1560 wird von dem Host an den Signalprozessor bereitgestellt und dazu verwendet, die Tonerzeugung zu stoppen oder zu pausieren. Die Sitzungs-ID 1561 wird bereitgestellt, um die Sitzung zu identifizieren. Die Ton-ID 1562 identifiziert die ID des zu stoppenden Tons.
Unter Bezugnahme nun auf 69 wird eine beispielhafte Nutzlast einer Antwort 1565 auf die STOP_TONE-Befehlsnachricht 1560 aus 68 dargestellt. Die hierin als die STOP_TONE_RSP-Nachricht 1565 bezeichnete Antwort wird von dem Signalprozessor als Antwort auf jede STOP_TONE-Befehlsnachricht 1560 bereitgestellt, die von dem Host empfangen wird. Die STOP_TONE_RSP-Nachricht 1565 umfasst einen Statusparameter 1566, der Informationen enthält, die den erfolgreichen Abschluss der STOP_TONE-Befehlsnachricht 1560 anzeigen. Die STOP_TONE_RSP-Nachricht 1565 umfasst ferner eine Sitzungs-ID 1567, die von dem Host bereitgestellt wurde, um die Sitzung zu identifizieren.
Unter Bezugnahme auf die 70 wird eine beispielhafte Nutzlast einer Ton-Report-(TONE_REPORT)-Befehlsnachricht 1570 gezeigt. Wenn der Tonerfassungsaktivierungsparameter 1324 der SESSION_SETUP-Befehlsnachricht (siehe 29) eingestellt ist und ein vom Nutzer programmierter Ton erfasst wird, werden die Töne berichtet, wenn sie die den Tonparameterkonfigurationsnachrichten (zum Beispiel SET_TONE_CADENCE_ON 1520 and SET_TONE_CADENCEOFF 1525) eingestellten EIN- und AUS-Zeiten einhalten.
Die TONE_REPORT-Befehlsnachricht 1570 umfasst einen Sitzungs-ID-Parameter 1571 zum Identifizieren der bestimmten Sitzung sowie einen Ton-ID-Parameter 1572 und einen Tondauerparameter 1573. Der Ton-ID-Parameter 1572 enthält Informationen bezüglich der Art des erfassten Tons, während der Tondauerparameter 1573 Informationen enthält, die die Gesamt-EIN-Zeitdauer des Tons festlegen (gemäß 15-ms-Intervallen).
Unter Bezugnahme auf 71 wird eine beispielhafte Nutzlast einer Fax-Ton-Report-(FAX_TON_REPORT)-Befehlsnachricht 1575 gezeigt. Wenn ein Faxton erfasst wird, wird die FAX_TON_REPORT-Befehlsnachricht 1575 gesendet, um den erfassten Ton anzuzeigen. Diese Nachricht wird bei der Erfassung von CNG, CED oder V.21-Faxtönen bei Einstellung der Parameter 1576, 1577 bzw. 1578 gesendet.
2d. Sprachdienstekatalog
Unter Bezugnahme nun auf 72 wird eine beispielhafte Auflistung von Nachrichten gezeigt, die mit einem Sprachdienstekatalog 1600 verbunden sind. Hierin enthält der Sprachdienstekatalog 1600 Nachrichten, die von verschiedenen Sprachfunktionen des Signalprozessors unterstützt werden. Alle Nachrichten in diesem Sprachdienstekatalog 1600 funktionieren bei einer eingerichteten Sitzung. Somit ist eine Sitzungs-ID für alle diese Nachrichten erforderlich. Alle Befehle bezüglich des „Setups" unterstützen voreingestellte Sprachwerte, das Senden dieser Nachrichten ist somit nicht erforderlich, wenn die voreingestellten Sprachwerte für eine Sitzung annehmbar sind. Um die voreingestellten Werte einzustellen, wird der Sitzungs-ID-Parameter auf 0xFFFF(–1) eingestellt.
Andernfalls wird der Befehl an die entsprechende Sitzung angelegt.
Wie in 73 gezeigt, wird eine beispielhafte Nutzlast einer SET_VOICE_PARMS-Befehlsnachricht 1605 gezeigt. Die SET_VOICE_PARMS-Befehlsnachricht 1605 umfasst eine Sitzungs-ID 1606 mit einer Vielzahl von Sprachparametern 1607. Diese Parameter 1607 umfassen ohne Einschränkung eines oder mehrere der Folgenden: einen Postfilteraktivierungs-(PFE)-Parameter 1610, einen Hochpassfilteraktivierungs-(HPFE)-Parameter 1611, einen stillen-Kompressions-Aktivierungs-(SCE)-Parameter 1612, einen Codiererraten-(ER)-Parameter 1613, einen Rückstellcodierer-(ERES)-Parameter 1614, einen Rückstell-Decodierer-(DRES)-Parameter 1615 und einen automatische-Ebenen-Steuerungs-(ALC)-Parameter 1616.
Die PFE- und HPFE-Parameter 1610 und 1611 enthalten Informationen zum Aktivieren oder Deaktivieren von Postfiltern bzw. Hochpassfiltern. Die ER- und ERES-Parameter 1613 und 1614 enthalten Informationen zum Modifizieren von Codiererraten und Rückstellen des Codierers für den nächsten verarbeiteten Rahmen. Der DRES-Parameter 1615 enthält Informationen, die den Decodierer für den nächsten verarbeiteten Rahmen zurückstellen. Der ALC-Parameter 1616 enthält Informationen für die automatische Anpassung von Audioebenen entsprechend vorgeschriebenen Dezibelinkrementen (zum Beispiel –5 dB Intervallen).
Unter Bezugnahme nun auf 74 wird eine beispielhafte Nutzlast einer Antwort auf die SET_VOICE_PARMS-Befehlsnachricht 1605 aus 73 dargestellt. Die als die SET_VOICE_PARMS_RSP-Nachricht 1620 bezeichnete Antwort wird von dem Signalprozessor als Antwort auf jede SET_VOICE_PARMS-Befehlsnachricht bereitgestellt, die von dem Host gesendet wird. Die SET_VOICE_PARMS RSP-Nachricht 1620 umfasst einen Statusparameter 1621, der Informationen enthält, die den erfolgreichen Abschluss der SET_VOICE_PARMS-Befehlsnachricht 1605 und eine Sitzungs-ID 1622 anzeigen, der von dem Host bereitgestellt wurde, um die Sitzung zu identifizieren.
Der Sprachdienstekatalog 1600 ermöglicht die Anforderung von gegenwärtig von dem Signalprozessor verwendeten Sprachparametern durch die Sendung einer REQ_VOICE_PARMS-Befehlsnachricht 1625 wie in 75 gezeigt. Eine beispielhafte Nutzlast der REQ_VOICE_PARMS-Befehlsnachricht 1625 enthält die Sitzungs-ID 1626 zum Identifizieren der Sitzung. Als Antwort werden die Sprachparameter 1631, wie in 76 gezeigt, die äquivalent zu denen sind, die durch die SET_VOICE_PARMS-Befehlsnachricht 1605 aus 73 bereitgestellt werden, zusammen mit der Sitzungs-ID 1632 und einem Statusparameter 1633 an den Host über eine Nutzlast eine Antwortnachricht (REQ_VOICE_PARMS_RSP) 1630 zurückgegeben.
2e. Faxdienstekatalog
Unter Bezugnahme nun auf 77 wird eine beispielhafte Auflistung von Nachrichten gezeigt, die mit einem Faxdienstkatalog 1700 verbunden sind. Hierin enthält der Faxdienstekatalog 1700 Nachrichten, die von verschiedenen Faksimilefunktionen des Signalprozessors unterstützt werden. Alle Nachrichten in diesem Faxdienstekatalog 1700 funktionieren bei einer eingerichteten Sitzung. Somit wird eine Sitzungs-ID für alle diese Nachrichten benötigt. Alle „Setup"-bezogenen Befehle unterstützen voreingestellte Faksimilewerte, das Senden dieser Nachrichten ist somit nicht erforderlich, wenn die voreingestellten Werte für eine Sitzung annehmbar sind. Um die voreingestellten Werte einzustellen kann der Sitzungs-ID-Parameter so eingestellt werden, dass er 0xFFFF(–1) beträgt. Andernfalls wird der Befehl auf die jeweilige Sitzung angelegt.
Wie in 78 gezeigt, umfasst eine beispielhafte Nutzlast einer SET FAX PARMS-Befehlsnachricht 1705 eine Sitzungs-ID 1706 und eine Vielzahl von Faxparametern 1707 einschließlich ohne Einschränkung eines oder mehrerer der Folgenden: einen maximale-Modem-Geschwindigkeit-Parameter 1710, einen Systemverzögerungsparameter 1711 und einen Debug-Parameter 1712. Der maximale-Modem-Geschwindigkeit-Parameter 1710 zeigt eine höchste Modemdatengeschwindigkeit an, die von dem Fax-relay-gateway unterstützt werden sollte. Der Systemverzögerungsparameter 1711 zeigt die Anzahl von Frames eingehender Daten an, die nach jeder neu modulierten Datensendung ignoriert werden sollen. Dies ist eine logische Form von Echoausblendung, die notwendig ist, da der Echoaufheber während der Faxsendung ausgestellt ist. In der Regel ist ein voreingestellter Wert auf ungefähr fünf (30 ms) Frames eingestellt. Der Debug-Parameter 1712 zeigt an, ob Debug-Informationen in den Faxpaketen enthalten sein sollen. Normalerweise sind die Debug-Informationen voreingestellt ausgeschlossen.
Unter Bezugnahme nun auf 79 wird eine beispielhafte Nutzlast einer Antwort 1715 auf die SET_FAX_PARMS-Befehlsnachricht 1705 aus 78 dargestellt. Die als SET_FAX_PARMS_RSP-Nachricht 1715 bezeichnete Antwort wird von dem Signalprozessor als Antwort auf jede SET_FAX_PARMS-Befehlsnachricht 1705, die von dem Host gesendet wird, bereitgestellt. Die SET_FAX_PARMS_RSP-Nachricht 1715 umfasst einen Statusparameter 1716, der Informationen enthält, die den erfolgreichen Abschluss der SET_FAX_PARMS-Befehlsnachricht 1705 und eine Sitzungs-ID 1717 anzeigen, die von dem Host zum Identifizieren der Sitzung bereitgestellt wurde.
Der Faxdienstekatalog 1700 ermöglicht das Anfordern von gegenwärtig von dem Signalprozessor verwendeten Faxparametern durch die Sendung einer REQ_FAX_PARMS-Befehlsnachricht 1720, wie in 80 gezeigt. Die REQ_FAX_PARMS-Befehlsnachricht 1720 enthält eine Sitzungs-ID 1721 zum Identifizieren der Sitzung. Wie in 81 gezeigt, werden als Antwort die Faxparameter 1726 (die äquivalent zu den Parametern sind, welche von der SET_FAX_PARMS-Befehlsnachricht 1705 aus 78 bereitgestellt werden) zusammen mit der Sitzungs-ID 1727 und dem Statusparameter 1728 an den Host über eine Nutzlast eine Antwortnachricht (REQ_FAX_PARMS_RSP) 1725 zurückgegeben.
Zusätzlich wird, wie in 82 gezeigt, eine beispielhafte Nutzlast einer Report-Fax-unterbrechen-(REPORT_FAX_DISCONNECT)-Befehlsnachricht 1730 dargestellt. Die REPORT_FAX_DISCONNECT-Befehlsnachricht 1730 ist eine autonome Nachricht, welche von dem Signalprozessor erzeugt wird, wenn er während einer Faxsitzung den Faxunterbrechen-Status erfasst. Die Nutzlast enthält einfach eine Sitzungs-ID 1731 zusammen mit einer Faxsitzung.
2f. Modemdienstekatalog
83 ist eine beispielhafte Auflistung von Nachrichten, die mit einem Modemdienstekatalog 1750 verbunden sind. Hier enthält der Modemdienstekatalog 1750 Nachrichten, die zum Einstellen von Modemparametern verwendet werden, welche von dem Signalprozessor verwendet werden, wie beispielsweise Ausrüstungsart, Datentransfergeschwindigkeiten, Bildgebungscharakteristiken und dergleichen. Ähnlich wie bei Telefonie-, Sprach- und Fax-Diensten funktionieren alle Nachrichten in diesem Modemdienstekatalog 1750 an einer eingerichteten Sitzung. Somit ist eine Sitzungs-ID für alle diese Nachrichten erforderlich. Alle „Setup"-bezogenen Befehle unterstützen voreingestellte Modemwerte, so dass das Senden dieser Nachrichten nicht erforderlich ist, wenn die voreingestellten Modemwerte für eine Sitzung annehmbar sind. Um die voreingestellten Werte einzustellen, kann der Sitzungs-ID-Parameter auf 0xFFFF(–1) eingestellt werden. Andernfalls wird der Befehl auf die jeweilige Sitzung angelegt.
C. VERANSCHAULICHENDE BEISPIELE DER INITIALISIERUNGSPHASE
Unter Bezugnahme nun auf 84 wird eine beispielhafte Ausführungsform einer Steuernachrichtensequenz gezeigt, die von dem Host und dem Signalprozessor während der Initialisierungsphase verwendet wird. Diese Steuernachrichten werden verwendet, um Betriebsparameter des Signalprozessors zu verändern. Die Parameter werden dann als Voreinstellungen für die einzelnen Sitzungen verwendet.
Bei dieser Ausführungsform sendet der Signalprozessor bei erfolgreichem Abschluss des Initialisierungsprozesses eine DEV_HEARTBEAT-Nachricht (siehe 21) an den Host (siehe Block 1800). Die DEV_HEARTBEAT-Nachricht zeigt dem Host an, dass der Signalprozessor aktiv ist. Bei Empfang der DEV_HEARTBEAT-Nachricht sendet der Host eine DEV_INFO-Nachricht an den Signalprozessor, um Informationen bezüglich des Signalprozessors zu erhalten (Block 1805). Als Antwort gibt der Signalprozessor eine DEV_INFO_RSP-Nachricht (siehe 16) an den Host zurück (Block 1810). Der Inhalt der DEV_INFO_RSP-Nachricht stellt dem Host den aktuellen Zustand der Hardware- und Firmwareversionen des Signalprozessors sowie andere Informationen auf Basisebene bereit, die erforderlich sind, um zu bestimmen, ob ihr Inhalt aktuell ist.
Als nächstes sendet der Host als optionales Merkmal eine DEV_POOL_INIT-Nachricht (siehe 17) an den Signalprozessor. Als Antwort sendet der Signalprozessor eine DEV_POOL_INIT_RSP-Nachricht (siehe 18), welche verwendet wird, um die interne Konfiguration des Speichers unter verschiedenen Pufferpools zu konfigurieren (siehe Blöcke 1815 und 1820).
Der nächste Vorgang enthält die Initialisierung und das Einrichten der seriellen Ports. Bei dieser Ausführungsform werden vier interaktive Nachrichten, nämlich SERIAL_PORT_SETUP (siehe 23) und SERIAL_PORT_SETUP_RSP (siehe 24) für jeden seriellen Port in Blöcken 1825, 1830, 1835, 1840, 1845, 1850, 1855 und 1860 gezeigt. Danach werden die verschiedenen Optionen zum Konfigurieren der Firmware je nach Anwendung sehr unterschiedlich. Eine oder mehrere Nachrichten, die mit der Vorrichtungssteuerung, der Sitzungssteuerung und einer Vielzahl von Dienstkatalogen verbunden sind, können gesendet werden, um die Firmware des Signalprozessors korrekt zu konfigurieren. Eine dieser Nachrichten, nämlich SET_EC_PARMS, kann verwendet werden, um die Echoausblendungsparameter einzustellen (Blöcke 1865 und 1870).
Nach Abschluss der Konfigurationsaustausche tritt in der Regel der Signalprozessor in den Leerlauf ein, während er auf Befehle von dem HOST zum Aufbauen und Handhaben von Sitzungen wartet. Während dieser Leerlaufzeit sendet der Signalprozessor asynchrone DEV_STATISTICS- und DEV_HEARTBEAT-Nachrichten (Block 1875) an den Host, abhängig davon, wie die Parameter dieser beiden Nachrichten in der DEV_REPORT_CONFIG-Nachricht (siehe 19) konfiguriert sind.
D. VERANSCHAULICHENDE BEISPIELE DER LAUFZEITPHASE
Unter Bezugnahme nun auf 85 wird eine beispielhafte Ausführungsform eines Flussdiagramms der Steuernachrichtensequenz gezeigt, die zwischen dem Host und dem Signalprozessor zum Aufbau und Betreiben einer Sprachverbindungssitzung ausgetauscht werden. Jede Sitzung ist unabhängig von allen anderen Sitzungen insofern, als sie asynchron voneinander aufgebaut und abgebaut werden. Die Parameter, die mit den Steuernachrichten auf Sitzungsebene eingestellt werden, sind nur für die Sitzung wirksam, auf die sie gerichtet sind und kehren nach Abbruch der Sitzung zu den voreingestellten Werten zurück.
Wie in Block 1900 gezeigt, beginnt der Host den Einrichtungsprozess durch Anfordern, dass eine Sitzung aufgebaut wird mit einer SESSION_SETUP-Nachricht (siehe 29). Neben dem Definieren der nahe-Ende- und ferne-Ende-Kanäle kann mit dieser Nachricht eine große Anzahl von Telefonieausrüstungsparametern eingestellt werden. Ein wichtiger Parameter, die Sitzungs-ID, wird jedoch von dem Host bereitgestellt, um die Sitzung sowohl für den Host, als auch den Signalprozessor eindeutig zu identifizieren. Es ist zwar zulässig, eine Sitzungs-ID wiederzuverwenden, nachdem eine vorherige Ausführung davon abgebaut worden ist, aber zu einer gegebenen Zeit ist nur eine einzige Ausführung einer Sitzungs-ID zulässig.
Der Signalprozessor antwortet mit einer SESSION_SETUP_RSP-Nachricht (siehe 34), welche die Annahme der Sitzungs-ID bestätigt und gibt auch korrigierte nahe-Ende- und ferne-Ende-Adressparameter zurück, wenn er dazu in der Lage ist (Block 1905). Von dieser Zeit an ist die Sitzungs-ID in allen Nachrichten auf Sitzungsebene ein kritischer Parameter. Wenn sie nicht mit einem Statuscodewert bestätigt worden ist, der den erfolgreichen Abschluss der SESSION_SETUP-Nachricht anzeigt, gibt es keine Sitzung.
Bei Annahme eines erfolgreichen Abschlusses der SESSION_SETUP-Nachricht wird die Sitzung nun aufgebaut, ist aber nicht aktiv. Andere Befehlsnachrichten sowohl von den Telefonie- als auch den Sprachdienste-Katalogen können verwendet werden, um die Parameter auf Sitzungsebene weiter zu modifizieren. Als veranschaulichendes Beispiel wird der SET_VOICE_PARMS- und der SET_VOICE_PARMS_RSP-Nachrichtenaustausch gezeigt (Blöcke 1910 und 1915).
Der nächste Vorgang ist der Beginn der Sitzung. Wie in Blöcken 1920 und 1925 gezeigt, kann dies dadurch erfolgen, dass der Host eine SESSION_START-Nachricht (siehe 35) an den Signalprozessor initiiert und der Signalprozessor eine SESSION_START_RSP-Nachricht zurückgibt (siehe 36). Wenn der Statusparameter der SESSION_START_RSP-Nachricht anzeigt, dass die SESSION_START-Nachricht erfolgreich abgeschlossen wurde, kann der Host mit dem Senden von Daten durch die unten beschriebenen Datennachrichten beginnen. In der Regel ist dies ein Zweiwegeprozess, da die meisten Verbindungen zwei Kanäle, jeweils in einer Richtung, aufweisen. Für einen Kanal sendet der Host Datennachrichten an den Signalprozessor. Für den anderen Kanal sendet der Signalprozessor Paketdaten an den Host.
Das Laden und Entladen von Daten aus dem internen Speicher von innerhalb des Signalprozessors umfasst die Analyse von Host-Port-DMA-Registern. Der Host prüft beispielsweise das HPRQSTAT_x-Register, bevor er Daten in die RX-Datenschlange schreibt und der Signalprozessor liest Datenpakete aus der RX-Datenschlange und nach dem Verarbeiten positioniert er Datenpakete in die TX-Datenschlange (Blöcke 1930 und 1935). Analog prüft der Host die HPXQSTAT_x-Register für diese Kanäle, bevor er paketierte Daten zum Lesen aus der TX-Datenschlange des Signalprozessors annimmt (Blöcke 1940 und 1945).
Wie in Block 1950 gezeigt, kann dieser Datentransferprozess solange wie notwendig anhalten und kann unter Verwendung der SESSION STOP-Nachricht (siehe 37) pausiert werden. Diese Nachricht zerstört die Sitzung nicht, sondern macht die Sitzung stattdessen an einer Framegrenze inaktiv.
Wenn es aus einem Grund wünschenswert ist, einen der Laufzeitparameter zu ändern, kann die Änderung erfolgen, indem die Sitzung zunächst unter Verwendung der SESSION_STOP-Nachricht (siehe 37) oder einer der Telefoniedienste- oder Sprachdienste-Nachrichten im Sitzungsmodus gestoppt wird (beispielsweise mit der Sitzungs-ID anstelle von 0xFFFF). Danach wird die SESSION_START-Nachricht verwendet, um die Sitzung erneut zu starten.
E. DATENNACHRICHTEN
Während der Laufzeitphase wird der Signalprozessor zu jeder Zeit verschiedene Sitzungen aktiv haben. Diese Sitzungen werden TDM- und Paketdatenframes als Eingabe benötigen und werden TDM- und Paketdatenframes als Ausgabe erzeugen. Die Datenschnittstelle legt Nachrichtenformate fest, die den Transport der Paketdatenframes über die Hostschnittstelle ermöglichen. Die TDM-Daten werden über die serielle-Port-Schnittstelle transportiert.
Wie zuvor erwähnt, weist der Signalprozessor für diese Ausführungsform eine Gesamtanzahl von 512 RX-Schlangen und vier TX-Schlangen auf, die von DMA unterstützt werden. Diese Schlangen sind in diesem Beispiel so konfiguriert, dass sie bis zu 509 einzelne RX-Paketdatenflüsse in den Signalprozessor und bis zu zwei globale TX-Paketdatenflüsse aus dem Signalprozessor unterstützen.
Unter Bezugnahme nun auf 86 wird eine beispielhafte Ausführungsform einer Datennachricht gezeigt. Die Datennachricht 2000 enthält einen Datenkopfteil 2005 und eine Nutzlast 2025. Der Datenkopfteil, der für diese Ausführungsform als ein 8-Byte-Kopfteil dargestellt wird, enthält einen Fluss-/Abschluss-Tag-Paramater 2010, nutzlastbezogene Parameter 2015 und Zeitstempelparameter 2020.
Der von dem Host in der SESSION_SETUP-Befehlsnachricht (siehe 29) zugewiesene Fluss/Abschluss-Tag-Parameter 2010 identifiziert den mit diesem Datenframe verbundenen Endpunkt. Somit werden Datenpakete, die mit der nahe-Ende-Sende-Schlange verbunden sind, das nahe-Ende-Tag aufweisen, während Pakete, die mit der ferne-Ende-Sende-Schlange verbunden sind, das ferne-Ende-Tag aufweisen werden.
Die nutzlastbezogenen Parameter 2015 enthalten eine Nutzlastpufferlänge 2016, einen Marker 2017 und eine Nutzlastart 2018. Der Nutzlastpufferlängenparameter 2016 enthält Informationen, die die Größe des Nutzlastpuffers in Bytes festlegen (ausschließlich des 8-Byte-Kopfteils). Bei dieser Ausführungsform sollte die Nutzlastpuffergröße 8 Byte betragen und groß genug für die maximale Nutzlastgröße sein, die für den Codierer/Decodierer benötigt wird (zum Beispiel der Sprachnutzlast). Der Markerparameter 2017 ist ein Steuerbit, das, wenn es eingestellt ist, den ersten Sprachframe nach einem oder mehreren still-Frames anzeigt. Der Nutzlastartparameter 2018 enthält Informationen, die das Format der Datenframenutzlast, das beispielsweise in 87 definiert wird, definiert.
Der Zeitstempelparameter 2020 enthält Informationen, die die Abtastungszeit des ersten Bytes in dem Datenframe anzeigen. Dieser Parameter 2020 wird als Mittel zum Synchronisieren und zur Berechnung von Schwankungen für das ferne-Ende verwendet. Der Zeitstempel kann in Einheiten von 1 ms vorliegen.
Bei einer Datennachricht, die PCM-Daten enthält, weist die Nutzlast 2025 M 16-Bit-PCM-Abtastungen (M ≥ 1) wie in 88 gezeigt auf. Padbytes können der Nachricht wenn notwendig zugefügt werden, um das Größenmodul auf vier Bytes einzustellen.
Bei einer codierte Sprachframes enthaltenden Datennachricht können diese Frames in Übereinstimmung mit G.711 A-law, ☐-law, G.726, G.727, G.723.1 und G.729A/B codiert werden. Es gibt zwei Arten G.711, G726 und G.727-Nutzlasten über den Signalprozessor zu übertragen. Eine Art erfolgt über den generischen PCM/ADPCM-Transfer (FRF.11&ITU G.764 Empfehlung). Bei diesem Nutzlasttransferschema werden die in Übereinstimmung mit G.711(PCM), G.726(ADPCM) oder G.727(EADPCM) codierten Sprachabtastungen in die Nutzlaststruktur 2025 eingeführt, wie in 89 dargelegt.
Die Sprachtransferstruktur 2025 enthält Blöcke 2030, die gemäß der Signifikanz der Bits angeordnet sind. Ein erster Block 2031 enthält die signifikantesten Bits (MSBs) aller codierten Abtastungen. Der zweite Block 2032 enthält die zweiten MSBs usw. In einem Block sind die Bits gemäß ihrer Abtastungsnummer angeordnet. Da das Codierintervall von 5 ms 40 Abtastungen entspricht, enthält jeder Block 5 Bytes.
Ein besonderes Merkmal dieser Struktur ist, dass nichtkritische (Verbesserungs-)Information an Stellen platziert wird, wo sie einfach verworfen werden kann, ohne die kritische (Kern-)Information zu beeinträchtigen. Wenn beispielsweise 32-kbits EADPCM (G.727 (4,2)) verwendet wird, gibt es beispielsweise nur vier Blöcke, die den vier Bits variierender Signifikanz entsprechen (MSB-Block, MSB- 1-Block, MSB-2-Block, „LSB" (am wenigsten signifikantes Bit)-Block). Die Blöcke der am wenigsten signifikanten Bits (MSB-2, LSB) würden den Verbesserungen zugeordnet werden und können bei Staubedingungen verworfen werden.

Claims

Nachrichtenkommunikationsverfahren, umfassend: Empfangen einer ersten Steuernachricht durch einen Signalprozessor (130), gekennzeichnet: dadurch, dass die erste Steuernachricht einen Nachrichtenkopfteil und einen Steuerkopfteil (900) umfasst, wobei der Steuerkopfteil einen Katalogparameter (980), der eine ausgewählte Gruppierung von Steuernachrichten anzeigt, und einen Codeparameter (990), der eineausgewählte Funktion der ausgewählten Gruppierung anzeigt, enthält; und durch Antworten auf die erste Steuernachricht durch Senden einer zweiten Steuernachricht durch den Signalprozessor (130).
Nachrichtenkommunikationsverfahren nach Anspruch 1, wobei der Signalprozessor (130) durch Steuernachrichten von einem Hostprozessor (150), einschließlich der ersten Steuernachricht, gesteuert, konfiguriert und überwacht wird.
Nachrichtenkommunikationsverfahren nach Anspruch 1, wobei der Katalogparameter (980) so ausgewählt wird, dass er ein Vorrichtungssteuerungskatalog (1010) ist.
Nachrichtenkommunikationsverfahren nach Anspruch 3, wobei die erste Steuernachricht eine Nachricht zum Einrichten eines Knotens (DEV_SET_NODE) für den Signalprozessor (130) zum Erstellen einer Knotenkennung (NODE-ID) zum Kennzeichnen des Signalprozessors (930) und Bereitstellen der Knotenkennung in der zweiten Steuernachricht ist.
Nachrichtenkommunikationsverfahren nach Anspruch 3, wobei die erste Steuernachricht eine Nachricht zum Anfordern von Vorrichtungsinformationen (DEV_INFO) für den Signalprozessor (130) zum Zurückgeben der zweiten Steuernachricht mit Informationen bezüglich einer Version des Signalprozessors, einer Version der internen Logik in dem Signalprozessor (130) und einer Größe des internen Speichers in dem Signalprozessor (130) ist.
Nachrichtenkommunikationsverfahren nach Anspruch 3, wobei die erste Steuernachricht eine Nachricht zur Vorrichtungskonfiguration (DEV_REPORT_CONFIG) ist, die den Signalprozessor (130) so konfiguriert, dass er periodisch Statusnachrichten an eine Quelle der ersten Steuernachricht sendet.
Nachrichtenkommunikationsverfahren nach Anspruch 3, wobei die erste Steuernachricht eine Nachricht zum Einrichten eines seriellen Ports (SERIAL_PORT_SETUP) ist, die den seriellen Port des Signalprozessors (130) konfiguriert.
Nachrichtenkommunikationsverfahren nach Anspruch 1, wobei der Katalogparameter (980) so ausgewählt ist, dass er ein Sitzungssteuerkatalog ist (1020, 1300).
Nachrichtenkommunikationsverfahren nach Anspruch 8, wobei die erste Steuernachricht eine Nachricht zum Einrichten einer Sitzung (SESSION_SETUP) ist, um eine Kommunikationssitzung zu erstellen, wobei die SESSION_SETUP-Nachricht einen Sitzungsidentfikationsparameter, ein Diensteinrichtungsfeld, ein Telefoniefeld, ein Feld der Kanäle des nahen Endes und ein Feld der Kanäle des entfernten Endes enthält.
Nachrichtenkommunikationsverfahren nach Anspruch 9, wobei der Sitzungsidentifikationsparameter von einer Quelle der Steuernachricht zugeführt und geführt wird, um die Kommunikationssitzung eindeutig zu identifizieren.
Nachrichtenkommunikationsverfahren nach Anspruch 9, wobei das Diensteinrichtungsfeld einen Codiererdienstparameter enthält, um die Codierer- und Decodierertypen anzuzeigen.
Nachrichtenkommunikationsverfahren nach Anspruch 9, wobei das Telefoniedienstfeld Parameter enthält, die die von dem Signalprozessor (130) gehandhabten Telefoniemerkmale konfigurieren.
Nachrichtenkommunikationsverfahren nach Anspruch 8, wobei die erste Steuernachricht eine Nachricht zum Sitzungsstop (SESSION_STOP) ist, um einen Informationsfluss zeitweilig anzuhalten und mit der Kommunikationssitzung zu pausieren.
Nachrichtenkommunikationsverfahren nach Anspruch 8, wobei die erste Steuernachricht eine Nachricht zum Abbrechen der ist (SESSION_TEARDOWN), um die Kommunikationssitzung abzubrechen.
Nachrichtenkommunikationsverfahren nach Anspruch 1, wobei der Katalogparameter (980) so ausgewählt ist, dass er ein Telefoniedienstkatalog (1030, 1400) ist, so dass die erste und zweite Steuernachricht die Telefoniefunktionalität des Signalprozessors (130) konfigurieren, wobei die Telefoniefunktionalität Tonerfassung und Tonerzeugung einschließlich Dual-Ton-Mehrfachfrequenz-(DTMF)-Töne und Echoausblendung enthält.
Nachrichtenkommunikationsverfahren nach Anspruch 1, wobei der Katalogparameter (980) so ausgewählt ist, dass er ein erster Faxdienstekatalog (1040, 1600) ist, so dass die erste Steuernachricht eine ausgewählte Sprachfunktion einschließlich der Modifikation von Codiererraten anpasst.
Nachrichtenkommunikationsverfahren nach Anspruch 1, wobei der Katalogparameter so ausgewählt ist, dass er ein Sprachdienstekatalog (1050, 1700) ist, so dass die erste Steuernachricht eine ausgewählte Faksimilefunktion einschließlich einer Modemdatenrate anpasst.
Datenmedium mit einem darauf gespeicherten Computerproduktcode, der dazu ausgelegt ist, alle Schritte nach einem der Ansprüche 1 bis 17 auszuführen, wenn der Programmcode auf einem Computer läuft.
Voice-Over-Packet-(VoP)-Subsystem, umfassend: einen Hostprozessor (150); und einen Signalprozessor (130) in Kommunikation mit dem Hostprozessor (150); gekennzeichnet durch: der Signalprozessor (130), der einen internen Speicher (490) enthält, einen Steuerprozessor (430), eine Steuerung (450) des Direktspeicherzugriffs (DMA), welche an den internen Speicher (490) und den Steuerprozessor (430) gekoppelt ist, mehrere serielle Ports (400) in Verbindung mit dem Steuerprozessor (430), wobei jeder der mehreren seriellen Ports (400) dazu ausgelegt ist, nicht-paketierte Sprachproben zu empfangen, und einen Hostport (410) in Verbindung mit dem Steuerprozessor (420), wobei der Hostport (410) paketierte Steuernachrichten von dem Hostprozessor (150) empfangen soll, wobei mindestens eine der Steuernachrichten einen Nachrichtenkopfteil und einen Steuernachrichtenteil umfasst, wobei der Steuerkopfteil einen Katalogparameter (980), der eine ausgewählte Gruppierung von Steuernachrichten anzeigt, und einen Codeparameter (990), der eine ausgewählte Funktion der ausgewählten Gruppierung anzeigt, enthält.
VoP-Subsystem nach Anspruch 19, wobei der Signalprozessor (130) betriebsfähig ist, um eine Nachricht zum Einrichten eines Knotens (DEV_SET_NODE) von dem Hostprozessor (150) zu empfangen, um eine Knotenkennung (Node-ID) zu erstellen, um den Signalprozessor (130) zu identifizieren, und wobei in Reaktion auf eine Antwortsteuernachricht die Knotenkennung von dem Signalprozessor (130) dem Hostprozessor (150) bereitgestellt wird.
VoP-Subsystem nach Anspruch 19, wobei der Signalprozessor (130) betriebsfähig ist, um eine Nachricht zur Vorrichtungsinformationsanforderung (DEV_INFO) von dem Hostprozessor (150) zu empfangen und eine Steuernachricht mit Informationen bezüglich einer Version des Signalprozessors (130), einer Version der internen Logik in dem Signalprozessor (130) und einer Größe des internen Speichers in dem Signalprozessor zurückzugeben.
VoP-Subsystem nach Anspruch 19, wobei der Signalprozessor (130) betriebsfähig ist, um eine Nachricht der Vorrichtungsberichtkonfiguration (DEV_REPORTCONFIG) zu empfangen, die den Signalprozessor (130) so konfiguriert, dass er periodisch Statusnachrichten an den Hostprozessor (150) sendet.
VoP-Subsystem nach Anspruch 19, wobei der Signalprozessor (130) betriebsfähig ist, um eine Nachricht zum Einrichten eines seriellen Ports (SERIAL_PORT_SETUP) von dem Hostprozessor (150) zu empfangen, wobei die SERIAL_PORT_SETUP-Nachricht einen seriellen Port des Signalprozessors (130) konfigurieren soll.
VoP-Subsystem nach Anspruch 19, wobei der Signalprozessor (130) betriebsfähig ist, um eine Nachricht zum Einrichten einer Sitzung (SESSION_SETUP) von dem Hostprozessor (150) zu empfangen, um eine Kommunikationssitzung zwischen dem Hostprozessor (150) und dem Signalprozessor (130) einzurichten, wobei die SESSION_SETUP-Nachricht (1) einen Sitzungsidentifikationsparameter, der von dem Hostprozessor (150) zugeführt und geführt wird, um die Kommunikationssitzung eindeutig zu identifizieren, (2) ein Diensteinrichtungsfeld, welches Parameter zum Spezifizieren der Codierer- und Decodierertypen, (3) ein Telefoniefeld, (4) ein Feld der Kanäle des nahen Endes und (5) ein Feld der Kanäle des entfernten Endes enthält.