Die Erfindung liegt auf dem Gebiet der Sprach-und Datenkom- munikation und berührt insbesondere Aspekte der Vermittlungs- technik.

In der Kommunikationstechnik gibt es ein stetiges Streben nach Ressourceneffizienz. Dabei spielen Einsparungen bei Kom- munikationsvorrichtungen zum Vermitteln und Verteilen von Nutzdaten eine wichtige Rolle. Bei der Reduzierung des Auf- wands und der Komplexität derartiger Einrichtungen ist jedoch zu berücksichtigen, dass Standards einzuhalten und die Kompa- tibilität zu anderen Kommunikationsvorrichtungen gewahrt wer- den soll. Diese Anforderungen stehen der Reduktion der einge- setzten Mittel bzw. Ressourcen häufig im Wege.

Ein wichtiges Beispiel für Kommunikationsvorrichtungen mit einem Potential für Einsparungen sind Vorrichtungen, deren Funktionalität keine Bearbeitung von eingehenden Nutzdaten erfordert. Beispiele für derartige Kommunikationsvorrichtun- gen sind : Reine Informationsausgabesysteme, z. B. reine Ansagensyste- me. Bei Informationsausgabesystemen, welche nur die Ausga- be von Informationen (z. B. Sprachinformationen) vorsehen und nicht evtl. durch extern zugeführte Informationen steuerbar sind (wie z. B. Systeme zum interaktiven Sprach-

dialog), können die Ressourcen zur Bearbeitung von zu dem System übermittelten Informationen reduziert werden.

Reine Verteilsysteme. Verteilsysteme beschränken sich häu- fig auf das Weiterleiten bzw. Weitervermitteln von Infor- mationen bzw. Nutzdaten. Ressourcen für die Interpretation bzw. Bearbeitung von Nutzdaten können in reduziertem Um- fang vorgesehen werden.

Die oben beschriebenen Einsparungsmaßnahmen sind dadurch be- grenzt, dass Kompatibilität bei der Kommunikation mit anderen Vorrichtungen bzw. Endgeräten gegeben sein muss. So gibt es Kommunikationsinstanzen (z. B. Endgeräte, Vermittlungsvorrich- tungen oder Gateways), bei welchen im Rahmen eines Kommunika- tionsvorgangs eine bidirektionale Verbindung vorgesehen ist, unabhängig davon, ob tatsächlich Nutzdaten zu der Kommunika- tionspartnerinstanz gesendet werden. Für Verbindungen zur Nutzdatenübermittlung zu einer derartigen Kommunikationsin- stanz müssen von Informationsausgabesystemen bzw. Kommunika- tionsverteilsystemen Ressourcen für die Bearbeitung von der Kommunikationspartnerinstanz übermittelten Informationen vor- gesehen werden, um eine bidirektionale Verbindung zu ermögli- chen.

Ein Beispiel für eine derartiges Szenario ist der Informati- onsaustausch zwischen einem reinen Ansagesystem und einem Endgerät, bei dem von dem Endgerät nur eine bidirektionale Verbindung unterstützt wird. Obwohl nur in einer Richtung (von dem Ansagesystem zu dem Endgerät) relevante Informatio- nen übertragen werden, kommt auch in der anderen Richtung ei- ne Nutzdatenübertragung zustande, die z. B. in der Übertragung von von einem Mikrophon des Endgerätes aufgenommenen Hinter- grundgeräuschen besteht. Der von dem Endgerät zu dem Ansage- system übertragene Nutzdatenstrom bzw. Bearer-Strom ist dann für den Dienst irrelevant, erfordert aber Bearbeitungsres- sourcen auf Seiten des Ansagesystems.

Zudem wird häufig bei einer bidirektionalen Verbindung von den verwendeten Protokollen vorgesehen, dass Informationen in beide Richtungen gesendet werden, welche statistische Aussa- gen über die Qualität der Verbindung enthalten. Diese Infor- mationen werden z. B. dazu verwendet, die Senderate zu regu- lieren. Eine beteiligte Kommunikationsvorrichtung muss daher über Mittel zur Generierung dieser Informationen verfügen.

