DE102005033211A1

DE102005033211A1 - Verfahren zur Feststellung der Aktivität eines Gerätes in einem Netzwerk verteilter Stationen sowie Netzwerkstation für die Durchführung des Verfahrens

Info

Publication number: DE102005033211A1
Application number: DE102005033211A
Authority: DE
Inventors: Ingo HÜTTER; Michael Weber
Original assignee: Deutsche Thomson Brandt GmbH
Current assignee: Deutsche Thomson OHG
Priority date: 2005-07-13
Filing date: 2005-07-13
Publication date: 2007-01-18
Also published as: DE602006005155D1; KR101271261B1; EP1902569A1; JP4898804B2; JP2009501371A; ATE422780T1; EP1902569B1; US8335818B2; WO2007006611A1; CN101218805A; US20090210525A1; KR20080031865A; CN101218805B

Abstract

Die Erfindung betrifft das technische Gebiet lokaler Datenübertragungsnetzwerke, insbesondere Heimnetzwerke. In solchen Netzwerken melden sich die Netzwerkstationen bei Anschaltung an das Netzwerk an. Bei Abschaltung erfolgt eine entsprechende Abmeldung von Seiten der das Netzwerk verlassenden Netzwerkstation. Für den Fall, daß der Benutzer eine Netzwerkstation durch einfaches Herausziehen des Netzwerkkabels vom Netzwerk trennt, ist das Aussenden der Abmeldebotschaft physikalisch nicht möglich. Die Erfindung beschäftigt sich nun mit dem Problem, wie zuverlässig eine inaktive Netzwerkstation erkannt werden kann, auch unter Berücksichtigung des Trennens der Netzwerkstation durch bloßes Abziehen des Netzwerksteckers. DOLLAR A Die Erfindung löst das Problem durch regelmäßiges Aussenden einer Suchanfrage an die Stationen im Netzwerk. Wenn eine Suchanfrage von einer Netzwerkstation unbeantwortet bleibt, wird zusätzlich noch ein HTTP-Zugriff auf z. B. die Gerätebeschreibung der fraglichen Netzwerkstation oder eine Steueranforderung versucht. Nur wenn auch dieser Zugriff/Steueranforderung fehlschlägt, wird die Netzwerkstation als inaktiv gekennzeichnet. Bei einem UPnP-Netzwerk erfolgt die Suchanfrage nach dem ungesicherten SSDP-Protokoll, so daß das Ausbleiben einer Antwort auf die Suchanfrage noch nicht zuverlässig die Abmeldung der Netzwerkstation anzeigt. Über den HTTP-Zugriff, der fehlergesichert stattfindet, wird der Verdacht, daß die die Suchanfrage nicht beantwortende ...

Description

Die Erfindung betrifft das technische Gebiet der lokalen Netzwerke, insbesondere Heimnetzwerke.

Hintergrund der Erfindung

Zur Vernetzung von Geräten im Heimbereich stehen unterschiedliche Heimnetzwerkstandards zur Verfügung. Ein Konsortium von Unternehmen, insbesondere der Unternehmen der Computer-Industrie, federführend ist Microsoft, haben eine Initiative für die Spezifizierung einer Netzwerk-Steuer-Software, basierend auf dem existierenden Internet-Protokoll (IP) gestartet. Dieses Netzwerk-System ist unter dem Kürzel UPnP (Universal Plug and Play) bekannt geworden. Das UPnP-System basiert auf einer Reihe von standardisierten Netzwerk-Protokollen und Datenformaten. Es dient zur Hersteller-übergreifenden Steuerung von Geräten (darunter typische Geräte der Computer-Industrie wie PC, Router, Drucker, Scanner, als auch Geräte der Unterhaltungselektronik sowie Haushaltsgeräte der weißen Ware und Haussteuerungen). Die Vernetzung der Geräte geschieht über ein IP-basiertes Netzwerk, mit oder ohne zentrale Kontrolle durch ein "Residential Gateway". Dabei ist das Netzwerk-System als Plug-and-Play-System ausgelegt, d. h. die Konfiguration des Netzwerkes geschieht ohne Interaktion des Benutzers. Ein Kontrollpunktgerät, entsprechend Control Point kann die Geräte im Netzwerk selbständig finden. Als physikalische Übertragungsmedien kommen alle Medien in Frage, die die IP-Kommunikation unterstützen, das sind z.B. Ethernet, Firewire, Funkübertragungssysteme wie Bluetooth und WirelessLAN etc. Es werden standardisierte Technologien wie IP, UDP, entsprechend User Datagram Protocol, Multicast, TCP entsprechend Transmission Control Protocol, HTTP, entsprechend Hyper Text Transfer Protokoll, XML, entsprechend Extended Mark up Language, SOAP, entsprechend Simple Object Access Protocol und SSDP, entsprechend Simple Service Discovery Protocol verwendet.

