DE60127968T2

DE60127968T2 - Bereitstellung von nahtloser benutzermobilität in einer drahtlosen netzumgebung kurzer reichweite

Info

Publication number: DE60127968T2
Application number: DE60127968T
Authority: DE
Inventors: Sandeep Kishan Englewood Cliffs SINGHAL; Ajei Sarat Riverdale GOPAL; Inder Sarat New York GOPAL
Original assignee: ReefEdge Inc
Current assignee: ReefEdge Inc
Priority date: 2000-08-11
Filing date: 2001-08-08
Publication date: 2008-01-17
Anticipated expiration: 2021-08-09
Also published as: AU2001283178B2; CN100391174C; CA2419114C; US20050277418A1; IL154132A; WO2002015472A3; CA2419114A1; EP1310063B1; AU8317801A; JP2004522331A; IL154132A0; ATE360307T1; US6633761B1; WO2002015472A2; EP1310063A2; CN1446419A; US20030195002A1; US6975864B2; DE60127968D1; US7197308B2

Description

TECHNISCHES GEBIET
Die vorliegende Erfindung betrifft Computernetzwerke und insbesondere Verfahren, Systeme und Computerprogrammanweisungen zum Herstellen von nahtlosen Verbindungen und für ein nahtloses Roaming mit drahtlosen Computervorrichtungen kurzer Reichweite.
HINTERGRUND
In den letzten Jahren entstanden verschiedene kurzreichweitige drahtlose Netzwerk-Kommunikationstechnologien, besonders IEEE 802.11 und Bluetooth, die tragbare Geräte (wie Laptops, Mobiltelefone, persönliche digitale Assistenten oder PDAs usw.) in die Lage versetzen, sowohl miteinander als auch mit Weitbereichsnetzwerkumgebungen in Verbindung zu treten. (IEEE 802.11 ist ein Standard des Institute for Electrical and Electronics Engineers, der 1997 für die Signale und Protokolle von drahtlosen lokalen Netzwerken oder LANs angenommen wurde. 802.11 betrifft Frequenzsprung-Ausbreitungsspektren, Direktsequenz-Ausbreitungsspektren und Übertragungen mit Infrarotlicht. Bluetooth ist eine Spezifikation für kurzreichweitige drahtlose Verbindungen, die zum Ziel hat, die Telekommunikation mit Computern zu vereinen. Im Internet sind unter www.ieee.org und www.bluetooth.com mehr Informationen über diese Spezifikationen zu finden.) Um eine solche Kommunikation zu ermöglichen, wurden verschiedene "Brücken-Zugangspunkte" entwickelt. Diese Brücken-Zugangspunkte erlauben es einem Gerät, sich selbst in das lokale LAN einzuklinken. Alle von dem Gerät übertragenen Pakete werden dann einfach auf dem LAN weitergegeben, und das Gerät kann alle Pakete auf dem LAN lesen (wobei der Zugangspunkt möglicherweise eine gewisse Filterung auf der Basis von zum Beispiel der Media Access Control oder MAC-Adresse des Geräts durchführt). Beispiele für kommerziell zur Verfügung stehende Brücken-Zugangspunkte sind die Produkte von Cisco und Lucent (für 802.11) und Widcomm und Axis (für Bluetooth). Ein anderes beispielhaftes System ist in der EP-A-0 851 633 beschrieben.
Die existierenden kurzreichweitigen drahtlosen LAN-Lösungen weisen jedoch eine Anzahl von Einschränkungen auf. Eine wesentliche Einschränkung ist, daß ein nahtloses Roaming unmöglich ist. Das heißt, daß die Verbindung an einem Gerät, das sich von einem Zugangspunkt zu einem anderen bewegt, nur dann bestehen bleibt, wenn sich alle Zugangspunkte im gleichen physikalischen LAN befinden. Es gibt keine Lösungen, die es einem Gerät ermöglichen, sich nahtlos von einem LAN zu einem anderen zu bewegen, die nicht den Einsatz einer völlig neuen Infrastruktur erforderlich machen (und wesentliche Änderungen an der Software des Geräts selbst). Dies ist besonders in einer drahtlosen Umgebung problematisch, da die Nutzer das physische Layout der LAN-Topologie meist nicht kennen und daher gar nicht realisieren, wenn sie sich physisch aus der Reichweite eines bestimmten LAN heraus bewegen.
Insbesondere in einer Bluetooth-Umgebung ist das Roaming über Brücken-Zugangspunkte hinweg besonders schwierig. Um die Verbindung bei der Bewegung von einem Zugangspunkt zu einem anderen zu behalten, muß ein Gerät seine Internet-Protokoll-(IP)-Adresse behalten. Ein Bluetooth-Teilnehmergerät erhält seine IP-Verbindung jedoch durch Ausbilden einer neuen Punkt-zu-Punkt-Protokoll-(PPP)-Verbindung mit jedem Zugangspunkt, so daß der Bluetooth-Teilnehmer daher (unter Verwendung des dynamischen Host-Konfigurationsprotokolls oder DHCPs) eine neue IP-Adresse anfordert. Das Erhalten einer neuen IP-Adresse für ein bestimmtes Teilnehmergerät jedesmal dann, wenn es sich zu einem anderen Zugangspunkt bewegt, unterbricht daher die Verbindung zu dem Gerät und macht damit das Roaming undurchsichtig. (PPP ist im Request For Comments (RFC) 1661 vom Juli 1994 dokumentiert. DHCP ist im RFC 2131 vom März 1997 dokumentiert. Beide sind im Internet unter www.ietf.org zu erhalten.) Eine Lösung des nahtlosen Roaming-Problems umfaßt die Verwendung einer mobilen IP. In diesem Schema ändert sich die IP-Adresse eines mobilen Geräts nicht, wenn es sich von einem Netzwerk zu einem anderen bewegt. Dazu besitzt ein Gerät in seinem Heim-Netzwerk einen festen "Heim-Agenten". Wenn sich das Gerät bewegt, meldet es sich bei einem "fremden Agenten" auf einem anderen Netzwerk an. Nachrichten von dem Gerät und für das Gerät werden über den fremden Agenten geführt (d.h. geleitet). Da sich bei dieser Konfiguration die IP-Adresse statisch verhält, kann ein Roaming stattfinden. Diese Lösung weist jedoch eine Reihe von Nachteilen auf. Erstens ist sie nur für den Gebrauch mit der IP-Version 4 ("IPv4") definiert und funktioniert nicht mit der IP-Version 6 ("IPv6"), die auch als "IP der nächsten Generation" bezeichnet wird und die IPv4 ersetzen soll. Außerdem erfordert eine mobile IP-Lösung, daß der LAN-Administrator auf jedes LAN einen fremden Agenten setzt, jedem Nutzer einen bekannten Heim-Agenten zuordnet und jedem Gerät eine feste (permanente) IP-Adresse zuteilt. Dieses letzte Erfordernis ist besonders schwierig, da im heutigen Internet netfähige IP-Adressen eine begrenzte Ressource darstellen; darüberhinaus teilen aus Sicherheitsgründen die meisten Systemadministratoren internen Hosts private Adressen zu und verstecken diese Adressen vor dem größeren Internet durch die Verwendung einer Firewall, die eine Netzwerkadressentranslation (NAT) ausführt. Eine mobile IP erfordert auch erhebliche Mühe beim Installieren und Konnfigurieren eines arbeitsfähigen Systems.
Von Alex Snoeren und Hari Balakrishnan wurde in ihrer Veröffentlichung "An End-to-End Approach to Host Mobility"; Proceedings of MobiCom 2000, August 2000 eine Lösung des Roaming-Problems vorgeschlagen. Diese Autoren haben die Grenzen der mobilen IP erkannt und schlagen daher vor, einen zusätzlichen Mechanismus zum Transmission Control Protocol (TCP) hinzuzufügen, der es ermöglicht, eine ausgebildete Verbindung auf eine neue IP-Adresse eines Teilnehmers "abzubilden" und dadurch eine nahtlose Mobilität zu erreichen. Auf diese Weise kann der Teilnehmer beim Roaming eine neue IP-Adresse erhalten und darauf alle seine offenen Verbindungen abbilden. Auch diese Vorgehensweise hat jedoch eine Reihe von Nachteilen. Sie erfordert das Ändern der TCP- Implementierung bei allen Teilnehmern und Servern, was praktisch nicht möglich ist. Anwendungen, die die IP-Adresse des Geräts handhaben, müssen so modifiziert werden, daß sie die Änderung der IP-Adresse beim Roaming des Geräts erkennen und entsprechend handeln. Diese Lösung arbeitet nicht bei User Datagram Protocol (UDP)/IP-Kommunikationen. Auch beruht das System auf dem dynamischen Domain-Namens-Service (DDNS), der es räumlich entfernten Hosts ermöglicht, die gegenwärtige IP-Adresse des Teilnehmers zu erfahren; unglücklicherweise hat sich das DDNS jedoch noch nicht ganz durchgesetzt.
Was noch benötigt wird, ist dementsprechend eine kurzreichweitige drahtlose Lösung, die nahtlose Netzwerkverbindungen ermöglicht, jedoch nicht unter den Einschränkungen der bekannten Techniken leidet.
ZUSAMMENFASSUNG DER ERFINDUNG
Die vorliegende Erfindung ist wie im Patentanspruch 1 angegeben auf ein Verfahren zum Herstellen einer nahtlosen Verbindung und auf ein nahtloses Roaming mit kurzreichweitigen drahtlosen Computergeräten, auf ein System wie in Patentanspruch 35 angegeben und auf ein computerlesbares Medium wie in Patentanspruch 36 beansprucht gerichtet.
Die beschriebenen Techniken ermöglichen es einer Vielzahl von Geräten, insbesondere Handgeräten geringer Leistung, sich nahtlos durch eine Netzwerkumgebung (wie sie etwa in einem Gebäude angetroffen wird) zu bewegen und dabei Verbindungen zu einer Anzahl von Netzwerk-Zugangspunkten aufzubauen. Diese Netzwerk-Zugangspunkte werden hier als Handoff-Managementpunkte (HMPs) bezeichnet. Die Illusion einer nahtlosen Netzwerkverbindung wird dadurch geschaffen, daß diese Zugangspunkte für die Nutzer-Authentifizierung, die Zuteilung der Geräteadresse und die Übergabedienste mit einem Kernserver zusammenarbeiten.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1 zeigt die Komponenten der bevorzugten Ausführungsform der vorliegenden Erfindung;
2 ein Beispiel für ein HMP-Register, das bei der bevorzugten Ausführungsform der vorliegenden Erfindung verwendet werden kann;
3 ein Beispiel für ein aktives Nutzerort-(AUL)-Register, das bei der bevorzugten Ausführungsform der vorliegenden Erfindung verwendet werden kann;
4 ein Flußdiagramm für den logischen Ablauf beim Hochfahren des Handoff-Managementpunkts (HMP) und bei dessen Verbindung mit dem Netzwerk bei der bevorzugten Ausführungsform der vorliegenden Erfindung;
5 ein Flußdiagramm für den logischen Ablauf bei der Verarbeitung eines HMP-Präsenzprotokolls durch einen Handoff-Kernserver bei der bevorzugten Ausführungsform der vorliegenden Erfindung;
6 ein Flußdiagramm für den logischen Ablauf, wenn ein Teilnehmer beim nahtlosen Roaming durch das Netzwerk dem HMP bekannt wird, bei der bevorzugten Ausführungsform der vorliegenden Erfindung;
7 ein Flußdiagramm für den logischen Ablauf beim Ausführen eines HMP-Übergabeprotokolls bei der bevorzugten Ausführungsform der vorliegenden Erfindung;
8 eine beispielhafte Verlaufsaufzeichnung bei der bevorzugten Ausführungsform der vorliegenden Erfindung; und
9 eine beispielhafte Vorgehensdatei, die bei der bevorzugten Ausführungsform der vorliegenden Erfindung verwendet werden kann.
GENAUE BESCHREIBUNG DER ERFINDUNG
Die vorliegende Erfindung wird nun anhand der beiliegenden Zeichnungen, in denen eine bevorzugte Ausführungsform der Erfindung gezeigt ist, genauer beschrieben. Gleiche Bezugszeichen bezeichnen dabei immer gleiche Elemente.
Die vorliegende Erfindung wird im folgenden mit Bezug zu Flußdiagrammdarstelungen von Verfahren, Vorrichtungen (Systemen) und Computerprogrammanweisungen beschrieben, die auf einem computerlesbaren Medium oder auf mehreren computerlesbaren Medien gemäß einer Ausführungsform der Erfindung liegen. Wie der Fachmann erkennt, stellen diese Flußdiagramme nur Beispiele für die Art dar, wie die bevorzugte Ausführungsform der vorliegenden Erfindung ausgeführt werden kann, und daß der gezeigte logische Ablauf abgeändert werden kann (zum Beispiel durch Ändern der Reihefolge von Operationen in einigen Fällen, durch Kombinieren von Operationen usw.), ohne vom beschriebenen erfinderischen Konzept abzuweichen.
In der 1 sind die vier Hauptkomponenten einer Ausführung der vorliegenden Erfindung dargestellt. Diese Komponenten sind (1) Teilnehmergeräte 120; (2) Handoff-Managementpunkte 110; (3) Handoff-Kernserver 100; und (4) Anwendungsserver 130. Jede dieser Komponenten wird nun in Verbindung mit der vorliegenden Erfindung beschrieben.
Die bei der vorliegenden Erfindung verwendeten Geräte 120 (wie Laptop-Computer, Handheld-Computer, PDAs, Mobiltelefone usw.) sind jeweils mit der Möglichkeit zur kurzreichweitigen drahtlosen Kommunikation ausgerüstet. Die jeweils verwendete Kommunikationsmöglichkeit bildet keinen Teil der vorliegenden Erfindung und kann Technologien wie 802.11, Bluetooth und ähnliche (jetzt noch nicht entwickelte) Technologien umfassen. Die drahtlose Ausrüstung kann in das Gerät eingebaut sein. Sie kann auch auf eine andere Weise zur Verfügung stehen, einschließlich, ohne darauf beschränkt zu sein: Über eine Plug-In-Karte (wie eine PCMCIA-Karte oder eine Personal Computer Memory Card oder eine International Association Card) oder durch Anbringen eines Dongle (d.h. eines Plug-In-Geräts an einem USB- oder Universal Serial Bus-Anschluß oder einem RS-2332-Anschluß).
Die HMPs 110 weisen zwei Netzwerkinterfaces auf. Das eine ist eine kurzreichweitige drahtlose Verbindung (die zur Kommunikation mit den Geräten 120 verwendet wird) und das andere eine Verbindung zu einer Netzwerkumgebung (wie einem Intranet oder dem Internet), in der sich eine Zielanwendung befindet, auf die von einem sich bewegenden Gerät 120 zugegriffen wird. Bei der bevorzugten Ausführungsform ist das zweite Interface ein Ethernet-Interface, alternativ können jedoch auch andere Protokolle verwendet werden, etwa das Token Ring-(IEEE 802.5), 802.11- und andere Protokolle. Die Geräte verwenden den HMP als ihren Kanal zum Senden um Empfangen von Netzwerkpaketen in die und aus der Netzwerkumgebung.
In der Netzwerk-Infrastruktur befindet sich ein zentraler Handover-Kernserver 100 (im folgenden als "Kern" bezeichnet), der den HMPs 110 Dienste bereitstellt, wenn sich die Nutzer der Geräte 120 durch die Umgebung bewegen.
Auf einem oder auf mehreren Anwendungsservern 130 befindet/befinden sich die Anwendung(en), auf die von den Geräten 120 zugegriffen wird, während sie sich durch das kurzreichweitige drahtlose Netzwerk bewegen.
Der Kern enthält vorzugsweise zwei Datenspeicher, die er dazu verwendet, das nahtlose Roaming eines Geräts 120 von einem HMP 110 zu einem anderen zu ermöglichen. Diese Speicher werden hier als das HMP-Register und das AUL-Register bezeichnet.
Das HMP-Register enthält eine Aufstellung der gegenwärtig bekannten HMPs, die Teil des Roaming-Bereichs sind, der vom Kern abgedeckt wird. In der bevorzugten Ausführungsform registriert das HMP-Register den Zeitpunkt, wenn sich ein HMP zuerst am Kern anmeldet, wenn die Registrierung zuletzt erneuert wurde, und wenn die gegenwärtige Registrierung abläuft. (Die HMP-Registrierung wird genauer weiter unten erläutert.) Weitere Felder in diesem Register umfassen vorzugsweise die MAC-Adresse des HMP, die IP-Adresse des HMP, wahlweise Identifikationsinformationen über den HMP (wie der vom Administrator zugewiesene Name, Hersteller, Modellnummer usw.) und (wahlweise) den gegenwärtigen physischen Ort.
In der 2 ist ein beispielhaftes HMP-Register 200 dargestellt. Als Schlüssel zum Zugang zu den Einträgen im HMP-Register wird vorzugsweise die MAC-Adresse des HMP (Spalte 210) verwendet. Die beispielhaften IP-Adressen in der Spalte 220 sind IPv4-Adressen, auch wenn dies nur der Illustration dient und keine Einschränkung darstellt. Alternativ können auch andere Adressenformen, insbesondere IPv6, angegeben werden. In der Spalte 230 sind die Zeitpunkte der Erst-Registrierung für die beispielhaften HMPs 270 und 280 enthalten. Die Spalte 240 enthält dann den neueren Zeitpunkt der Erneuerung der Registrierung, die zu dem Zeitpunkt abläuft, der in der Spalte 250 angegeben ist. Die Spalte 260 enthält schließlich weitere Informationen über jeden HMP, etwa welche Art Gerät es ist und wo er sich physisch befindet.
Das AUL-Register enthält eine Liste der gegenwärtig aktiven Nutzer, die HMP(s) im Gebiet des Kernservers nutzen. Die Felder in diesem Register umfassen vorzugsweise den Namen oder einen anderen Identifikator für jeden aktiven Nutzer (im folgenden zur leichteren Bezugname als Nutzername bezeichnet); die IP-Adresse des Geräts, das von diesem Nutzer benutzt wird; die MAC-Adresse des Geräts; und die MAC-Adresse(n) eines oder mehrerer der HMPs, über die das Gerät gegenwärtig kommuniziert.
In der 3 ist ein beispielhaftes AUL-Register 300 dargestellt. Die MAC-Adresse des Geräts (Spalte 330) wird vorzugsweise als Schlüssel zum Zugang zu den Einträgen im AUL-Register verwendet. Alternativ kann eine Kombination des Nutzernamens 310, der Geräte-IP-Adresse 320 und/oder der Geräte-MAC-Adresse 330 entsprechend den Erfordernissen einer bestimmten Ausführung der vorliegenden Erfindung als Schlüssel verwendet werden. Wie oben anhand der 2 erläutert, sind die in der Spalte 320 gezeigten beispielhaften IP-Adressen zur Illustration IPv4-Adressen. Wie in der Spalte 340 gezeigt, kann das Gerät, das ein bestimmter Nutzer benutzt, zur Zeit mit einem einzigen HMP verbunden sein (wie es beim Nutzer 350 der Fall ist), oder es kann mit mehreren HMPs verbunden sein (wie es für den Nutzer 360 gezeigt ist).
Anhand des in den Flußdiagrammen der 4 bis 7 gezeigten logischen Ablaufs wird nun die Art und Weise beschrieben, wie sich die HMPs selbst beim Kern vorstellen und wie diese Informationen vom Kern dazu verwendet werden, es Geräten zu ermöglichen, sich nahtlos von einem HMP zu einem anderen zu bewegen.
Ein HMP bootet, wird dann im Netzwerk bekannt, und kommuniziert schließlich über das Netzwerk, um die Verbindung mit dem Kern aufrecht zu erhalten. Diese Verbindung ist erforderlich, um sicherzustellen, daß der HMP mit dem Kern bei Weitergabe seiner Nutzergeräte zusammenarbeiten kann, und um sicherzustellen, daß der Kern weiß, welcher HMP funktioniert und welcher ausgefallen ist, abgekoppelt wurde oder anderweitig nicht mehr zur Verfügung steht. Die 4 zeigt die bevorzugte Ausführungsform des logischen Ablaufs, mit der dieser Prozeß erfolgt.
Wenn der HMP bootet, erhält er eine IP-Adresse (Block 400). Bei der bevorzugten Ausführungsform wird diese IP-Adresse mittels DHCP erhalten, es können aber auch andere Adressenbestimmungsverfahren (wie das BOOTP- oder RARP-Protokoll) alternativ verwendet werden, ohne vom beschriebenen erfinderischen Konzept abzuweichen.
Der HMP muß auch den Ort des Kerns feststellen, wie es im Block 410 gezeigt ist. Diese Feststellung des Orts des Kerns kann ein beliebiges des üblichen Satzes von Erfassungsprotokollen anwenden, etwa das Service Location Protokoll (SLP), das DHCP oder den Domain-Namen-Service (DNS). Bei der bevorzugten Ausführungsform wird DHCP verwendet. Bekanntlich kann ein DHCP-Server so konfiguriert werden, daß er Teilnehmer nicht nur mit einer IP-Adresse versorgt, sondern auch mit anderen Konfigurationsinformationen (wie der Adresse von DNS-Servern, der Adresse des lokalen Routers usw.). Dieses Merkmal kann dadurch vorteilhaft bei der vorliegenden Erfindung angewendet werden, daß ein System-Administrator den DHCP-Server so konfiguriert, daß er einen bootenden HMP zusätzlich zu der IP-Adresse des HMP mit der Adresse des Kernservers versorgt. Wenn der DHCP-Server zusammen mit der IP-Adresse des HMP auch die Adresse des Kernservers übermittelt, wird diese Kernserveradresse als Ergebnis des Blocks 410 ver wendet. Anderenfalls gibt der HMP eine explizite Anfrage nach dieser Information aus (unter Verwendung z.B. einer SLP-Abfrage).
Jeder HMP muß den Kernserver von seinem Vorhandensein in Kenntnis setzen, und dieses Vorhandensein wird dann vom Kern in seinem HMP-Register aufgezeichnet (wie oben angegeben). Zum Registrieren jedes bootenden HMPs beim Kern wird daher ein "HMP-Präsenzprotokoll" verwendet. Dieses Protokoll beginnt beim HMP, der eine Registrieranforderung an den Kernserver ausgibt (Block 420). Bei der Registrieranforderung werden die MAC-Adresse und die IP-Adresse des HMP angegeben und wahlweise auch noch andere Identifikationsinformationen. (Siehe die Spalten 210, 220 und 260 des beispielhaften HMP-Registers der 2.)
Wahlweise kann der HMP eine bestimmte Gültigkeitsdauer der Registrierung anfordern (wie es genauer noch mit Bezug zum Block 430 beschrieben wird). Wenn diese Option verwendet wird, wird die vom HMP angeforderte Gültigkeitsperiode vorzugsweise als optionales Feld in der Registrieranforderungsnachricht angegeben. Diese Nachricht kann entsprechend den Erfordernissen einer bestimmten Ausführung eine Anzahl von optionalen Feldern enthalten, wobei jedes Feld vorzugsweise einen bekannten numerischen Identifikator enthält, der zur Anzeige seines Vorhandenseins verwendet wird. In der Registrieranforderungsnachricht wird dann das Paar (Option Identifikator, Option Wert) angegeben, wobei im vorliegenden Fall der Identifikator der Option angibt, daß dies die Informationen sind, die für die Gültigkeitsdauer der Registrierung verwendet werden sollen. Vorzugsweise wird der Wert als Offset angegeben, der dann vom Kern dazu verwendet wird, den tatsächlichen Ablaufzeitpunkt (etwa den in der Spalte 250 der 2 gezeigten) zu berechnen.
Nach der Ausgabe der Registrationsanforderung wartet der HMP auf die Antwort des Kerns. Wie bei dem Entscheidungsblock 430 gezeigt, stellt der HMP nach Erhalt der Antwort fest, ob die Antwort eine erfolgreiche Registrierung anzeigt. Wenn die Antwort negativ ist, deaktiviert sich im Block 490 der HMP vorzugsweise selbst. (Er kann jedoch den Registrierprozeß jederzeit durch den Neubeginn des logischen Ablaufs am Block 400, 410 oder 420 wieder starten.)
Wenn die Antwort im Entscheidungsblock 430 positiv ist, steht dies für eine erfolgreiche Registrierung (d.h. die Registrierung wird vom Kern akzeptiert, wie es genauer weiter unten mit Bezug zur 5 beschrieben wird), und die Steuerung geht zum Block 440 über. Bei der bevorzugten Ausführungsform zeigt die Antwort vom Kernserver an, für wie lange diese HMP-Registrierung gültig ist. (Vorzugsweise wird dieser Wert vom Kern als Offsetwert gesendet, und der HMP verwendet dann den Offsetwert zur Berechnung des tatsächlichen Ablaufzeitpunkts. Bei dieser Technik spielen Uhrzeitunterschiede zwischen dem Kern und dem HMP keine Rolle. Alternativ kann vom Kern als Ablaufzeitpunkt ein bestimmtes Datum und ein bestimmter Zeitpunkt gesendet werden.) Die Gültigkeitsdauer der Registrierung kann wahlweise auch beiden oder nur dem Kern oder dem HMP von vornherein bekannt sein. Die Art und Weise, wie die Länge der Gültigkeitsdauer bestimmt wird, kann ausführungsspezifisch sein, sie bildet nicht Teil der vorliegenden Erfindung. Alternativen umfassen das Festlegen eines festen Werts in einer Konfigurationsdatei (oder einem Konfigurationsregister, einer Datenbank usw.); das Angeben eines festen Werts mit einem administrativen Werkzeug; das feste Einkodieren eines Wertes in eine Ausführung des Kerns (und/oder des HMP, wenn der HMP bei der Registrationsanforderung einen Anforderungsparameter für die Gültigkeitsdauer vorgibt); das dynamische Bestimmen der Gültigkeitsdauer auf der Basis von Umgebungsfaktoren oder anderen Faktoren (wie der gegenwärtigen Auslastung des Kerns, dabei wird berücksichtigt, daß der Registrationsprozeß und insbesondere die erneute Registrierung eines bereits registrierten HMPs am Kern eine Verarbeitungslast darstellt); usw.
Bei der bevorzugten Ausführungsform ist die Gültigkeitsdauer der Registration für jeden HMP gleich lang. Alternativ kann bei einer Ausführung der vorliegenden Erfindung die Gültigkeitsdauer für jeden HMP anders sein. Wenn zum Beispiel für einen bestimmten HMP bekannt ist, daß er häufiger ausfällt als irgendein Mittelwert vorgibt, oder wenn bekannt ist, daß ein HMP relativ oft bewegt wird, kann es wünschenswert sein, einem solchen HMP eine Gültigkeitsdauer für die Registration zu geben, die diese Faktoren berücksichtigt. Als weiteres Beispiel kann einem neu aufgetauchten HMP eine kurze Ablaufzeit zugeteilt werden, während einem HMP, der dem Kern bereits relativ lange bekannt ist, eine längere Ablaufzeit zugeteilt werden kann (vielleicht in der Erkenntnis, daß ein neuer HMP eher wieder bewegt wird, ein bereits seit langem feststehender HMP jedoch weniger).
Der Kernserver der bevorzugten Ausführungsform unterstützt vorzugsweise hinsichtlich der Registrations-Gültigkeitsdauer ein Mischmodell, wobei die Werte für die Gültigkeitsdauer von den HMPs akzeptiert werden, die diese Information angeben, und wobei der Kern den anderen HMPs Werte für die Gültigkeitsdauer vorgibt. (Es ist offensichtlich, daß der Kern den Wert der Gültigkeitsdauer, der von einem HMP vorgegeben wird, unter Verwendung von statischen oder dynamischen Faktoren wie der oben erwähnten Auslastung des Kerns auch modifizieren kann.) Alternativ kann ein Kernserver in einer bestimmten Ausführung auch immer die Gültigkeitsdauer erzeugen (und dabei gegebenenfalls vom HMP zugeführte Werte ignorieren), oder immer einen Wert vom HMP erwarten (wobei für die HMPs, die diese Information nicht abgeben, ein Standardwert verwendet wird).
Wenn die vom Kern erhaltene Registrationsantwort positiv ist und der Prozeß daher zum Block 440 übergeht, wartet hinsichtlich des HMP-Präsenzprotokolls der HMP, bis der Ablaufzeitpunkt für die Gültigkeitsdauer der Registration kommt, und gibt dann eine Anforderung ab, die Registration zu erneuern (Block 450). Mit dieser Ablauf- und Erneuerungstechnik für die Registrierung setzt der HMP den Kern periodisch davon in Kenntnis, daß er immer noch "am Leben" ist und funktioniert, und die Antwort vom Kern setzt den HMP periodisch davon in Kenntnis, daß seine Registration und die Beteiligung am Gebiet des Kerns immer noch gilt (vorausgesetzt, die Antwort auf die Erneuerungsanforderung ist positiv). Nach dem Absenden der Erneuerungsanforderung (die wahlweise eine Gültig keitsdauer enthalten kann, wie oben beschrieben), geht der Ablauf zum Block 430 über und wartet auf die Antwort des Kerns (und den Beginn des dazugehörigen Prozesses).
Durch die Verwendung des beschriebenen HMP-Präsenzprotokolls kann ein HMP booten, sich konfigurieren und in den Kernserver integrieren, ohne daß ein Administrator eingreift. Die nahtlose Verbindung und das nahtlose Roaming ist daher einfach und kostengünstig zu erhalten, und es ist nicht der riesige administrative Aufwand der vorhandenen, manuell konfigurierten drahtlosen Netzwerklösungen des bekannten Standes der Technik erforderlich.
Die Prozesse, die im Kernserver stattfinden, um das HMP-Präsenzprotokoll auszuführen, werden nun anhand der 5 beschrieben. Der Prozeß beginnt am Block 500, mit dem der Kern von einem HMP eine Registrieranforderung aufnimmt (oder eine Registrier-Erneuerungsanforderung). Im Entscheidungsblock 510 stellt der Kern fest, ob diese Registrierung akzeptiert werden soll oder nicht. Eine Registrieranforderung kann entsprechend den Erfordernissen einer bestimmten Ausführung aus verschiedenen Gründen zurückgewiesen werden. Zum Beispiel können den Kern betreffende Bedingungen bewertet werden, etwa ob der Kern zur Zeit mit maximaler Auslastung arbeitet oder mit maximalem Wirkungsgrad oder mit maximaler Lizenzkapazität, und wenn ja, kann eine neue Registrierung zurückgewiesen werden. (Es ist auch wünschenswert, unter bestimmten den Kern betreffenden Bedingungen wie diesen Registriererneuerungsanforderungen zurückzuweisen.) Oder der Kern hat festgestellt, daß ein bestimmter HMP defekt ist und häufig ausfällt (und dabei Netzwerkstörungen verursacht) oder anderweitig schlecht arbeitet. In einem solchen Fall kann die Anforderung zur Registrierung eines HMP (oder zur Erneuerung der Registrierung) zurückgewiesen werden. (Die Registriernachrichten für neu hinzugekommene HMPs und die Registriererneuerungsnachrichten für bereits bekannte HMPs, die vom Kern gemäß dem logischen Ablauf der 5 zu verarbeiten sind, werden im folgenden einfach als Registrieranforderungsnachrichten bezeichnet, um die Bezugnahme zu erleichtern.) In der bevorzugten Ausführungsform beruht die Kapazität auf Faktoren wie (1) der Anzahl der gekauften Lizenzen (die Lizenzen für eine feste Anzahl von HMPs, eine feste Anzahl von unterstützten Nutzern und/oder eine feste Anzahl von Nutzergeräten umfassen kann); (2) dem gegenwärtigen Verkehr oder der Auslastung der CPU; und/oder (3) Speicherbeschränkungen in den Ressourcen des Kerns (einschließlich dessen, ob das beschriebene HMP-Register und das beschriebene AUL-Register mehr Registrationsinformationen aufnehmen können). Wahlweise können für weitere Kapazitätsinformationen von einem Systemadministrator Möglichkeiten vorgesehen werden, zum Beispiel um die Registrierungen aus Sicherheitsgründen einzuschränken.
Wenn die Antwort auf den Entscheidungsblock 510 negativ ist (das heißt die Registrierung zurückgewiesen wird), geht der Ablauf zum Block 590 über, mit dem eine negative Antwort zu dem anfordernden HMP gesendet wird. (Der Server kann wahlweise existierende Einträge im HMP-Register für einen zurückgewiesenen HMP löschen, wenn die Anforderung eine Registriererneuerung betrifft.) Die Steuerung kehrt dann zum Block 500 zurück und wartet auf die nächste eingehende Registrieranforderung.
Wenn die Antwort im Entscheidungsblock 510 positiv ist, stellt der Kern im Block 520 fest, ob der anfordernde HMP bereits im HMP-Register registriert ist. Wie oben mit Bezug zur 2 angegeben, wird als Schlüssel für den Index im HMP-Register vorzugsweise die MAC-Adresse des HMP (die mit der Registrieranforderungsnachricht erhalten wird) verwendet.
Wenn sich für diesen HMP ein Eintrag im HMP-Register befindet, ist das Ergebnis im Entscheidungsblock 520 positiv, und der Ablauf geht zum Block 530 über. Im Block 530 wird der Eintrag des HMP im Register mit einem neuen Ablaufzeitpunkt für die Registrierung (der vom Kern, aus Informationen vom HMP oder als Kombination davon bestimmt werden kann, wie es oben beschrieben wurde) aktualisiert. Im Block 590 wird dann eine Antwortnachricht zum HMP zurückgegeben, und die Steuerung kehrt zum Block 500 zurück.
Wenn für diesen HMP im HMP-Register kein Eintrag gefunden wird, ist das Ergebnis im Entscheidungsblock 520 negativ, und im Block 540 wird ein neuer Eintrag erzeugt. Zusätzlich zum gegenwärtigen Datum und Zeitpunkt und der Gültigkeitsdauerinformationen, die wie beschrieben bestimmt werden, werden für diesen neuen Eintrag Informationen über den HMP verwendet, die bei der bevorzugten Ausführungsform mit der Registrieranforderungsnachricht erhalten werden. (Alternativ können auch Informationen von anderen Quellen genutzt werden. Zum Beispiel können Informationen darüber, wo sich ein bestimmter HMP physisch befindet, durch Durchsehen der vorhandenen Einträge in einem Verzeichnis oder einer Tabelle erhalten werden, oder sie können über eine externe Dateneingabeanwendung erhalten werden, die von einem Systemadministrator ausgeführt wird.)
Nach dem Erzeugen des neuen Eintrags für das HMP-Register wird an den anfordernden HMP eine Antwort zurückgegeben (Block 590), und die Steuerung geht zum Block 500 zurück und wartet auf die Ankunft der nächsten Registrieranforderungsnachricht.
Es ist anzumerken, daß während dieses Prozesses ein HMP-Registereintrag für einen HMP, dessen Registrationsablaufzeit ohne erfolgreiche Erneuerung abgelaufen ist, so behandelt wird, als ob er vorher nicht existiert hätte. Der Kern kann periodisch gegenstandslos gewordene Einträge aus seinem HMP-Register löschen, um solche Situationen zu berücksichtigen. Auch kann ein HMP den Kern explizit dazu auffordern, seine Registrierung zu beenden, wobei dann der Kern den Eintrag des HMP aus dem HMP-Register löscht. (Ein solcher Beendigungsablauf ist in den 4 und 5 nicht gezeigt, der Fachmann erkennt jedoch sofort, wie ein solcher logischer Ablauf eingefügt werden kann.) Bei der bevorzugten Ausführungsform werden, wenn ein Eintrag im HMP-Register abläuft oder gelöscht wird, auch die entsprechenden Einträge im AUL-Register gelöscht, die diesen HMP betreffen (siehe Spalte 340 in der 3).
Auf diese Weise kennt der Kern die HMPs in seinem Gebiet und verfolgt deren Schicksal. Der Kern kann auch Ausfälle oder ein Abschalten von HMPs feststellen, weshalb er Einträge im HMP-Register (und AUL-Registerinformationen) für HMPs löscht, die ihre Registrierung nicht erneuern.
Anhand der 6 wird nun die Art und Weise beschrieben, wie ein Teilnehmergerät über HMPs in der Nähe kommuniziert und damit ein nahtloses Roaming erhalten wird. Durch das Ausbilden einer Verbindung mit einem HMP, zu dem ein Zugang möglich ist (d.h. einem HMP, der sich innerhalb der Reichweite des Geräts befindet), wird eine Sitzung oder ein Kanal ausgebildet, über den in der Folge der IP-Verkehr fließen kann. Dieser IP-Verkehr wird dann durch den HMP und/oder den Kern zu seinem Zielort geleitet. In einer Bluetooth-Umgebung zum Beispiel ist dieser Kanal vorzugsweise eine PPP-Verbindung, die über die Bluetooth-RFCOMM-Ebene ausgebildet wird. In einer 802.11-Umgebung wird der Kanal vorzugsweise implizit ausgebildet, wenn der IP-Verkehr zum ersten Mal zum HMP fließt. In der bevorzugten Ausführungsform wird ein Authentifizierungsprozeß durchgeführt, um die Nutzer der verbundenen Geräte zu authentifizieren, bevor ein Kommunikationskanal erfolgreich ausgebildet werden kann. Der Kernserver enthält zu diesem Zweck vorzugsweise ein RADIUS-Interface. (RADIUS, oder Remote Authentication Dial In User Service ist im RFC 2865, Juni 2000, dokumentiert.) Der Name und das Paßwort des Nutzers werden dem räumlich entfernten Endpunkt (der bei der vorliegenden Erfindung der HMP ist) zugeführt. PPP zum Beispiel sieht das Weiterleiten dieser Informationen zum HMP als Teil der Ausbildung der PPP-Verbindung vor. Nach Erhalt des Nutzernamens und des Paßworts verwendet der HMP dann RADIUS, um diese Informationen zu einem Authentifizierungsserver (der bei der vorliegenden Erfindung der Kernserver ist) weiterzuleiten.
Nach dem Ausbilden eines Kommunikationskanals (bei der Verwendung eines Protokolls auf Verbindungsebene wie PPP, wie hier mit Bezug zu Bluetooth dargestellt), gibt das Teilnehmergerät dann eine DHCP-Adressenzuteilungsanforderung (Block 600 der 6) aus, um eine IP-Adresse zu erhalten. (Wenn wie oben mit Bezug zu 802.11 angegeben in Reaktion auf einen erfaßten IP-Verkehr eine implizite Kanalausbildung erfolgt, kann dieser IP-Verkehr selbst die DHCP-Anforderung sein.)
Bei der bevorzugten Ausführungsform verwendet das Teilnehmergerät beim Roaming durch die drahtlose Netzwerkumgebung immer die gleiche IP-Adresse. Dadurch kann das Gerät eine durchgehende Verbindung mit allen Anwendungen aufrecht erhalten, die es ausführt. Folglich wird die IP-Adresse des Geräts durch den Kernserver zugeteilt. Der Kern stellt sicher, daß alle DHCP-Anforderungen von einem bestimmten Gerät während der Laufzeit der laufenden Sitzung dieses Geräts im Gebiet des Kerns immer mit der gleichen (konstanten) IP-Adresse beantwortet werden. (Die Verbindung zu einem Gerät kann für eine kurze Zeit vorübergehend unterbrochen sein, zum Beispiel während sich das Gerät durch ein Gebiet bewegt, das nicht von einem HMP abgedeckt ist. Bei der bevorzugten Ausführungsform überwacht der Kern vorübergehende Unterbrechungen dieser Art unter Verwendung eines Werts für einen Ablaufzeitgeber, wodurch das Gerät seine IP-Adresse behält, bis es eine Verbindung mit einem anderen HMP ausbildet, wie es weiter unten mit Bezug zum Erhalten von Einträgen im AUL-Register beschrieben ist. Die optimale Zeitdauer, die für den Ablaufzeitgeber verwendet wird, ist ausführungsspezifisch.)
Die vom Teilnehmergerät im Block 600 ausgegebene DHCP-Anforderung wird von dem HMP erhalten, mit dem es gerade in Verbindung steht (Block 605). Der HMP schließt dann diese DHCP-Anforderung in eine Anforderungsnachricht ein und gibt die eingeschlossene Nachricht an den Kernserver (Block 610). Die weitergeleitete Anforderung wird unter Verwendung einer vorgegebenen, bekannten Port-Nummer zu einem bezeichneten Port des Kerns gesendet. (Die bezeichnete Port-Nummer kann für die Verwendung mit der vorliegenden Erfindung speziell gewählt werden. Alternativ kann eine bereits zugeteilte Port-Nummer wie die DHCP-Port-Nummer zu diesem Zweck wiederverwendet werden, vorausgesetzt die Informationen in der weitergeleiteten Nachricht können dazu verwendet werden, festzustellen, daß dies eine DHCP-Anforderung ist, die von einem HMP weitergeleitet wird.)
Im Block 615 nimmt der Kern die DHCP-Anforderung an und legt sie frei. Der Kern untersucht dann die MAC-Adresse des Teilnehmergeräts für diese Anforderung und stellt fest (im Entscheidungsblock 620), ob es für diese MAC-Adresse im AUL-Register des Kerns bereits ein Eintrag gibt. Wenn ja, geht es zum Block 635 weiter, in dem die vorhandene IP-Adresse aus dem AUL-Registereintrag für das anfordernde Gerät ausgewählt und diesem zugeteilt wird. Wenn im AUL-Register kein Eintrag gefunden wird, geht es zum Block 625 weiter, in dem der Kern einen neuen Eintrag im AUL-Register erzeugt. Vorzugsweise werden bei der Erzeugung der Werte für das AUL-Register die Informationen in der weitergeleiteten DHCP-Anforderung verwendet, wie es in den Spalten 310, 330 und 340 der 3 gezeigt ist. Der Kern teilt dann dem anfordernden Gerät eine neue IP-Adresse zu (Block 630) und speichert diese Adresse in dem neu erzeugten Eintrag für das Gerät im AUL-Register (wie in der Spalte 320 der 3 gezeigt).
Nach den Prozessen des Blocks 630 oder des Blocks 635 erzeugt der Kern im Block 640 seine DHCP-Antwort, wozu entweder die neu erzeugte oder die ausgelesene IP-Adresse verwendet wird. Im Block 645 schließt der Kern dann diese Antwort ein und gibt sie an den HMP, der die DHCP-Anforderung weitergeleitet hat. Der HMP erhält die Antwort, legt sie frei und gibt sie an das anfordernde Teilnehmergerät weiter (Block 650). Nach Erhalt der Antwort (Block 655) kennt der Teilnehmer dann die IP-Adresse, die er für die weitere Kommunikation verwenden soll.
Auf diese Weise kann der Teilnehmer eine Standard-DHCP-Anforderung durchführen. Diese Anforderung wird immer vom Kern behandelt, unabhängig davon, ob es im LAN noch weitere DHCP-Server gibt. Darüberhinaus führt jede DHCP-Anforderung durch ein bestimmtes Gerät immer zu der Zuteilung der gleichen IP-Adresse, unabhängig davon, welcher HMP die Anforderung aufnimmt. (Bei der bevorzugten Ausführungsform gibt, wenn mehr als ein HMP durch den Prozeß des Blocks 600 eine DHCP-Anforderung von einem bestimmten Teilnehmer erhält, jeder HMP die Anforderung an den Kern weiter. Da jede Anforderung durch die gleiche Teilnehmer-MAC-Adresse identifiziert wird, teilt der Kern durch den Algorithmus der 6 dem anfordernden Gerät die gleiche IP-Adresse zu und gibt diese IP-Adresse mit seiner Antwort zu jedem HMP. Jedes HMP gibt dann die Antwort zu dem Gerät weiter, das mehrere Antworten erhält, die alle die gleiche IP-Adressenzuteilung enthalten.)
Anhand des Flußdiagramms der 7 wird nun der Prozeß beschrieben, mit dem ein Teilnehmergerät beim Roaming durch das drahtlose Netzwerk weitergereicht wird.
Der Kernserver verfolgt mittels des AUL-Registers, welchen HMP jedes Gerät derzeit zur Kommunikation benutzt. Das Aktualisieren dieser Informationen wird durch ein Übergabe-Protokoll erleichtert, das die HMPs ausführen. Die Art dieses Übergabeprotokolls hängt davon ab, wie der Kommunikationskanal zwischen dem Gerät und dem HMP ausgebildet wird. Es werden nun zwei Alternativen beschrieben, die hier als "explizite Umgebung" und als "implizite Umgebung" bezeichnet werden.
Die explizite Umgebung wird verwendet, wenn ein Gerät die Verbindung mit einem HMP explizit anfordert, zum Beispiel durch Ausbilden einer PPP-Verbindung. Wenn die Kommunikationskanal-Ausbildungsnachricht erhalten wird, hat die Entscheidung im Block 700 ein positives Ergebnis, und der Prozeß geht zum Block 710 weiter; anderenfalls geht der Prozeß mit dem Block 705 weiter. In der expliziten Umgebung entnimmt der HMP der erhaltenen Nachricht die MAC-Adresse des Geräts (Block 710) und gibt dann an den Kern eine Mitteilung ab (Block 715), die die MAC-Adresse des Geräts sowie die MAC-Adresse des HMPs enthält. (Wenn eine PPP-Verbindung ausgebildet wird, stellt der Teilnehmer einen Nutzernamen bereit, was es dem HMP ermöglicht, dem Kern auch mitzuteilen, welcher Nutzer gerade den Kanal benutzt, wenn er die Mitteilungsnachricht im Block 710 absendet.)
Die implizite Umgebung wird verwendet, wenn sich ein Gerät implizit mit einem HMP verbindet, zum Beispiel wenn der HMP neuen IP-Verkehr entdeckt, der von einem bisher nicht gesehenen Gerät erzeugt wird. Wenn die implizite Verbindung ausgebildet wird, ist das Ergebnis von Block 705 positiv, und der Prozeß geht mit dem Block 710 weiter; anderenfalls zeigt die 7, daß das HMP-Übergabeprotokoll auch die Beendigung von Verbindungen mit Teilnehmern überprüft, wie es weiter unten mit Bezug zu den Blöcken 750 und 755 beschrieben wird. In der impliziten Umgebung entnimmt der HMP dem empfangenen Verkehr die MAC-Adresse des Geräts (Block 710) und schickt eine Mitteilung wie oben beschrieben an den Kern (Block 715).
Wenn der Kern die Mitteilung über einen neuen Kommunikationskanal von einem HMP erhält (Block 720), prüft er das AUL-Register (Block 725), um festzustellen, ob es für dieses Gerät einen Eintrag gibt, wozu er die MAC-Adresse des Geräts verwendet, die vom HMP mit der Miteilung übertragen wurde. Wenn ein Eintrag gefunden wird (d.h. die Entscheidung im Block 725 ein positives Ergebnis hat), wird im Block 730 die MAC-Adresse des die Mitteilung abgebenden HMP zu der Liste der HMPs hinzugefügt, die ge genwärtig von diesem Gerät genutzt werden. (Siehe zum Beispiel die Spalte 340 der 3.) Wenn andererseits kein Eintrag gefunden wird, wird im Block 735 ein neuer Geräteeintrag erzeugt, der (wie angegeben) vorzugsweise als Schlüsselwort die MAC-Adresse des Geräts verwendet. Die IP-Adresse dieses neuen Geräteeintrags bleibt vorzugsweise noch leer (siehe Spalte 320), da der Teilnehmer noch keine DHCP-Adressenzuteilung angefordert hat, und zeichnet die MAC-Adresse des mitteilenden HMPs auf (siehe Spalte 330). Wenn in der Mitteilung ein Nutzername angegeben ist, wird auch diese Information in dem neuen Geräteeintrag aufgezeichnet (siehe Spalte 310).
Bei der bevorzugten Ausführungsform behandelt das HMP-Übergabeprotokoll auch das Ende einer Verbindung mit einem Teilnehmer. Wenn das vom HMP bewertete Übergabeereignis weder eine explizite noch eine implizite Kommunikationsausbildung ist, geht der Prozeß zum Entscheidungsblock 750, an dem geprüft wird, ob eine explizite Trennung erfolgt ist. Bei der bevorzugten Ausführungsform ist diese explizite Trennung das Ergebnis des Erhalts einer expliziten Beendigungsnachricht von einem Teilnehmergerät. Wenn eine solche Nachricht erhalten wird, hat die Überprüfung im Block 750 ein positives Ergebnis, und der Prozeß geht mit dem Block 760 weiter.
Wenn der Test im Entscheidungsblock 750 ein negatives Ergebnis hat, wird im Block 755 geprüft, ob eine implizite Trennung erfolgt ist. Wenn dieser Test ein positives Ergebnis zeigt, geht der Prozeß mit dem Block 760 weiter. Eine implizite Trennung kann sich ergeben, wenn ein HMP feststellt (anhand von ausführungsspezifischen Bedingungen), daß der Kommunikationskanal mit einem Gerät geschlossen werden sollte. Eine implizite Trennung kann sich auch ergeben, wenn während einer überwachten Zeitspanne kein Verkehr vom Gerät festgestellt wird, wobei nach dieser Zeitspanne der HMP sicher darauf schließen kann, daß das Gerät ausgefallen ist, abgeschaltet wurde oder anderweitig die Kommunikation beendet hat. Die überwachte Zeitspanne kann protokollspezifisch sein und von dem Protokoll abhängen, das in der expliziten Umgebung verwendet wird; alternativ kann die überwachte Zeitspanne gemäß den Erfordernissen des jeweiligen Systems, in dem sich der HMP befindet, festgelegt werden.
Wenn die Überprüfungen in allen Blöcken 700, 705, 750 und 755 ein negatives Ergebnis zeigen, kehrt der Prozeß zum Block 700 zurück und wartet auf das nächste Übergabeereignis.
Der Block 760 wird erreicht, wenn entweder eine explizite oder eine implizite Trennung von einem bestimmten Gerät durchgeführt wurde. Der HMP sendet dann eine Trennungsmitteilung an den Kern, wobei in dieser Nachricht die MAC-Adresse des Geräts und die MAC-Adresse des HMP enthalten sind. Wenn der Kern diese Mitteilung vom HMP erhält (Block 765), durchsucht er sein AUL-Register (Block 770) nach einem Eintrag für diese MAC-Adresse eines Geräts. Wenn eine Aufzeichnung gefunden wird (d.h. die Überprüfung im Entscheidungsblock 770 ein positives Ergebnis hat), wird der die Mitteilung sendende HMP von der Liste der HMPs entfernt (Block 775), mit denen das Gerät gegenwärtig in Verbindung steht. (Wenn kein Eintrag für dieses Gerät gefunden wird, hat die Überprüfung im Entscheidungsblock 770 ein negatives Ergebnis. Dies ist ein Fehlerzustand, der vom Kernserver so behandelt wird, wie es geeignet erscheint, etwa durch Ignorieren der Situation; Speichern einer Fehlernachricht in einer Datei; Anzeigen einer Fehlernachricht an einem Nutzerinterfacedisplay für einen Systemadministrator; usw.) Nach einem negativen Ergebnis im Block 770 oder dem Prozeß des Blockes 775 kehrt der Ablauf zum Block 700 zurück, um auf das nächste Übergabeereignis zu warten.
Mit dieser Technik zum Übermitteln von Übergabeinformationen von den HMPs zum Kern behält der Kern den Überblick darüber, welche HMPs von jedem Gerät in dem Gebiet zu jedem Zeitpunkt benutzt werden. Da sich die Geräte durch das Netzwerk bewegen, wird die gegenwärtige HMP-Identifikation für jedes Gerät im AUL-Register immer wieder aktualisiert.
Durch das Aufzeichnen der Informationen in einer Protokolldatei bei der Aktualisierung der Informationen über den Ort des Nutzers im AUL kann eine historische Aufzeichnung erzeugt werden, welche Nutzer welche Geräte und/oder HMPs zu einem bestimmten Zeitpunkt benutzt haben. Die 8 zeigt ein Beispiel für eine solche Protokolldatei, die in diesem Fall den Nutzernamen oder einen anderen Identifikator (Spalte 810); den Gerätetyp und die Seriennummer des Geräts des Nutzers, falls bekannt (Spalte 820); den physischen Ort und/oder die Seriennummer (falls bekannt) des HMP, der verwendet wurde (Spalte 830); und die Startzeit der Verwendung dieses HMP (Spalte 840) enthält. Anstelle oder zusätzlich zu der Seriennummer des Geräts kann auch seine MAC-Adresse verwendet werden. Gleichermaßen kann die MAC-Adresse des HMP anstelle oder zusätzlich zu dessen Seriennummer verwendet werden. Bei dem Beispiel der 8 wird nur die Startzeit der Verwendung eines HMP aufgezeichnet. Die Beendigungszeit kann programmatisch abgeleitet werden, zum Beispiel durch die Feststellung, daß es für den Nutzer "Bob" mit dem gleichen Palm Pilot Gerät mehrere Protokolleinträge gibt: Aus der beispielhaften Protokolldatei ist zu ersehen, daß Bob ursprünglich den HMP mit der Seriennummer 93414A3 genutzt hat (Zeile 850), 17 Sekunden dann zu dem HMP mit der Seriennummer 93413B1 gewechselt ist (Zeile 870) und dann 14 Sekunden danach wieder zu dem HMP mit der Seriennummer 93414A3 zurückgekehrt ist (Zeile 880). Bob hat sich somit, während er seinen Palm Pilot benutzt hat, in einem Gebiet bewegt, das wenigstens zwei relativ eng benachbarte HMPs umfaßt. Alternativ kann die Protokolldatei einen expliziten Endzeitpunkt für die Verwendung eines HMP enthalten, wobei der Kern diesen Endzeitpunkt erzeugt, nachdem er die Mitteilung erhalten hat, daß das Gerät den Kommunikationskanal geschlossen oder sich von einem HMP zu einem anderen bewegt hat.
Zusätzlich zu den Einträgen und Löschungen im AUL-Register, die mit Bezug zu der 7 erläutert wurden, kann der Kernserver auch Einträge in dieses Register tätigen, die nicht von Mitteilungen von einem HMP initiiert werden. Wie angegeben löscht, wenn die Registrierung eines HMP abläuft oder ein HMP anderweitig getrennt wird und daher seine Registrierung nicht mehr erneuert, der Kernserver in der bevorzugten Ausführungsform die MAC-Adresse des HMP aus allen Einträgen im AUL-Register. Außerdem ver wendet der Kern vorzugsweise einen Ablaufzeitgeber, um Einträge aus dem AUL-Register zu entfernen, wenn für einen Eintrag und eine gewisse Zeit kein aktiver HMP festgestellt wird, was anzeigt, daß der Nutzer für eine ausreichend lange Zeit keinen aktiven Kommunikationskanal mit einem HMP unterhielt. Die Zeitspanne am Ablaufzeitgeber ist vorzugsweise ausreichend, damit Geräte, die sich vorübergehend durch einen Bereich bewegen, der nicht von einem HMP abgedeckt wird, verbunden bleiben, bis sie wieder in den Bereich eines anderen HMP eintreten, ohne daß ihre Einträge aus dem AUL-Register gelöscht werden. (Vorzugsweise werden der Wert für den Ablaufzeitgeber und der Wert für die Ablaufzeitspanne des Blocks 755 anhand einer Konfigurationsdatei oder anhand von ähnlichen gespeicherten Informationen bestimmt und dabei Techniken verwendet, die bekannt sind.)
In einem optionalen Aspekt der vorliegenden Erfindung stellt der Kernserver ortsbezogene Sicherheitsmerkmale für ein kurzreichweitiges drahtloses Netzwerk bereit. Wie angegeben wird der ganze Netzwerkverkehr der Teilnehmergeräte über den HMP geleitet, der vom Teilnehmer und vom Kernserver genutzt wird. Der Kern kann diesen Verkehr so filtern, wie es die Anforderungen einer bestimmten Ausführung nötig machen. Zum Beispiel kann der Kern den Verkehr herausfiltern, der für bestimmte Anwendungsserver und/oder Anwendungsprogramme bestimmt ist, wozu eine Anzahl von Faktoren herangezogen wird, etwa die Identität und/oder der Ort des Nutzers (oder des Teilnehmergeräts des Nutzers), der oder das den Verkehr erzeugt. Bei der bevorzugten Ausführungsform erfolgt dieses Filtern mittels einer Vorgehensdatei des Kerns. Der für ein bestimmtes Teilnehmergerät am Kern ankommende Verkehr kann ebenfalls gefiltert werden, wobei die gleiche oder eine andere Vorgehensdatei angewendet wird. Die Informationen in der Vorgehensdatei werden vorzugsweise vom Systemadministrator erzeugt (unter Verwendung zum Beispiel eines einfachen Texteditors). Alternativ können die Einträge auch auf andere Weise erzeugt werden (einschließlich der programmatischen Erzeugung von Vorgehensinformationen), wobei Techniken angewendet werden, die nicht Teil der vorliegenden Erfindung sind.
Die 9 zeigt ein Beispiel 900 für eine Vorgehensdatei, die bei der vorliegenden Erfindung verwendet werden kann. Wie in diesem Beispiel bei 910 gezeigt, wird der für eine Ressource, die als "Bobs Thermostat" 915 identifiziert wird, bestimmte Verkehr nur dann für den Nutzer namens "Bob" 920 zugelassen, wenn sich dieser Nutzer an dem Ort befindet, der als "Bobs Büro" 925 identifiziert wird. Mit anderen Worten kann Bob seinen Thermostat nur ändern, wenn er sich in seinem Büro befindet, und sonst nicht, da alle anderen Änderungen vom Kern herausgefiltert werden (d.h. abgelehnt werden), bevor sie ein Anwendungsprogramm erreichen, das die Einstellung des Thermostats verändert. Dieser erste beispielhafte Eintrag 910 zeigt die Verwendung einer restriktiven Vorgehensweise, die explizit die Bedingungen angibt, die das Weiterleiten eines Verkehrs erlauben. Alternativ kann auch eine liberale Vorgehensweise angewendet werden, wie es bei dem Eintrag 930 gezeigt ist. Dieser Eintrag 930 für die Vorgehensweise gibt explizit die Bedingungen an, die verhindern, daß Verkehr weitergeleitet wird, so daß jeder andere Verkehr erlaubt ist. Im vorliegenden Fall wird nur der Verkehr, der von dem Nutzer ausgeht, der als "Rich" 940 identifiziert wird, oder der von dem Ort ausgeht, der als "Lobby" 950 identifiziert wird, herausgefiltert (abgelehnt), bevor er die Ressource erreicht, die als "Bobs Drucker" 935 identifiziert wird. Jeder andere Verkehr wird erlaubt.
Die in der 9 gezeigte Syntax stellt nur ein Beispiel dar und keine Einschränkung. Wenn dieses ortsbezogene Sicherheitsmerkmal der vorliegenden Erfindung angewendet wird, kann der Kernserver dafür vorgesehen werden, in einer ähnlichen Notation eingegebene Verhaltenseinträge zu verarbeiten. Die Verhaltenseinträge können auf viele Arten gespeichert werden, etwa als einfache Datei, als Datenbankeintrag, als Verzeichniseintrag usw. Es ist offensichtlich, daß die Ressourcen, die durch die Verhaltensinformationen geschützt werden sollen, sich von einer Ausführung zur anderen stark ändern können, und daß die Bedingungslogik für die Angabe der Filterbedingungen eine oder mehrere Bedingungen der in der 9 gezeigten Art umfassen kann.
In einem anderen optionalen Aspekt der vorliegenden Erfindung erlauben es Anwendungsprogramminterfaces (APIs) den auf Anwendungsservern laufenden Anwendungen, das HMP-Register, das AUL-Register, die Protokolldateien und/oder die Konfigurationsdateien des Kerns (einschließlich der Verhaltensdateien wie den oben genannten) abzufragen. (Die Art und Weise, wie räumlich entfernte APIs erzeugt werden und wie sie arbeiten, ist bekannt und wird hier nicht näher erläutert.) Durch diese APIs kann eine Anwendung eine Anzahl von nützlichen Funktionen ausführen, etwa: Abfragen, welche HMPs gerade aktiv sind; Feststellen von Identifikationsinformationen über einen HMP (einschließlich wo sich der HMP befindet, wenn sich diese Information im HMP-Register befinden); Feststellen, ob bei einem HMP, der gerade auf die Anwendung zugreift, bald eine Erneuerung der Registrierung fällig ist; Identifizieren des Satzes von gerade aktiven Nutzern sowie der HMPs, mit denen diese Nutzer gerade verbunden sind; usw.
Eine Anwendung kann die Informationen, die aus dem HMP-Register, dem AUL-Register, den Protokolldateien und/oder den Verhaltensdateien gewonnen werden, dazu verwenden, personalisierte und auf den Ort bezogene Dienstleistungen für den Nutzer zu erzeugen. Da die drahtlose Kommunikationsumgebung, in der die vorliegende Erfindung vorzugsweise angewendet wird, kurzreichweitig ist, sind die ortsbezogenen Informationen ziemlich fein gerastert (in der Bluetooth-Umgebung auf 10 Meter beschränkt zum Beispiel), so daß auf Mikroorte bezogene Dienstleistungen aufgebaut werden können. Beispiele für solche auf den Ort bezogene Dienstleistungen sind "Drucke auf dem nächsten Drukker"; "Erinnere den Nutzer daran, daß er den Müll rausträgt, wenn er sich in der Nähe der Vordertür befindet"; "Manipuliere die lokale Raumbeleuchtung" (oder vielleicht die lokalen Geräte oder die lokale Temperatur) usw.
Die Umgebung, in der die vorliegende Erfindung betrieben wird, kann durch die Verwendung einer Anzahl von Kernservern, von denen jeder eine Anzahl von HMPs verwaltet, ausgedehnt werden. In diesem Fall ist mit der Anzahl der Kernserver ein Kernver waltungsserver verbunden. Dieser Kernverwaltungsserver führt zum Beispiel Überwachungsdienste; Ferndiagnosedienste; Fernkonfigurationsdienste und andere Verwaltungsdienste für die Kernserver aus. Diese Dienste werden vorzugsweise durch APIs wie den genannten bereitgestellt, die den Kernverwaltungsserver in die Lage versetzen, auf die Informationen in den einzelnen Kernservern zuzugreifen. Auf diese Weise kann ein Administrator oder Dienstprovider einfach und flexibel einen Satz von räumlich entfernten Kernservern unterstützen und unterhalten.
Der Kernverwaltungsserver (in der Umgebung der 1 nicht gezeigt) kann getrennt von anderen Kernservern als selbständige Funktion ausgebildet werden, oder er wird in eine Vorrichtung integriert, die auch als Kernserver arbeitet. Jeder Kernserver kann in einer Umgebung auch die Möglichkeit haben, gegebenenfalls als Kernverwaltungsserver zu arbeiten, so daß sich der Ort der Verwaltungsfunktionen dynamisch von einer Vorrichtung zur anderen bewegen kann. Vorzugsweise arbeitet der Kernverwaltungsserver in einem passiven Modus, in dem er immer aktiv ist, seine Dienste jedoch nur dann abgerufen werden, wenn sie gewünscht sind (wenn es z.B. erforderlich ist, einen bestimmten Kern zu verwalten, um es einem Nutzer zu ermöglichen, sich von einem Heimnetzwerk, das von einem ersten Kern verwaltet wird, zu einem anderen Netzwerk zu begeben, das von einem anderen Kern verwaltet wird, usw.).
Darüberhinaus kann ein Kernserver mittels APIs am Kernverwaltungsserver Abfragen durchführen. Beispielhafte Funktionen, für die am Kernverwaltungsserver APIs vorgesehen werden können, umfassen das Feststellen des Orts oder der Adresse eines anderen Kerns; das Ausbilden einer Verbindung mit einem anderen Kern; und das Ausführen von anderen Diensten.
Wie gezeigt weist die vorliegende Erfindung eine Anzahl von Vorteilen gegenüber den bekannten kurzreichweitigen drahtlosen Netzwerklösungen auf. Bei der vorliegenden Erfindung ist keine Modifikation des Betriebssystems, der Netzwerksoftware oder der Anwendungen auf einem Teilnehmergerät erforderlich, um dem Nutzer eine nahtlose Mobilität zu ermöglichen. Die HMPs konfigurieren und registrieren sich selbst ohne die Intervention eines Systemadministrators. Der Ausfall von HMPs und von Teilnehmergeräten wird automatisch erfaßt und behandelt. Die Übergabe der Teilnehmergeräte bei der Bewegung von einem HMP zu einem anderen wird für das Teilnehmergerät transparent durchgeführt. Es brauchen nicht von einem Systemadministrator LAN-spezifische Server ausgebildet oder installiert werden, wodurch sich im Vergleich zu den bekannten Lösungen die administrative Belastung und die Kosten stark verringern. Es können miteinander verbundene Gebiete ausgebildet werden, wobei die Kernserver für die einzelnen Gebiete von einem Kernverwaltungsserver verwaltet werden.
Die vorstehende Beschreibung einer bevorzugten Ausführungsform dient nur der Darstellung der vorliegenden Erfindung und stellt keine Einschränkung davon dar. Es wurde zwar eine bevorzugte Ausführungsform beschrieben, dem Fachmann ist jedoch klar, daß viele Modifikationen dieser bevorzugten Ausführungsform möglich sind, ohne materi ell von der neuen Lehre und den Vorteilen der beschriebenen Erfindung abzuweichen. Entsprechend liegen alle Modifikationen innerhalb des Umfangs der vorliegenden Erfindung, der nur durch die im folgenden präsentierten Ansprüche (und deren Äquivalente) eingeschränkt wird.