Ein wichtiges Protokoll, bei dem die oben beschriebene Situa- tion vorkommen kann, ist das RTP (real time protocol) Proto- koll, welches in Verbindung mit dem RTCP (real time control protocol) verwendet wird. Das RTP Protokoll ermöglicht die Übertragung von Sprache als Nutzdaten bzw. Bearer. Die Über- tragung des Bearers wird durch das RTCP Protokoll gesteuert.

Wenn beispielsweise ein Ansagesystem mittels dem RTP/RTCP Protokollstapel Sprachinformationen an ein Endgerät ausgibt, welches nur bidirektionale RTP Verbindungen unterstützt, wer- den mittels des RTCP Protokolls statistische Informationen über die Verbindung in beiden Richtungen übermittelt.

Die Erfindung hat zur Aufgabe, eine Aufwandsreduzierung bei Kommunikationsvorrichtungen zu ermöglichen.

Die Aufgabe wird durch die Gegenstände der unabhängigen An- sprüche gelöst.

Die Erfindung beruht auf der Beobachtung, dass für Kommunika- tionsvorrichtungen, welche generell oder für bestimmte Diens- te keine Nutzdatenübertragung an eine Kommunikationspartner- instanz vorsehen, in Fällen, in denen trotzdem eine bidirek- tionale Verbindung zu der Partnerinstanz aufgebaut wird, bei- spielsweise weil die Kommunikationspartnerinstanz nur bidi- rektionale Verbindungen mit dem verwendeten Protokoll unter- stützt, der Aufwand bei der Bearbeitung, der von der Kommuni- kationspartnerinstanz übertragenen Nutzdaten reduziert werden kann, indem zumindest ein Teil dieser von der Kommunikations-

partnerinstanz in Richtung der Kommunikationsvorrichtung ü- bertragenen Nutzdaten verworfen werden.

Beispiele für Vorrichtungen bzw. Dienste, für die in der Re- gel nur Nutzdatenübertragung in einer Richtung, d. h. unidi- rektional vorgesehen ist, sind Informationsausgabesysteme (z. B. Ansagesysteme) und Verteilsysteme bzw. Informationsaus- gabedienste (z. B. Ansagedienste) und Verteildienste. Die Kom- munikationspartnerinstanz kann beispielsweise durch ein End- gerät oder ein Gateway gegeben sein.

Die Erfindung hat den Vorteil von im Vergleich zur herkömmli- chen Systemen größerer Ressourceneffizienz. Der Bearbeitungs- aufwand wird reduziert, indem übertragene Nutzdaten, die für den Dienst irrelevant sind, verworfen werden. Ein eventuell bei einer Sprachverbindung übertragenes irrelevantes Hinter- grundgeräusch wird in der Kommunikationsvorrichtung nicht vollständig ausgewertet. Ein Teil der Hardware bzw. Software- ressourcen, die in der Kommunikationsvorrichtung herkömmlich zur Bearbeitung von an die Kommunikationsvorrichtung übertra- genen Nutzdaten vorgesehen sind, können eingespart werden.

Dies kann teure spezielle Hardware, wie DSPs (DSP : digital signalling processor) oder ASICs (ASIC : application specific integrated circuit) betreffen.

Die Erfindung ist beispielsweise anwendbar in paketorientier- ten Netzen, über welche Nutzdaten als Nutzdatenpakete in Richtung der Kommunikationsvorrichtung übertragen werden. In diesem Fall lässt sich der Verwurf der Pakete z. B. auf fol- gende zwei Weisen realisieren : Ein der Kommunikationsvorrichtung vorgelagerter Router verwirft die zu der Kommunikationsvorrichtung übertragenen Nutzdaten.

* In der Kommunikationsvorrichtung werden eintreffende Da- tenpakete gefiltert, z. B. anhand der UDP-Portadressen (UDP : user datagram protocol), und Nutzdatenpakete, welche von der Kommunikationspartnerinstanz gesendet wurden, wer-