Die UPnP-Spezifikation beschreibt, wie Geräte nach dem UPnP-Standard aufgebaut sind und wie sie kontrolliert werden können. Eine der Basisideen dieser Spezifikation liegt darin, daß es möglich ist, jedes UPnP-Gerät über einen Standard-Web-Browser zu bedienen. Dazu verfügt ein jedes UPnP-Gerät über einen Web-Server, auf dem die HTML-Seiten zur Bedienung des Gerätes (die sogenannten Presentation Pages) abgelegt sind.

In dem UPnP-Netzwerk-System ist es festgelegt, daß sich neue Stationen im Netzwerk anmelden müssen sowie abgeschaltete Stationen sich vom Netzwerk abmelden müssen. Dies geschieht mit Spezialnachrichten gemäß des SSDP-Protokolls. Im UPnP-Standard ist es vorgesehen, daß die einzelnen Netzwerkstationen regelmäßig ihre Aktivität bekannt geben. Dies geschieht mit einer SSDP-Nachricht, nämlich "ssdp:alive", die eine Netzwerkstation minimal alle 1.800 Sekunden aussenden muß. Dies entspricht einer minimalen Periodendauer von einer halben Stunde.

Wenn die Geräte vom Netz gehen, sollen sie auch eine Abmeldebotschaft des Typs "ssdp:byebye" aussenden. Wenn die Abmeldebotschaft gesendet wird, kann ein Kontrollpunktgerät anhand dessen schnell feststellen, daß ein UPnP-Gerät das Netzwerk verlassen hat. Auch daran, daß nach dem definierten Wiederholungsintervall keine Aktivitätsbestätigungsbotschaft mehr kommt, könnte das Kontrollpunktgerät erkennen, daß die entsprechende Netzwerkstation inaktiv geschaltet wurde. Tatsächlich ist es den Geräten möglich eine ssdp:byebye-Botschaft zu senden, wenn sie ausgeschaltet werden und somit prinzipiell nicht mehr im Netzwerk vorhanden sind – auch wenn sie noch mit diesem verbunden sind. Doch wenn sie durch Herausziehen des Kabels vom Netzwerk getrennt werden, ist es aus physikalischen Gründen nicht mehr möglich, die erwähnte Abmeldebotschaft zu versenden. Da der zu beobachtende minimale Zeitraum mit einer halben Stunde aber recht lang ist, können für den Benutzer unerwartete Reaktionen entstehen. Insbesondere dann, wenn ein Benutzer ein Gerät bedienen möchte, welches bereits eine Weile nicht mehr aktiv geschaltet ist, jedoch die Aktivitätsbestätigungsnachricht noch nicht über den maximal zulässigen Bereich ausgeblieben ist, zeigt das Netzwerk ein unschönes Verhalten. Sobald er nämlich auf das angeblich existente Gerät zugreift, wird erkannt, daß es nicht mehr aktiv ist und es wird aus dem Benutzermenü plötzlich verschwinden, was den Benutzer verwirren kann.

Erfindung

Die Erfindung setzt sich zum Ziel, ein benutzerfreundlicheres Verhalten für den Fall von unerkannten Geräteabmeldungen zu erreichen.

Die erfindungsgemäße Lösung basiert darauf, daß ein Kontrollpunktgerät regelmäßig in kurzen Zeitabständen Suchanfragen an die Netzwerkstationen sendet. Dies ist nach der UPnP-Spezifikation erlaubt und es gibt keinen minimalen Zeitabstand für solche Suchanfragen. So lassen sich Suchanfragen z.B. alle fünf, zehn oder fünfzehn Sekunden versenden. Die angesprochenen Netzwerkstationen müssen auf solche Suchanfragen antworten. Durch das Ausbleiben der Antworten von einzelnen Geräten kann das Kontrollpunktgerät feststellen, welche Geräte das Netzwerk verlassen haben.