Claims

Verfahren zum Ermöglichen einer nahtlosen Nutzermobilität und eines nahtlosen Roaming in einer drahtlosen Netzwerkumgebung kurzer Reichweite, zu der ein oder mehrere tragbare Teilnehmergeräte (120) gehören, deren jedes mit einer drahtlosen Kommunikationsfähigkeit kurzer Reichweite zur Kommunikation in der drahtlosen Netzwerkumgebung kurzer Reichweite ausgestattet ist, dadurch gekennzeichnet, daß von mehreren Handoff-Verwaltungspunkten (HMP) (110), die jeweils mit einer drahtlosen Verbindung kurzer Reichweite zur Kommunikation mit den Teilnehmergeräten (120) und einer Verbindung mit einer Netzwerkumgebung ausgestattet sind, ein ausgewählter HMP dynamisch in Betrieb genommen wird, wobei Zugriff auf ein oder mehrere in einem oder mehreren Anwendungsservern (130) liegende Anwendungsprogramme besteht, wobei für den ausgewählten HMP (110) eine Internetprotokoll-(IP)-Adresse erhalten wird; durch den ausgewählten HMP (110) die Identität eines Handoff-Kernservers (100) zur Verwaltung der HMPs (110) ermittelt wird; und wobei durch den ausgewählten HMP (110) der Austausch eines HMP-Präsenzprotokolls mit dem Handoff-Kernserver (100) eingeleitet wird, wobei des weiteren an den Handoff-Kernserver (100) eine Registrierungsanforderung gesendet wird, um den ausgewählten HMP (110) bei dem Handoff-Kernserver (100) zu registrieren; von dem Handoff-Kernserver (100) eine Registrierungsantwort erhalten wird; und wenn diese erfolgreich ist, die Registrierung des ausgewählten HMP (110) bei dem Handoff-Kernserver (100) periodisch erneuert wird.
Verfahren nach Anspruch 1, wobei zum Erhalten einer IP-Adresse eine Anforderung für ein dynamisches Hostkonfigurationsprotokoll (DHCP) ausgegeben wird.
Verfahren nach Anspruch 2, wobei zum Feststellen der Identität des Handoff-Kernservers (100) die Antwort auf die DHCP-Anforderung untersucht wird.
Verfahren nach Anspruch 1, wobei zum Erkennen der Identität des Handoff-Kernservers (100) eine Anforderung für ein Dienstortprotokoll (SLP) ausgegeben wird.
Verfahren nach Anspruch 1, wobei von den Teilnehmergeräten (120) erzeugte Anforderungen für ein dynamisches Hostkonfigurationsprotokoll (DHCP) von einem ausgewählten HMP (110) aufgenommen und von diesem an den Handoff-Kernserver (100) zur Verarbeitung weitergegeben werden.
Verfahren nach Anspruch 5, wobei von dem Handoff-Kernserver (100) bei Erhalt einer bestimmten der weitergeleiteten DHCP-Anforderungen eine Internetprotokoll-(IP)-Adresse für ein bestimmtes Teilnehmergerät (120) ausgewählt; die ausgewählte IP-Adresse von dem Handoff-Kernserver (100) an den ausgewählten HMP (110) weitergeleitet und von dem ausgewählten HMP (110) eine DHCP-Antwort an das bestimmte Teilnehmergerät (120) weitergeleitet wird.
Verfahren nach Anspruch 6, wobei zum Auswählen einer IP-Adresse für ein bestimmtes Teilnehmergerät (120) eine Tabellensuche in einem Register (300) über aktive Nutzerorte (AUL) ausgeführt wird.
Verfahren nach Anspruch 1, wobei der Handoff-Kernserver (100) eine Aufzeichnung des momentanen Ortes jedes Teilnehmergeräts (120) enthält.
Verfahren nach Anspruch 8, wobei die Aufzeichnung in einem Register (300) über aktive Nutzerorte (AUL) liegt.
Verfahren nach Anspruch 9, wobei der Handoff-Kernserver (100) auch eine historische Aufzeichnung ein oder mehrerer Orte jedes sich innerhalb der drahtlosen Netzwerkumgebung kurzer Reichweite bewegenden Teilnehmergerätes (120) enthält.
Verfahren nach Anspruch 8, wobei von einem bestimmten Teilnehmergerät (120) erzeugter und/oder für ein bestimmtes Teilnehmergerät (120) bestimmter Verkehr von dem Handoff-Kernserver (100) aufgenommen und von diesem entsprechend dem Ziel des Verkehrs und/oder dem momentanen Ort des bestimmten Teilnehmergerätes (120) und/oder der Identität des Nutzers des bestimmten Teilnehmergerätes (120) gefiltert wird.
Verfahren nach Anspruch 8, wobei (1) von einem bestimmten Teilnehmergerät (120) erzeugter und/oder (2) für ein bestimmtes Teilnehmergerät (120) bestimmter Verkehr vom Handoff-Kernserver (120) aufgenommen und entsprechend dem momentanen Ort des bestimmten Teilnehmergerätes (120) gefiltert wird.
Verfahren nach Anspruch 8, wobei von einem bestimmten Teilnehmergerät (120) erzeugter und/oder für ein bestimmtes Teilnehmergerät (120) bestimmter Verkehr vom Handoff-Kernserver (100) aufgenommen und entsprechend der Identität des Nutzers des bestimmten Teilnehmergerätes (120) gefiltert wird.
Verfahren nach Anspruch 1, wobei die Ausbildung eines neuen Nachrichtenkanals mit einem ausgewählten Teilnehmergerät (120) von einem bestimmten HMP (110) festgestellt; bei einer solchen Feststellung eine Kanalausbildungsmitteilung an den Handoff-Kernserver (100) ausgegeben und von diesem bei Erhalt dieser Nachricht ein Register (300) über aktive Nutzerorte (AUL) aktualisiert wird.
Verfahren nach Anspruch 14, wobei die Ausbildung eine explizite Ausbildung ist.
Verfahren nach Anspruch 14, wobei die Ausbildung eine implizite Ausbildung ist.
Verfahren nach Anspruch 14, wobei die Beendigung eines bestehenden Nachrichtenkanals mit einem bestimmten Teilnehmergerät (120) von dem bestimmten HMP (110) festgestellt; bei einer solchen Feststellung eine Kanalende-Nachricht an den Handoff-Kernserver (100) ausgegeben und von diesem bei Erhalt dieser Nachricht das AUL-Register (300) aktualisiert wird.
Verfahren nach Anspruch 17, wobei die Beendigung eine explizite Beendigung ist.
Verfahren nach Anspruch 17, wobei die Beendigung eine implizite Beendigung ist.
Verfahren nach Anspruch 1, wobei der Handoff-Kernserver (100) ein HMP-Register (200) und/oder ein Register (300) über aktive Nutzerorte (AUL) enthält.
Verfahren nach Anspruch 20, wobei der Handoff-Kernserver (100) mehrere Anwendungsprogramminterfaces (API) bereitstellt, über die die Anwendungsprogramme Informationen aus dem HMP-Register (200) und/oder dem AUL-Register (300) abrufen können.
Verfahren nach Anspruch 21, wobei ein auf mindestens einem der Anwendungsserver (130) laufendes ausgewähltes Anwendungsprogramm eines der APIs aufruft.
Verfahren nach Anspruch 22, wobei das ausgewählte Anwendungsprogramm aufgrund von über die APIs erhaltenen Informationen ortsbezogene Dienste bereitstellt.
Verfahren nach Anspruch 22, wobei das ausgewählte Anwendungsprogramm aufgrund von über die APIs erhaltenen Informationen personenbezogene Dienste bereitstellt.
Verfahren nach Anspruch 22, wobei das ausgewählte Anwendungsprogramm umgebungsbezogene Druckvorgänge bereitstellt.
Verfahren nach Anspruch 1, wobei die drahtlose Netzwerkumgebung kurzer Reichweite mehrere Handoff-Kernserver (100) enthält und ein Kernverwaltungsserver zum Verkehr mit diesen eingerichtet ist.
Verfahren nach Anspruch 26, wobei der Kernverwaltungsserver Anforderungen an die Handoff-Kernserver (100) abgeben kann.
Verfahren nach Anspruch 26, wobei die Handoff-Kernserver (100) Dienste vom Kernverwaltungsserver anfordern können.
Verfahren nach Anspruch 1, wobei einem ausgewählten Teilnehmergerät (120) eine Internetprotokoll-(IP)-Adresse zugeteilt wird, wenn sich dieses in Übertragungsreichweite eines ersten HMP (100) befindet, und wobei die IP-Adresse für das ausgewählte Teilnehmergerät (120) weiter verwendet wird, wenn es sich in Übertragungsreichweite eines zweiten HMP (100) befindet.
Verfahren nach Anspruch 29, wobei die IP-Adresse für das ausgewählte Teilnehmergerät (120) bei dem Handoff-Kernserver (100) gespeichert und von diesem abgerufen wird.
Verfahren nach Anspruch 1, wobei von dem Handoff-Kemserver (100) ein ausgewähltes Teilnehmergerät (120) einem ersten HMP (110) mitgeteilt wird, wenn es in dessen Reichweite gelangt.
Verfahren nach Anspruch 1, wobei von dem Handoff-Kernserver (100) ein ausgewähltes Teilnehmergerät (120) von einem ersten HMP (110) an einen zweiten HMP (110) weitergegeben wird, wenn es den Übertragungsbereich des ersten HMP (110) verläßt und in den des zweiten HMP (110) eintritt.
Verfahren nach Anspruch 32, wobei während und nach der Weitergabe eine zwischen dem ausgewählten Teilnehmergerät (120) und einem oder mehreren Anwendungsprogrammen laufende Sitzung von dem Handoff-Kernserver (100) aufrecht erhalten wird.
Verfahren nach Anspruch 1, wobei jeder registrierte HMP (110) nach Ablauf einer Zeitspanne von dem Handoff-Kemserver (100) neu registriert wird.
System zum Ermöglichen einer nahtloser Nutzermobilität und eines nahtlosen Roaming in einer drahtlosen Netzwerkumgebung kurzer Reichweite, zu der ein oder mehrere tragbare Teilnehmergeräte (120) gehören, deren jedes mit einer drahtlosen Kommunikationsfähigkeit kurzer Reichweite zur Kommunikation in der drahtlosen Netzwerkumgebung kurzer Reichweite ausgestattet ist, wobei das System Einrichtungen zur Durchführung sämtlicher Schritte des Verfahrens nach einem der Ansprüche 1 bis 34 aufweist.
Computerlesbares Medium mit einkodierten Anweisungen zur Ausführung, auf einem oder mehreren Prozessoren, sämtlicher Schritte des Verfahrens nach einem der Ansprüche 1 bis 34.