den verworfen. Dieses Herausfiltern der nicht für den Dienst relevanten Nutzdaten kann auf den unteren Schichten des Protokollstapels vorgenommen werden. Eine Bearbeitung auf den oberen Schichten des Kommunikationsprotokolls oder eine Auswertung bzw. Interpretation übermittelter Nutzda- ten ist nicht erforderlich, so dass dafür keine Ressourcen vorgesehen werden müssen.

Die Nutzdatenpakete werden im Falle von Echtzeitverkehr bei- spielsweise mittels des RTP-Protokolls übertragen. Für die Steuerung von RTP-Verbindungen wird das RTCP-Protokoll ver- wendet. Gemäß dem RTCP-Protokoll werden statistische Informa- tionen zwischen den Kommunikationsinstanzen übertragen, wel- che sich häufig auf die Übertragungsqualität der Nutzdaten- übertragen der Kommunikationsinstanzen bezieht. Herkömmlich erfordert die Generierung solcher statistischer Informationen oder generell von Kontrollinformationen zur Verbindungsquali- tät die Auswertung der übersendeten Nutzdaten. Die vorliegen- de Erfindung sieht allerdings vor, dass für die angesproche- nen Fälle ein Teil der Nutzdaten verworfen, also nicht auf die Übertragungsqualität hin ausgewertet werden. Entsprechend einer vorteilhaften Weiterbildung kann verhindert werden, dass die Kontrollpartnerinstanz wegen ausbleibender oder ir- reführender Meldungen bzw. Informationen über die zur Kommu- nikationsvorrichtung aufgebauten Verbindung zu ungewünschten Reaktionen-im Extremfall der Beendigung der bidirektionalen Verbindung-veranlasst wird. Dabei sendet die Kommunikati- onsvorrichtung Informationen bzw. Meldungen an die Kommunika- tionspartnerinstanz, die ein einwandfreies Funktionieren der Nutzdatenübertragung von der Kontrollpartnerinstanz zu der Kommunikationsvorrichtung simuliert. Dabei kann z. B. ein be- kannter Wertebereich für die Kontrollinformationen benutzt werden, welcher einer störungsfreien Nutzdatenübertragung entspricht. Weiter ist es möglich, dass man einen kleinen Teil der Nutzdaten nicht verwirft, sondern für die Berechnung statistischer Informationen bzw. Kontrollinformationen aus-

wertet und die erhaltenen Ergebnisse für die gesamte Menge an Nutzdaten extrapoliert.

Die Erfindung wird im Folgenden im Rahmen eines Ausführungs- beispiels anhand von Figuren näher erläutert. Es zeigen : Figur 1 : Eine Kommunikationsvorrichtung und eine Kommunika- tionspartnerinstanz, die miteinander kommunizieren, wobei von der Kommunikationspartnerinstanz zu der Kommunikationsvorrichtung übertragenen Nutzdaten von einem Router herausgefiltert werden.

Figur 2 : Eine Kommunikationsvorrichtung und eine Kommunika- tionspartnerinstanz in Kommunikationsbeziehung, wo- bei von der Kommunikationspartnerinstanz an die Kommunikationsvorrichtung gesendete Nutzdaten in der Kommunikationsvorrichtung herausgefiltert und verworfen werden.

Beide Figuren zeigen eine Kommunikationsvorrichtung IVR (IVR : Interactive Voice Response) und eine Kommunikationspartnerin- stanz KPI, welche über eine bidirektionale Verbindung mittels des RTP-Protokolls Nutzdaten miteinander austauschen. Gesteu- ert bzw. kontrolliert werden diese Verbindungen mittels des RTCP-Protokolls. In Figur 1 ist ein Router R gezeigt, der mit Hilfe eines Filters F an die Kommunikationsvorrichtung IVR übertragene Nutzdaten herausfiltert, so dass diese nicht zu der Kommunikationsvorrichtung IVR gelangen. In Figur 2 wird diese Filterfunktion von der Kommunikationsvorrichtung IVR selber vorgenommen, welche mit Hilfe eines Filters F von der Kommunikationspartnerinstanz KPI übertragene Nutzdaten her- ausfiltert und verwirft, welche so nicht durch höhere Proto- kollschichten bearbeitet werden müssen.