In diesem Zusammenhang muß aber beachtet werden, daß sowohl die Suchanfragen als auch die zugehörigen Antworten als UDP-Pakete versendet werden, d. h. es ist nicht sichergestellt, daß die Pakete auch tatsächlich den Adressaten erreichen. UDP ist ein ungesichertes Datenübertragungsprotokoll. Dies ist besonders dann ein Problem, wenn einzelne Geräte über eine drahtlose Verbindung mit dem Netzwerk kommunizieren. Zwar läßt sich das Problem ansatzweise dadurch lösen, daß man nicht nach dem erstmaligen Ausbleiben von Antworten auf eine Suchanfrage davon ausgeht, daß ein Gerät inaktiv ist, sondern erst nach mehrmaligem Ausbleiben der Antworten. Dies hat aber wiederum den Nachteil, daß es länger dauert, bis erkannt wird, ob ein Gerät tatsächlich aus dem Netzwerk abgemeldet wurde.

Zur Lösung dieser zusätzlichen Problematik ist es erfindungsgemäß vorgesehen, daß nach Ausbleiben einer Antwort auf eine Suchanfrage zusätzlich über ein fehlergesichertes Übertragungsprotokoll überprüft wird, ob das Gerät noch aktiv ist. Zwar unterstützt das SSDP-Protokoll und auch das gesamte Kapitel zur Geräterkennung gemäß UPnP-Spezifikation diese Maßnahme nicht, doch gibt es eine Möglichkeit, die Existenz eines Gerätes im Rahmen der UPnP-Spezifikation auf einfache Art und Weise zu überprüfen. Jedes UPnP-Gerät besitzt lt. Spezifikation einen Web-Server, über den auf Informationen zu dem Gerät zugegriffen werden kann. Zu diesen Informationen zählen z.B. die sogenannten Gerätebeschreibungen entsprechend Device Description, aber auch die Dienstebeschreibungen, entsprechend Service Description. In beiden Fällen handelt es sich um XML-Dateien. Der Zugriff auf diese Dateien erfolgt ausschließlich über das HTTP-Protokoll. Das HTTP-Protokoll ist ein fehlergesichertes Protokoll, da es auf dem TCP-Protokoll basiert. Dem Kontrollpunktgerät ist auf jeden Fall die URL, entsprechend Uniform Resource Locator der Gerätebeschreibung eines UPnP-Gerätes bekannt, weil dies bei Anmeldung des Gerätes an alle Netzwerkstationen übermittelt wird. Das Kontrollpunktgerät kann deshalb nach Ausbleiben der zuvor beschriebenen Antworten auf die Suchanfragen mittels eines HTTP-Zugriffs auf die Gerätebeschreibung oder eine andere existente Datei feststellen, ob das Gerät im Netzwerk noch aktiv ist. Alternativ kann auch an ein zu steuerndes Gerät eine Steueranforderung geschickt werden, welche auch über HTTP verschickt wird. Ist der Aufbau einer HTTP-Verbindung möglich, ist das Gerät noch aktiv, ist es dagegen nicht mehr möglich, wurde es vom Netzwerk entfernt.

Das benutzerunfreundliche Verhalten – wie zuvor geschildert – ist damit behoben.

Durch die in den abhängigen Ansprüchen aufgeführten Maßnahmen sind vorteilhafte Weiterbildungen und Verbesserungen des erfindungsgemäßen Verfahrens bzw. der erfindungsgemäßen Vorrichtung möglich.

Wenn für den Datenzugriff ein HTTP Head-Zugriff verwendet wird, hat das den Vorteil, dass nur minimale Datenmengen transferiert werden müssen. Bei Aktivitätsüberprüfung mittels Absendung einer Steueranforderung ist es von Vorteil einen HTTP Post-Zugriff zu verwenden. Dann ist es auch von Vorteil, wenn die Steueranforderung nicht den Zustand des angesprochenen Gerätes verändert.

