DE69529948T2 - Halbleiterspeicherbasierter Server zum Bereitstellen von Multimedianachrichten auf Anfrage in einem Grossraumnetz - Google Patents

Description

TECHNISCHES GEBIET
• Die vorliegende Erfindung betrifft ein Verfahren und eine Vorrichtung zum Bereitstellen von Multimedia- und Videodaten von einem Server über ein Datenübertragungsnetz (Datenfernverarbeitungsnetz) für anfordernde Clients.
BESCHREIBUNG DES STANDS DER TECHNIK
• Die Systeme zum Bereitstellen von Informations- und Unterhaltungsdienstleistungen in der Wohnung eines Endbenutzers weisen drei verschiedene Komponenten auf: das Serversystem, das Endbenutzersystem und das Netz zum gleichzeitigen Verbinden einer großen Anzahl von Endbenutzern (Clients) mit dem Server. Die beiden am weitesten verbreiteten Systeme zur privaten Bereitstellung von Informationen sind das öffentliche Telefonnetz und das Funk-/Kabelfernsehsystem. Das Telefonnetz bietet heutzutage den Zugang zu elektronisch gespeicherten Textinformationen wie Bankkontoständen sowie Audiosequenzen wie beispielsweise Anweisungen für verschiedene Büroabläufe.
• Weithin wird erwartet, dass durch die technologischen Fortschritte interaktive Multimediadienste ermöglicht werden. Die entsprechenden Dienste sind Video on Demand für Filme, Nachrichten, Sportsendungen, Fernsehprogramme usw., Homeshopping, interaktive Spiele, Reisebilder und eine breite Vielfalt von Bildungs- und Informationsdiensten. Alle drei Komponenten der herkömmlichen Informations-/ Unterhaltungsversorgungssysteme, also die Server, das Netz und das Endgerät des Benutzers (Personal Computer oder Set Top Box) müssen für das Bereitstellen der interaktiven Multimediadienste verbessert werden. Die PCs und die Set Top Boxen müssen in der Lage sein, bewegte Videofilme und die zugehörigen Audiodateien zu empfangen und dekomprimieren. Das Netz muss eine ausreichende Bandbreite aufweisen, um jedem Benutzer seinen eigenen Videokanal zum Server zur Verfügung zu stellen, und bei den meisten Diensten muss der Server in der Lage sein, gleichzeitig und zu niedrigen Kosten eine große Anzahl von Videodatenströmen bereitzustellen.
• Das Haupthindernis des gegenwärtigen Telefonnetzes besteht in der begrenzten für jeden Endbenutzer verfügbaren Bandbreite, die gerade so für einen Audiokanal ausreicht. Damit ist die Übertragung bewegter Videoinformationen ausgeschlossen, und die Übertragung von hochauflösenden Bildern verläuft langsam. Das Fernsehen bietet sowohl per Kabel als auch per Funk jedem Benutzer eine sehr viel höhere Bandbreite; da jedoch die Gesamtbandbreite des Netzes begrenzt ist (Bandbreite des Kabels oder für die Sendefrequenzen reservierte spektrale Bandbreite), kann der Benutzer die für ihn interessanten Informationen nicht interaktiv auswählen. Statt dessen beschränkt sich seine Auswahl auf eines der ca. 50 Programme, die zu einem bestimmten Zeitpunkt gerade gesendet werden. Daher sind die gegenwärtigen Telefon- und Fernsehnetze, sowohl per Funk als auch per Kabel, zum Bereitstellen interaktiver Multimediadienste wie Video on Demand und interaktiver Spiele nicht geeignet.
• Die Anbieter der Telefon- und Kabelfernsehdienste nutzen jedoch die technologischen Fortschritte, um die oben erwähnten Beschränkungen aufzuheben. Durch den zunehmenden Integrationsgrad der VLSI-Technologie (Very Large Scale Integration) konnten die Kosten der Kompressions-/ Dekompressionshardware für Videofilme gesenkt und solche Technologien wie die ADSL (Asymmetric Digital Subscriber Loop, asymmetrische digitale Teilnehmerleitung) ermöglicht werden. Durch diese beiden Verfahren können Videofilme zu einem privaten Benutzer übertragen und von diesem empfangen und der Benutzer mit der örtlichen Telefonvermittlung verbunden werden, so dass jeder Benutzer seinen eigenen Videokanal erhält. Desgleichen sind infolge der Fortschritte in der Glasfaserübertragungstechnik und deren sinkender Kosten Verbesserungen der Hauptleitungen und Einspeisesysteme des Fernsehnetzes möglich geworden, durch die die Bandbreite des Netzes so weit erhöht wurde, dass jeder Teilnehmer bis zu seinem Anschluss seinen eigenen Kanal für den Empfang komprimierter digitaler Videofilme erhält. Auch Direktempfangssatelliten und andere neue drahtlose Übertragungstechnologien stellen eigene Videokanäle zwischen einer großen Anzahl von Endbenutzern und einem Server zur Verfügung. Immer mehr kommen auch Personal Computer und Set Top Boxen in Gebrauch, die vernetzte Multimediaanwendungen ermöglichen, indem sie sich der preiswerten Videokomprimierungs-/-dekomprimierungshardware und der neuen leistungsfähigen und dennoch preiswerten Mikroprozessoren bedienen.
• Während sich einerseits die Client-Systeme (Endbenutzersysteme) und die Netzinfrastruktur schnell entwickeln, um die Anforderungen der interaktiven Multimediadienste zu befriedigen, sind die gegenwärtig gebräuchlichen Server immer noch teuer und zum Bereitstellen dieser Dienste wenig geeignet, da jeder dieser Server nur die Übertragung einer begrenzten Anzahl von Datenströmen unterstützen kann. Gegenwärtig werden Standard-Großrechner oder Parallelrechnersysteme auf Basis der Workstationtechnologie als Server für die interaktiven Multimediadienste eingesetzt. Die Hardware and Software ist in beiden Fällen auf rechenintensive Anwendungen und auf die Unterstützung mehrerer Parallelbenutzer (Timesharing) zugeschnitten, wobei der Datenübertragung zu und von Netzschnittstellen und den E/A-Einheiten (Eingabe/Ausgabe) nur geringe Bedeutung beigemessen wird. Zum Beispiel beträgt in einer RS/6000 die Übertragungsbandbreite vom Hauptspeicher zum Cachespeicher 400 MBytes, während die Bandbreite von den E/A- Einheiten oder den Netzeinheiten zum System lediglich 80 MBytes beträgt. Die Systemkosten werden noch durch die Gleitkommaunterstützung erhöht, die für die Bereitstellung von Video-/Multimediadaten keinerlei Vorteil bringt. Die Netzprotokolle sind für die zuverlässige Bereitstellung von Daten über die unzuverlässigen langsamen Netzleitungen sowie die Netzinfrastruktur und die Anwendungsumgebung der frühen siebziger Jahre optimiert, während angesichts der geringeren Zuverlässigkeitsanforderungen der Videoübertragung über die stabileren modernen Netze ein unnötiger CPU-Systemaufwand betrieben wird.
• Die oben genannten Faktoren bewirken, dass das Preis- Leistungsverhältnis von Video-/Multimediaservern auf Basis von Standardrechnersystemen wesentlich höher ist als bei einem speziell für die Bereitstellung von Videodaten optimierten System. Die öffentlich bekannt gewordenen Anstrengungen zur Lösung der oben erwähnten Beschränkungen waren bisher bescheiden und beschränkten sich auf das Optimieren der Verteilung von Daten auf eine Gruppe von Datenträgern, um den Datenträgerdurchsatz bei Videoserveranwendungen zu maximieren (siehe: H. M. Vin und P. V. Rangan, "Designing a multiuser HDTV storage server", IEEE Journal on Selected Areas in Communications, 11(1), Januar 1993, S. 153-164. D. Kandlur, M. S. Chen und Z. Y. Shae, "Design of a multimedia storage server", in IS&T/SPIE symposium on Electronic Imaging Science and Technology, (San Jose, CA, 1994)), auf die Optimierung der Verfahrensweise beim Puffern der von den Datenträgern abgerufenen Daten, um deren Wiederverwendbarkeit in der Videoserverumgebung zu maximieren (siehe: A. Dan und D. Sitaram, "Buffer management policy for an on-demand video server", IBM Research Report RC 19347. A. Dan und D. Sitaram, "Scheduling policy for an on-demand video server with batching", IBM Research Report RC 19381) oder auf die Optimierung des Dateisystems für Videodaten (siehe: R. Haskin, "The Shark continuous media file server", Proc. IEEE COMPCON 1993 (San Francisco CA, 1993)). Derartige Verbesserungen können das Preis-Leistungsverhältnis heutiger Videoserversysteme um einen Faktor zwei oder vier verbessern; um die interaktiven Multimediadienste ökonomisch tragbar zu machen, sind jedoch Verbesserungen im Bereich von 100 bis 1000 erforderlich.
• Die beiden Patentschriften von Hoarty et al. (US- Patentschriften 5,093,718 und 5,220,420) schlagen die Verwendung von mehreren Servern vor, die jeweils einen kleinen Bereich versorgen und auf die das gesamte Multimediaprogramm geladen wird. Gemäß der vorliegenden Erfindung werden jedoch große Server verwendet, die nur den zu liefernden Videoanteil der Multimediaanwendung auf die Vermittlungsrechner oder Router in einem Netz laden. Die Anwendungssteuerung, d. h. festzulegen, wann und welche Videosequenz wiedergegeben werden soll, obliegt ebenso wie auch die Abrechnung weiterhin den Hilfsfunktionen des Zentralservers.
• Die US-Patentschrift 5,287,507 von Hamilton und Nelson widmet sich dem Problem, das entsteht, wenn ein Client, der einem anderen Client einen Verweis auf eine Information senden will, nicht einen Zeiger auf die im Server gespeicherte Kopie sendet, wodurch die Empfänger-Clients in die Lage versetzt werden, den Zeiger auf die im Server gespeicherte Information zu rekonstruieren, sondern einen Zeiger auf eine im lokalen Speicher des Clients gespeicherte Kopie dieser Information sendet. Das Bereitstellungsschema der vorliegenden Erfindung geht nicht von der Existenz lokaler Cachespeicher aus, so dass diese Patentschrift für die vorliegende Erfindung ohne Bedeutung ist.
• In der US-Patentschrift 5,005,122 von Griffen et al. wird die Verwendung von Serverrechnern in einem Netz vorgeschlagen, das eine große Anzahl von Clientrechnern enthält, um solche Dienste wie Datensicherung, Softwarebereitstellung usw. zu bieten. Sie befasst sich jedoch nicht mit der Konstruktion von Servern für die Bereitstellung von kontinuierlichen Medieninformationen.
• In der US-Patentschrift 5,218,697 von Chung wird ein Verfahren zum Bereitstellen eines zentralen Dateiservers in einem Netz mit heterogenen Dateiservern vorgeschlagen, das unter verschiedenen Betriebssystemen, mit verschiedenen Dateiservern und mit verschiedenen Dateisystemen läuft. Chung legt dar, dass lokale Dateiserver direkt auf das Dateisystem des zentralen Dateiservers zugreifen können, indem sie nicht entsprechend dem herkömmlichen Verfahren eine Dateiserveranforderung an den zentralen Server sendet, der diese dann in einen entsprechenden Dateisystembefehl übersetzen muss, sondern indem sie Dateisystembefehle an ihn senden.
• Die US-Patentschrift 5,287,461 von Moore betrifft ferne Server. Das vorgeschlagene Verfahren besteht darin, die Konsolenleitungen zahlreicher Server zu multiplexen und für die Übertragung der gemultiplexten Informationen zum gewünschten Ort einen Modem zu verwenden.
• In der US-Patentschrift 4,897,781 von Chang et al. wird ein Netzdateisystem beschrieben, in dem Clients einen lokalen Cachespeicher für geöffnete Dateien aufweisen. Die Patentschrift legt ein Verfahren zum Verwenden der von einer Datei bereits im Cache zwischengespeicherten Daten dar, indem mittels eines weiteren Öffnungsbefehls erneut auf dieselbe Datei zugegriffen wird.
• In dem Artikel "Interactive Video on Demand" von Deloddere et al. in IEEE Communications Magazine, Bd. 32, Nr. 5, 1. Mai 1994, S. 82-88, werden ein Überblick über die Kenndaten eines Video-on-Demand-Dienstes (VOD) gegeben und mögliche zu diesem Dienst gehörende Netzarchitekturen und Funktionen beschrieben. Außerdem beschreibt dieser Artikel zwei Ausführungen eines VOD-Dienstes, bei dem die Bandbreitenanforderungen an das Netz stark verringert sind, während die Qualität des Dienstes auf einem hohen Niveau erhalten bleibt. Diese Optimierung wird durch Verwendung von VOD-Servern mit dynamischer Programmsofortkontrolle, verteilten Videopufferverfahren sowie, wenn geeignet, Mehrpunktanschlüssen erreicht.
• Die Veröffentlichung "Asynchronous Transfer Mode - a solution for broadband ISDN" von Martin Prycker (Zweite Auflage, Ellis Horwood, 1993, (Kapitel 3.6, 3.7.5, 4.1)) beschreibt die Grundzüge der ATM-Standards und das Format der ATM-Zellen sowie der AAL PDUs (ATM Adaption Layer Protocol Data Units, Dateneinheiten des ATM-Protokolls der Anpassungsschicht).
ÜBERBLICK OBER DIE ERFINDUNG
• Es ist eine Aufgabe der Erfindung, interaktive Multimediadienste über ein Datenübertragungsnetz zu verringerten Kosten bereitzustellen.
• Eine weitere Aufgabe dieser Erfindung besteht insbesondere darin, den mit dem Bereitstellen von Videoinhalten von einem Server an einen anfordernden Client verbundenen Systemaufwand zu verringern, indem die Videoinhalte auf Vermittlungsrechner des Netzes geladen werden, die die Videoinhalte den anfordernden Clients effizienter bereitstellen können.
• Die vorliegende Erfindung beschreibt ein Verfahren zum Verringern der Kosten für das Bereitstellen von Videodatenströmen um einen Faktor einhundert bis eintausend im Vergleich zu herkömmlichen Lösungen, indem Verbesserungen in das Netz eingeführt werden. Durch die vorgeschlagene Verbesserung können Video-/Multimediainhalte in den Vermittlungsrechnern oder Routern eines Netzes im Format von Netzpaketen gespeichert werden. Der Multimedia- Anwendungsserver überträgt eine Steuernachricht zu dem Vermittlungsrechner oder Router, in dem die Netzpakete für die angeforderten Video- oder Multimedianachrichten gespeichert werden, um eines oder mehrere dieser Pakete zu einem bestimmten Client zu senden. Der diese Informationen empfangende Vermittlungsrechner oder Router öffnet die angeforderten Pakete, ändert die Kopfdaten und eventuell die Fußdaten des Pakets, insbesondere die Routinginformationen, mittels derer das Netz diese Pakete über eine Reihe von Routern und Vermittlungsrechnern zudem bestimmten Client schicken kann, und sendet diese Pakete in das Netz. Um eine große Anzahl von Datenströmen, in der Größenordnung von einigen zehntausend Datenströmen, unterstützen zu können, werden Halbleiterspeicher zum Speichern der vorgepackten Videosequenzen und spezielle Hardware zum Öffnen der Pakete sowie zum Ändernder Kopfdaten verwendet. Siehe hierzu im Folgenden den Videodispatcher in Fig. 4 sowie die Beschreibung der Datenstromsteuerung und des Ausgabeadapters. Der Halbleiterspeicher kann durch Plattenspeicherlaufwerke ergänzt werden, um weniger gefragte Videoinhalte zu speichern. Zum Unterstützen von weniger, also einigen Hundert bis zu wenigen Tausend Datenströmen, können auch Plattenlaufwerke allein verwendet werden, und anstelle der speziellen Hardware zum Öffnen der Pakete und Ändern der Kopfdaten kann ein Mikrocontroller/Mikroprozessor verwendet werden.
KURZBESCHREIBUNG DER ZEICHNUNGEN
• Fig. 1 veranschaulicht schematisch die Datenorganisation in einer Datei eines UNIX-Betriebssystems.
• Fig. 2 veranschaulicht schematisch die Umgebung, in der die Erfindung implementiert ist, sowie das Laden von Daten in die Vermittlungsrechner des Netzes mit Zeigern auf die im Host gespeicherten und zu übertragenden Daten.
• Fig. 2B veranschaulicht schematisch die vorverarbeiteten Pakete, die aus den Videoinhalten abgeleitet werden.
• Fig. 3 veranschaulicht schematisch einen Vermittlungsrechner mit gemeinsamem Puffer, der zum Speichern vorverarbeiteter Pakete angepasst wird.
• Fig. 4 veranschaulicht schematisch den Vermittlungsrechner mit dem zum Speichern der vorverarbeiteten Pakete angepassten gemeinsamen Puffer.
• Fig. 5 veranschaulicht die Details der Videodispatchereinheit des Vermittlungsrechners mit dem angepassten gemeinsamen Puffer.
• Fig. 6 veranschaulicht schematisch das Format der vom Hostprozessor zum Vermittlungsrechner gesendeten Steuernachricht.
• Fig. 7 veranschaulicht den Nachrichtenfluss zwischen dem Client, dem Vermittlungsrechner und dem Hostprozessor.
• Besonders deutlich werden die Anforderungsnachricht vom Client zum Host und die Steuernachricht vom Host zum Vermittlungsrechner gezeigt. Die Übertragung von Videopaketen als Reaktion auf die Steuernachricht vom Vermittlungsrechner zum Client wird ebenfalls gezeigt.
• Fig. 8 ist eine schematische Veranschaulichung des bei dieser Erfindung verwendeten bevorzugten Videospeichers.
• Fig. 9 ist eine schematische Veranschaulichung des angepassten Ausgangsadapters der vorliegenden Erfindung.
• Fig. 10 ist eine schematische Veranschaulichung einer alternativen Ausführungsart der Erfindung, die einen unterschiedlichen Vermittlungsrechner verwendet, welcher keinen gemeinsamen Puffer aufweist.
• Fig. 11 veranschaulicht ein alternatives Verfahren zum Einfügen eines Halbleiterspeichers in den Vermittlungsrechner.
• Fig. 12 veranschaulicht die Verwendung eines Magnetplattenspeichers anstelle eines Halbleiterspeichers.
BESCHREIBUNG DER ERFINDUNG
• In der folgenden Ausführungsart wird die Verwendung von Vermittlungsrechnern zum Laden mit Video-/Multimedia- oder fortlaufenden Medieninhalten beschrieben, jedoch lässt sich die folgende Erörterung leicht auf die Verwendung von Routern/Brücken etc. übertragen, die anstelle von Vermittlungsrechnern stehen. Weiterhin wird zwar die Verwendung eines paketvermittelten Netzes beschrieben, in dem nur Einheiten bestimmter Größe übertragen werden, jedoch kann die folgende Ausführungsart auf die Verwendung in Netzen, in denen Pakete veränderlicher Größe befördert werden, sowie in leitungsvermittelten Netzen übertragen werden. In dieser. Ausführungsart wird ein ATM-Breitbandnetz (Asynchronous Transfer Mode, asynchroner Übertragungsmodus) und eine AAL5- Anpassungsschicht (ATM Adaption Layer, ATM-Anpassungsschicht) verwendet (siehe: Craig Partridgd, "Gigabit Networking", Addison Wesley Publishing Co., Reading, Mass. 01867, ISBN 0- 201-56333-9, Oktober 1993). Und schließlich ist dem Fachmann klar, dass ebenso auch unkomprimierte Videodaten und andere fortlaufende Medieninformationen wie Audiodateien, Animationen usw. ohne Änderungen der Ausführungsart verarbeitet werden können, obwohl in dieser Ausführungsart nur die Bereitstellung von Videodaten beschrieben wird, die in komprimierter Form gespeichert sind. Unterschiedliche Audio- oder Videodaten können unterschiedlich stark komprimiert werden. Beispielsweise kann Musik mit einer höheren Bitrate (geringeres Komprimierungsverhältnis) als Sprache komprimiert werden.
• Ein fortlaufender Medienstrom kann auch aus mehreren Strömen unterschiedlicher Medientypen bestehen, die zu einem MPEG-II- Transportstrom (Motion Picture Expert Group, Filmexpertengruppe) gemultiplext werden. Bei der hier vorliegenden Ausführungsart wird der MPEG-II-Transportstrom verwendet, der als Videoinhalt einen Video- und einen Audiokanal überträgt. Es soll angenommen werden, dass jede Sekunde dieses Videos auf 4 Megabit digitale Daten komprimiert wird.
• Die Ausführungsart der vorliegenden Erfindung weist zwei einzelne Komponenten auf, die erste besteht im Übertragen von Videoinhalten vom Host oder Anwendungsserver zu den Vermittlungsrechnern im Netz, und die zweite besteht in der Vermittlungshardware, die Videoinhalte speichern und auf Anweisung des Hosts an die angegebenen Clients senden kann. Im Folgenden wird eine Beschreibung des Formats, in dem Videoinhalte im Netz gespeichert werden, sowie der zusätzlichen Daten gegeben, die zusammen mit den Videoinhalten gespeichert werden, um für das Abrufen und Senden zu den Clients mit möglichst wenig Hardware in den Vermittlungsrechnern auszukommen. Im Folgenden werden auch die in einem Vermittlungsrechner mit gemeinsamem Puffer erforderlichen Hardwareänderungen/-ergänzungen beschrieben, die zum Speichern in dem Halbleiterspeicher erforderlich sind, um die Arbeitsschritte zum Zuordnen und Wiederherstellen dieses Speichers auszuführen und auf Anforderung durch den Host das Abrufen und Senden von Videoinhalten zu unterstützen. Im letzten Abschnitt werden kurz einige alternative Ausführungsarten für dieselben Erfindungen dargestellt, bei denen Vermittlungsrechner ohne gemeinsamen Puffer als Netzvermittlungsrechner sowie Plattenspeicher anstelle des Halbleiterspeichers verwendet werden.
ÜBERTRAGEN VON VIDEOINHALTEN VOM HOST ZU DEN VERMITTLUNGSRECHNERN IM NETZ
• In den Fig. 1 und 2 umfasst der erste Schritt der vorliegenden Erfindung das Übertragen der Videoinhalte 900 (Fig. 2B) in die Vermittlungsrechner 60 (Fig. 2A) eines ATM- Breitbandnetzes 50. Der MPEG-II-Transportstrom für ein einstündiges Programm beträgt ca. 1,8 Gigabyte an digitalen Daten 900. Wenn diese Daten 900 in einem unter einem UNIX- ähnlichen Betriebssystem laufenden Mehrzeckcomputer gespeichert werden, werden diese in 4 KByte umfassende Seiten 901 (Fig. 1) eingeteilt und vielleicht auf einer Magnetplatte in Form von ca. 450 000 Datenblöcken 910 gespeichert, wobei jeder Datenblock 4 KByte umfasst. Zusätzlich zu diesen Datenblöcken, die die Videoinhalte darstellen, werden auf der Platte noch weitere Daten gespeichert, wie die Dateiindizes 911 und die indirekten Blöcke 912, die gemeinsam unter der Bezeichnung Metadaten bekannt sind. (Siehe: M. J. Bach, "The design of the Unix operating system", Prentice Hall Inc., Englewood Cliffs, NJ 07632, ISBN 0-13-201799-7 025, 1986.) Diese in Fig. 1 gezeigten Metadaten werden getrennt von den Videoinhalten gespeichert, d. h. in Plattenblöcken, in denen keine Videoinhalte gespeichert sind. Diese Metadaten werden durch das Betriebssystem dazu verwendet, die zu einer bestimmten Videodatei gehörenden Seiten sowie ferner Seiten zu suchen, in denen ein bestimmter Datenbereich der Videodatei gespeichert ist.
• In Fig. 7 ist eine vom Client 20 über die Vermittlungsrechner 60 des Netzes zum Host 10 gesendete Anforderungsnachricht 6 gezeigt. Diese Anforderungsnachricht ist vorzugsweise ein durch einen Client getätigter Fernprozeduraufruf, der mit mehreren Parametern die Videobereitstellungsprozedur im Host auslöst. Der erste Parameter der Anforderungsnachricht ist der Name oder Index der durch den Client angeforderten Videodatei, die zuvor während der Ausführung einer in einer verteilten Rechnerumgebung auf den Clients und den Servern laufenden interaktiven Multimediaanwendung aus einer vom Server dem Client zur Verfügung gestellten Liste von verfügbaren Videodateien ausgewählt wurde. Ein zweiter Parameter in der Anforderungsnachricht gibt eine Zeitspanne bezogen auf den Anfang der Videodatei an, nach der das Abspielen der Videodatei beginnen soll. Ein dritter Parameter in der Anforderungsnachricht gibt eine Zeitspanne an, entweder bezogen auf den Anfang der Videodatei oder auf den verzögerten Startzeitpunkt, nach der das Abspielen der Videodatei beendet sein soll. Ein weiterer Parameter gibt an, ob sich die Zeitspanne im dritten Parameter auf den Anfang der Videodatei oder auf den Startzeitpunkt der Wiedergabe bezieht. Die Zeitspannen im zweiten und im dritten Parameter können als Zeitdauer oder als Anzahl von Datenbytes angegeben werden. Die Fernprozeduraufrufe sind in der Technik gut bekannt; daher werden die Anforderungsnachrichten in diesem Dokument nicht näher erörtert. (Siehe: W. Rosenberry et al., "Understanding DCE", O'Reilley and Associates Inc., 103 Morris Street, Suite A, Sebastopol, CA 95472, ISBN 1-56592-005-8, September 1992, das durch Bezugnahme einbezogen wird.) Der Host verarbeitet die Anforderungsnachricht und ermittelt, wie unten beschrieben, ob die angeforderten Videoinhalte in einem der Netzvermittlungsrechner gespeichert sind. Wenn dies der Fall ist, sendet der Host Steuernachrichten 8 an die Vermittlungsrechner, in denen die angeforderten Daten enthalten sind; siehe Fig. 2 und 6. Als Reaktion auf die Steuernachrichten rufen die Vermittlungsrechner die in den Steuernachrichten angegebenen Videopakete ab und liefern diese Pakete zum Client.
• Fig. 2A veranschaulicht schematisch eine Prinzipskizze des Systems der vorliegenden Erfindung, das den Host 10, Clients 20 und das Netz 50 mit einer Vielzahl von Vermittlungsrechnern 60 umfasst. Um die Videoinhalte 900 (siehe Fig. 1) vom Host oder vom Anwendungsserver zu übertragen, der üblicherweise ein Mehrzweckcomputer ist, werden die Videoinhalte 900 zum Erzeugen der Videonachrichten 920 in Nutzdatenpakete 915 mit festgelegter Größe aufgeteilt (siehe Fig. 2B). Die Größe der Nutzdatenpakete beträgt üblicherweise 1 KByte bis 16 KByte, wobei in der vorliegenden Ausführungsart eine Größe von 1528 Byte gewählt wurde. Ein Nutzdatenpaket dieser Größe passt, wie in Fig. 2B gezeigt, in 32 ATM-Zellen 930. Jedes Nutzdatenpaket im Host oder im Anwendungsserver wird durch einen Zeiger 925 ersetzt, der eine Netzvermittlungsrechneradresse 926 und die Adresse der Nachricht 927 im Vermittlungsrechner umfasst (siehe Fig. 2A). Die Größe jedes dieser Zeiger liegt erwartungsgemäß zwischen 8 und 16 Bytes. Die Videonachricht 920 selbst, die im Host jetzt durch einen Zeiger 925 repräsentiert wird, ist in dem durch die Komponente 926 des Zeigers für die Vermittlungsrechneradresse definierten Vermittlungsrechner 60 gespeichert, und zwar an der im Zeiger angegebenen Nachrichtenadresse, wie in Fig. 2A gezeigt ist.
• Da sich eine im Host befindliche Datei, die Videoinhalte 900 enthält, von einer Datei unterscheidet, die die Zeiger 925 auf die in den Vermittlungsrechnern des Netzes gespeicherten Videonachrichten enthält, und der Host diese Dateien unterschiedlich behandeln muss, bedient sich der Host einer Namensgebung, um allen Dateien mit Videoinhalten 900 einen Dateityp und allen die Zeiger auf die im Netz gespeicherten Videonachrichten enthaltenden Dateien einen anderen Dateityp zuzuweisen. Alternativ kann der Host eine Tabelle speichern, in der alle Videodateien aufgeführt sind und in der ein Eintrag anzeigt, ob die Datei Videoinhalte oder eine Liste von Zeigern auf die in den Vermittlungsrechnern des Netzes gespeicherten Videonachrichten enthält.
• Vor dem Speichern der Videoinhalte in einem Vermittlungsrechner des Netzes wird an jedes Nutzdatenpaket 915 ein Trailer 931 der ATM-AAL5-Konvergenzunterschicht angehängt, und die entstehenden Bytes werden zu einer Videonachricht 920 umformatiert, die, wie in Fig. 2B gezeigt, eine Folge von ATM-Zellen 930 umfasst (in ATM-Netzen werden die Netzpakete als Zellen bezeichnet). Auch in einem nicht ATM-paketvermittelten Netz wird erforderlichenfalls eine Segmentierung durchgeführt, nachdem der Transportschichtheader/-trailer an die Nachricht angehängt wurde, und der Netzschichtheader und/oder -trailer wird an die Segmente angehängt, bevor diese im Vermittlungsrechner gespeichert werden.
• Die Felder in den Netz-/Transport-/Anpassungsschichtheadern oder -trailern, die zum Zeitpunkt des Speicherns der Pakete im Vermittlungsrechner vorausberechnet werden können, werden vorausberechnet und an entsprechenden Stellen in den ATM- Zellen gespeichert. Im vorliegenden Fall weist das letzte Paket jeder Nachricht einen Konvergenzunterschichttrailer (convergence sublayer, CSL) 931 mit einer Größe von 8 Byte auf, bei dem die Nachrichtenlänge und die Prüfsummenfelder vorausberechnet und die Felder für die Benutzer-Benutzer- Meldung (user-to-user indication, UU) sowie für die Meldung Gemeinsamer Anteil (common part indication, CPh) auf Null gesetzt werden, bevor die Nachricht im Vermittlungsrechner gespeichert wird. Diese vier Felder bilden den gesamten ATM- AAL5/CSL-Trailer (Convergence Sub-Layer, CSLY. In dem fünf Byte langen Header 935 jeder ATM-Zelle kann nur das letzte halbe Byte vorausberechnet werden. Diese vier Bits umfassen die Zellverlustpriorität und den Typ des Nutzdatenpakets, wobei der Typ des Nutzdatenpakets auch das 1-Bit-Ende des Datenpaketfeldes für die AAL5-SAR-Schicht (Segmentation and Reassembly, Segmentierung und Neuerstellung) enthält. Die ATM- Zellen 930 mit den, wie oben erläutert, teilweise vorausberechneten Headern/Trailern umfassen die vorverarbeiteten Videopakete.
• Eine Videonachricht 920 stellt die Grundeinheit der Flusssteuerung im Netz und folglich die Grundsteuerungseinheit für den Zugriff auf Videospeicher sowie für die Übertragung von Videodaten zum Client dar. Wenn eine aus dem Videospeicher abgerufene ATM-Zelle nicht die letzte Zelle einer Videonachricht ist, legt der Vermittlungsrechner automatisch den Abruf der nächsten Zelle in der Videonachricht fest. Der Client empfängt die ATM-Zellen einer Videonachricht blockweise, da der Vermittlungsrechner zur Steuerung der Übertragungsrate zwischen die Übertragungen zweier ATM-Zellen einer Videonachricht keine Pausen einschiebt. Um bei interaktiven Multimediaanwendungen kurze Antwortzeiten zu gewährleisten und den Pufferspeicherbedarf beim Client zu minimieren, muss der Umfang der Videonachricht begrenzt werden, damit das Netz effizient arbeiten kann. Bei kurzen Videonachrichten können jedoch häufige Interaktionen zwischen dem Host und den Vermittlungsrechnern erforderlich sein, was wiederum leistungsfähigere (und damit teurere) Hosts sowie mehr Hardware in den Vermittlungsrechnern bedingt, um die erhöhte Anzahl von Steuernachrichten zu verarbeiten.
• Das oben genannte Problem wird dadurch gelöst, dass der Vermittlungsrechner in die Lage versetzt wird, als Reaktion auf eine einzelne vom Host empfangene Steuernachricht mehrere Videonachrichten zum Client zu übertragen. Um diese Fähigkeit zu unterstützen, müssen für jede Videonachricht weitere Daten erzeugt und gemeinsam mit der Videonachricht im Netzvermittlungsrechner gespeichert werden. Diese Daten bestehen aus dem Verknüpfungsfeld 940 und dem Flusssteuerungsfeld 950; siehe Fig. 2B. Das Verknüpfungsfeld in jeder Videonachricht 920 eines Videodatenstroms 900 zeigt auf die nächste Videonachricht dieses Datenstroms. Auf diese Weise kann der Host oder Anwendungsserver eine Steuernachricht an einen Vermittlungsrechner senden, indem er die Adresse der Startnachricht und die Anzahl der danach zu sendenden Nachrichten angibt, so dass der Vermittlungsrechner mittels des Verknüpfungsfeldes 940 die nachfolgenden Nachrichten abrufen kann. Das Flusssteuerungsfeld enthält, bezogen auf einen festen Startzeitpunkt, die Abspieldauer der nächsten Videonachricht. Dadurch kann der Vermittlungsrechner zwischen die Übertragungen zweier Videonachrichten desselben Datenstroms die richtige Verzögerungsdauer einfügen, um die richtige Datenrate für die Bereitstellung des Videos zum Client einzuhalten.
ANGEPASSTE HARDWARE DES VERMITTLUNGSRECHNERS UND DEREN ARBEITSWEISE
• In diesem Abschnitt werden zuerst kurz der Aufbau eines 1 Vermittlungsrechners mit gemeinsamem Puffer, der die Grundlage der vorliegenden Ausführungsart bildet, und dessen Arbeitsweise besprochen. Dann werden die Anpassungen beschrieben, die dem Vermittlungsrechner die Fähigkeit verleihen, Videos zu speichern und bestimmte Videopakete auf Anweisung durch den Host an bestimmte Clients zu senden. Wenn zuerst der Vermittlungsrechner ohne Anpassung beschrieben wurde, so bezieht sich das nicht direkt auf diese bevorzugte Ausführungsart; der Zusammenhang mit dieser Ausführungsart wird jedoch aus der folgenden Beschreibung der angepassten Version des Vermittlungsrechners klar.
EIN VERMITTLUNGSRECHNER MIT GEMEINSAMEM PUFFER
• Fig. 3 zeigt die Systemarchitektur eines Vermittlungsrechners mit gemeinsamem Speicher. Zentraler Bestandteil ist ein großer gemeinsamer Speicher 400 mit einem Eingangsbus 300 zum Einschreiben von Daten in den Speicher sowie einen Ausgangsbus 350 zum Lesen von Daten aus dem Speicher. Bei der vorliegenden Ausführungsart besitzen sowohl der Eingabebus 300 als auch der Ausgabebus 350 eine Breite von 53 Bytes, was der Größe einer ATM-Zelle entspricht. Die auf jeder der seriellen Hochgeschwindigkeitsleitungen 100 ankommenden Pakete (ATM- Zellen) werden in einem Eingangsadapter 200 verarbeitet, um die Kopfdaten (Header) der ATM-Zelle daraufhin zu prüfen, zu welchem Ausgang 150 des Vermittlungsrechners das Paket geleitet werden soll, und die Adressfelder VPI (Virtual Path Identifier, Virtueller Pfadkennzeichner) und VCI (Virtual Circuit Identifier, Virtueller Schaltungskennzeichner) der Zelle gemäß den ATM-Netzverfahren auszutauschen. Nach diesem Verarbeitungsschritt setzt der Eingangsadapter 200 das bitserielle Paket in ein einziges 53 Bytes breites Wort um und legt dieses auf den Eingabebus 300; gleichzeitig legt er auf den Ausgangsadressbus 310 die Adresse des Vermittlungsrechnerausgangs 150, zu dem dieses Paket übertragen werden soll. Das Paket wird daher im gemeinsamen Speicher 400 an einem Ort gespeichert, den der Controller 500 selbstständig festlegt. Die Busbandbreite stimmt mit der Gesamtbandbreite aller ankommenden Leitungen überein. Der gemeinsame Speicher 400 ist als Matrix von 53-Byte-Wörtern 410 aufgebaut, d. h. die Grundeinheit der Datenübertragung für Lese- und Schreiboperationen beträgt 53 Bytes, was der Größe einer ATM-Zelle entspricht. Um das Verständnis der nachfolgenden Erörterung zu erleichtern, werden diese 53-Byte- Wörter im gemeinsamen Speicher als Zellen bezeichnet. Jede Ausgangsleitung 150 weist einen zu dieser Leitung gehörenden Ausgangsadapter 250 auf. Die Adapter 250 für alle Ausgangsleitungen sind, ähnlich dem durch die Eingabeadapter 200 gemeinsam genutzten Bus 300, über den Bus 350 im Zeitmultiplexbetrieb mit dem gemeinsamen Speicher verbunden.
• Durch den Steuerbereich 500 wird im gemeinsamen Speicher 400 eine Liste der freien Zellen verwaltet. Diese Liste wird in der FIFO-Warteschlange (First-In, First-Out) 510 gespeichert. Jede Ausgangsleitung 150 weist eine zu ihr gehörende FIFO- Warteschlange 520 im Steuerbereich 500 auf. Diese Warteschlangen unterscheiden sich logisch voneinander, können jedoch mittels eines einzigen physischen Speichers realisiert werden. Die Warteschlange 520 speichert die Adressen der ATM- Zellen, die der entsprechende Ausgangsadapter aus dem gemeinsamen Speicher abrufen und in das Netz stellen muss. Um ein ankommendes Paket im gemeinsamen Speicher zu speichern, wird aus der Liste der freien Zellen 510 die Adresse einer freien Zelle geholt und auf den Schreibadressbus 530 gelegt. Gleichzeitig wird diese Adresse aus der Warteschlange der Liste der freien Zellen 510 gelöscht und in die durch den Ausgangsadressbus 310 ausgewählte Adresswarteschlange 520 eingefügt; auf diesem Ausgangsadressbus liegt die Adresse des Vermittlungsrechnerausgangs 150 vor, zu dem das Paket gesendet wird. Die Ausgangsadapter 250 löschen die Adressen der im gemeinsamen Speicher gespeicherten Pakete, die zu ihren Ausgangsleitungen 150 übertragen werden sollen, aus ihrer entsprechenden Adresswarteschlange 520 im zentralen Controller 500, lesen das Paket aus dem gemeinsamen Speicher, wandeln es in serielle Form um und transportieren es über die Leitung 150. Die aus der Adresswarteschlange 520 gelöschte Paketadresse wird auf den Leseadressbus 540 gegeben und gleichzeitig wieder in die Liste der freien Zellen 510 aufgenommen.
• Die Bandbreite des Eingabebusses 300 ist gleich der Gesamtbandbreite aller ankommenden Leitungen 100. Daher brauchen für den Eingabebus 300 keine Prioritäten festgesetzt zu werden. Statt dessen wird der Bus segmentweise betrieben, wobei jeder der N Eingabeadapter während jedes N-ten Segments auf den Bus zugreift. In der vorliegenden Ausführungsart ist ein Segment ein Taktzyklus. Der Ausgangsbus 350 wird ähnlich betrieben, und die Eingangs- und Ausgangsbusadapter treten mit dem zentralen Controller nur während desjenigen Taktzyklus in Verbindung, in dem sie Zugriff auf die Eingangs- oder Ausgangsbusse erlangen. In jedem Eingangsadapter 200 ist auch ein Mikroprozessor 210 und in jedem Ausgangsadapter 250 ein Mikroprozessor 260 gezeigt. Diese dienen zum Ausführen verschiedener Funktionen zur Leitungsüberwachung und Dienstfunktionen, wobei die Mikroprozessoren in den Eingangsadaptern auch zur Verwaltung der Routingtabellen dienen. Sie werden vorteilhaft auch in den folgenden Erörterungen über die Steuerung der vom Vermittlungsrechner gelieferten Videodatenströme verwendet. Der Steuerpunkt 600 ist eine Workstation oder ein Mehrzweck-PC, der zum Ausführen von Netzverwaltungsfunktionen wie der Verwaltung der Datenbank, welche die Topologie, die Leitungszustände und die Leitungsbelegungen des gesamten Netzes umfasst, zum Zuordnen von Bezeichnungen für neu eingerichtete Schaltungen sowie zum Initialisieren und Überwachen der Mikroprozessoren 210 und 260 dient. Auch dies wird vorteilhaft in den folgenden Erörterungen über die Zuordnung und Wiederherstellung des zum Speichern der Videoinhalte verwendeten Speichers verwendet.
• Und schließlich wird der Vermittlungsrechner mit gemeinsamem Puffer der einfacheren Erörterung wegen so beschrieben, dass er separate Eingangs- und Ausgangsadapter mit je einem Mikroprozessor sowie separate Eingangs- und Ausgangsbusse aufweist. Bei einer kompakten Ausführungsart können diese beiden Adapter auf einer einzigen Karte zusammengefasst werden, wobei die einen Mikroprozessoren beide Adapter versorgen; ferner könnten die Eingangs- und Ausgangsbusse durch einen einzelnen Bus ersetzt werden, der die doppelte Bandbreite der Eingangs- und Ausgangsbusse besitzt.
VERMITTLUNGSRECHNER MIT GEMEINSAMEM PUFFER, DER ZUM SPEICHERN VON VIDEOS UND ZU DEREN LIEFERUNG AN DIE CLIENTS NACH EMPFANG EINER ANWEISUNG VOM HOST ANGEPASST IST
• Fig. 4 veranschaulicht die im Vermittlungsrechner mit gemeinsamem Puffer erforderlichen Hardware-Anpassungen, die ihn in die Lage versetzt, Videonachrichten 920 zu speichern und nach dem Empfangen einer entsprechenden Steuernachricht 8 vom Host 10 eine bestimmte Gruppe von Nachrichten zu einem bestimmten Client 20 zu liefern. Um die ATM-Zellen 930 einer Videonachricht im Vermittlungsrechner mit gemeinsamem Puffer in Fig. 4 zu speichern, wird der gemeinsame Puffer 400 durch einen Videospeicher 700 erweitert. Der gemeinsame Puffer 400 und der Videospeicher 700 benutzen gemeinsam die Eingangs- und Ausgangsbusse sowie den Adressbus und die Schreibaktivierungssteuerung. Das Verknüpfungsfeld 940 und das Taktsteuerungsfeld 950 werden gesondert in einem Befehlsspeicher 810 gespeichert, der im Videodispatcher 800 untergebracht ist, siehe Fig. 4 und 5.
• Fig. 5 zeigt den Videodispatcher 800 etwas genauer. Er kann ATM-Zellen direkt vom Host 10 empfangen, die die Steuernachricht 8 umfassen (Fig. 6 und 7). Diese Steuernachrichten werden vom Eingangsbus 300 mittels der Schnittstellenlogik 870 empfangen, wenn ein Eingangsadapter 200 das Signal 717 aktiviert. Jede Steuernachricht 8 gibt, wie in Fig. 6 gezeigt, die Adresse der ersten ATM-Zelle in einer Gruppe von Videonachrichten, den für die Lieferung der ersten Videonachricht in der Gruppe vorgesehenen Zeitpunkt, die Anzahl dei Videonachrichten in der Gruppe, eine Ausgangsadapteradresse und eine Datenstromnummer an und fordert den Videodispatcher auf, vom zentralen Controller 500' die Lieferung aller ATM-Zellen in der Gruppe zum angegebenen Ausgangsadapter 250' zu verlangen, indem sie zu einem bestimmten Zeitpunkt eine Anförderung nach einer ATM-Zelle an den zentralen Controller 500' ausgibt. Die Anforderung zum Lesen der ATM-Zelle wird zu den in der Steuernachricht angegebenen Zeitpunkten durch den Scheduler 815 über den Multiplexer 820 in die Sendewarteschlange 825 eingestellt. Der Videodispatcher empfängt über den Bus 270 auch entsprechende, nicht in ATM-Zellen eingebundene Anweisungen von den Mikroprozessoren 260 in den Ausgangsadaptern 250', wobei die Anweisungen über die Schnittstellenlogik 871 in den Videodispatcher gelangen. Ebenso wie beim zentralen Controller treten die Eingangs- und Ausgangsadapter nur in dem Zyklus mit dem Videodispatcher in Verbindung, in dem sie auf den Eingangsbus 300 oder den Ausgangsbus 350 zugreifen; daher brauchen auf den Bussen 270, 271 sowie auf dem Bus 717 keine Prioritäten festgelegt werden; die Verwendung des Busses 717 wird später eingehend erörtert. Sobald dem Videodispatcher der Lieferzeitpunkt der ersten Nachricht einer Nachrichtengruppe mitgeteilt wurde, kann der Lieferzeitpunkt jeder der übrigen Nachrichten aus dem Datenflusssteuerfeld der vorigen im Befehlsspeicher gespeicherten Nachricht entnommen werden.
• Der Videodispatcher weist eine FIFO-Dispatchwarteschlange 825 auf, in der die Leseanforderungen für ATM-Zellen aus dem Videospeicher gespeichert werden, welche aufgrund der Konfliktsituation seitens der Eingangsadapter 200 für die Adresswarteschlangen 520 nicht sofort in den zentralen Controller 500' aufgenommen werden können. Jeder Eintrag in der Versendewarteschlange 825 weist drei Felder auf: das Ausgangsadapteradressfeld 826 zeigt an, welcher Ausgangsadapter 250' die nach der Anforderung aus dem Videospeicher 700 gelesene Zelle empfängt, das Datenstrom-ID- Feld 827 bezeichnet den Videodatenstrom in dem im Feld 826 angegebenen Adapter, für den die Zelle gelesen wird, und das Videospeicheradressfeld 828 gibt die Adresse der zu lesenden Zelle im Videospeicher an. Wenn ein Bit auf der Leitung 315 des Ausgangsadressbusses 310 in Fig. 4 inaktiv ist und somit anzeigt, dass kein Eingangsadapter mit dem zentralen Controller in Verbindung steht, wird ein Eintrag aus der Versendewarteschlange 825 entfernt. Der Inhalt des Ausgangsadapteradressfeldes 826 wird auf den Bus 745 geschickt, um die Adresswarteschlange 520 im zentralen Controller auszuwählen. Die übrigen Felder, nämlich das Datenstrom-ID-Feld 827 und das Videospeicheradressfeld 828 werden auf den Bus 725 geschickt, dort mit den Eingängen in die Adresswarteschlange 520 gemultiplext und in der durch die Adresse auf dem Bus 745 ausgewählten Adresswarteschlange 520 gespeichert.
• Der Videodispatcher überwacht auch die Adressen aller aus dem Videospeicher gelesenen Zellen sowie die zugehörigen Ausgangsadapter und Datenstrom-IDs auf dem Bus 540 in der Zelladressenüberwachung 850. Durch die Leitung 851 soll angezeigt werden, dass eine Zelle aus dem Videospeicher gelesen wurde. Wenn die soeben aus dem Videospeicher gelesene Zelle nicht die letzte Zelle der Nachricht ist, wird durch Erhöhen der Zelladresse im Inkrementer 855 eine neue Anforderung generiert und diese über den Multiplexer 820 zur Versendewarteschlange 825 gesendet. Wenn die aus dem Videospeicher gelesene Zelle die letzte Zelle der Nachricht ist, werden das Leitungssteuerfeld und das Datenflusssteuerfeld dieser Nachricht aus dem Befehlsspeicher gelesen und zusammen mit der vom Bus 540 empfangenen Datenstrom-ID zum Ausgangsadapter 250' gesendet. Diese Daten werden auf dem Bus 271 gesendet und sollen den, im Adapter befindlichen Mikroprozessor 260 dazu bringen, eine neue Nachricht vom Videospeicher anzufordern.
• Um mit dem Videodispatcher 800 und den Eingangsadaptern 200 zum Laden von Videoinhalten in Verbindung zu treten, wird der zentrale Controller 500 wie folgt angepasst (500' in Fig. 4). Zwischen die Liste der freien Zellen 510 und die Adresswarteschlangen 520 wird ein Multiplexer 720 geschaltet. Ein Eingang dieses Multiplexers ist der Bus 530, auf dem die Adresse der freien Zelle im gemeinsamen Puffer 400 übertragen Wird, die während des aktuellen Zyklus durch einen Eingangsadapter geschrieben wird und in die durch den Ausgangsadressbus 310 angegebene Adresswarteschlange 520 gestellt werden muss. Der ändere Eingang ist der Bus 725 vom Videodispatcher 800, auf dem die Adresse einer Zelle im Videospeicher sowie eine Datenstromkennnummer übertragen werden, welche beide in die durch den Bus 745 angegebene Adresswarteschlange 520 eingeordnet werden müssen. Ein Bit auf der Leitung 315 des Ausgangsadressbusses 310 zeigt an, dass die Ausgangsadresse gültig ist, und dient dazu, dem Bus 530 eine höhere Priorität zu verleihen, und steuert daher den Multiplexer 720. Das Bit 315 steuert auch den Adressmultiplexer 740 im zentralen Controller, um die Ausgangsadresse 310 zu verwenden, wenn der Bus 530 ausgewählt wird, und die durch den Videodispatcher auf dem Bus 745 generierte Adresse zu verwenden, wenn der in der Adresswarteschlange 520 zu speichernde Inhalt durch den Bus 725 ausgewählt wird. Es muss erwähnt werden, dass dem Videodispatcher in der aktuellen Ausführungsart das Schreiben in die Adresswarteschlange 520 auch dann verwehrt wird, wenn der Inhalt von Bus 530 in eine andere Adresswarteschlange 520 geschrieben werden soll. Durch Bereitstellen einer komplexeren Logikschaltung kann dieser Nachteil umgangen werden. Aus der Adresswarteschlange 520 entfernte Adressen werden nur dann wieder in die Liste der freien Pufferadressen 510 aufgenommen, wenn es sich um die Adressen des gemeinsamen Puffers 400 handelt. Die Steuerlogik 730 prüft, ob sich die Adresse auf dem Bus 540 im Bereich der Adressen für gemeinsame Puffer befindet und gestattet nur der Adresse in diesem, Bereich die Aufnahme in die Liste der freien Zellen 510. Da die Adressen für den Videospeicher 700 wesentlich mehr Bits aufweisen als die Adressen für den gemeinsamen Puffer 400 und durch eine Videodatenstromnummer gekennzeichnet sind, werden die Adresswarteschlangen 520 und der Bus 540 erweitert.
LADEN DES VIDEOSPEICHERS AUS DEM HOST
• Um Daten aus dem Eingangsadapter 200 in den Videospeicher 700 zu laden, wird ein Ladeadressbus 760 zusammen mit einem Steuerbit 761 verwendet. Der Mikroprozessor 210 in einem Eingangsadapter 200 empfängt Nachrichten vom Host, um eine Folge von in der Nachricht enthaltenen ATM-Zellen zu laden; dies beginnt mit einer Adresse im Videospeicher, die auch in der Nachricht angegeben ist. Als Reaktion darauf werden die ATM-Zellen auf den Eingangsbus 300 und die für sie im Videospeicher vorgesehene Speicheradresse auf den Ladeadressbus 760 geschickt und das Steuerbit 761 aktiviert. Das Steuerbit 761 steuert den Multiplexer 710 im zentralen Controller 500', sodass die Schreibadresse 532 für den Videospeicher nicht aus der Liste der freien Zellen auf dem Bus 530, sondern aus dem Ladeadressbus 760 ausgewählt werden kann. Bei aktivem Steuerbit 761 ist das Steuerbit 315 inaktiv, wodurch der Videodispatcher auf die Adresswarteschlange 520 zugreifen kann.
• Der im Vermittlungsrechner mit gemeinsamem Puffer als Steuerpunkt verwendete Mehrzweckcomputer 600' fungiert auch als Videospeichermanager, um den Videospeicher zuzuweisen und wiederherzustellen. Der Hostrechner oder Anwendungsserver steht im Dialog mit dem Videospeichermanager, um einen Block des freien Videospeichers anzufordern oder einen Block des Videospeichers wieder freizugeben. Wenn der Videospeichermanager einem Host einen Block des Videospeichers zuweist und dem Host den Adressbereich dieses Blocks mitteilt, kann der Host, wie im vorigen Abschnitt erläutert, ohne weitere Beteiligung des Videospeichermanagers den ihm zugewiesenen Videospeicher direkt beschreiben. Der Befehl vom Host zum Beschreiben des Videospeichers 700 kann direkt an den Mikroprozessor 210 oder indirekt über den Steuerpunktprozessor 600' gesendet werden, der den Befehl dann an den Mikroprozessor 210 weiterleitet.
• Da der Videospeichermanager ein Mehrzweckcomputer ist, kann die Kommunikation zwischen ihm und dem Host mittels beliebiger zuverlässiger Standardtransportprotokolle abgewickelt werden, wobei die gewünschten Sicherheits- und Berechtigungsmaßnahmen eingesetzt werden können. Die Nachrichten vom Host an die Mikroprozessoren 210 in den Eingangsadaptern 200 können auch auf sicheren Leitungen bereitgestellt werden, wobei die Verteilung der Schlüssel durch den Videospeichermanager und die Entschlüsselung der Nachrichten in den Mikroprozessoren selbst erfolgt. Die beiden üblichen vom Host zum Mikroprozessor 210 gesendeten Nachrichtentypen besagen, dass der Videospeicher geladen und Befehle zum Videodispatcher gesendet werden sollen. Wenn diese Befehlsnachrichten entsprechende Informationen zur Empfangsbestätigung enthalten, kann der Mikroprozessor 210 so programmiert werden, dass er eine Bestätigung zum Host zurücksendet. Die Aufteilung des Videospeichers kann ohne Komprimierung erfolgen, indem das Buddysystemverfahren verwendet wird, das für die Hauptspeicheradressierung in Mehrprogrammcomputern vorgeschlagen wurde.
Bereitstellen von Videodaten aus dem Videospeicher für den Endbenutzer
• Die vom Host zum Verteilen einer Gruppe von Videonachrichten gesendete Steuernachricht 8 wird, wie oben beschrieben, durch den Eingangsadapter 200 abgefangen, der diesen Befehl dann zum Videodispatcher 800 weiterleitet. Der Videodispatcher sendet für jede ATM-Zelle in dieser Gruppe von Videonachrichten eine gesonderte Anfrage an den zentralen Controller, diese zu lesen und zum richtigen Ausgangsadapter zu liefern. Die Ausgangsadapter müssen die VPI/VCI-Felder in den Kopfdaten der aus dem Videospeicher gelesenen ATM-Zellen ausfüllen, bevor diese Zellen zur Ausgangsleitung 150 gesendet werden (siehe unten).
• Wenn eine ATM-Zelle aus dem Videospeicher 700 gelesen und zu einem Ausgangsadapter 250' geliefert wird (siehe Fig. 9), empfängt der Videodispatcher die Datenstrom-ID dieser, Zelle vom Bin 540 und leitet sie auf dem Bus 271 zum entsprechenden. Ausgangsadapter weiter. Gemeinsam mit der Datenstrom-ID werden auch die Datenflusssteuerungs- und Verknüpfungsfelder 940 und 950 gesendet, wenn die zu dem Ausgangsadapter gelieferte ATM- Zelle die letzte Zelle einer Videonachricht ist. Der Ausgangsadapter vervollständigt, wie unten beschrieben, die gleichzeitig vom Videospeicher empfangenen Kopfdaten der ATM- Zelle.
• Der Ausgangsadapter kann eine Rückmeldung zum Host erzeugen, um die erfolgreiche Übertragung von Videonachrichten zu bestätigen. Um dies in großen Servern erfolgreich zu implementieren, muss diese Bestätigung unter Verwendung der Rückmeldeadresse und anderer notwendiger Informationen aus der Datenstromsteuertabelle in Hardware erzeugt werden, es sei denn, die Anzahl der ATM-Zellen in einer Nachrichtengruppe ist groß genug und daher die Häufigkeit der Rückmeldungen niedrig genug, dass sie durch den Mikroprozessor 260 bewältigt werden kann.
• In der bevorzugten Ausführungsart ist, der gemeinsame Puffer 400 durch SRAM-Module (Static Random Access Memory, Statischer Arbeitsspeicher) implementiert. Da der Videospeicher jedoch viel größer als der gemeinsame Puffer ist, kann er aus Kosten-, Energie- und Platzgründen nicht in der SRAM- Technologie ausgeführt werden (der gemeinsame Puffer besitzt einen Umfang von einigen Megabytes, während die Größe des Videospeichers im Bereich von Hundert Gigabytes liegt). Deshalb wird der Videospeicher 700, wie in Fig. 8 gezeigt, mittels DRAM-Modulen (Dynamic Random Access Memory, Dynamischer Arbeitsspeicher) implementiert. Vorzugsweise werden vier bis 16 DRAM-Module eingesetzt, die eine Breite von je 53 Bytes besitzen. Bei der vorliegenden Ausführungsart werden 4 Module eingesetzt. Da DRAM-Module im Gegensatz zu, SRAMs über keine separaten Dateneingangs- und Datenausgangsanschlüsse verfügen, werden zum Verbinden der Datenanschlüsse der DRAM-Module mit dem Eingangsbus 300 und dem Ausgangsbus 350 dreistufige Treiber (tristate drivers) 711 und 712 verwendet. Der Multiplexer 420 dient dazu, die Leseadresse 540 und die Schreibadresse 532 auf dem Adressbus 425 zu multiplexen. Ein Schreibaktivierungssignal 585 steuert den Multiplexer 420 und stellt ebenfalls das Schreibaktivierungssteuersignal für SRAM- und DRAM-Module bereit.
• Der DRAM-Controller 750 verwendet die vom Adressbus 425 empfangene Adresse, um die Adresssignale und die Chipauswahlsignale für jedes DRAM-Modul zu erzeugen. Außerdem erzeugt er die Zeilenadress- und Spaltenadressauswahlsignale für die DRAM-Module und stellt die Speicheraktualisierungssignale bereit.
• Die Datenzugriffszeit ist bei SRAMs wesentlich kürzer als bei DRAMs. Die dem SRAM bereitgestellten Adressen werden im Verzögerungselement 410 verzögert, um für SRAMs und DRAMs gleiche Zugriffszeiten zu bewirken und so Konflikte auf dem Ausgangsbus 350 zu vermeiden. Wenn eine Anförderung nach Zugriff auf ein DRAM-Modul nicht sofort angenommen werden kann, da dieses DRAM-Modul gerade mit einer vorangehenden Anforderung beschäftigt ist, wird ein Signal "Anforderung empfangen" 581 gesperrt, damit die Adresse nicht aus der Adresswarteschlange 520 entfernt wird, und um dem Videodispatcher 800 mitzuteilen, dass im Augenblick kein Videopaket zu den Ausgangsadaptern gesendet wird.
• Die ATM-Zellen im Videospeicher werden überlappend über die DRAM-Module verteilt.
Ausgangsadapter
• Fig. 9 zeigt die Systemarchitektur des angepassten Ausgangsadapters 250'. Nach jeweils N Taktzyklen wird auf dem Ausgangsbus 350 je eine ATM-Zelle vom gemeinsamen Puffer oder Videospeicher empfangen, wobei N die Anzahl der Ausgangsadapter ist. In Logikblock 282 wird die auf dem Ausgangsbus 350 empfangene ATM-Zelle seriell auf einen 32 Bit oder 16 Bit breiten Bus 283 gegeben. Der Logikblock 284 überwacht, gesteuert durch den Videodispatcher 800, den Bus 271; wenn die ATM-Zelle auf dem Bus 283 vom gemeinsamen Puffer 400 kommt, wird sie unverändert durch den Multiplexer 286 zur Schnittstellenschaltlogik 288 der Ausgangsleitung weitergeleitet, der die Zelle dann schließlich auf der Ausgangsleitung 150 überträgt.
• Wenn die ATM-Zelle auf dem Bus 283 vom Videospeicher kommt, enthält der Bus 271 für diese Zelle eine Datenstrom-ID. Die Datenstrom-ID wird durch den Logikblock 284 auf den Bus 285 gelegt, um sie in die Datenstromsteuertabelle 280 einzutragen und die Kopfdaten für die ATM-Zelle zu erhalten. Diese Kopfdaten werden über den Bus 289 zum Multiplexer 286 übertragen, der sie in der auf dem Bus 283 empfangenen ATM- Zelle austauscht. Das durch den Logikblock 284 erzeugte Steuersignal 287 löst den Austausch der Kopfdaten aus.
• Der Logikblock 284 überprüft auch die Kopfdaten jeder vom gemeinsamen Puffer 400 empfangenen ATM-Zelle, um festzustellen, ob die ATM-Zelle an den Mikroprozessor 260 des Ausgangsadapters adressiert ist; in diesem Fall wird die. Zelle nicht zur Schnittstellenlogik 288 der Ausgangsleitung übertragen, sondern statt dessen zum Mikroprozessor 260 gesendet. Das ist das Grundmuster des Dialogs zwischen dem Host 10 und dem Mikroprozessor 260, um die Datenstromsteuertabelle 280 zu verwalten. Durch zwei vom Host zum Mikroprozessor 260 gesendete Schlüsselbefehle soll ein neuer Eintrag in die Datenstromsteuertabelle erzeugt bzw. ein Eintrag aus dieser Tabelle entfernt werden (siehe Fig. 7). Der Mikroprozessor 260 verwendet den lokalen Speicher 261 zum Speichern seines Programms und seiner Daten und wirkt mit dem Logikblock 284 zusammen, um Änderungen in der Datenstromsteuertabelle zu erreichen. Der Host kann Befehle zum Verwalten der Datenstromsteuertabelle entweder direkt zum Mikroprozessor 260 oder über den Steuerpunktprozessor 600 zum Mikroprozessor 260 senden.
• Wie oben erwähnt, muss der Vermittlungsrechner als Reaktion auf jede vom Host empfangene Steuernachricht mehrere Videonachrichten zu einem Client übertragen. Ein Verfahren zum Überprüfen bestand darin, den Kost aufzufordern, die Lieferung mehrerer Videonachrichten in einer einzigen Steuernachricht anzufordern.
• Bei einem anderen Verfahren wird eine Anzahl der Nachrichten oder ein Abbruchzeitpunkt oder ein Zeigerwert zum Leitungsabbruch für jeden Datenstrom in der Datenstromsteuertabelle angegeben. Der Host startet den Datenstrom durch Senden einer Steuernachricht zum Videodispatcher, indem er die Lieferung der ersten Videonachricht angibt. Wenn im Ausgangsadapter die letzte ATM- Zelle einer Videonachricht verarbeitet wird, wird der in der Datenstromsteuertabelle gespeicherte Wert der Zahl der Nachrichten für den Datenstrom verringert, oder wenn statt dessen der Abbruchzeitpunkt für den Datenstrom angegeben ist, wird der Abbruchzeitpunkt mit dem Lieferzeitpunkt verglichen, oder der Zeigerwert für den Leitungsabbruch wird mit dem auf dem Bus 271 empfangenen Verknüpfungsfeld verglichen. Wenn die Abbruchbedingung erfüllt ist, wird eine entsprechende Bestätigungsmeldung erzeugt und zum Host gesendet. Wenn die Abbruchbedingung nicht erfüllt ist, werden das Verknüpfungsfeld und das Datenflusssteuerfeld zum Erzeugen einer neuen Anforderung verwendet, um die nächste Videonachricht für diesen Datenstrom zu lesen, und die neue Anforderung wird auf dem Bus 270 zum Videodispatcher gesendet.
• Der Host kann nach Empfang der Bestätigung der Abbruchbedingung mit der Lieferung des Videodatenstroms fortfahren, indem er einen Befehl zum Ausgangsadapter sendet, dass die Abbruchbedingung in der Datenstromsteuertabelle zurückzusetzen ist, und indem er eine Steuernachricht zum Videodispatcher sendet, dass die nach der letzten für diesen Datenstrom gelieferten Nachricht folgende Videonachricht gesendet werden soll.
• Auf den ersten Blick scheint die Bereitstellung der beiden oben beschriebenen unterschiedlichen Verfahren zum Anfordern der Lieferung mehrerer Videonachrichten durch den Hast überflüssig. Allerdings können bei dem ersten Verfahren, nach dem der Host in der direkt zum Videodispatcher gesendeten Steuernachricht mehrere Videonachrichten anfordern kann, kurze Videodatenströme mit sehr kurzer Startverzögerung übertragen werden, während das zweite Verfahren eine lange Startverzögerung aufweist, da der Host zuerst die genaue Abbruchbedingung in die Datenstromsteuertabelle eintragen muss, bevor er mit der Lieferung von Videonachrichten an den Client beginnen kann. Der Nachteil des ersten Verfahrens besteht jedoch darin, dass der Host, sobald er mit dem Senden einer Steuernachricht zum Vermittlungsrechner begonnen hat, damit dieser eine bestimmte Anzahl von Videonachrichten zu einem Client sendet, weder die vollständige Lieferung aller Videonachrichten vom Vermittlungsrechner unterbrechen noch den Wiedergabemodus ändern kann, bevor alle Videonachrichten geliefert worden sind. Andererseits kann der Host jederzeit die Datenstromsteuertabelle anpassen, um den Wiedergabemodus oder die Abbruchbedingung zu ändern bzw. einen neuen Startzeitpunkt einzutragen. Dem ersten Verfahren ist der Vorzug zu geben, wenn der Host bei einer Anwendung oft mit dem Vermittlungsrechner in Verbindung treten muss, da dieses Verfahren mit geringem Systemaufwand und kurzer Startverzögerung verbunden ist. Das zweite Verfahren hingegen ist dann vorzuziehen, wenn zwischen dem Host und dem Vermittlungsrechner nur selten ein Dialog stattfindet, da hier der Host die Kontrolle über die Übertragung von Videonachrichten behält.
Unterstützung von Rückwärtswiedergabe, schnellem Vorlauf und Zurückspulen
• In der vorangehenden Erörterung wurde das Verfahren der Lieferung von Videos zur normalen Wiedergabe behandelt. Für diesen Zweck wurde ein einzelnes Verknüpfungsfeld und ein einzelnes Datenflusssteuerfeld verwendet. Um mehrere Wiedergabemodi zu unterstützen, erfordern manche Videonachrichten mehrere Verknüpfungsfelder und mehrere Datenflusssteuerfelder. In diesem Abschnitt wird zunächst beschrieben, wie Videonachrichten, oft unter Verwendung mehrfacher Verknüpfungen in jeder Videonachricht, miteinander verknüpft werden, um mehrere Wiedergabemodi zu unterstützen. Jedes Verknüpfungsfeld wird stets seinem Datenflusssteuerfeld zugeordnet, welches die durch den Vermittlungsrechner zu berücksichtigende Verzögerung bestimmt, wenn dieser den Ablauf der durch die jeweilige Verknüpfung angezeigten Videonachricht steuert. Dann wird ein speicherplatzsparendes Verfahren zum Speichern der Verknüpfungs- und Datenflusssteuerfelder im Vermittlungsrechner beschrieben.
• Bei einem nach dem MPEG-Algorithmus komprimierten Videodatenstrom liegen die komprimierten Bilder in drei Typen vor: Intra-codiert, Vorhersehbar-codiert und Bidirektional- Vorhersehbar-codiert. Intra-codierte Bilder (I-Bilder) können ohne zusätzliche Informationen decodiert werden, aber zum Decodieren von Vorhersehbar-codierten Bildern (P-Bilder) wird das ihnen vorangehende decodierte I-Bild benötigt. Für das Decodieren von Bidirektional-vorhersehbar-codierten Bildern (B-Bilder) werden sowohl das vorangehende decodierte I- oder P-Bild als auch das nachfolgende decodierte I- oder P-Bild benötigt.
• Fig. 13a zeigt eine Bildfolge (Einzelbilder) in einem Videodatenstrom. Die Bilder werden in dieser Reihenfolge empfangen und angezeigt, auf die sich die folgenden Ausführungen beziehen. Man erkennt jedoch leicht, dass das zweite Bild, ein B-Bild, erst dann decodiert werden kann, wenn das fünfte Bild, das als erstes P-Bild oder I-Bild auf dieses B-Bild folgt, decodiert wurde. Daher unterscheidet sich die Reihenfolge, in der die Bilder eines Videodatenstroms decodiert werden und die als Decodierungsreihenfolge bezeichnet wird, von der Darstellungsreihenfolge. In Fig. 13b veranschaulichen die Pfeile die Decodierungsreihenfolge für die in der Darstellungsreihenfolge von links nach rechts aufgeführten Bilder. In der vorliegenden Ausführungsart werden die komprimierten Einzelbilder in einem Videodatenstrom in der Decodierungsreihenfolge gespeichert und daher in der Decodierungsreihenfolge zum Client gesendet. In den durch die Vorwärtsverknüpfungen 941 abgerufenen Videonachrichten erscheinen die komprimierten Einzelbilder in der Decodierungsreihenfolge.
• Um die Rückwärtswiedergabe von. Videos zu unterstützen, werden die in Fig. 13c gezeigten komprimierten Einzelbilder, die in der Darstellungsreihenfolge für die normale Wiedergabe von links nach rechts aufgeführt sind, zum Client gesendet, dann in der durch die Rückwärtsverknüpfung 942 gezeigten Reihenfolge decodiert und dann durch den Client in der Reihenfolge von rechts nach links angezeigt. Wenn die Rückwärtsverknüpfungen zum Abrufen der Videonachrichten verwendet werden, erscheinen die komprimierten Videobilder in der Decodierungsreihenfolge, um das Video, wie in Fig. 13c gezeigt, rückwärts wiederzugeben. Da Videonachrichten eine feste Größe aufweisen, werden der Anfang und das Ende von Einzelbildern nicht an die Begrenzungen der Videonachricht angepasst. Wenn also Videonachrichten in einer Reihenfolge abgerufen werden, die sich vom normalen Wiedergabemodus, also bei normaler Wiedergabe, schnellem Vorlauf und Rückspulen, unterscheidet, enthalten die erste und die letzte Videonachricht eines Videobildes zusätzliche Daten. In diesem Fall muss entweder der Client so programmiert werden, dass er die zusätzlichen Daten löscht, oder es müssen in der Videonachricht Auffüllbytes verwendet werden, um die Einzelbildbegrenzungen an die Videonachrichten anzupassen.
• Bei Videonachrichten, die nicht das Ende eines Einzelbilds enthalten, werden Rückwärtsverknüpfungen nicht gespeichert, da bei diesen Bildern die Vorwärts- und die Rückwärtsverknüpfung identisch sind.
• Schneller Vorlauf und Zurückspulen werden auf dieselbe Weise unterstützt wie die Rückwärtswiedergabe. Die Verknüpfung 943 (siehe Fig. 13d) verknüpft die letzte Videonachricht, die Daten eines I-Bildes enthält, mit der ersten Videonachricht, die Daten des nächsten I-Bildes enthält. Dadurch wird der schnelle Vorlauf erreicht, wenn die Verknüpfung 943 zum Abrufen der Daten Verwendet wird und die I-Bilder mit einer höheren Geschwindigkeit abgerufen und zum Benutzer geliefert werden als die Geschwindigkeit, mit der die I-Bilder bei normaler Wiedergabe durch den Benützer empfangen werden. Da der Client bei normaler Wiedergabe üblicherweise zwei I-Bilder je Sekunde empfängt, eignet sich dieses Schema, wenn die Geschwindigkeit des schnellen Vorlaufs etwa 15 mal so hoch wie die normale Wiedergabegeschwindigkeit ist. Um eine niedrigere Geschwindigkeit für den schnellen Vorlauf zu unterstützen, könnte man, wie in Fig. 13d gezeigt, unter Verwendung der Verknüpfung 944 alle I- und P-Bilder miteinander verknüpfen. Die ebenfalls in Fig. 13d gezeigten Verknüpfungen 945 und 946 werden auf ähnliche Weise zum Unterstützen der Rückspulfunktion bei unterschiedlichen Geschwindigkeiten verwendet. Auch hier liegen die Verknüpfungen 943 und 945 in Videonachrichten vor, die das Ende eines I-Bildes enthalten, und die Verknüpfungen 944 und 946 liegen in Videonachrichten vor, die das Ende eines I-Bildes oder eines P-Bildes enthalten.
• Wenn diese Verknüpfungen nicht in einer Videonachricht gespeichert sind, wird die Vorwärtsverknüpfung verwendet. Und schließlich weisen die Verknüpfungen 943 und 944 ihre eigenen Datenflusssteuerfelder auf, die von den Verknüpfungen 944 bzw. 946 mitbenutzt werden können.
• Da jede Videonachricht eine unterschiedliche Anzahl von Verknüpfungsfeldern aufweist, wäre es verschwenderisch, Speicherplatz für die maximal mögliche Anzahl von Verknüpfungsfeldern in jeder Videonachricht bereitzuhalten. Um den benötigten Speicherbedarf auf ein Minimum zu beschränken, werden die Verknüpfungsfelder kompakt zusammen mit den Datenflusssteuerfeldern im Befehlsspeicher des Videodispatchers sowie Zeiger fester Größe, die auf die Verknüpfungen in jeder Videonachricht zeigen, in einem dem Videodispatcher angefügten Befehls-Zeiger-Speicher gespeichert. Jetzt wird die Adresse der Videonachricht dazu verwendet, um aus dem Befehls-Zeiger-Speicher einen Zeiger abzurufen, der wiederum zum Abrufen der Verknüpfungen für die Videonachricht aus dem Befehlsspeicher verwendet, wird. Jeder Eintrag des Befehls-Zeiger-Speichers besitzt zusätzlich zum Zeiger des Befehlsspeichers einen Maskeneintrag. Die Maske zeigt an, welche Verknüpfungen vorliegen.
• Um schließlich die Modi Rückwärtswiedergabe, schneller Vorlauf und Zurückspulen zu unterstützen, wird zu der vom Host zum Videodispatcher gesendeten Steuernachricht ein zusätzliches Feld hinzugefügt. Dieses Feld gibt den Wiedergabemodus an. Die Daten zum Wiedergabemodus werden gemeinsam mit der ATM- Zellenadresse (und der Datenstrom-ID) auf den Bussen 725 und 540 transportiert und gemeinsam für der ATM-Zellenadresse in den Warteschlangen 540 gespeichert. Wenn die letzte ATM-Zelle einer Videonachricht vom Videospeicher abgerufen wird, wird daher unter Verwendung der Information zum Wiedergabemodus aus der Menge der für jede aktuell gesendete Videonachricht gespeicherten Verknüpfungen die Verknüpfung zur nächsten Videonachricht und dem entsprechenden Datenflusssteuerfeld ausgewählt.
Alternative Ausführungsarten
• Bei der in den vorangehenden Abschnitten beschriebenen Ausführungsart unter Verwendung eines Vermittlungsrechners mit gemeinsamem Puffer wurde der Videospeicher als Erweiterung des gemeinsamen Puffers selbst realisiert, und die vom gemeinsamen Speicher abgerufenen Videopakete (-zellen) wurden zu den Ausgangsadaptern des Vermittlungsrechners weitergeleitet. In diesem Abschnitt werden drei Alternativen der obigen Ausführungsarten beschrieben, die jeweils das Speichern von paketweise verarbeiteten Videoinformationen in den Vermittlungsrechnern des Netzes unterstützen.
• Solange in den Ausgangsadaptern des Vermittlungsrechners Puffer bereitgestellt werden und in diesen Adaptern. Rechenleistung zum Ausführen der für die Ausgangsadapter beschriebenen Funktionen zur Verfügung steht, kann dem Vermittlungsrechner auch dann Videospeicher hinzugefügt werden, wenn dieser nicht auf dem gemeinsamen Speicher basiert. Fig. 10 veranschaulicht das allgemeine Verfahren zum Einfügen von Halbleiterspeichern in derartige Vermittlungsrechner. Fig. 10A zeigt einen typischen Vermittlungsrechner 61 mit Eingangsleitungen und. Ausgangswarteschlangen 1250 zusätzlich zur Hardware 1100 und zur Steuerung 1150 des Vermittlungsrechners. Fig. 108 zeigt, dass der Videospeicher 700 in diesen Vermittlungsrechner eingefügt werden kann, indem er mittels des Videodispatchers direkt mit den Ausgangswarteschlangen verbunden wird. Im Gegensatz zur bevorzugten Ausführungsart werden die Videodaten jetzt durch den Videodispatcher auf einem anderen Bus als der normale Netzverkehr zum Ausgangsadapter gesendet. Der Videospeichermanager 1600 empfängt jetzt die Videodaten ebenfalls und schreibt sie in den Videospeicher 700. Ansonsten entsprechen die Einzelheiten des Arbeitsschritts im Wesentlichen der bevorzugten Ausführungsart auf Basis des Vermittlungsrechners mit dem gemeinsamen Puffer.
• Wenn der Halbleiterspeicher, wie im vorangehenden Kapitel beschrieben, nicht direkt mit den Ausgangsadaptern verbünden werden kann, können die Eingangsleitungen des Vermittlungsrechners, wie in Fig. 11 gezeigt, zum Anschließen verwendet werden. Der Videospeicher 700' wird nun über die Anschlüsse 800' mit den Eingängen des Vermittlungsrechners verbunden. Die Eingangsadapter werden so angepasst, dass sie die Logik des Videodispatchers aufnehmen. Jeder angepasste Eingangsadapter 200' weist die Datenstromsteuertabelle auf und führt die Videodispatcherfunktion an jedem durch sie abgerufenen Videodatenstrom aus. Die Ausgangsadapter 250 unterscheiden sich nur insofern von den Ausgangsadaptern 250, als die Schnittstelle zur Hardware des Vermittlungsrechners hier nicht mehr ein allgemein benützter Bus ist. Dieser Ansatz weist den Nachteil auf, dass für die Unterstützung desselben Videodurchsatzes mehr Hardware des Vermittlungsrechners benötigt wird, da die Videodaten sowohl durch die Eingangs- als auch durch die Ausgangsadapter geleitet werden. Bei den oben beschriebenen Designs könnte der Vermittlungsrechner eventuell weniger Eingangsadapter aufweisen, da der Datenverkehr überwiegend aus Videodaten besteht, die direkt den Ausgangsadaptern zugeordnet sind. Wenn weniger Eingangsadapter verwendet werden, resultieren die Einsparungen nicht nur aus der Hardware der Eingängsadapter, sondern auch aus der möglichen Verwendung eines kleineren Vermittlungsrechners.
• Schließlich könnte der Speicher bei allen vorangehenden Designs anstelle des Halbleiterspeichers auf einer Anordnung von Plattenspeicherlaufwerken 790 basieren, insbesondere wenn die Anzahl der zu unterstützenden Datenströme nicht allzu groß ist. Ein kleiner Halbleiterpuffer 795 stellt den aktuell durch die aktiven Videodatenströme abgerufenen Abschnitt des Videos vorab bereit. Dieses Bereitstellen kann genau terminiert werden, da die Abrufe der Videodaten überwiegend sequenziell erfolgen. Letzten Endes laufen bei diesem System alle Videoinhalte über den Puffer. Dieser Ansatz wird durch Fig. 12 veranschaulicht.

Claims (5)

1. Verfahren, um Video-, Multimedia- oder andere kontinuierliche Medieninhalte (900) von einem bestimmten Vermittlungsrechner (60) aus einer Anzahl von Vermittlungsrechnern, in dem der Inhalt vor einer oder ohne eine aktuelle Anforderung des Inhalts in Form vorverarbeiteter Pakete (920) gespeichert ist, an Clients (20) zu verteilen, wobei die Vermittlungsrechner (60) und die Clients (20) Teil eines Datenübertragungssystems (50) sind, das ferner einen Hostprozessor (10) und weitere Vermittlungsrechner (60) umfasst, wobei das Verfahren die folgenden Schritte umfasst:

-- 1. Anfordern des Inhalts oder eines Teils davon durch Senden einer Anforderung (6) zur Übertragung von einem der Clients (20) an den Hostprozessor (10);

-- 2. Erkennen des bestimmten Vermittlungsrechners, in dem der angeforderte Inhalt gespeichert ist;

-- 3. Übertragen einer Steuernachricht (8) vom Rostprozessor (10) an den Vermittlungsrechner (60), wobei die Steuernachricht eine Anforderung zum Senden des Inhalts oder eines Teils davon vom Vermittlungsrechner an den einen Client anzeigt und die Steuernachricht weder den angeforderten Inhalt noch einen Teil davon enthält;

-- 4. Übertragen einer Kopie des angeforderten Inhalts oder eines Teils davon in Form von vorverarbeiteten Paketen vom Vermittlungsrechner an den einen Client (20) in der Weise, dass der kontinuierliche Medieninhalt (900) durch den Client (20) aus den vorverarbeiteten Paketen wiederhergestellt werden kann, während der Inhalt anschließend in Form von vorverarbeiteten Paketen im Speicher des Vermittlungsrechners erhalten bleibt, wobei der Vermittlungsrechner über Schaltmittel und mehrere Ausgangsanschlüsse verfügt, mittels derer der Vermittlungsrechner (60) in der Lage ist, Inhalte unabhängig voneinander an jeden der Clients (20) zu übertragen, der die Inhalte oder Teile davon anfordert.

2. Verfahren gemäß Anspruch 1, bei dem jedes der vorverarbeiteten Pakete (920) Nutzinformationen des Inhalts sowie Header und Trailer des Netzprotokollstapels umfasst.

3. Datenübertragungssystem zum Übertragen von Video-, Multimedia- oder anderen kontinuierlichen Medieninhalten (900) von einem Vermittlungsrechner (60), in dem der Inhalt vor einer oder ohne eine aktuelle Anforderung des Inhalts in Form von vorverarbeiteten Pakten gespeichert ist, an Clients, wobei der Vermittlungsrechner (60) und die Clients (20) Teil des Datenübertragungssystems (50) sind, welches ferner einen Hostprozessor (10) umfasst sowie:

-- 1. Mittel zum Anfordern der Übertragung des Inhalts (900) oder eines Teils davon durch Senden einer Übertragungsanforderung (6) von einem der Clients (20) an den Hostprozessor (10),

-- 2. Mittel zum Übertragen einer Steuernachricht (8) vom Hostprozessor (10) an den Vermittlungsrechner (60), in dem der angeforderte Inhalt gespeichert ist, wobei die Steuernachricht (8) eine Anforderung zum Senden des Inhalts oder eines Teils davon vom Vermittlungsrechner (60) an einen der Clients (20) anzeigt und die Steuernachricht weder den angeforderten Inhalt noch einen Teil davon enthält,

-- 3. Mittel zum zeitlichen Steuern und Übertragen einer Kopie des angeforderten Inhalts oder eines Teils davon in Form von vorverarbeiteten Paketen (920) vom Vermittlungsrechner (60) an einen der Clients (20), und

-- 4. Mittel, die dem Vermittlungsrechner (60), der über Schaltmittel und mehrere Ausgangsanschlüsse verfügt, die Übertragung des Inhalts an einen beliebigen der Clients (20), der den Inhalt oder einen Teil davon anfordert, zu ermöglichen, während der Inhalt anschließend in Form von vorverarbeiteten Paketen (920) im Speicher des Vermittlungsrechners (60) verbleibt.

4. Datenübertragungssystem gemäß Anspruch 3, bei dem der Inhalt nur dann aus dem Speicher des Vermittlungsrechners entfernt wird, wenn an diesen Vermittlungsrechner der Gruppe von Vermittlungsrechnern eine unabhängige Steuernachricht übertragen wird, die das Löschen des Inhalts anfordert, wobei die unabhängige Steuernachricht von der Anforderungsnachricht unabhängig ist.

5. Datenübertragungsnetz, das Folgendes umfasst:

-- a. ein Datenübertragungsnetz (50), das eine Vielzahl von Vermittlungsrechnern (60) aufweist;

-- b. einen mit dem Datenübertragungsnetz (50) verbundenen Hostprozessor (10);

-- c. eine Vielzahl von mit dem Datenübertragungsnetz (50) verbundenen Clients (20); wobei

-- d. jeder der Vermittlungsrechner (60) über Folgendes verfügt:

-- 1. spezielle Speichermittel zum Speichern von vorverarbeiteten Videopaketen,

-- 2. Mittel zum Abrufen und Versenden von Kopien von abgerufenen vorverarbeiteten Videopaketen an einen abrufenden Client der Clients (20), und

-- 3. Mittel zum Liefern fehlender Informationen in den Headern und Trailern des Netzprotokollstapels in den vorverarbeiteten Paketen,

wobei die vorverarbeiteten Videopakete auch nach dem Übertragen von Kopien der angeforderten Videopakete an den anfordernden Client (20) in jedem der Vermittlungsrechner (60) gespeichert bleiben; und

-- e. Mittel, die jedem der Vermittlungsrechner (60) die unabhängige Übertragung von vorverarbeiteten Videopaketen an Clients (20) ermöglichen.