Bei der Kommunikationsvorrichtung IVR handelt es sich bei- spielsweise um ein Software-basiertes VoIP (VoIP : voice over IP) Ansagesystem auf Basis des RTP und des RTCP Protokolls.

Im Folgenden wird beispielhaft für ein Ansagesystem beschrie- ben, wie man statt bidirektional betriebener RTP/RTCP Kanäle mit unidirektional betriebenen Kanälen arbeiten kann.

Bei dem ersten Beispiel entsprechend Fig. 1 verwirft ein vor- gelagerter Router die RTP Pakete in Richtung Ansagesystem, so dass trotz bidirektionaler Durchschaltung das Ansagesystem nicht mit RTP-Last beaufschlagt wird.

Im Fall der Behandlung der Nutzdaten in dem Ansagesystem (Beispiel entsprechend Fig. 2) schaltet der die Verbindung steuernde Call Controller oder der entfernte Endpunkt einen symmetrischen RTP Strom durch das IP Netz zum Ansagesystem durch. Oberhalb des IP Stacks, d. h. des IP Protokollstapels im Ansagesystem, wird ein statischer Filter eingerichtet, der alle zum Ansagesystem führenden mittels des RTP Protokolls übertragenen IP Pakete anhand der durch diese Protokolle ver- wendeten UDP (user datagramm protocol) Ports erkennt und ver- wirft. Die höheren Protokoll Layer, die rechenzeitaufwendige- re Aufgaben für diese Pakete durchführen müssten, werden da- durch nicht mehr belastet und müssen nur noch ausgehende Da- tenströme behandeln.

Da in einem Software-basierten Ansagesystem ein sehr hoher Anteil der Performance auf die Behandlung von RTP Protokoll- abläufe entfällt, kann das frei werdende Rechenzeit Budget nun z. B. zur Behandlung weiterer Ansage Ports verwendet wer- den.

RTCP sender reports werden wie in RFC 1889 (RFC : request for comments) vorgesehen ausgesendet. Der Standard sieht bereits vor, dass diese relativ selten ausgesendet werden, so dass es keines großen Rechenzeitaufwandes bedarf. Daher kann der Fil- ter RTCP Pakete an den RTCP Rrotokollstapel des Ansagesystems weiterleiten.

Entsprechend einer Weiterbildung des Anmeldegegenstands kann auf Ebene des RTCP Protokolls ein einwandfreies Funktionieren einer bidirektionalen Verbindung simuliert werden. Das RTCP Protokoll sieht das optionale Aussenden von sogenannten Re- ceiver Reports vom Ansagesystem zum entfernten Anwender vor.

Da im Ausführungsbeispiel ein Bearer bzw. Nutzdaten Strom physikalisch durch das IP Netz geschaltet wurde, kann man versuchen, die vom entfernten Mikrofon aufgenommenen und via der Kommunikationspartnerinstanz übertragenen Sprachströme oder Voice Activity Meldungen zu bewerten, um dem entfernten Anwender, bzw. dessen Bearer Behandlung, einen Duplex Stream, d. h. eine bidirektionale Verbindung, vorzuspiegeln.