Zeichnungen
Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und werden in der nachfolgenden Beschreibung näher erläutert. Es zeigen:
1 die Struktur eines beispielhaften Netzwerkes mit zwei Netzwerkverbindungsschalteinheiten;
2 eine Übersicht über die Software-Protokolle einer erfindungsgemäßen Netzwerkstation;
3 ein Prinzipschaubild für die Übertragung von AV-Daten zwischen zwei Netzwerkstationen gemäß UPnP/AV-Architecture:0.8.3;
4 die Darstellung wichtiger Software-Komponenten einer erfindungsgemäßen Netzwerkstation;
und 5 ein Ablaufdiagramm für ein Programm, mit dem die Aktivität einer Netzwerkstation überprüft werden kann.
Ausführungsbeispiele der Erfindung
In der 1 ist ein beispielhaftes Heimnetzwerk mit fünf Netzwerkstationen 12–16 und zwei Netzwerkverbindungsschalteinheiten 10, 11 gezeigt. Die Bus-Verbindungen zwischen den Netzwerkverbindungsschalteinheiten 10, 11 und den Netzwerkstationen 12 bis 15 basieren auf Ethernet-Technologie, speziell 100 Base/TX-Ethernet. Die Netzwerkstation 16 ist drahtlos mit der Netzwerkverbindungsschalteinheit 10 verbunden, z.B. über Wireless LAN, entsprechend IEEE802.11b. Auch die Verbindung zwischen den beiden Netzwerkverbindungsschalteinheiten 10 und 11 beruht auf Ethernet-Technologie. Bei jeder Netzwerkverbindungsschalteinheit 10, 11 sind vier Netzwerkverbindungsstellen (auch Ports genannt) dargestellt. Nicht dargestellt sind die Ethernet-Schnittstellen in den einzelnen Netzwerkstationen, wie auch in den Netzwerkverbindungsschalteinheiten.
Als Übertragungssystem für die Datenübertragung im Netzwerk wird das schon eingangs erwähnte Ethernet-Bus-System in der Variante 100 Base/TX eingesetzt. Für den gewählten Anwendungsfall wurde diese Variante als ausreichend angesehen, jedoch kann in anderen Anwendungsfällen eine andere Variante als Übertragungssystem angewendet werden. Wenn es auf höhere Datenraten ankommt, stehen beispielsweise die sogenannten 1000 Base/T oder 1000 Base/SX oder 1000 Base/LX zur Verfügung. Die letzten beiden Varianten basieren dabei auf optischer Glasfasertechnologie. Das gezeigte Netzwerk gemäß 1 ist UPnP-basiert, d. h. die einzelnen Netzwerkstationen sind nach dem UPnP-Standard ausgelegt.
Das Ethernet-Bus-System stellt für die höheren Protokollschichten keine gesicherte Verbindung zur Verfügung, da Übertragungsrahmen verloren gehen können. Dies ist für die Übertragung vieler Nutzdaten nicht ausreichend, weshalb eine Sicherung der Übertragung häufig durch die höher liegenden Protokollschichten erfolgt. Für das UPnP-Netzwerksystem ist als nächsthöhere Protokollebene das IP-Protokoll, entsprechend Internet Protocol auf der Höhe der Netzwerkschicht des OSI-Schichtenmodells der Datenkommunikation vorgesehen. Die Sicherungsschicht wird erst von dem darauf aufbauenden TCP-Protokoll realisiert. Für beide Protokollebenen, die nicht mehr Bestandteil des Ethernet-Standard sind, geltend eigene Standardisierungen, auf die im Hinblick der Offenbarung der Erfindung lediglich verwiesen wird.
Für die Kommunikation im UPnP-Netzwerk ist ein erweiterter Protokollstapel für die einzelnen Netzwerkstationen erforderlich. Diesen Protokollstapel zeigt die 2. Die beiden Ethernet-Protokollebenen Ethernet PHY und Ethernet MAC sind auf den untersten Ebenen angeordnet. Darüber befindet sich die schon erwähnte Protokollebene IP. Auf der Ebene der Transportschicht ist dann noch das UDP-Protokoll angeordnet, welches für die Übertragung aller mit der Geräteerkennung (Device Discovery) zusammenhängenden Botschaften benutzt wird. Darüber ist eine spezielle Version des HTTP-Protokolls angesiedelt. Es handelt sich um das HTTPMU-Protokoll (HTTP Multicast Over UDP). Solche HTTP-Nachrichten werden also pauschal adressiert über die unteren UDP- und IP-Protokollebenen weitergeleitet.
Oberhalb der HTTPMU-Protokollebene ist noch das SSDP-Protokoll vorgesehen. Neben dem UDP-Protokoll kommt noch das TCP-Protokoll zur Anwendung, welches für die Übertragung aller sonstigen UPnP-Nachrichten, insbesondere für Geräte- und Service-Beschreibungen, zur Gerätesteuerung sowie zur Ereignis-Mitteilung vorgesehen ist. Darüber befindet sich das HTTP-Protokoll und darüber auf der Ebene des SSDP-Protokoll das SOAP-Protokoll, welches früher als Simple Object Access Protocol bezeichnet wurde. Es kann benutzt werden, um bei anderen Geräten Funktionsaufrufe durchzuführen, entsprechend Remote Procedure Calls (RPC). Des weiteren kann auch das GENA-Protokoll implementiert sein, entsprechend General Event Notification Architecture, womit Registrierungen für Ereignismitteilungen in anderen Netzwerkstationen möglich sind.
Eine vollständige Protokollarchitektur, die in dem UPnP-Netzwerksystem benutzt wird, kann aus der UPnP-Spezifikation (zu beziehen über www.upnp.org) entnommen werden.
Im Rahmen der UPnP-Standardisierung wurde auch eine Spezifikation für die Übertragung von AV-Daten (Audio/Video-Daten) zwischen Netzwerkteilnehmerstationen erarbeitet und im Juni 2002 abgeschlossen. Der genaue Titel dieser Spezifikation lautet: UPnP-AV-Architecture:0.83 vom 12. Juni 2002. In dieser Spezifikation sind für die Übertragung von AV-Daten 3 verschiedene Typen von Geräten definiert. Zum ersten ein sogenannter Mediaserver; so wird dasjenige Gerät bezeichnet, das als Quelle der AV-Daten ausgewählt ist. Zum zweiten gibt es den Gerätetyp Media-Renderer, der für ein Gerät, das als Datensenke für die AV-Daten dient, steht. Zum dritten ist als eigener Gerätetyp noch der Typ Control Point vorgesehen, was nachfolgend als Kontrollpunktgerät bezeichnet ist. Als Kontrollpunktgerät kommt regelmäßig z.B. eine Universalfernbedienung für die AV-Geräte in Betracht. Alternativ kann aber auch ein Personalcomputer im Netz diese Aufgabe erfüllen oder auch ein TV-Gerät mit Fernbedienung kann sich ebenfalls als Kontrollgerät eignen.
Das Kontrollpunktgerät kommuniziert mit zwei weiteren UPnP-Geräten, die als Datenquelle und Datensenke für eine gewünschte AV- Verbindung in Frage kommen. Das Kontrollpunktgerät initialisiert und konfiguriert beide Geräte für die AV-Verbindung, so daß der gewünschte Datenstrom auch aufgesetzt werden kann. Somit besteht die Aufgabe eines Kontrollpunktgerätes typischerweise darin, eine AV-Verbindung zwischen zwei Netzwerkteilnehmern einzurichten, eventuell Änderungen bei den Einstellungen der beiden Geräte vorzunehmen und nachdem der gewünschte AV-Datenstrom übertragen worden ist, die Verbindung wieder zu kappen, d. h. beide Geräte der AV-Verbindung zur Löschung der die Verbindung charakterisierenden Daten aufzufordern.
3 zeigt die prinzipielle Einteilung von Netzwerkstationen, die für eine AV-Verbindung nötig sind. Das Gerät Media-Server beinhaltet einen oder hat Zugriff zu einem AV-Datenstrom, der z.B. lokal gespeichert ist oder von außen empfangen wird. Das Media-Server-Gerät hat Zugriff zu den AV-Daten und ist in der Lage, einen zugehörigen AV-Datenstrom über das Netzwerk zu einer anderen Netzwerkstation zu übertragen. Der AV-Datenstrom wird dabei mit einem Transferprotokoll entsprechend des im Netz vorhandenen Übertragungsmediums übertragen. Die vom Media-Server unterstützten Datenübertragungsformate sind im Content Directory Service für jede mögliche Ressource explizit definiert. Typischerweise kann der Gerätetyp Media-Server einem der folgenden Geräte zugeordnet werden: Digitaler Videorecorder, CD/DVD-Player, Kamera, Camcorder, PC, Set-top-Box, Satellitenempfänger, Kassettenrecorder, etc. Zur Auswahl eines bestimmten AV-Inhaltes ist üblicherweise gemäß UPnP-Standard in dem Media-Server ein Modul für ein Content Directory implementiert. Daneben gibt es auch noch ein Modul, das als Connection Manager bezeichnet wird und mit dem das Kontrollpunktgerät beim Aufbau einer Verbindung mit einem Media-Renderer kommuniziert.
Ein Media-Renderer-Gerät empfängt den vom Media-Server gesendeten AV-Datenstrom und gibt diesen entweder als Bildinformation oder als Hörinformation aus. Genauso beinhaltet das Media-Renderer-Gerät ebenfalls eine Implementation des Connection Manager Moduls für die Kommunikation mit dem Kontrollpunktgerät beim Einrichten einer Verbindung. Weiterhin ist in dem Media-Renderer-Gerät ein Modul Rendering Control implementiert. Dieses Modul empfängt Kommandos zur Einstellung von Wiedergabecharakteristiken wie Lautstärke, Ton, Bildschärfe, Kontrast, Helligkeit, Farbe usw. und setzt diese um. Als Beispiel von Geräten, denen der Gerätetyp Media-Renderer im Heimnetz zugewiesen werden sollte, werden ein TV-Gerät, ein Stereoverstärker und ein MP3-Player genannt. Abhängig vom implementierten Übertragungsformat besitzt der Media-Server oder der Media-Renderer noch einen AV-Transportservice, welcher zur Steuerung des Datentransfers und der Wiedergabe (z.B. Play, Stop, Fast Forward, etc.) dient. Ein Kontrollpunktgerät koordiniert den Datentransport zwischen Media-Server und Media-Renderer. Es wird ebenfalls dazu genutzt, um die Bedienungsbefehle der Bedienperson umzusetzen und an die entsprechenden Geräte der AV-Verbindung weiterzuleiten. Hier kommen insbesondere als Beispiel die Befehle Play, Stop, Pause, Vorlauf, Rücklauf in Betracht. Wie eingangs erwähnt, sind die Kontrollpunktgeräte auch zum Auffinden und Steuern von Standard-UPnP-Geräten ausgelegt. Darauf wird nachfolgend noch genauer eingegangen werden. Zunächst werden die Standard-Software-Komponenten eines UPnP-Gerätes anhand der 4 erläutert. Mit der Bezugszahl 35 ist ein Protokollstapel, bestehend aus den Protokollebenen Ethernet, IP und TCP bezeichnet. Bezugszahl 31 entspricht der Software-Komponente, in der die UPnP-Gerätebeschreibung entsprechend UPnP Device Description abgelegt ist. Bezugszahl 32 bezeichnet eine Software-Komponente, in der die Verwaltung von Ereignismitteilungen geschieht, entsprechend UPnP-Eventing. Eine Standardkomponente des UPnP-Gerätes ist noch ein Webserver 33. Mit der Bezugszahl 34 ist eine UPnP-Discovery-Einheit bezeichnet. Damit kann das UPnP-Kontrollpunktgerät die anderen Geräte im Netzwerk erkennen, worauf noch genauer eingegangen wird. Oberhalb dieser Blöcke ist noch ein UPnP-Anwendungsprogramm mit der Bezugszahl 30 bezeichnet. All diese Einheiten sind Standard-Komponenten in einem UPnP-Gerät und sind in der UPnP-Spezifikation genau beschrieben.
Die UPnP-Discovery-Einheit dient dazu, daß UPnP-Geräte in einem Netzwerk gefunden werden können – denn nur, wenn sie gefunden worden sind, können sie auch bedient werden. Diese Einheit funktioniert prinzipiell folgendermaßen:
Die Geräte senden "Discovery-Nachrichten" als sogenannte Multicast-UDP-Pakete aus. Dazu wird das schon erwähnte HTTPMU-Protokoll benutzt. Multicast-Datenpakete zeichnen sich dadurch aus, daß sie grundsätzlich an alle Geräte im Netzwerk übertragen werden. Die einzelnen Netzwerkstationen können sich für das Empfangen von solchen Multicast-Paketen mit ihrer speziellen Adresse registrieren. Prinzipiell gibt es zwei Arten von Discovery-Nachrichten:

1. Sogenannte Advertisement-Nachrichten. Sobald ein Gerät mit einem Netzwerk verbunden wird, soll es eine Advertisement-Nachricht aussenden. Nach dem SSDP-Protokoll handelt es sich um die Nachricht "ssdp:alive". Damit gibt es den anderen Geräten im Netzwerk bekannt, daß es nun im Netzwerk aktiv ist. Doch auch nachdem sich das Gerät im Netzwerk bekannt gemacht hat, soll es regelmäßig diese Advertisement-Nachrichten aussenden. Am Ausbleiben der Advertisement-Nachricht kann das Kontrollpunktgerät dann erkennen, daß das Gerät aus dem Netzwerk entfernt worden ist. Die maximale Periodendauer für das wiederholte Aussenden der Advertisement-Nachricht beträgt 1800 Sekunden, also eine halbe Stunde.
2. Search-Nachrichten: Um nach Geräten zu suchen, können Kontrollpunktgeräte Suchanfragen, entsprechend den "Search Requests" aussenden. Nach dem SSDP-Protokoll dient dazu die Nachricht "ssdp:discover". Ein UPnP-Gerät, das eine solche Nachricht empfängt, muß darauf antworten und somit dem Sender bekanntgeben, daß es existiert.
3. Schließlich wird noch eine dritte Art von Advertisement-Nachrichten erwähnt – die sogenannten Abmeldebotschaften, die nach dem SSDP-Protokoll als "ssdp:byebye" bezeichnet sind. Diese sollen von einem Gerät ausgesandt werden, wenn es aus dem Netzwerk entfernt wird. Tatsächlich ist dies den Geräten möglich, wenn sie regulär ausgeschaltet werden. Nur, wenn sie durch Herausziehen des Netzwerkkabels vom Netzwerk getrennt werden, ist es aus physikalischen Gründen nicht mehr möglich, die Abmeldebotschaft zu versenden.