Damit das Ziel der Aufwandsreduzierung, die durch Ausfüh- rungsbeispiel 1 erreicht wird, nicht konterkariert wird, ist es sinnvoll, auf eine kontinuierliche Berechnung der RTCP Statistiken auf Basis aller empfangenen RTP Pakete zu ver- zichten. Folgende Lösungsansätze zur Reduzierung des Aufwands bei der Berechnung der RTCP Statistiken können beschritten werden : a) Aussenden eines default Reception Reports Da ein hier beschriebenes Ansage-oder Verteilsystem nicht von der Qualität des empfangenen Stroms abhängig ist, können in den Report erfahrungsgemäß akzeptable Standardwerte einge- tragen werden. Sollte ein Network Operator diese auswerten bzw. interpretieren, muss ihm der Umstand, dass speziell die- se Reports nicht aussagekräftig sind, lediglich im Rahmen der Definition der Standardwerte bewusst sein. Damit wird sicher- gestellt, dass das entfernte Bearer Treatment keine ungewoll- ten Gegenmaßnahmen einleitet (z. B. die Senderate reduziert oder Fehler Reports generiert). Der Reception Report kann folgende Parameter (entsprechend RFC 1889) enthalten : SSRC (Synchronization source) der sendenden Quelle (kann aus beliebigen empfangenen RTP Paketen, z. B. mittels ei-

nes RTP Sniffers bzw. Filters, welcher wenigstens zu Be- ginn des Rufes/der Session einige Pakete auswertet, er- mittelt werden oder aus dem letzten empfangenen Sender Report ermittelt werden) Lost Fraction : hier wird 256 eingetragen, was einem i- dealem Empfang entspricht.

Cumulated number of lost packages : hier wird 0 oder ein sehr geringer Wert eingetragen Highest received sequence number : die Anzahl der Sequen- ce Number Cycles und der Highest Sequence Number Recei- ved wird aus einer Rundung einer algorithmischen Berech- nung aus - der Zeit seit dem letzten Reception Report (alternativ kann der Beginn der Bearer Durchschaltung zugrunde ge- legt werden) - dem Codec Type und seiner Bandbreite und - den verwendeten Paketisierungsgrössen (Ergebnisse der Codec Negotiation) mittels der zu erwartenden RTP Paketanzahl ermittelt.

Diese Parameter sind bei Ansagesystemen pro Ruf/Session stabil und es ist daher eine derartige Berechnung/Fol- ge von Divisionen möglich.

Interarrival Jitter : hier wird ein unverdächtiger Wert, der 1 ms entspricht, eingetragen.

Last (arrived) SR : der Zeitstempel des letzten Sendere- ports wird von der RTCP Statistik Funktion für Sender Reports übernommen.

Delay since last (arrived) SR : die im letzten Sendere- port eingetragene Verzögerung wird von der RTCP Statis- tik Funktion für Sender Reports übernommen. b) Reduktion der Anzahl der RTP Pakete, die von der RTCP Sta- tistik Funktion bearbeitet werden muss

Kontrolliert über einen geeigneten, zeitlich gesteuerten dy- namischen Filter oberhalb des IP stacks (der auf RTP Port Ad- ressen sensibilisiert ist), werden der RTCP Statistik Funkti- on nur RTP Pakete über einen beschränkten Zeitabschnitt (z. B. die Dauer eines Ansage-Rufs), z. B. über mehrere gleichver- teilte 100 ms Intervalle der im Mittel 10 Sekunden lang dau- ernden Ansageverbindung zugestellt. Die RTCP ports sind hier prinzipiell offen.

Hier kann im Wesentlichen eine kommerzielle RTCP Statistik wiederverwendet werden, die eine längere Messung als tatsäch- lich erfolgt vortäuscht. Der Parameter"Highest Received Se- quence Number"muss aber wie unter a) approximativ berechnet werden. Für den"Interarrival Jitter und Lost Fraction"Para- meter können dagegen die aus der 100 ms Messung erzeugten Werte als die, realen'Messwerte in den Reception Report ein- getragen werden. Der Parameter"Cumulated number of lost packages"muss ebenfalls extrapoliert werden.

Geht man z. B. von 1 Sekunde dauernden Intervallen für das Aussenden der Reception Reports aus und misst man darin je- weils nur 100 ms, so wäre der zu sendende Wert um den Faktor 10 zu multiplizieren. Man trifft hier die Annahme einer Gleichverteilung der Paketverluste über die Rufdauer.