Anhand der 5 wird jetzt ein Ausführungsbeispiel für das erfindungsgemäße Verfahren zur Feststellung der Aktivität eines Gerätes in einem Netzwerk verteilter Stationen erläutert.
5 zeigt ein Ablaufdiagramm für ein Programm, das in einem Kontrollpunktgerät zu diesem Zweck abgearbeitet wird. Der Programmstart ist mit der Bezugszahl 50 versehen. Bezugszahl 51 markiert eine Abfrage, in der überprüft wird, ob für das zu testende Gerät bereits eine ssdp:byebye-Nachricht eingetroffen ist. Wenn das der Fall ist, brauchen die weiteren Verarbeitungsschritte 52 bis 55 nicht durchgeführt werden und das Programm verzweigt direkt zum Schritt 56, in dem das fragliche Gerät als vom Netzwerk abgemeldet eingestuft wird. Danach würde das Programm mit Programmschritt 58 enden. Wurde in Abfrage 51 noch keine Abmeldebotschaft für das fragliche Gerät erkannt, folgt im Programmschritt 52 eine Suchanfrage für das fragliche Gerät. Das Kontrollpunktgerät sendet dazu die ssdp:discover-Nachricht an das fragliche Gerät aus. Mit Abfrage 53 wird dann überprüft, ob die Suchanfrage von der angesprochenen Netzwerkstation innerhalb eines bestimmten Zeitraums beantwortet wurde. Wenn ja, wird die Netzwerkstation im Programmschritt 57 als aktive Netzwerkstation deklariert. Hier kann der entsprechende Eintrag bei der Tabelle der Netzwerkstationen gesetzt werden. Danach wird das Programm wieder mit dem Programmschritt 58 beendet.
Wenn in Abfrage 53 erkannt wird, daß keine Rückantwort zu der Suchanfrage eingegangen ist, folgt im Programmschritt 54 ein HTTP-Zugriff auf das XML-Dokument mit der Gerätebeschreibung für die fragliche Netzwerkstation. Die URL für diese Datei war bei Anmeldung der Netzwerkstation bekanntgegeben worden, so daß das Kontrollpunktgerät diese Information nur aus einer zugehörigen Tabelle entnehmen muß. Ein beispielhafter HTTP-Head-Aufruf ist wie folgt aufgebaut:
Head/upnp/device description.xml HTTP/1.1
Host: lokale IP-Adresse Station 3
Alternativ kann auch ein HTTP-Get-Aufruf erfolgen.
Als Steueranforderung kann z.B. das UPnP Kommando Get-Status an die Netzwerkstation per HTTP Post-Zugriff gesandt werden.
In der Abfrage 55 wird überprüft, ob die gewünschte Datei zurückgeliefert wurde. Sollte die fragliche Station inaktiv sein, konnte schon gar keine TCP-Verbindung zu dieser aufgebaut werden. Bereits daran wird die anfragende Netzwerkstation erkennen, daß der HTTP-Zugriff gescheitert ist. Es folgt daraufhin im Programmschritt 56 der Eintrag in der Tabelle für die Netzwerkstationen, zur Kenntlichmachung, daß die Netzwerkstation vom Netzwerk abgemeldet ist bzw. im Netzwerk inaktiv geworden ist. Das Programm endet danach wieder im Programmschritt 58.

Claims

Verfahren zur Feststellung der Aktivität eines Gerätes in einem Netzwerk verteilter Stationen, bei dem die Aktivität einer Netzwerkstation per Suchanfrage an eine Netzwerkstation (12 bis 16) mittels eines ungesicherten Übertragungsprotokolls überprüft wird, wobei für einen Datenzugriff und/oder zur Steuerung einer Netzwerkstation mindestens ein gesichertes Übertragungsprotokoll zur Verfügung gestellt wird, dadurch gekennzeichnet, dass bei Nichtbeantwortung der Suchanfrage seitens der gesuchten Netzwerkstation zusätzlich ein Datenzugriff und/oder eine Steueranforderung auf/an diese Netzwerkstation mittels des gesicherten Übertragungsprotokolls durchgeführt wird und, dass die Inaktivität der angesprochenen Netzwerkstation festgestellt wird, wenn über das gesicherte Übertragungsprotokoll signalisiert wird, dass der Datenzugriff und/oder die Steueranforderung fehlgeschlagen ist.
Verfahren nach Anspruch 1, wobei die Funktionalitäten einer zu steuernden Netzwerkstation in Form von einer oder mehreren Informationsdateien zur Verfügung gestellt werden, und der Datenzugriff auf eine zur Verfügung gestellte Informationsdatei der Netzwerkstation erfolgt.
Verfahren nach Anspruch 1, wobei die Informationsdatei über einen Datenbereitstellungsdienst zur Verfügung gestellt wird.
Verfahren nach Anspruch 1 oder 2, wobei die Informationsdatei eine per Beschreibungssprache generierte Informationsseite betrifft.
Verfahren nach Anspruch 2 oder 3, wobei der Datenbereitstellungsdienst als Web-Server ausgelegt wird.
Verfahren nach Anspruch 3 oder 4, wobei die Beschreibungssprache zur Generierung der Informationsseite HTML, entsprechend Hyper Text Mark-up Language oder XML, entsprechend Extended Mark-up Language, entspricht.
Verfahren nach einem der vorhergehenden Ansprüche, wobei bei dem Datenzugriff ein fehlergesichertes Datenübertragungsprotokoll verwendet wird.
Verfahren nach Anspruch 6, wobei als fehlergesichertes Datenübertragungsprotokoll das HTTP-Protokoll, entsprechend Hypertext Transfer Protocol, verwendet wird.
Verfahren nach Anspruch 8, wobei der Datenzugriff mittels eines HTTP Head-Zugriffs erfolgt und/oder die Steueranforderung mittels eines HTTP Post-Zugriffs erfolgt.
Verfahren nach einem der vorhergehenden Ansprüche, wobei für eine Suchanfrage das SSDP-Protokoll, entsprechend Simple Service Discovery Protocol, verwendet wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Netzwerk verteilter Stationen ein UPnP-basiertes Netzwerk ist, entsprechend Universal Plug and Play.
Netzwerkstation für die Durchführung des Verfahrens nach einem der vorgehenden Ansprüche, mit einer Kommunikationsschnittstelle, mit Aktivitätsüberprüfungsmitteln (36) zur Überprüfung der Aktivität einer Netzwerkstation (12 bis 16) in einem Netzwerk verteilter Stationen, wobei die Aktivitätsüberprüfungsmittel (36) Suchanfragemittel aufweisen, die eine Suchanfrage für eine Netzwerkstation in einem Netzwerk verteilter Stationen erzeugen und mittels eines ungesicherten Übertragungsprotokolls übermitteln, wobei Kommunikationsmittel vorgesehen sind, die für einen Datenzugriff und/oder zur Steuerung einer Netzwerkstation mindestens ein gesichertes Übertragungsprotokoll zur Verfügung stellen, dadurch gekennzeichnet, dass die Aktivitätsüberprüfungsmittel (36) bei Nichtbeantwortung der Suchanfrage die Kommunikationsmittel nutzen und einen Datenzugriff und/oder eine Steueranforderung für die Netzwerkstation versuchen, dass die Aktivitätsüberprüfungsmittel (36) Auswertemittel (55) aufweisen, die den Datenzugriff und/oder die Reaktion auf die Steueranforderung auswerten und die Inaktivität der angesprochenen Netzwerkstation feststellen, wenn über das gesicherte Übertragungsprotokoll signalisiert wird, dass der Datenzugriff und/oder die Steueranforderung fehlgeschlagen ist.
Netzwerkstation nach Anspruch 14, wobei das gesicherte Datenübertragungsprotokoll dem HTTP-Protokoll, entsprechend Hypertext Transfer Protocol, entspricht.
Netzwerkstation nach Anspruch 13, wobei der Datenzugriff mittels eines HTTP Head-Zugriffs erfolgt und/oder die Steueranforderung mittels eines HTTP Post-Zugriffs erfolgt.
Netzwerkstation nach einem Ansprüche 10 bis 15, wobei die Suchanfragemittel (52) für die Suchanfrage das SSDP-Protokoll, entsprechend Simple Service Discovery Protocoll, nutzen.
Netzwerkstation nach einem der Ansprüche 10 bis 16, wobei die Netzwerkstation nach dem UPnP-Standard, entsprechend Universal Plug and Play ausgelegt ist.
Netzwerkstation nach einem der Ansprüche 10 bis 17, wobei die Kommunikationsschnittstelle eine Ethernet-Schnittstelle betrifft.