DE102014221304B4 - Peer-To-Peer Kommunikationen auf beschränkten Kanälen - Google Patents

Abstract

Vorrichtung zum Durchführen von Peer-to-Peer-Kommunikationen, wobei die Vorrichtung umfasst:einen Prozessor;einen Speicher; undeinen drahtlosen Sendeempfänger zum Durchführen von drahtlosen Kommunikationen;wobei der Prozessor und der drahtlose Sendeempfänger konfiguriert sind zum:Bestimmen einer Zielbeaconübermittlungszeit (target beacon transmission time, TBTT) auf einem beschränkten Kanal, wobei der beschränkte Kanal einen Kanal umfasst, der Rücksichtnahme auf eine bevorzugte Signalquelle oder eine bevorzugte Signalart erfordert;Einstellen des beschränkten Kanals vor der TBTT; nach dem Einstellen des beschränkten Kanals:Unterlassen von Übertragen während eines Zeitintervalls, welches die TBTT beinhaltet; undÜbermitteln auf dem beschränkten Kanal nur nachdem:Empfangen eines Beacon oder eines Verwaltungsframes, die angeben, dass der beschränkte Kanal frei ist; oderScheitern einen Beacon oder ein Verwaltungsframe während dem Zeitintervall zu empfangen.

Description

• Hintergrund
• Diese Offenbarung bezieht sich auf das Gebiet der Datenkommunikation. Genauer gesagt werden Verfahren und Vorrichtungen bereitgestellt zum Durchführen von Peer-to-Peer-Kommunikationen auf einem beschränkten Kommunikationskanal.
• Drahtlose Kommunikationen haben viele Vorteile für sowohl Daten wie auch Sprache, aber sind nicht ohne Beschränkungen. Zum Beispiel in den Vereinigten Staaten ist die Nutzung der Verbraucher von Hochfrequenzbereichen 5,25-5,35 GHz und 5,47-5,725 GHz nicht erlaubt, um nicht mit einigen Arten von Radarsystemen zu interferieren (z.B. Dopplerwetterradar). Beim Entdecken eines Signals, das auf ein geschütztes Radarsystem hinweist, muss jede Vorrichtung, die konfiguriert oder konfigurierbar ist, um beschränkte Bereiche zu benutzen, automatisch und schnell auf einen Kanal, der nicht interferiert, wechseln.
• Ein dynamischer Frequenzauswahlalgorithmus (Dynamic Frequency Selection, DFS) wird oft verwendet, um Frequenzwechsel zu erleichtern. Sogar in unbeschränkten Frequenzbändern wird DFS verwendet, um es Hochfrequenzvorrichtungen (z.B. drahtlose Zugriffspunkte) zu erlauben automatisch einen von mehreren Frequenzkanälen zu wählen, normalerweise um Interferenzen oder Überlastung auf anderen Kanälen zu vermeiden.
• Allerdings war die Anwendung von DFS innerhalb einer Peer-to-Peer-Kommunikationsumgebung, um Kanalbeschränkungen zu erfüllen, unmöglich oder zumindest schwierig, wenn kommunizierende Peers zu unterschiedlichen Zugriffspunkten verbunden sind. Zum Beispiel, wenn zwei Peer-Vorrichtungen direkt kommunizieren und eine von ihnen wird aufgefordert durch ihren Zugriffspunkt ihren aktuellen (beschränkten) Kanal zu ändern, können die Peer-to-Peer-Kommunikationen unterbrochen werden, insbesondere wenn die Änderung mit einer Serie von Kanaländerungen, die für die Vorrichtung bereits geplant sind, in Konflikt sind. WO 2013/ 022293 A2 offenbart ein Verfahren und eine Vorrichtung zur dynamischen Frequenzauswahl (DFS) in einem drahtlosen Netzwerk. WO 2011/ 078948 A2 bezieht sich auf ein Verfahren und ein System für die Ermittlung von leistungssparenden Peer-to-Peer Vorrichtungen.
• Zusammenfassung
• In einigen Ausführungsformen werden Verfahren und Vorrichtungen bereitgestellt zum Durchführen von Peer-to-Peer-Kommunikationen während eines Kanalspringens über zwei oder mehrere drahtlose Kanäle, wobei zumindest einer von diesen ein beschränkter Kanal ist. In diesen Ausführungsformen ist ein beschränkter Kanal ein Kanal, der Rücksichtnahme auf eine bevorzugte Signalquelle oder eine bevorzugte Art von Signal erfordert. Ein beispielhafter beschränkter Kanal ist einer, der die die Verwendung von DFS (Dynamic Frequency Selection) oder einem ähnlichen Schema für Radarvermeidung oder für Vermeidung eines Interferierens mit einigen anderen Arten von Signalen erfordert.
• In einigen Ausführungsformen springen kommunizierende Peers synchron über mehrere Kanäle und richten ihre Sprünge an beschränkten Kanälen mit TBTTs (Zielbeaconübermittlungszeiten, Target Beacon Transmission Times) von Zugriffspunkten oder DFS-Mastern aus, die auf den Kanälen arbeiten. Zum Beispiel kann jede Kanalsprungsequenz bei einem beschränkten Kanal beginnen und sie können dann einen Kanal sehr nahe an einem TBTT (z.B. einige Millisekunden davor) einstellen. Sie sind dann still, um illegales Übertragen zu vermeiden und um ein Entdecken des Beacons zu erleichtern. Sie können auch kurz vor TBTT stillgelegt werden, wenn sie bereits auf dem beschränkten Kanal kommunizierten (d.h. anstelle von nur gerade zu dem Kanal gesprungen sein).
• Wenn der Beacon angibt, dass der Kanal frei ist, können sie sofort ihre Kommunikationen beginnen oder wieder aufnehmen. Andernfalls richten sie sich nach jeder Kanalwechselankündigung oder anderen Direktiven, die sie entdecken. Die Ruheperiode um TBTT stellt sicher, dass die Peer-to-Peer-Frames nicht mit einem Beacon kollidieren oder die Übermittlungen eines Beacons verspäten. Somit verringern Peer-to-Peer-Kommunikationen nicht die Fähigkeit einer Peer-Vorrichtung Kanalvermeidungsankündigungen zu empfangen und diese zu erfüllen.
• Kommunizierende Peer-Vorrichtungen können ihre Kanalsprünge mit Beacons von mehreren beschränkten Kanälen und/oder einigen anderen Kanälen (z.B. andere Infrastrukturkanäle, ein sozialer Kanal) ausrichten, so dass sie sich einstellen, um Kontakt mit anderen Zugriffspunkten beizubehalten oder um eine Synchronisation mit einer Sammlung von anderen Peer-Vorrichtungen beizubehalten. Abhängig von den Beacon-Intervallen in den verschiedenen Kanälen müssten Peer-Vorrichtungen eventuell dynamisch die Zeitdauer bestimmen, die sie auf einem bestimmten Kanal verweilen, nicht nur, um zu einem „Basis“-Kanal (z.B. ein beschränkter Kanal) am Start einer Kanalsprungsequenzperiode zurückzukehren, sondern auch, um einen Beacon zu erfassen (oder einem Peer zu erlauben, einen Beacon auszugeben).
• Figurenliste
• 1 stellt die Verwendung von Ermittlungs-Beacons zum Erlangen und Beibehalten einer Synchronisation zwischen Gruppenvorrichtungen in Übereinstimmung mit einigen Ausführungsformen dar.
• 2 ist ein Flussdiagramm, welches Synchronisation und Betrieb einer Vorrichtung in einer Gruppe von Peers in einer drahtlosen Kommunikationsumgebung demonstriert in Übereinstimmung mit einigen Ausführungsformen.
• 3 ist ein Diagramm, welches einen bandexternen (out-of-band) Austausch zwischen Peer-Vorrichtung in Übereinstimmung mit einigen Ausführungsformen demonstriert.
• 4A-B stellen eine Sequenz von Kanälen dar, auf die sich Vorrichtungen einstellen, um in Konflikt stehender Kommunikationsnachfrage zu genügen, während eines Durchführens einer Datenübertragungsoperation in Übereinstimmung mit einigen Ausführungsformen.
• 5 stellt einen Zeitplan von Kanalwechseln, der zwischen kommunizierenden Peer-Vorrichtungen geteilt wird, in Übereinstimmung mit einigen Ausführungsformen dar.
• 6 stellt Peer-to-Peer-Kanalsprungkommunikationen auf zwei drahtlosen Kanälen dar in Übereinstimmung mit einigen Ausführungsformen.
• 7A stellt Peer-to-Peer-Kanalsprungkommunikationen auf zwei drahtlosen Kanälen dar, wobei einer von ihnen ein beschränkter Kanal ist, in Übereinstimmung mit einigen Ausführungsformen.
• 7B stellt Peer-to-Peer-Kanalsprungkommunikationen auf zwei beschränkten drahtlosen Kanälen dar in Übereinstimmung mit einigen Ausführungsformen.
• 8 stellt Peer-to-Peer-Kanalsprungkommunikationen zwischen einem sozialen Kanal und einem oder mehreren beschränkten Kanälen in Übereinstimmung mit einigen Ausführungsformen dar.
• 9 ist ein Blockdiagramm einer Peer-Kommunikationsvorrichtung in Übereinstimmung mit einigen Ausführungsformen.
• Detaillierte Beschreibung
• Die folgende Beschreibung wird dargestellt, um dem Fachmann zu ermöglichen, die offenbarten Ausführungsformen herzustellen und zu benutzen und wird in dem Kontext von einer oder mehreren bestimmten Anwendungen und deren Anforderungen bereitgestellt. Verschiedene Änderungen an den offenbarten Ausführungsformen werden dem Fachmann leicht offensichtlich sein und die hierin definierten generellen Prinzipien können auf andere Ausführungsformen und Anwendungen angewandt werden, ohne von dem Umfang von denen, die offenbart sind, abzuweichen. Somit ist diese Offenbarung nicht dazu gedacht, auf die gezeigten Ausführungsformen beschränkt zu sein, sondern es soll ihr der weiteste Umfang eingeräumt werden, der konsistent mit der folgenden Beschreibung ist.
• In einigen Ausführungsformen werden Verfahren und Vorrichtungen bereitgestellt zum Durchführen von Peer-to-Peer drahtlosen Kommunikationen auf beschränkten Kanälen. Die beschriebenen Ausführungsformen sind geeignet für eine Verwendung innerhalb beschränkter Teile des 5 GHZ-Hochfrequenzbandes - wie beispielsweise jene Frequenzbereiche, die der Unlicensed National Information Infrastructure (U-NII-2, U-NII-2e und U-NII-3) zugewiesen sind, von welchen Vorrichtung aufgefordert sind, sie beim Entdecken von vorbestimmten Signalen zu verlassen (z.B. Wetterradarsignaturen).
• Insbesondere sind die beschriebenen Ausführungsformen kompatibel mit DFS (Dynamic Frequency Selection), welches eine Technologie ist zum Befolgen von Radarvermeidungsanforderungen. Andere Ausführungsformen für andere Betriebsumgebungen und -beschränkungen können leicht aus der nachfolgenden Diskussion entwickelt werden.
• In diesen Ausführungsformen springen mehrere Peer-Vorrichtungen synchron zwischen mehreren Kanälen, wobei zumindest einer beschränkt ist (z.B. durch Erfordern von DFS, um Interferenzen mit einem geschützten Signal oder Sender zu vermeiden). Die Vorrichtungen können dynamisch ihre Verweilzeiten auf unterschiedlichen Kanälen berechnen (oder Zeitschlitze fester Länge verwenden) und ihre Sprünge terminieren, um ihnen zu ermöglichen, mit anderen Peer-Vorrichtungen zusammenzutreffen, Kommunikationen mit Infrastrukturknoten beizubehalten, verschiedene Beacons und/oder andere Managementframes zu erfassen, usw.
• Einleitung
• Eine Peer-to-Peer drahtlose Kommunikationsumgebung kann gekennzeichnet sein durch jede Anzahl von Vorrichtungen derselben Art und/oder verschiedener Arten - wie beispielsweise Smartphones, Tablets, persönliche digitale Assistenten, Laptops und Desktop Computer, Medienvorrichtungen (z.B. zum Streamen von Multimediainhalten) usw. Unterschiedliche Vorrichtungen werden unterschiedliche Merkmale aufweisen, können unterschiedliche Anwendungen ausführen, können unterschiedliche Energiestufen (z.B. Batterieladungen), unterschiedliche Kommunikationserfordernisse, unterschiedliche Lasten aufweisen (z.B. auf einem Prozessor, auf einer Antenne), können erfasst werden durch (oder können erfassen) andere Vorrichtungen mit variierenden Signalstärken usw. Zusätzlich kann die Kommunikationsumgebung fließend sein, mit Vorrichtungen, die kontinuierlich eintreten, sich hindurch bewegen und den räumlichen Bereich verlassen, der die Umgebung umfasst.
• Einige der hier offenbarten Ausführungsformen ermöglichen Vorrichtungen in solch einer Umgebung einander zu ermitteln und direkt zu kommunizieren, Peer-to-Peer. Diese Ausführungsformen: Fördern niedrigen Energieverbrauch, sogar während sie Vorrichtungen und Dienste leicht ermittelbar machen; koexistieren mit anderen Kommunikationstechnologien (z.B. Bluetooth^®); unterstützen Mehrfachbandoperationen (z.B. 2,4 GHz und 5 GHz); vermeiden die Durchsatz- und Latenzverschlechterung, die normalerweise in Netzwerkinfrastrukturen begegnet werden (z.B. Zugriffspunkte), während eine Kompatibilität mit infrastrukturbasierten Technologien beibehalten wird; leichte und schnelle Erholung falls und wenn eine Vorrichtung, die als Master agiert, die Umgebung verlässt; skalierbar sind, um dichte Umgebungen, die viele Vorrichtungen aufweisen, zu beherbergen; und Interferenzen mit anderen Sammlungen von Vorrichtungen zu vermeiden. Diese andere Merkmale und Vorteile werden nachfolgend beschrieben.
• In einigen Ausführungsformen wird eine Sammlung von Vorrichtungen in einer Umgebung synchronisiert, so dass sie zu vorbestimmten Zeiten auf vorbestimmten Kanälen zusammentreffen. Eine synchronisierte Sammlung von Vorrichtungen kann als Gruppe bezeichnet werden. Eine Zeitperiode, während der Vorrichtungen einer einzelnen Gruppe zusammentreffen, wird als Verfügbarkeitsfenster bezeichnet und alle Mastervorrichtungen innerhalb der Gruppe bewerben den gleichen Zeitplan von Verfügbarkeitsfenstern. Während eines Verfügbarkeitsfensters können Peers Multicast- und oder Unicast-Datenkommunikationen austauschen, Management oder Betrieb der Gruppe erleichtern und andere Vorrichtungen und Dienste ermitteln.
• Parameter eines oder mehrerer bevorstehender Verfügbarkeitsfenster (z.B. Kanal, Startzeit und Dauer) werden über Ermittlungs-Beacons kommuniziert, die auf einem oder mehreren sozialen Kanälen ausgestrahlt werden. In unterschiedlichen Implementierungen können unterschiedliche Strategien zum Begegnen eines Beacon angewandt werden.
• Zum Beispiel kann eine Vorrichtung auf einem gegebenen sozialen Kanal für eine kontinuierliche Zeitperiode zuhören, die ausreichend ist, um zumindest einen Ermittlungs-Beacon zu erfassen, kann periodisch für kurze Zeitperioden zuhören, usw.
• Somit, wenn eine Vorrichtung bootet, online geht oder sich in eine Umgebung von Peer-Vorrichtungen bewegt, wird sie einen vorbestimmten sozialen Kanal einstellen und schnell lernen, wo und wann sie mit anderen Vorrichtungen zusammentreffen kann. Wenn die Vorrichtung keinen Ermittlungs-Beacon erfasst, kann sie annehmen, dass sie als ein Master agieren soll und beginnt ihre eigenen Ermittlungs-Beacons auszugeben, um Synchronisation mit anderen Vorrichtungen zu erleichtern, welche vorhanden sein oder welche später auftauchen können.
• Synchronisationsparameter (z.B. ein Zeitplan von bevorstehenden Verfügbarkeitsfenstern) können auch in einigen Implementierungen während eines Verfügbarkeitsfensters angekündigt werden, welches damit den Vorrichtungen den Aufwand eines Wechselns ihrer Hochfrequenzeinrichtungen zu einem sozialen Kanal, um die Parameter zu empfangen, erspart. Eine Vorrichtung kann sogar ihre Hochfrequenzeinrichtung ausschalten, wenn sie nicht auf einen Ermittlungs-Beacon hört, an einem Verfügbarkeitsfenster teilnimmt, direkt mit einem Peer kommuniziert oder sie für einige andere Zwecke verwendet.
• Daher teilt eine Vorrichtung, die an einer Gruppe teilnimmt, eine Hochfrequenzeinrichtung, eine Antenne und/oder andere Kommunikationsressource(n) zwischen mehreren Vorrichtungsfunktionen, wie beispielsweise einer Infrastrukturverbindung oder einer Bluetooth^®-Verbindung. Allerdings können die Kommunikationsanforderungen von der synchronisierten Peer-to-Peer-Umgebung - wie beispielsweise periodisches Einstellen eines sozialen Kanals, um ein Ermittlungs-Beacon zu empfangen, Teilnehmen an Verfügbarkeitsfenstern auf Treffpunktkanälen und Einhalten von Kommunikationskanalbeschränkungen - in Konflikt mit anderen Nachfragen für diese Ressourcen stehen.
• Innerhalb einer Gemeinschaft von Peer-Vorrichtungen wird ein Auswahlverfahren angewendet, um zu bestimmen, welche Vorrichtungen Master werden und Verantwortung für ein Synchronisieren anderer Vorrichtungen übernehmen werden. Die Anzahl an ausgewählten Mastervorrichtungen kann von der gegenwärtigen Anzahl von Peer-Vorrichtungen, ihrer Signalstärken, Signalverbreitungsmustern, Betriebsparametern usw. abhängen.
• Obwohl sich Vorrichtungen in der Kommunikationsumgebung in Peer-to-Peer-Kommunikationen ohne die Last von Infrastrukturanforderungen engagieren, wird die Auswahl von Mastern die Vorrichtungen der Gruppe logisch in eine Hierarchie zum Zwecke von Synchronisation organisieren. Innerhalb der Hierarchie ist ein „Ankermaster“ („anchor master“) (oder Topmaster) verantwortlich für eine gesamte Synchronisation der Gruppe über Synchronisationsparameter, die durch die Ermittlungs-Beacons, die er ausstrahlt, übermittelt werden. Jeder untergeordnete Master, der Synchronisations-(oder „sync“)-Master genannt wird, synchronisiert sich mit dem Ankermaster oder einem intervenierenden Sync-Master und übermittelt weiter oder verpackt weiter die Synchronisationsparameter des Ankermasters innerhalb seiner eigenen Ermittlungs-Beacons, um damit den Bereich der gesamten Synchronisation zu erweitern. Andere Vorrichtungen, die in der Hierarchie teilnehmen, werden Nichtmastervorrichtungen.
• Der Hochfrequenzbereich einer einzelnen drahtlosen Vorrichtung (z.B. des Ankermasters) ist beschränkt, welches normalerweise diese Vorrichtung hindern würde, Vorrichtungen außerhalb eines lokalen Bereichs zu organisieren. Das Erfordern von untergeordneten Mastern, ihre Synchronisationsparameter wieder auszustrahlen, ermöglicht dieser einzelnen drahtlosen Vorrichtung, eine Sammlung von Vorrichtungen, die über eine weitere Fläche verteilt sind, zu synchronisieren. Die gesamte Gruppe genießt die resultierenden Vorteile (z.B. betriebsbereite Ermittlung von Diensten und anderen Vorrichtungen, weniger Energieverbrauch).
• Anders als eine Umgebung, die Infrastrukturanforderungen aufweist (z.B. welche eine Koordination über einen Zugriffspunkt erfordert), weil eine Hauptaufgabe des Masters einfach ein Verbreiten von Treffpunkt/Synchronisationsparametern ist, ist ein Verlust einer Mastervorrichtung leicht bereinigt. Zum Beispiel wird der Treffpunktzeitplan, der durch eine fehlende Ankermastervorrichtung herausgegeben wurde, einfach durch die Synchronisationsmaster der Gruppe beibehalten, während ein Ersatz-Ankermaster gewählt wird, dabei werden alle Vorrichtungen synchronisiert gehalten. Und dieser Ersatz wird normalerweise den gleichen Zeitplan beibehalten.
• Unterschiedliche Algorithmen zum Auswählen von Mastern können zu unterschiedlichen Zeiten und/oder in unterschiedlichen Umgebungen angewandt werden, dienen aber generell, um eines oder alle dieser Ziele zu fördern: gleiche räumliche Verteilung von Mastern durch die Umgebung hindurch, eine einstellbare Dichte von Mastern innerhalb der Umgebung und Steuerung der Größe der geografischen Fläche, die die Umgebung umfasst.
• In einigen Ausführungsformen wird ein Algorithmus zum Auswählen oder Identifizieren von Mastern regelmäßig ausgeführt, um sicherzustellen, dass die am meisten geeigneten Vorrichtungen als Master agieren basierend auf verschiedenen Metriken oder Attributen der Vorrichtungen. Das Auswahlverfahren kann auch berücksichtigen, wie viel Master bereits gegenwärtig in einer Fläche sind, wie viele Master eine gegebene Peer-Vorrichtung erfassen kann, wie weit sie entfernt sind (z.B. basierend auf der Signalstärke oder einigen anderen Distanzmessungen), usw.
• Einige Einheiten, die in der folgenden Beschreibung angesprochen werden, können in anderen Kontexten unter unterschiedlichen Bezeichnungen bekannt sein und daher wird die folgende Zuordnung bereitgestellt, um einige alternative Terminologien zu identifizieren, welche nicht als erschöpfend gedacht ist. Zum Beispiel kann eine generische Mastervorrichtung auch „Synchronisationsstation“ genannt werden. Die Vorrichtung, die als Ankermaster agiert, kann auch als „Root“, „Root Master“, die „Root-Synchronisationsstation“ oder der „Topmaster“ bekannt sein. Ein Synchronisationsmaster, ausgenommen des Ankermasters, kann auch als eine „Zweig-Synchronisationsstation“, ein „Zweig“-Master oder als ein untergeordneter Master bekannt sein. Eine Nichtmastervorrichtung kann auch als eine „Blatt“-Vorrichtung oder als ein „Slave“ bezeichnet werden. Ein Ermittlungs-Beacon kann alternativ auch als ein „periodisches Synchronisationsframe“ („Periodic Synchronisation Frame“ oder PSF) benannt werden und ein Verfügbarkeitsfenster kann auch als „Ermittlungsfenster“ bezeichnet werden. Eine Gruppe von Vorrichtungen kann alternativ auch als ein Baum, ein Synchronisationsbaum oder eine Hierarchie bezeichnet werden. Andere Bezeichnungen, die unten eingeführt werden, beinhalten ein „Synchronisations-Beacon“, der auch als ein „Masterindikationsframe“ („Master Indication Frame“ oder MIF) bekannt ist.
• Die nachfolgenden Abschnitte beschreiben eine Synchronisation von Vorrichtungen innerhalb einer Peer-to-Peer-Kommunikationsumgebung, um eine Gruppe kooperativer Peer-to-Peer-Kommunikationen zu formieren, die Peer-to-Peer-Verbindungen innerhalb einer beschränkten Umgebung durchführen und eine veranschaulichende Peer-Vorrichtung, entsprechend einiger Ausführungsformen.
• Synchronisation von Vorrichtungen
• Wie oben beschrieben ermöglicht die Synchronisation von Vorrichtungen innerhalb einer drahtlosen Kommunikationsumgebung entsprechend einiger Ausführungsformen ihnen sich gegenseitig leicht zu ermitteln, verfügbare Dienste zu identifizieren und sich in direkten Peer-to-Peer-Kommunikationen zu engagieren (Unicast und/oder Multicast), dies alles während eines Einsparens von Energieressourcen und einem Koexistieren mit anderen Kommunikationsverfahren.
• Eine Synchronisation zum Formen einer Gruppe beginnt sobald eine Vorrichtung online geht oder sich innerhalb einer Reichweite von zumindest einer anderen Vorrichtung, die ein kompatibles Protokoll betreibt, bewegt und kann, solange wie die Vorrichtung online innerhalb der räumlichen Fläche, die die synchronisierten Vorrichtungen umfasst (z.B. solange sie in der Reichweite einer Mastervorrichtung ist), beibehalten werden.
• Durch die Synchronisations- und Masterauswahlverfahren werden Vorrichtungen automatisch in eine hierarchische Gruppe organisiert, in welcher Master in jeder Stufe (oder Schicht) der Hierarchie periodisch Synchronisationsparameter ausstrahlt, um eine Synchronisation zwischen den Vorrichtungen in einer Fläche zu erlangen und beizubehalten. Ermittlungs-Beacons (Discovery Beacons, DBs) sind ein Mechanismus zum Verbreiten von Synchronisationsparametern und werden von allen synchronisierten Vorrichtungen konsumiert.
• Ermittlungs-Beacons dienen einem Ermitteln von Informationen wie beispielsweise, aber nicht beschränkt auf, Informationen zum Synchronisieren von Vorrichtungsuhren, eine Beschreibung von einem oder mehreren bevorstehenden Verfügbarkeitsfenstern, während welcher Gruppenvorrichtungen zusammentreffen können, und Metriken (oder Attributen) des Ankermasters und des Synchronisationsmasters, die den DB übermittelt haben. In anderen Ausführungsformen kann ein DB eine unterschiedliche Sammlung von Informationen beinhalten, wird aber normalerweise Kriterien beinhalten, die zumindest ein Verfügbarkeitsfenster identifizieren.
• Formierung einer Gruppe und Synchronisierung von Vorrichtungen innerhalb der Gruppe können durch Konfigurations- oder Betriebsparameter beeinflusst sein, wie beispielsweise aber nicht beschränkt auf: eine maximale Tiefe oder Schicht der Gruppe, Periodizität von Ermittlungs-Beacons, Anzahl von Mastervorrichtungen (z.B. insgesamt und/oder innerhalb einer Reichweite einer gegebenen Vorrichtung), der Auswahlalgorithmus, der verwendet wird, um die Master auszuwählen, Vorrichtungsmetriken oder -attribute, die von dem Auswahlalgorithmus berücksichtigt werden, usw. In unterschiedlichen Ausführungsformen können unterschiedliche Parameter angewendet werden. Die US 2013 / 0185373 A1 offenbart Verfahren zum Auswählen von Mastern in einem Peer-to-Peer-Netzwerk und zum Formieren von privaten Gruppen.
• 1 stellt die Verwendung von Ermittlungs-Beacons zum Erlangen und Beibehalten einer Synchronisation zwischen zwei oder mehreren Vorrichtungen entsprechend einiger Ausführungsformen dar.
• In diesen Ausführungsformen werden Ermittlungs-Beacons 110 (z.B. Beacons 110a, 110b, 110n) regelmäßig auf einem oder mehreren sozialen Kanälen 120 (z.B. Kanal A 120a, Kanal B 120b, Kanal N 120n) übermittelt.
• Unterschiedliche Mastervorrichtungen können Ermittlungs-Beacons auf dem gleichen oder unterschiedlichen sozialen Kanälen übermitteln und jeder gegebene Master kann einen oder mehrere soziale Kanäle (und/oder andere Kanäle) verwenden, um seine DBs zu verbreiten. Unterschiedliche Master in einer einzelnen Gruppe können unterschiedliche soziale Kanäle verwenden, eventuell, um eine Interferenz untereinander zu vermeiden, weil deren sozialer Kanal, der von einem Master verwendet wird, durch einen unterschiedlichen Master für einen unterschiedlichen Zweck in Verwendung sein kann (z.B. eine Infrastrukturverbindung) und/oder für jeglichen anderen Grund. Verfügbarkeitsfenster können auf sozialen Kanälen durchgeführt werden oder nicht.
• Obwohl mehrere soziale Kanäle 120 in 1 dargestellt sind, können in einigen Implementierungen alle Mastervorrichtungen in einer Gruppe den gleichen sozialen Kanal verwenden und den gleichen Zeitplan von Verfügbarkeitsfenstern bewerben. Soziale Kanäle und/oder andere Kanäle, die hier diskutiert werden, können IEEE 802.11 drahtlose Kanäle sein, die Beschränkungen haben oder nicht. Zum Beispiel kann ein sozialer Kanal oder andere Art von Kanal, der verwendet wird, um Beacons zu übermitteln oder um zwischen Peer-Vorrichtungen zu kommunizieren, der DFS (Dynamische Frequenzauswahl, Dynamic Frequency Selection) unterliegen und können Beschränkungen bei ihrer Verwendung involvieren. Eine solche Beschränkung, die in einem nachfolgenden Abschnitt adressiert wird, erfordert von den Vorrichtungen, einen Kanal zu verlassen, wenn eine bestimmte Art von Signal (z.B. ein Wetterradarimpuls) erkannt wird. Wie im nachfolgenden Abschnitt diskutiert, kann dies Änderungen an der normalen Kommunikation der Peer-Vorrichtungen erfordern.
• Auf den sozialen Kanälen 120a, 120b, 120n werden entsprechende Ermittlungs-Beacons 110a, 110b, 110n periodisch durch einen verantwortlichen Master ausgestrahlt. Jeder der DB-Ausstrahlungen durch einen einzelnen Master auf einem einzelnen Kanal (z.B. Beacons 110a) kann identisch sein oder kann sich irgendwie unterscheiden.
• Obwohl die Periode der Ermittlungs-Beacon jedes Kanals (P_A , P_B , P_N ) in 1 unterschiedlich sind, sind in einigen Ausführungsformen, in welchen mehrere soziale Kanäle benutzt werden, die Beacon-Perioden von zwei oder mehr Kanälen identisch. Eine veranschaulichende Periode zwischen DBs auf einem Kanal kann ungefähr im Bereich von 100 Millisekunden sein, muss aber nicht exakt 100 ms sein. Unterschiedliche Master können die gleichen oder unterschiedlichen DB-Perioden verwenden. In einigen Implementierungen kann die Länge oder Dauer einer Ermittlungs-Beacon-Periode invers proportional zu der gesamten Anzahl von Mastern, die DBs ausstrahlen, sein (oder der Anzahl von Mastern in einem bestimmten Bereich, die ausstrahlen).
• Es ist zu beachten, dass Zeitperioden, die hier als Millisekunden (ms) bezeichnet werden, alternativ in Form von Zeiteinheiten (time units, TU) von der gleichen oder äquivalenten Größenordnung implementiert werden können. Wie in dem IEEE 802.11 Standard spezifiziert, ist eine Zeiteinheit gleich zu 1,024 Mikrosekunden. Somit kann eine 100 ms Zeitperiode, auf die hierin Bezug genommen wird, stattdessen als 100 Zeiteinheiten oder als eine äquivalente Anzahl von Zeiteinheiten (z.B. ungefähr 98 TU) implementiert werden, 102,4 ms können als 100 TU implementiert werden, usw.
• In einigen Ausführungsformen werden DB-Perioden auf jedem sozialen Kanal unterschiedlich sein; allerdings können die Verfügbarkeitsfensterperioden, die durch die Master, die die DBs ausgeben, implementiert sind, die gleichen sein. Daher können innerhalb einer Gruppe mehrere DB-Perioden und eine einzelne Verfügbarkeitsfensterperiode implementiert sein.
• Wenn ein DB übermittelt wird, braucht der ausgebende Master nur seine Hochfrequenzeinrichtung auf den richtigen Kanal einzustellen und sie lange genug einzuschalten, um den Beacon zu senden. Es braucht den Kanal nach dem Ausgeben der DB nicht beizubehalten, sondern kann seine Hochfrequenzeinrichtung ausschalten, um Energie zu sparen, sie zu einem unterschiedlichen sozialen Kanal zu wechseln (z.B. um eine Übermittlung eines DBs auf einem unterschiedlichen Kanal vorzubereiten) oder sie für einen anderen Zweck zu verwenden, wie beispielsweise Abwarten eines Verfügbarkeitsfensters (wie unten beschrieben), sowie beispielsweise Teilnehmen an einem Verfügbarkeitsfenster (wie unten beschrieben), Handhaben von Infrastrukturkommunikation, Austauschen von Daten mit anderen Vorrichtungen, usw.
• In einigen Ausführungsformen müssen Ermittlungs-Beacons keine strikte periodische Zeitplanung einhalten. Stattdessen können Beacons so regelmäßig wie möglich gesendet werden, aber verzögern andere Operationen der Vorrichtung, wie berechtigt. In einigen Implementierungen benötigen Ermittlungs-Beacons nur so häufig ausgegeben zu werden, um zumindest eine minimale Durchschnittsperiodizität zu ergeben, die es ermöglicht, neue Peer-Vorrichtungen einer Gruppe von Vorrichtungen mit einer gewissen Wahrscheinlichkeit oder innerhalb einer gewissen beschränkten Zeitdauer zu ermitteln.
• DB 110x der 1 ist eine veranschaulichende Beacon-Ausstrahlung durch einen Master in einigen Ausführungsformen. In anderen Ausführungsformen kann ein Ermittlungs-Beacon eine Untermenge oder eine Übermenge von veranschaulichten Elementen enthalten. Zum Beispiel, auch wenn primär DBs als von einem Master ausgegeben hierin beschrieben sind, können Nichtmastervorrichtungen auch Ermittlungs-Beacons oder andere Arten von Beacons oder Frames ausgeben, wobei diese Nichtmaster-Beacons oder Frames aber nur eine Untermenge der Informationselemente, die vom DB 110x getragen werden, beinhalten können und mit längeren Perioden ausgegeben werden können.
• In der veranschaulichten Ausführungsform können die Informationselemente eines Kanals 130, einer Zeit 132 und einer Periode 134 (und möglicherweise einer Dauer 136) kollektiv als „Synchronisationsparameter“ oder „Verfügbarkeitsfensterparameter“ bezeichnet werden, da sie einer Hörvorrichtung ermöglichen, von einer Sequenz von Verfügbarkeitsfenstern zu erfahren, die durch den Master, der den DB ausgegeben hat (oder durch einen höheren Master) ausgegeben wurde. Der Kanal 130 identifiziert den Kanal (z.B. ein 802.11 drahtloser Kanal), auf welchem alle Verfügbarkeitsfenster (oder zumindest das nächste Verfügbarkeitsfenster) auftreten werden, die Zeit 132 identifiziert, wenn das Fenster auftreten wird (die Fenster auftreten werden) und die Periode 134 identifiziert die Verfügbarkeitsfensterperiode, welche der Hörvorrichtung erlauben wird, nachfolgende Verfügbarkeitsfensterstartzeiten zu berechnen. Die Dauer 136 identifiziert die Dauer des Verfügbarkeitsfensters.
• Mehrere Sätze von Synchronisationsparametern können in einer DB enthalten sein, entweder um Sequenzen von Verfügbarkeitsfenstern auf unterschiedlichen Kanälen zu bewerben, um andere Vorrichtung von einem Wechseln von einer Sequenz zu einer anderen zu benachrichtigen oder aus irgendeinem anderen Grund.
• Das Zeitelement 132 der Synchronisationsparameter des veranschaulichten Ermittlungs-Beacons 110x kann eine absolute Startzeit identifizieren (z.B. basierend auf einer synchronisierten Uhr, UTC (Coordinated Universal Time oder irgendeiner anderen möglichen Referenz) und/oder eine relative Zeit. In einigen Implementierungen trägt das Zeitstempelfeld die TSF (Zeitsynchronisierungsfunktion, Time Sync Function) von der Station, die den DB 110x ausgegeben hat.
• In einigen Ausführungsformen beinhaltet die Zeit 132 mehrere Werte, die eine Peer-Vorrichtung verwendet, um die Startzeit des nächsten Verfügbarkeitsfensters zu berechnen. Zum Beispiel kann die Zeit 132 einen „Ziel“-Zeitstempel beinhalten, der konfiguriert ist, um anzugeben, wann DB 110x formiert wurde und für die Übermittlung innerhalb des ausgebenden Masters eingereiht wurde (z.B. wann der DB in einen Übermittlungspuffer gesetzt wurde) und einen „tatsächlichen“ Zeitstempel beinhaltet, der konfiguriert ist, um anzugeben, wann der DB tatsächlich über die Antenne des Masters abgesendet wurde.
• Veranschaulichend kann der DB zu der Zeit, zu der ein „Master-Offset“-Parameter vom Master berechnet wird, als geformt angesehen werden. Der Master-Offset-Wert, der auch innerhalb der DB 110x als Teil der Zeit 132 oder eines unterschiedlichen Informationselements enthalten ist, stellt den internen Offset des ausgebenden Masters zum Start des nächsten Verfügbarkeitsfensters dar, gemessen von der Zeit an, in der es den DB veröffentlicht. Somit misst der Master-Offset die Zeitperiode des Zielzeitstempels zum Start des Verfügbarkeitsfensters, wie sie von der Station berechnet wurde, die den Ermittlungs-Beacon ausgegeben hat.
• Mit diesen Werten kann eine Peer-Vorrichtung, die DB 110x konsumiert, einen Offset zur Startzeit des Verfügbarkeitsfensters wie folgt berechnen: $$\text{Offset}=\text{Master}-\text{Offse}\left(\text{tatsächer Zeitstempel}-\text{Zielzeitstempel}\right)$$

  
• Insbesondere empfängt die Peer-Vorrichtung den Master-Offset und kann, aus dem Ziel und tatsächlichen Zeitstempeln, messen, wie viel von der Master-Offset-Zeitperiode abgelaufen ist; sie zieht dann diese abgelaufene Periode vom Master-Offset ab, um den Betrag der verbleibenden Zeit bis zum Verfügbarkeitsfenster zu bestimmen.
• Die Periode 134 identifiziert die Periode der Verfügbarkeitsfenster, die vom ausgebenden Master durchgeführt werden. Die gesamte Gruppe der Peer-Vorrichtungen kann die gleiche Periode und den gleichen Zeitplan von Verfügbarkeitsfenstern anwenden, die veranschaulichend durch den Ankermaster der Gruppe gesetzt wurde.
• Die Dauer 136 des DB 110x ist in einigen Implementierungen optional, aber wenn bereitgestellt, gibt sie die minimale Zeitdauer während des Verfügbarkeitsfensters an, in welcher die Vorrichtung, die den DB 110x ausgegeben hat, zuhören wird und für eine Kommunikation verfügbar sein wird. Die Dauer kann auch auf die synchronisierten Vorrichtungen angewendet werden, die den Beacon 110x konsumieren; d.h. von einer Vorrichtung, die am Fenster teilnimmt, kann erfordert werden, dass sie für zumindest diese Zeitperiode verfügbar ist, gemessen vom Anfang des Fensters.
• In einigen Ausführungsformen kann ein Master automatisch sein Verfügbarkeitsfenster erweitern (z.B. in Stufen die der Dauer 136 entsprechen oder durch irgendeine andere Zeitdauer), solange zumindest eine Station mit ihm während dieses Fensters kommuniziert. Somit können, sogar wenn mehrere Stationen mit der Mastervorrichtung kommunizieren wollen, da das Fenster erweitert werden wird, sie in der Lage sein, es zu tun ohne auf ein anderes Verfügbarkeitsfenster zu warten.
• In ähnlicher Weise kann eine Peer-Vorrichtung, die am Verfügbarkeitsfenster teilnimmt, ihr Fenster solange erweitern, so dass zumindest einer seiner Peers es in einer Kommunikation engagiert. Daher kann ein Peer, der mit einem anderen Peer kommunizieren will, einfach eine erste Menge an Paketen, Datagrammen, Nachrichten oder anderen Kommunikationseinheiten zu diesem anderen Peer während eines Verfügbarkeitsfensters ausgeben. Beide Peers werden dann automatisch ihre Fenster erweitern aufgrund der aktiven Kommunikation. Dies ermöglicht zweckmäßigerweise ausgedehnte Peer-to-Peer-Kommunikation während Verfügbarkeitsfenstererweiterungen, ohne Sättigung oder Monopolisierung der Bandbreite während des Verfügbarkeitsfensters.
• Somit kann eine maximale Dauer einer Präsenz eines Masters während eines Verfügbarkeitsfensters in DB 110x spezifiziert werden und/oder kann während des Verfügbarkeitsfensters angekündigt werden. Veranschaulichend kann der Master benötigen, das Fenster zu verlassen, um einen DB auf einem unterschiedlichen Kanal auszugeben, seine Hochfrequenzeinrichtung für andere Kommunikationsfunktionen zu verwenden oder aus irgendeinem anderen Grund. Was individuelle Vorrichtungen angeht, können sie sich von einem Verfügbarkeitsfenster entfernen, wenn sie nichts zu kommunizieren haben und wenn keine andere Vorrichtung mit ihr kommuniziert, während einer gewissen Zeitdauer innerhalb des Fensters.
• In anderen Ausführungsformen können die Verfügbarkeitsfensterparameter eines Ermittlungs-Beacons ausdrücklich ein oder mehrere Verfügbarkeitsfenster identifizieren anstatt nur eines zu identifizieren, und einer Periode bereitzustellen. Diese Ausführungsformen können in Umgebungen implementiert sein, in welchen eine Mastervorrichtung und/oder andere Peer-Vorrichtungen sich nicht auf einen regulären, periodischen Zeitplan von Verfügbarkeitsfenstern einigen können. In noch anderen Ausführungsformen kann ein periodischer Zeitplan angewendet werden, aber ein oder mehrere Verfügbarkeitsfenster können ausdrücklich zum Zeitplan hinzugefügt werden oder ein oder mehrere Vorkommen eines periodischen Fensters können annulliert werden.
• Somit können Synchronisationsparameter oder Daten eines DBs jede Anzahl von Verfügbarkeitsfenstern (z.B. eines oder mehrere) identifizieren. Verschiedene DBs, die auf den gleichen oder unterschiedlichen sozialen Kanälen und durch unterschiedliche Master übermittelt werden, können die gleichen oder unterschiedlichen Verfügbarkeitsfenster identifizieren. Typischerweise werden allerdings Synchronisationsparameter, die durch den Ankermaster gesetzt sind (einschließlich des Zeitplans oder der Sequenz von Verfügbarkeitsfenstern), durch die Gruppe hindurch angewendet. In diesen Ausführungsformen strahlen somit alle Ermittlungs-Beacons durch die Gruppe hindurch denselben Zeitplanbericht von Verfügbarkeitsfenstern aus.
• In einigen Ausführungsformen sind Verfügbarkeitsfenster nummeriert und als eine Wiederholungssequenz durchgeführt. Zum Beispiel können die n Verfügbarkeitsfenster, die in einer Sequenz durchgeführt werden, als 0 bis n-1 durchnummeriert sein. Nach einer Iteration wiederholen sich die Verfügbarkeitsfenster-Sequenznummern (d.h. von o bis n-1). Die Sequenznummer des nächsten Verfügbarkeitsfensters, das nach DB 110x auftritt, kann ausdrücklich in dem Beacon identifiziert sein (z.B. in einem Informationselement, das in 1 nicht dargestellt ist), kann während des Verfügbarkeitsfensters bestimmt werden oder kann auf eine andere Art erfahren werden.
• Der veranschaulichende Ermittlungs-Beacon 110x der 1 berichtet auch ein oder mehrere Einstellungswerte (alternativ bezeichnet als ein Master-Rang, ein Master-Einstellungswert oder ein Auswahlwert). Ein Einstellungswert ist ein Wert (z.B. eine ganze Zahl), der verwendet wird, um die Eignung oder die Einstellung einer Vorrichtung, um ein Master zu sein, identifiziert. Ein Einstellungswert der Vorrichtung wird berechnet unter Verwendung von verschiedenen Metriken, Attributen oder Eigenschaften von der entsprechenden Vorrichtung und möglichen Eigenschaften der Kommunikationsumgebung oder der Gruppe der Vorrichtung. Veranschaulichende Metriken für die Berechnung eines Einstellungswertes der Vorrichtung beinhalten die verfügbaren Energieressourcen der Vorrichtung (z.B. Batteriestärke oder Batterieladung, Verbindung zu einer Wechselstromenergiequelle), Prozessorlast, Signalstärke, den Namen und/oder die Adresse der Vorrichtung (z.B. MAC-Adresse), den Namen oder die Adresse des Ankermasters der Vorrichtung, einen Zeitstempel, die Stufe oder Schicht der Vorrichtung innerhalb der Gruppe (z.B. die Anzahl von Sprüngen vom Ankermaster), die Periodizität (oder Durchschnittsperiodizität) der Ermittlungs-Beacons der Vorrichtung, einem sozialen Kanal, der von der Station verwendet wird, einem Infrastrukturkanal auf den die Station sich periodisch einstellen muss, andere Verpflichtungen der Vorrichtung (z.B. Bluetooth-Koexistenz, Infrastrukturverbindung) usw.
• Einstellungswerte von synchronisierten Vorrichtungen können als Teil eines Auswahlverfahrens verglichen werden, um zu bestimmen, welche Vorrichtungen innerhalb einer Gruppe Master sein sollen. Das Verfahren kann regelmäßig ausgeführt werden, wie beispielsweise während oder nach jeder Sequenz von Verfügbarkeitsfenstern, zu einem fixen Zeitplan, usw.
• In dem DB 110x ist ein Sync-Master-Einstellungswert 140 der Master-Einstellungswert des Synchronisationsmasters, der den Ermittlungs-Beacon 110x ausgestrahlt wurde und gibt die Eignung oder die Einstellung der Vorrichtung ein Master innerhalb der Gruppe zu sein, an. Durch Bewerben seines Einstellungswertes können alle Vorrichtung in Reichweite dieses Masters das Auswahlverfahren korrekt anwenden und z.B. bestimmen, ob sie besser geeignet sind, um ein Master zu sein.
• Ähnlich ist der Ankermaster-Einstellungswert 142 der Master-Einstellungswert des Ankermasters für die Gruppe, in welcher der Beacon 110x ausgestrahlt wurde und gibt die Eignung oder den Vorzug dieser Vorrichtung ein Master zu sein, an. Veranschaulichend durch Verbreiten des Ankermaster-Einstellungswertes 142 durch die Gruppe hindurch, kann eine Vorrichtung, die am Rande der Gruppe oder in einer Fläche, in der sich mehrere getrennte Gruppen überlappen, ist, bestimmen, welcher Gruppe sie beitritt. Zusätzlich können alle Vorrichtungen in einer Gruppe bestimmen, ob sie besser geeignet sind, um der Ankermaster zu sein.
• Wenn der DB 110x ausgegeben wird durch den Ankermaster einer Gruppe, werden die Einstellungswerte 140, 142 übereinstimmen. Alternativ könnte eines der Einstellungswertfelder weggelassen werden.
• In einigen Implementierungen kann ein Ermittlungs-Beacon Informationselemente beinhalten, die anders sind als die, die in DB 110x der 1 dargestellt sind. Zum Beispiel kann ein Beacon einen Algorithmus identifizieren zum Auswählen von Mastern, kann Beschränkungen für Master spezifizieren (z.B. wie viele innerhalb einer Reichweite zueinander sein können), kann eine maximale Tiefe für die Gruppe der Vorrichtung bewerben, kann eine Benachrichtigung bereitstellen, dass eine Vorrichtung die Gruppe verlässt, usw.
• Obwohl ein Master eine angegebene Periode zur Ausgabe von Ermittlungs-Beacons aufweisen kann, ist diese Periode, wie bereits erwähnt, flexibel und es kann daher eine hohe Toleranz für Variationen geben. Ein gegebener DB kann in der Zeit vorangegangen sein oder verspätet sein aufgrund von anderen Nachfragen an der Hochfrequenzeinrichtung der Mastervorrichtung, aufgrund von einem Konflikt auf dem Kommunikationskanal oder aus irgendeinem anderen Grund. In einigen Implementierungen können DB ungefähr +/- 20 Millisekunden alle 100 Millisekunden variieren. In einigen anderen Implementierungen können Variationen von der Größenordnung +/- 100 Millisekunden sein, solange wie die langfristige Durchschnittsperiodizität von Ermittlungs-Beacons ungefähr 100 Millisekunden ist.
• Ermittlungs-Beacons können opportunistisch übermittelt werden, das bedeutet, wenn eine Hochfrequenzeinrichtung des Masters auf einen unterschiedlichen Kanal zu dem Zeitpunkt, wo sie normalerweise einen DB auf einem sozialen Kanal ausgibt, eingestellt ist, kann sie stattdessen den Beacon auf ihrem aktuellen Kanal ausgeben. Ermittlungs-Beacon-Ausstrahlungen werden zu ihrer normalen Zeitplanung auf dem/den sozialen Kanal/Kanälen zurückgehen, wenn möglich.
• Diese Art von Situation, in welcher ein DB auf einem nicht sozialen Kanal gesendet wird, um ein zukünftiges Verfügbarkeitsfenster zu identifizieren, kann für eine lokalisierte Gruppe von Vorrichtungen nützlich sein. Solche Vorrichtungen werden wahrscheinlich mit dem gleichen Infrastrukturnetzwerk auf dem gleichen (nicht sozialen) Kanal verbunden. Übermitteln eines DBs auf diesem Kanal erspart diesen Vorrichtungen die Kosten eines Kanalwechsels (d.h. auf den sozialen Kanal) und vermeidet ein Interferieren mit deren Infrastrukturkommunikationen.
• Im schlechtesten Fall kann eine neue Vorrichtung, die auf einen normalen sozialen Kanal des Masters eingestellt ist, eine beschränkte Anzahl von Ermittlungs-Beacons verpassen, wenn der Master auf einem unterschiedlichen Kanal beschäftigt ist. Allerdings kann der Master auf eine häufig verwendete Frequenz eingestellt sein (z.B. ein Infrastrukturkanal, der von einer bestimmten Anwendung erfordert wird, wie oben beschrieben) und kann daher die gleiche Vorrichtung zu einer unterschiedlichen Zeit erreichen.
• Unter anderen Informationen, die in einer DB enthalten sein können, ist die (Durchschnitts)-Periode des ausgebenden Masters zum Senden von Ermittlungs-Beacons und der Kanal oder die Kanäle, auf denen die Beacons ausgestrahlt werden. Dies erlaubt einer Peer-Vorrichtung eine Zeitmenge zu bestimmen, welche sie auf einem bestimmten sozialen Kanal zu hören braucht, um einen DB zu erfassen und um sich den Verfügbarkeitsfenster-Zeitplan anzueignen.
• Verfügbarkeitsfenster, die von einem Master geplant werden, können zu einer regelmäßigen Periode auftreten oder nicht und können mit den DBs des Masters synchronisiert sein oder nicht. In anderen Worten benötigen die Verfügbarkeitsfenster nicht zu identischen Offsets von den Ermittlungs-Beacons aufzutreten. Eine veranschaulichende Zeitdauer, die eine vollständige Sequenz von Verfügbarkeitsfenstern belegt, kann ungefähr mehrere Sekunden sein, obwohl eine spezifische Implementierung einer Ausführungsform eine kürzere oder längere Dauer verwendet.
• In einigen Ausführungsformen gibt es weniger Toleranz bezüglich einer Verfügbarkeitsfensterperiode als es sie bezüglich einer Ermittlungs-Beacon-Periode gibt, vielleicht ungefähr +/- 100 Mikrosekunden pro Sekunde für Verfügbarkeitsfenster (verglichen mit +/- 200 Millisekunden pro Sekunde für DBs). Obwohl DBs sehr kurz sind (z.B. weniger als 1 Millisekunde) werden sie aber oft ausgegeben, Verfügbarkeitsfenster sind relativ lang und werden selten durchgeführt. Zum Beispiel können Verfügbarkeitsfenster 16 ms, 50 ms oder länger andauern. Ermittlungs-Beacons können opportunistisch geplant werden aufgrund ihrer kurzen Dauer, Verfügbarkeitsfenster sind allerdings für Vorrichtungsermittlung und Kommunikation eingerichtet und können daher generell nicht spontan oder opportunistisch durchgeführt werden.
• Obwohl relativ selten, können Verfügbarkeitsfenster eine Hochfrequenzeinrichtungsschnittstelle für eine signifikante Zeitdauer monopolisieren; aufgrund dessen ist ein Einhalten eines strikten Zeitplans vorteilhaft, insbesondere wenn andere Hochfrequenztechnologien präsent sind (z.B. Bluetooth). Andere (synchronisierte) Vorrichtungen hängen auch von dem beworbenen Zeitplan von Fenstern für Ermittlung und/oder Peer-Kommunikation ab, welches weniger Raum für Variationen lässt.
• Daher wird in einigen Ausführungsformen eine Ermittlungs-Beacon-Periode eine relativ hohe Toleranz für Variationen haben, während eine Verfügbarkeitsfensterperiode eine relativ niedrige Toleranz für Variationen hat. Ein Vorteil dieser Strategie ist, dass sie WiFi-Konflikte berücksichtigt, welche bei jeder Ermittlungs-Beacon-Übermittlung auftreten. Übermittlung eines Ermittlungs-Beacon ist nur möglich, wenn der ausgewählte soziale Kanal nicht verwendet wird und Konflikte für den Kanal oder die Hochfrequenzeinrichtung können die Ausgabe der DB verzögern oder nicht. Daher würde eine strikte Planung für alle DB-Übermittlungen schwer zu erreichen sein.
• Wenn eine Peer-Vorrichtung sich zum ersten Mal mit einer Mastervorrichtung synchronisiert und anfängt, an Verfügbarkeitsfenstern teilzunehmen, kann sie in dem ersten Fenster (und/oder dem ersten Fenster, für welches von allen Vorrichtungen erfordert wird, teilzunehmen) eine Nachricht, in der sie sich selbst identifiziert, ihren Einstellungswert identifiziert, ihre Auswahlmetriken bereitstellt, ihre Dienste bewirbt usw., ausgeben. Jede Vorrichtung, die mit ihr kommunizieren will, kann dann Kontakt herstellen.
• Obwohl Verfügbarkeitsfenster als ein primärer Mechanismus den Peer-Vorrichtungen zum Ermitteln voneinander und von Diensten, die angeboten werden, bereitgestellt werden, kann eine Vorrichtung (einschließlich eines Masters) ein oder mehrere Fenster in einer Sequenz überspringen. Zum Beispiel, wenn eine Peer-Vorrichtung ihre Hochfrequenzeinrichtung für einige andere Zwecke in regelmäßigen Intervallen benötigt, die manchmal mit einem Verfügbarkeitsfenster überlappen, kann sie nicht an einem in Konflikt stehenden Verfügbarkeitsfenster insgesamt teilnehmen, kann später kommen oder kann früher gehen. Die Vorrichtung kann einen Master oder andere Vorrichtungen über ihre Abwesenheit benachrichtigen oder nicht (z.B. über eine Multicastnachricht).
• In einigen Ausführungsformen kann eine Vorrichtung einen „Anwesenheitsmodus“ für sich selbst setzen und diesen Wert zu ihrem Master bewerben (d.h. der Master, mit welchem sie synchronisiert ist) und/oder anderen Peers, um anzugeben, wie oft sie erworbene Verfügbarkeitsfenster einstellen oder daran teilnehmen wird. In einigen Implementierungen ist ein Anwesenheitsmodus (oder PM presence mode) ein Ganzzahlwert, wie beispielsweise 1, 2, 4, usw. Der reziproke Wert des Anwesenheitsmodus der Vorrichtung ist ein Bruch, der angibt, an wie vielen Verfügbarkeitsfenstern in einer Sequenz sie teilnehmen wird. Zum Beispiel falls ein Anwesenheitsmodus der Vorrichtung gleich 1 ist, wird die Vorrichtung an jedem Verfügbarkeitsfenster teilnehmen; mit einem PM von 2 wird die Vorrichtung an jedem Fenster teilnehmen, welches eine Sequenznummer aufweist, die ein Vielfaches von 2 ist (d.h. die Hälfte von den Fenstern); falls ihr PM gleich 4 ist, wird sie an jedem Fenster teilnehmen, dessen Sequenznummer ein Vielfaches von 4 ist (d.h. ein Viertel von den Fenstern).
• Höhere Anwesenheitsmoduswerte ermöglichen einer Vorrichtung mehrere Fenster zu überspringen und ihre Hochfrequenzeinrichtung auszuschalten, wobei sie Energie einsparen. Schlussendlich bedeutet ein Anwesenheitsmodus, der gleich mit der Anzahl von Verfügbarkeitsfenstern in einer Sequenz ist, dass eine Vorrichtung an nur einem Verfügbarkeitsfenster pro Sequenz teilnimmt. Ein PM Wert von Null kann angeben, dass eine Vorrichtung immer verfügbar ist (d.h. nicht nur während Verfügbarkeitsfenstern).
• In einigen Ausführungsformen muss jede synchronisierte Vorrichtung an zumindest einem Verfügbarkeitsfenster in der Sequenz, die durch ihren Master beworben wird, teilnehmen. Zum Beispiel kann von Vorrichtungen verlangt werden an dem Verfügbarkeitsfenster 0 von jeder Sequenz teilzunehmen. Somit gibt in diesem Fall ein PM Wert, der gleich der Länge der Verfügbarkeitsfenstersequenz ist, an, dass die Vorrichtung nur während Verfügbarkeitsfenstern, die die Sequenz 0 aufweisen, anwesend sein wird.
• Die Länge von Verfügbarkeitsfenstersequenzen ist generell eine Potenz von 2 (z.B. 8, 32, 256). In einigen Implementierungen beginnen Sequenznummern von Verfügbarkeitsfenstern, die durch einen Master durchgeführt werden, bei Null und erhöhen sich eins nach dem ändern, bis zum Erreichen des Wertes Länge minus 1 (z.B. 7, 31, 255), nach welchem sie sich wiederholen. Von Synchronisationsmastern wird verlangt die aktuelle Sequenznummer von ihren Mastern (in ihre Beacons) zu übernehmen und zu wiederholen (d.h. ein höherstufiger Syncmaster oder der Ankermaster). Deshalb werden alle Vorrichtungen, die unter einem Ankermaster synchronisiert sind (d.h. alle Peer-Vorrichtungen innerhalb einer Gruppe) zustimmen, welches Verfügbarkeitsfenster die Sequenznummer 0 aufweist.
• In einigen Ausführungsformen können Sequenzen von Verfügbarkeitsfenstern, die durch unterschiedliche Master beworben werden, von unterschiedlichen Längen sein. Allerdings werden alle Sequenzen ausgerichtet, so dass alle Vorrichtungen, die einen bestimmten Anwesenheitsmoduswert aufweisen, an den gleichen Fenstern teilnehmen. In anderen Worten werden alle Vorrichtungen zustimmen, welche bestimmten Fenster Vielfache einer gegebenen Zahl sind.
• Man bedenke zum Beispiel, eine Gruppe, in welcher Verfügbarkeitsfenstersequenzen von den Längen 8, 16 und 64 aus unterschiedlichen Mengen von Vorrichtungen in Verwendung sind (z.B. Vorrichtungen, die mit unterschiedlichen Mastern synchronisiert sind). Aus den Vorrichtungen, die die Sequenz von 8 Fenstern implementieren, wird jedes achte Fenster als Verfügbarkeitsfenstersequenznummer 0 bekannt sein. Jedes Verfügbarkeitsfenster, welches die Sequenznummer 0 für diese Vorrichtungen aufweist, wird ein Verfügbarkeitsfenster sein, welches Sequenznummer 0 oder 8 für diese Vorrichtungen, die eine Sequenz aufweisen, die 16 Fenster lang ist und als ein Verfügbarkeitsfenster, das die Sequenznummern o, 8, 16, 24, 32, 40, 48 oder 56 für diese Vorrichtungen mit 64 Verfügbarkeitsfenstern in ihren Sequenzen aufweist.
• Eine Vorrichtung kann an mehr Verfügbarkeitsfenstern teilnehmen wie ihr PM angibt, aber durch Ankündigen ihres Anwesenheitmoduswertes (z.B. durch eine Multicastnachricht in Verfügbarkeitsfenstersequenznummer 0), werden andere Vorrichtungen wissen, wann sie mit ihr interagieren können. Und wie vorher beschrieben, solange eine Peer-Vorrichtung eine Kommunikation an eine Vorrichtung, während eines Fensters an dem von der empfangenden Vorrichtung teilgenommen wird, sendet, wird diese Vorrichtung ihre Anwesenheit in diesem Kanal erweitern, um die Kommunikation durchzuführen, falls möglich, und wird in der Lage sein, auch noch von anderen Peers kontaktiert zu werden.
• Ferner werden auch immer in einigen Ausführungsformen eine Peer-Vorrichtung einen Anwesenheitsmodus größer 1 aufweist, (oder irgendeine andere Schwelle) eine Kommunikation empfängt, kann sie automatisch ihren Anwesenheitsmodus auf 1 setzen (oder irgendein anderer niedriger Wert), um die gewünschte Kommunikation zu erleichtern. Darüber hinaus kann eine Vorrichtung mit einem niedrigen Anwesenheitsmodus (z.B. 0 oder 1), nachdem sie ein Multicastframe in einem Verfügbarkeitsfenster empfangen hat, fest in einem oder mehreren nachfolgenden Fenstern wiederholen, um dabei zu helfen, es zu seinen Peers zu geben.
• Ein Master kann jeden PM-Wert haben; obwohl er Ermittlungsbeacons in periodischen Intervallen sendet (möglicherweise sogar während eines Verfügbarkeitsfensters), kann er seine Hochfrequenzeinrichtung ausschalten oder seine Hochfrequenzeinrichtung oder Antenne für andere Kommunikationsanforderungen während eines Verfügbarkeitsfensters, wenn er keine Beacon versendet, verwenden.
• In einigen Ausführungsformen können zwei oder mehrere Peer-Vorrichtungen, die eine relativ erweitere Kommunikationsperiode durchführen wollen (z.B. für eine Dateiübertragung, um sich in einem Spiel oder anderer Anwendung zu engagieren) ihre eigene Synchronisation für diesen Zweck von Datenaustausch, parallel zu der gesamten Synchronisation, aber außerhalb von oder zusätzlich zu geplanten Verfügbarkeitsfenstern, einzurichten. In diesen Ausführungsformen können eine von den zwei oder mehreren Vorrichtungen die Rolle von einem Nichtauswahlmaster übernehmen, das bedeutet, dass sie nicht in einem formalen Masterauswahlverfahren teilnimmt, ist aber für andere Vorrichtungen zur Synchronisation zu oder mit verfügbar ist (z.B. um einen Dateiaustausch durchzuführen, um ein Spiel zu spielen). Vorrichtungen, die mit einem Nichtauswahlmaster synchronisiert sind, können eine unabhängige Basisdienstmenge formieren (Basic service set IBSS).
• Ein Nichtauswahlmaster kann Beacons ausgeben, welche die anderen Peer-Vorrichtungen, mit welchen er kommunizieren will, zum Synchronisieren mit dem Nichtauswahlmaster verwenden werden, welcher aber von anderen Vorrichtungen in der Gruppe ignoriert werden. Veranschaulichend können diese Beacons während einem Verfügbarkeitsfenster und/oder auf einem vereinbarten Kanal übermittelt werden. Beacons eines Nichtauswahlmasters können spezifizieren, dass die Vorrichtung ein Nichtauswahlmaster ist, so dass Vorrichtungen, die nicht direkt mit ihm kommunizieren müssen, wissen werden, dass sie sich nicht mit ihm synchronisieren sollen. Wenn eine Vorrichtung, die in einer Kommunikation mit einem Nichtauswahlmaster engagiert war, diese Kommunikation beendet, kann sie sich neu mit einem regulären Master synchronisieren und der Gruppe des Masters wieder betreten (z.B. falls eine Synchronisation mit dem Nichtauswahlmaster zu einem Verlieren der Synchronisation mit der Gruppe veranlasst hat).
• Eine Vorrichtung, die sich synchronisieren will oder eine Synchronisation beibehalten will mit einer Gruppe von Peers kann nicht in der Lage sein, dieses zu tun, vielleicht weil sie die sozialen Kanäl(e) der Gruppe nicht überwachen kann, hat andere Verpflichtungen während den geplanten Verfügbarkeitsfenstern oder wegen irgendeinem anderen Grund. In dieser Situation kann die Vorrichtung ein Nichtauswahlmaster werden (und identifizieren, wenn sie verfügbar ist) um anderen Vorrichtungen zu helfen, sie zu entdecken. Alternativ kann sie eine Änderung des Verfügbarkeitsfensterzeitplans der Gruppe anfragen, um die Vorrichtung zu beherbergen oder kann ein Master werden, falls ihr Auswahleinstellungswert angibt, dass sie soll. Als ein Master, insbesondere als der Ankermaster, könnte sie den Verfügbarkeitsfensterzeitplan ändern.
• In einigen Ausführungsformen kann, während eines Verfügbarkeitsfensters auf einem Zusammentreffkanal, ein Master oder eine andere Vorrichtung (z.B. ein Nichtauswahlmaster) eine unterschiedliche Art von Beacon ausstrahlen, die Synchronisationsbeacon (SB) genannt wird. In diesen Ausführungsformen stellen Synchronisationsbeacon Informationen bereit, die Peer-Vorrichtungen helfen, eine Synchronisation zu erreichen oder beizubehalten - entweder mit einem Master, der reguläre DB ausgibt oder mit einem Nichtauswahlmaster, zu dem Vorrichtungen sich synchronisieren können, um Daten zum Beispiel direkt auszutauschen. Ein Synchronisationsbeacon kann während eines Verfügbarkeitsfensters gesendet werden, wird generell aber nicht auf einem sozialen Kanal gesendet, außer eins wird beispielsweise während eines Verfügbarkeitsfensters gesendet, das auf einem sozialen Kanal stattfindet.
• Ein Sychronisationsbeacon kann jede Daten beinhalten, die ein Ermittlungsbeacon beinhalten könnte, und/oder andere Informationen. Zum Beispiel könnte ein SB von einem Master gesendet werden, um zu berichten, dass er beginnen wird, einen unterschiedlichen sozialen Kanal zum Senden von DBs zu verwenden, könnte von einem Nichtauswahlmaster gesendet werden, um zu berichten, dass er ein Fenster von Verfügbarkeit auf einem bestimmten Kanal zu einer bestimmten Zeit haben wird, könnte von einer anderen Vorrichtung gesendet werden, um Synchronisationsdaten zu berichten, die sie von einigen anderen Mastern gehört hat oder um ihre Verfügbarkeit zu bewerben, usw.
• Wenn ein Verfügbarkeitsfenster mit der Zeit, in der ein DB normalerweise gesendet werden würde (d.h. entsprechend der DB-Periode des Ausgabemasters) überlappt, kann der reguläre Ermittlungsbeacon auf dem Kanal gesendet werden, auf welchen die Verfügbarkeitsfenster durchgeführt werden (und nicht auf dem sozialen Kanal, unter der Annahme, dass das Verfügbarkeitsfenster nicht auf dem sozialen Kanal durchgeführt wird). Während Verfügbarkeitsfenster, die nicht mit dem Ende einer DB-Periode des Masters überlappen, kann der Master nichtsdestotrotz ein Synchronisationsbeacon senden, um sicherzustellen, dass Vorrichtungen, die mit ihm synchronisiert sind, die notwendigen Synchronisationsdaten haben, ohne einen sozialen Kanal für einen regulären DB einstellen zu müssen. Allerdings kann eine Vorrichtung weiterhin periodisch auf einem oder mehreren sozialen Kanälen hören, um von anderen Mastern zu erfahren und/oder aus anderen Gründen.
• Da Peer-Vorrichtungen, die einen Anwesenheitsmoduswert größer als 1 aufweisen, nicht an jedem Verfügbarkeitsfenster teilnehmen können, es aber von ihnen verlangt werden kann, dass sie während Verfügbarkeitsfenstern, die die Sequenznummer 0 aufweisen, anwesend sind, kann ein Master standardmäßig immer während diesen Fenstern ein DB oder SB ausstrahlen. Wohingegen DB kurz sind, aber häufig, sind SB länger und seltener und können erweiterte Dienste und Vorrichtungs-, Fähigkeits-, Nutzlasten tragen.
• Es wäre zu wiederholen, dass Ermittlungsbeacons häufig gesendet werden, üblicherweise außerhalb von Verfügbarkeitsfenstern, um nichtsynchronisierten Vorrichtungen zu helfen sich mit ihren Peers zu synchronisieren. Nachdem eine Gruppe von Vorrichtungen synchronisiert ist, können diese Vorrichtungen sich nur (oder primär) während relativ spärlichen Verfügbarkeitsfenstern treffen, insbesondere diese Vorrichtungen, die ihre Anwesenheitmodi angepasst haben, um ihre Hochfrequenzeinrichtungen weniger zu verwenden und damit Energie zu sparen. Um synchronisiert zu bleiben, können diese Vorrichtungen auf Synchronisationsbeacons vertrauen, die während Verfügbarkeitsfenstern gesendet werden.
• In einigen Ausführungsformen wird von Vorrichtungen verlangt, Schutzperioden an dem Anfang von einigen (oder allen) Verfügbarkeitsfenstern zu implementieren, während denen sie hören und Kommunikation empfangen können, aber nicht übermitteln. In unterschiedlichen Ausführungsformen kann oder kann nicht diese Beschränkung immer auf Master angewendet sein, die reguläre DBs ausgeben, aber werden generell immer auf Nichtauswahlmaster angewendet.
• 2 ist ein Flussdiagramm, das Synchronisation und Betrieb von einer Vorrichtung innerhalb einer Gruppe von Peers in einer drahtlosen Kommunikationsumgebung entsprechend einigen Ausführungsformen demonstriert.
• In Operation 202 schaltet sich die Vorrichtung an oder betritt die Gruppenumgebung und beginnt auf einem oder mehreren vorbestimmten sozialen Kanälen nach einem Ermittlungsbeacon (DB) zu hören. Sie kann mit Informationen programmiert sein, die den Standard- oder möglichen Periodizitäten von DBs entsprechen und kann deshalb nur auf einem gegebenen sozialen Kanal für eine beschränkte Anzahl von diesen Perioden (z.B. 1,2) zu hören müssen, um eine DB-Ausstrahlung von einem Master auf diesem Kanal abzufangen.
• In Operation 204 vernimmt die Vorrichtung eine oder mehrere DB und extrahiert die angebotenen Synchronisationsdaten. In der veranschaulichten Ausführungsform bewerben alle DB die von dem Master innerhalb der gleichen Vorrichtungsgruppe ausgegeben sind, die gleiche Verfügbarkeitsfenstersequenz oder den gleichen Verfügbarkeitsfensterzeitplan. Die Master können ihre DB auf dem gleichen oder unterschiedlichen sozialen Kanälen übermitteln und können die Verfügbarkeitsfenster auf den gleichen nichtsozialen Kanälen durchführen.
• Falls die Vorrichtung keinen Ermittlungsbeacon hört, kann sie annehmen, dass es keinen Master innerhalb einer Reichweite gibt. Deshalb kann sie die Rolle von einem Rootmaster übernehmen und beginnen, ihre eigenen DB auszugeben, um andere Vorrichtungen in Reichweite zu synchronisieren.
• In Operation 206 stellt die Vorrichtung ihre Hochfrequenzeinrichtung auf den spezifizierten Kanal ein und nimmt an dem nächsten Verfügbarkeitsfenster teil, unter der Annahme, dass ihre Hochfrequenzeinrichtung nicht von einer anderen Anwendung oder einem anderen Dienst vorweggenommen wird. Falls sie nicht teilnehmen kann, wird die Vorrichtung an dem nächsten Verfügbarkeitsfenster teilnehmen, an dem sie teilnehmen kann, obwohl sie wieder ein Hören auf einem sozialen Kanal benötigen könnte, um den nächsten Satz von Synchronisationsdaten zu empfangen und den Zusammentreffkanal und die Startzeit zu identifizieren. Die Vorrichtung kann ein Teilnehmen an einem Verfügbarkeitsfenster bis zu dem Start von der nächsten Sequenz von Fenstern verschieben und deshalb das nächste verlangte Fenster einstellen (üblicherweise ein Fenster, das die Sequenznummer o aufweist).
• In Operation 208 während eines Verfügbarkeitsfensters wird ein Beacon, welches Synchronisationsdaten enthält (z.B. ein DB oder ein SB) durch den Master, mit welchem die Vorrichtung jetzt synchronisiert ist ausgestrahlt. Dies kann die Vorrichtung befreien von der Notwendigkeit, um einen oder mehrere soziale Kanäle zu scannen. Das Beacon kann veranschaulichend während einer initialen Schutzperiode oder Ruheperiode am Anfang von dem Verfügbarkeitsfenster übermittelt werden, während welchem Nichtmastervorrichtungen nicht übermitteln können.
• In Operation 210 setzt die Vorrichtung ihren Anwesenheitsmodus, falls erforderlich oder gewünscht (z.B. falls die Vorrichtung nicht an der gesamten Sequenz von Verfügbarkeitsfenstern teilnehmen kann). Während zumindest dem ersten Verfügbarkeitsfenster, an dem sie teilnimmt und/oder das erste Verfügbarkeitsfenster, welches die Sequenznummer o aufweist, identifiziert die Vorrichtung sich selbst (z.B. Adresse, Name, Dienstinformation) in einer Nachricht, die an alle synchronisierten Vorrichtungen ausgestrahlt wird. Sie kann ihren Anwesenheitsmodus zu der gleichen Zeit bewerben.
• In einer optionalen Operation 212 kann die Vorrichtung direkt mit einer oder mehreren von ihren synchronisierten Peers kommunizieren, während des Verfügbarkeitsfensters und/oder außerhalb des Bandes oder sie können mit der Vorrichtung kommunizieren. Wie oben diskutiert, kann die Vorrichtung ihre Teilnahme an dem Fenster ein oder mehrere Male erweitern, um die Kommunikationen zu erleichtern, wird an ihrer aktiven Peers bewerben, falls und wenn sie das Fenster verlassen muss, bevor ihres normalen Beendens (z.B. um ihre Hochfrequenzeinrichtung für irgendeinen anderen Zweck zu verwenden) und kann ein getrenntes Zusammentreffen vereinbaren (auf dem gleichen oder einem unterschiedlichen Kanal) mit einem oder mehreren Peers.
• In einigen Ausführungsformen können Verkehrsreduzierungs- oder Beschränkungsmaßnahmen implementiert werden während einigen oder allen Verfügbarkeitsfenstern, um Kommunikationskonflikte und Kollisionen zu verringern. Veranschaulichend kann der Master, der die Verfügbarkeitsfenstersequenz steuert, spezifizieren wann eine Maßnahme eingesetzt wird. In einigen Implementierungen werden Verkehrsreduzierungsmaßnahmen nur angewendet, während Verfügbarkeitsfenstern und nicht während Verfügbarkeitsfenstererweiterungen. In Pflichtverfügbarkeitsfenstern (d.h. Verfügbarkeitsfenstern, die die Sequenznummer o aufweisen) können Verkehrsreduzierungsmaßnahmen Pflicht sein.
• Als Beispiel kann eine Verkehrsreduzierungsmaßnahme dazu dienen, um eine Vorrichtung bezüglich der Anzahl von Multicastframes, die sie während eines Verfügbarkeitsfensters übermitteln kann (z.B. ungefähr 3) zu beschränken. Übermittlungen von Unicastframes können auch beschränkt werden.
• Zum Beispiel können Unicastübermittlungen nur erlaubt werden zu (und/oder von) Vorrichtungen, die unbekannte Anwesenheitsmoduswerte oder Werte größer als 1 (oder irgendein anderer Schwelle) aufweisen. Beschränkungen für Unicast oder Multicastframeübermittlungen können nicht auf Vorrichtungen, die unter sich selbst (z.B. mit einem Nichtauswahlmaster) für einen beschränkten Zweck, wie beispielsweise einen Dateiaustausch, synchronisiert sind, angewendet werden.
• In Operation 214 kann die Vorrichtung ihre Hochfrequenzeinrichtung ausschalten, wenn sie nicht gebraucht wird zum Hören nach DB auf einem sozialen Kanal oder zum Teilnehmen an einem Verfügbarkeitsfenster.
• Das in 2 dargestellte Verfahren ist nur veranschaulichend und beschränkt nicht Verfahren, die anderen Ausführungsformen entsprechen.
• Wie oben beschrieben können zwei oder mehrere Peers sich in ihrer eigenen Synchronisation engagieren, außerhalb von oder zusätzlich zu jedem Verfügbarkeitsfenster. Zum Beispiel kann eines von ihnen die Rolle von einem Nichtauswahlmaster übernehmen und Synchronisationsbeacons oder andere Ermittlungsbeacons während eines Verfügbarkeitsfensters ausgeben, um seine Peers zu benachrichtigen, wann und wo (d.h. Zeit und Kanal) sie sich mit ihm synchronisieren können.
• Allerdings kann ein Peer einen kurzen Kommunikationsaustausch mit einem anderen Peer ohne Synchronisierung wünschen. Zum Beispiel kann eine Vorrichtung, die innerhalb der einen Gruppe synchronisiert ist, Dienste ermitteln wollen, die von einem Peer (oder Peers) angeboten werden, der innerhalb einer unterschiedlichen (z.B. benachbarten) Gruppe synchronisiert ist, und eine Gruppenvorrichtung kann einen benachbarten Peer befragen wollen oder kann einige Informationen zu ihrem Master kommunizieren wollen, usw. Zumindest Initial beabsichtigen sie nicht, sich in einem signifikanten Datenaustausch zu engagieren (z.B. wie mit einem Dateiaustausch). Einige Ausführungsformen stellen diese Fähigkeit in Form von Anfragen und Antworten, die außerhalb des Bandes sind, bereit.
• 3 ist ein Diagramm, das einen bandexternen Austausch zwischen Peer-Vorrichtungen entsprechend einiger Ausführungsformen demonstriert. Wie mit dem Timing von den oben beschriebenen Ermittlungs-beacons muss die Übermittlungsvorrichtung Verzögerungen berücksichtigen, die innerhalb ihr selbst auftreten werden, zwischen der Zeit, zu der sie die Anfrage freigibt oder vorbereitet für die Übertragung und der Zeit, zu der sie tatsächlich übermittelt wird.
• Anfragezeitachse 310 spiegelt Aktivität an der Anfragevorrichtung wider, während eine Antwortzeitachse 330 Aktivität an der antwortenden Peer-Vorrichtung widerspiegelt. Wenn die Anfrage ausgegeben wird, muss die anfragende Vorrichtung eine angemessene Anfragelebenszeit 350 wählen, so dass die antwortende Vorrichtung Zeit hat zum Empfangen, Bearbeiten und auf die Anfrage zu reagieren.
• In der veranschaulichenden Anfrage und Antwort, ist die Anfrage für eine Übertragung von der anfragenden Vorrichtung zu einer Zielübermittlungszeit 312 eingereiht. Aufgrund von Konflikten für die Antenne oder das Medium und/oder andere Verzögerungen (kollektiv als Konflikt 314 in 3 dargestellt) ist die Anfrage nicht physikalisch übermittelt bis zur tatsächlichen Übermittlungszeit 316.
• Verweildauer 318 ist der Rest von der Anfragelebenszeit, während welcher die antwortende Peer-Vorrichtung die Anfrage empfangen muss und ihre Antwort generieren und übermitteln muss. Die Dauer der Verweildauer 318 hängt von der Anfragelebenszeit ab, die durch die anfragende Vorrichtung und die Dauer der Konflikte 314 gesetzt wird. Die antwortende Vorrichtung kann auch Verzögerung zwischen ihrer Zielübermittlungszeit 332 und der tatsächlichen Übermittlungszeit 336 der Antwort erfahren; diese Verzögerung wird als Konflikte 334 dargestellt.
• Die Anfrage kann (in der bandexternen Anfrage) irgendeinen oder alle von den relevanten Zeitparametern identifizieren (z.B. Anfragelebenszeit, Zielübermittlungszeit, tatsächliche Übermittlungszeit, Konflikt), so dass der antwortende Peer bestimmen kann, ob er fähig sein wird, zu antworten bevor die Anfrage abläuft. Falls nicht, kann er die Anfrage fallen lassen oder seine Antwort abbrechen. Falls die anfragende Vorrichtung keine Antwort empfängt, während der Anfragelebenszeit, kann sie es nochmals versuchen (z.B. mit einer längeren Lebenszeit), die Anfrage aufgeben oder eine andere Aktion ausführen.
• In einigen Ausführungsformen kann eine Peer-Vorrichtung bandexterne Anfragen zu einem Master ausgeben, den sie hören kann, aber mit welchem sie nicht synchronisiert ist, um Dienste zu identifizieren, die von diesem Master angeboten werden und/oder Vorrichtungen, die zu dieser Station synchronisiert sind. In einigen Implementierungen kann sie Informationen, bezogen auf andere Master (oder andere Gruppen) zu ihrem Master und/oder synchronisierten Peers weitergeben, sowie während einer oder mehreren von ihren Verfügbarkeitsfenstern. Informationen über einen anderen Master, Vorrichtung oder Gruppe, die aufgezeigt werden können, können Dinge sowie beispielsweise einen sozialen Kanal, den sie verwendet, ihren Verfügbarkeitsfensterzeitplan (z.B. Zeit, Kanal, Periode), (Durchschnitts)-Beaconperiode, Masteroffset, Dienste, die sie anbietet, Adressen, usw. beinhalten. Eine bandexterne Anfrage kann somit als eine Quasi-DB oder Quasi-SB funktionieren, insofern als sie Synchronisation mit einer Vorrichtung zu oder mit einer anderen vereinfacht.
• Einige unsynchronisierte Master (z.B. Master mit welchen keine Peer-Vorrichtungen synchronisiert sind) können einen Niedrigenergiebetriebsmodus übernehmen. Dieser Niedrigenergiebetriebsmodus kann in den Ermittlungsbeacons der Station angegeben sein oder kann aus der Sequenz oder dem Zeitplan von Verfügbarkeitsfenstern und/oder des Anwesenheitsmodus, der in den Ermittlungsbeacons beworben wird, schlussgefolgert werden.
• In solch einem Betriebsmodus kann ein unsynchronisierter Master weiterhin Ermittlungsbeacons senden, stellt aber kurze Verfügbarkeitsfenster, die lange Perioden aufweisen (z.B. mehrere Sekunden) bereit. Aufgrund der kurzen, spärlichen Natur der Verfügbarkeitsfenster, kann es einige Zeit in Anspruch nehmen für einen Peer, um Dienste zu ermitteln, die von dem unsynchronisierten Master angeboten werden.
• Während einer Synchronisation von Peers innerhalb einer Kommunikationsumgebung entsprechend einiger Ausführungsformen, während Peer-Vorrichtungen innerhalb einer Gruppe in einem Synchronisationsbaum organisiert sind, synchronisieren sich Nichtmastervorrichtungen mit Sync-Mastern innerhalb der Reichweite; wobei diese Synchronisationsmaster (und möglicherweise andere Nichtmastervorrichtungen) sich mit höheren Sync-Mastern synchronisieren, usw. mit einem Ankermaster an der Spitze des Baumes, der Synchronisationsinformationen für die gesamte Umgebung bereitstellt. Eine Nichtmastervorrichtung kann sich direkt mit dem Ankermaster synchronisieren, falls er in Reichweite ist.
• Ein Betriebsparameter von Vorrichtungen kann die maximale Tiefe von dem Synchronisationsbaum der Gruppe spezifizieren, welche als die Anzahl von Stufen oder Schichten von Mastern definiert werden kann. Die Position des Ankermasters ist definiert als Schicht o und Synchronisationsmaster werden in Schichten, die von 1 bis D durchnummeriert sind, liegen, wobei D die maximale Schicht ist, an welcher ein Master liegen kann. Die Tiefe des Baumes kann als D definiert werden (oder als D+1, um Nichtmastervorrichtungen zu erfassen) und die maximale Anzahl von Sprüngen zwischen dem Ankermaster und einer Nichtmaster-(z.B. Blatt)-Vorrichtung ist D+1.
• Standardmäßig während die Gruppe organisiert wird, kann eine Peer-Vorrichtung Ermittlungsbeacons ausgeben bis sie in eine Position als ein Nichtmaster fällt, zu welcher Zeit sie stoppen kann Beacons zu übermitteln oder nicht zu übermitteln. Eine Vorrichtung kann wählen, eine Nichtmastervorrichtung zu sein, sogar falls der anwendbare Auswahlalgorithmus anderweitig sie als ein Master machen könnte, außer wenn es keinen Master in Reichweite der Vorrichtung gibt. Falls es keinen anderen Master in Reichweite gibt, muss die Vorrichtung diese Rolle übernehmen.
• Alle Master geben weiterhin DB aus, um Synchronisation innerhalb ihrer Flächen zu behalten und machen dies mit einer Periodizität, die eine Funktion ihrer Stufe oder Schicht innerhalb ihrer Gruppe ist. Zum Beispiel kann der Ankermaster auf Schicht 0 ungefähr alle 100 Millisekunden DB ausgeben, ein Synchronisationsmaster auf Schicht 1 kann ungefähr alle 150 Millisekunden DB ausgeben, ein Syncmaster auf Schicht 2 kann alle 500 Millisekunden DB ausgeben usw. Diese Werte sind nur beispielhaft und in keiner Art beschränken oder begrenzen sie die Dauer von DB Perioden; Master innerhalb unterschiedlicher Schichten können die gleiche Periode benutzen und Master in der gleichen Schicht können unterschiedliche Perioden benutzen.
• Eine Schicht eines Masters wird üblicherweise innerhalb seines DB berichtet. Diese Information ermöglicht es, einer Hör-Vorrichtung zu bestimmen, wie tief die Gruppe innerhalb ihrer Fläche der Gruppe ist. Abhängig von dieser Tiefe und/oder anderen Informationen (z.B. wie viele Master sie hören kann, die DB ausgeben, der maximalen Gruppentiefe) kann die Vorrichtung bestimmen, dass sie ein Nichtmaster sein soll oder dass sie weiterhin DB ausgeben soll und weiterhin ein Master bleiben soll.
• Ein maximaler Tiefenparameter einer Gruppe kann in eine Vorrichtung programmiert sein und/oder innerhalb von Ermittlungsbeacons und/oder anderen Beacons beworben werden. Andere Beschränkungen können auch eingeführt werden, wie beispielsweise eine maximale Anzahl von Mastern, eine Beschränkung, dass ein Master nur solange in seiner Rolle weitermachen kann, wie er nicht mehr als eine Schwellenanzahl von anderen Mastern hören kann (z.B. innerhalb einer bestimmten Reichweite, auf einer bestimmten Schicht, insgesamt), usw.
• Zum Beispiel wo die maximale Tiefe der Gruppe D ist, kann ein Master, der auf einer Schicht S>i liegt (d.h. alle Schichten abgesehen von der des Ankermasters) nur ermöglicht werden, D-S andere Master zu hören, die in der Schicht S arbeiten und weiterhin als ein Master dienen (angenommen diese anderen Master haben höhere und bessere Mastereinstellungswerte). Diese Maßnahme kann eine Konzentration von höherstufigen Syncmaster nahe dem Ankermaster und eine Verteilung von Synchronisationsmaster weiter entfernt erlauben.
• In einigen Ausführungsformen kann ein Masterauswahlalgorithmus oder -Verfahren bevorzugen, einen etablierten Master zu behalten, anstelle einer anderen Vorrichtung, der ansonsten der Vorzug gegeben würde, außer die Auswahleinstellungswerte der anderen Vorrichtung übertreffen den des etablierten um eine Schwelle. Dies kann helfen durchzudiskutieren oder exzessive Wechsel von Master zu verhindern. Allerdings weil eine Hauptaufgabe eines Masters ein einfaches Ausstrahlen von Synchronisationsdaten ist, führt Wechseln von Mastern nicht zu hohen Transaktionskosten in der Gruppe oder einer individuellen Vorrichtung.
• In einigen Ausführungsformen wird eine Vorrichtung sich mit dem besten Master synchronisieren, den sie hören kann (d.h. der Master, der den höchsten Einstellungswert aufweist) oder der beste Master, den sie innerhalb einer gegebenen Reichweite hören kann (z.B. mit einer Signalstärke über einer bestimmten Schwelle).
• Wenn eine Vorrichtung in einer Umgebung online geht und nach Ermittlungsbeacons hört, falls sie nur von einem Synchronisationsmaster von der tiefsten oder maximal erlaubten Schicht von einer Gruppe hört, kann sie sich zu dieser Station synchronisieren als ein Nichtmaster. Falls allerdings die Vorrichtung auch andere Master in einer unterschiedlichen Gruppe vernimmt (z.B. wie durch die Ankermasterattribute, die in einem Ermittlungsbeacon beworben werden, bestimmt wird) kann sie ein Betreten dieser Gruppe favorisieren, falls dieser andere Master nicht auf der maximalen Tiefe oder Schicht ist oder falls dieser andere Master einen besseren Mastereinstellungswert hat.
• Eine Vorrichtung, die nur andere Vorrichtungen hören kann, die relativ tief in der Gruppe sind (z.B. hohe Schichtenwerte) können fähig sein zu bestimmen, dass sie am Rande der synchronisierten Umgebung sind. Falls die meisten oder alle der anderen Vorrichtungen bereits auf der maximalen Tiefe sind, kann eine neue Gruppe sich hervorbringen, insbesondere falls eine Vorrichtung mit einem hohen Einstellungswert erscheint.
• Eine neue Umgebung/Gruppe kann sich also auch hervorbringen, wenn sich eine existierende sich zu weit über eine räumliche Fläche aufspannt. Zum Beispiel kann eine Kombination von der Tiefe der Gruppe, ein Maß wie nahe Peer-Vorrichtungen sind und/oder andere Faktoren eine neue Gruppe dazu veranlassen, hervor gebracht zu werden. Signalstärken, die zwischen Peers entdeckt werden, können eine Art sein, um die Nähe von Peers zu bestimmen.
• Von Peers zu verlangen, sich nur mit Mastern zu synchronisieren, die relativ nahe zu Ihnen sind, kann die Gruppe dazu veranlassen, relativ kompakt zu sein. Im Gegensatz dazu kann eine hohe Grenze der maximalen Tiefe des Baums der Gruppe ermöglichen, mehr Fläche zu bedecken. Durch Anpassen dieses (und/oder anderer Parameter) kann eine geeignete Gruppe formiert werden.
• Unterschiedliche Parameter zum Konfigurieren einer Gruppe werden für unterschiedliche Umgebungen geeignet sein, abhängig von der Dichte der Vorrichtungen, der Kommunikationslast und/oder anderen Faktoren. Zum Beispiel falls die Last relativ leicht ist (z.B. die Vorrichtungen sind Niedrigenergiesensoren), sollen Beeinträchtigungen, die mit einem versteckten Knotenproblem verbunden sind, begrenzt werden und eine relativ tiefe Gruppe kann implementiert werden (z.B. in der Größenordnung von 10-15 Schichten). In spärlicheren Umgebungen löst sich auch ein Verfahren zur Auswahl von Mastern schneller auf.
• Das versteckte Knotenproblem bezieht sich auf ein Szenario, in welchem mehrere Vorrichtungen, die nicht in Reichweite zueinander sind, versuchen mit einem gemeinsamen Peer zu kommunizieren. Weil sie nicht die Übermittlung voneinander vernehmen können, können sie sie nicht vermeiden und ihre Kommunikationen zu dem gemeinsamen Peer können kollidieren. Obwohl dies durch die Notwendigkeit während einer relativen kurzen Zeitperiode zu kommunizieren verschlimmert wird (z.B. innerhalb eines Verfügbarkeitsfensters), kann eine leichte Last helfen, um das Problem zu mildern und eine tiefere Gruppe als sie in einer dichteren Umgebung mit einer schwereren Last möglich wäre, zu ermöglichen.
• Ohne hierin ein Synchronisationsverfahren zu beschreiben, könnte die totale Anzahl von Ermittlungsbeacons oder Frames, die gebraucht werden, um alle Vorrichtungen in einer Umgebung zu ermitteln, sich dem Quadrat der Anzahl von Vorrichtungen nähern (d.h. jede Vorrichtung könnte zumindest ein Frame zu jeder anderen Vorrichtung senden müssen). Diese Frames würden zu Zufallszeiten und auf jeden Kanälen gesendet werden.
• Im Gegensatz dazu ermöglicht die kollektive Synchronisation die von einigen Ausführungsformen angeboten wird, eine Synchronisation basierend auf regelmäßigen Übermittlungen von einer ausgewählten Menge an Vorrichtungen (d.h. Master) und skaliert gut. In einer perfekten synchronisierten Umgebung, ist die Anzahl an Frames, die benötigt wird, damit alle Vorrichtungen einander ermitteln, proportional zu der Anzahl an Vorrichtungen. Die eine Ermittlungsbeaconausstrahlung während eines Verfügbarkeitsfensters, welches eine Sequenznummer o aufweist, wird alle anderen Vorrichtungen in Reichweite erreichen.
• Kooperative Kanalwechsel
• In einigen Ausführungsformen plant eine Peer-Vorrichtung eine Sequenz von Kanälen und passt sie an, zu welchen eine Hochfrequenzeinrichtung eingestellt wird, basierend auf mehreren konkurrierenden Nachfragen, die Datenübertragung oder Datenaustauschoperationen beinhalten. Zum Beispiel und wie vorher beschrieben, kann ein Teil von einem synchronisierten Peer-to-Peer Netzwerk von einer Vorrichtung verlangen, an einer oder mehreren Verfügbarkeitsfenstern auf einem Zusammentreffkanal teilzunehmen und könnte Ausstrahlen oder Empfangen von Ermittlungsbeacons (DB) auf einem oder mehreren sozialen Kanälen müssen. Andere Vorrichtungsfunktionen können auch eine Verwendung von einer geteilten Antenne verlangen, um eine Verbindung mit einem Zugriffspunkt beizubehalten, um einen oder mehrere Kanäle, abgesehen von dem aktuellen Kanal, zu scannen, Bluetooth^® Operationen zu unterstützen usw.
• Traditionelle Verfahren zum Beherbergen mehrerer Nachfragen auf einer geteilten Kommunikationsressource involvieren üblicherweise ein Gewähren der Ressource einer Funktion nach der anderen nacheinander. In diesen Verfahren könnten zum Beispiel eine Peer-to-Peer Kommunikationssitzung einer Vorrichtung mit einer anderen Vorrichtung (z.B. zur Datenübertragung) unterbrochen werden, um eine Bluetooth-Anforderung zu beherbergen, um eine andere Einheit zu kontaktieren, dann könnte die Peer-to-Peer Sitzung weitergehen, nur um durch eine Anforderung auf einen sozialen Kanal einzustellen unterbrochen zu werden, um einen Ermittlungsbeacon zu erfassen, um dann zu der Datenübertragungsoperation zurückzukehren, um dann Frequenzen zu wechseln, um einen Kanalscan durchzuführen, usw.
• Ein Problem mit diesen traditionellen Verfahren zum Beherbergen von konkurrierenden Nachfragen für eine Hochfrequenzeinrichtung einer Vorrichtung ist, dass der Durchsatz von einer Datenübertragungsoperation, die von der Vorrichtung durchgeführt wird, leiden wird. Insbesondere jedes Mal, bei dem die Hochfrequenzeinrichtung von einem Kommunikationspartner entfernt eingestellt wird, muss die Datenkommunikation für eine gewisse Zeitdauer enden.
• Deshalb ist in einigen Ausführungsformen eine Sequenz von Kanälen, zu welchen eine Peer-Vorrichtung seine Hochfrequenzeinrichtung einstellt, gestaltet, um einen laufenden Datenaustausch oder andere Kommunikationen zu fördern, während die Vorrichtung einen oder mehreren konkurrierenden Kommunikationsnachfragen genügt. In diesen Ausführungsformen wird eine Vorrichtung, die eine Kommunikationsressource (z.B. Hochfrequenzeinrichtung, Antenne) unter mehreren Funktionen oder Operationen teilen muss, während sie in einer Datenübertragung mit einem oder mehreren Peers engagiert ist, eine Sequenz von Sequenzwechsel entwickeln, die diese Nachfragen beherbergen wird, diese Peers über den Zeitplan benachrichtigen und, während der Sequenz von Wechseln, weiterhin Daten austauschen bis zu dem Umfang, der möglich ist.
• Weil jeder Frequenzwechsel eine vorbestimmte Dauer (z.B. 60ms, 100ms) haben kann und die Vorrichtung nur einen Teil von dieser Zeit benötigen kann, um der Arbeitslast zu genügen, die verlangt hat, einen bestimmten Kanal einzustellen (z.B. um einen aktiven oder passiven Scan durchzuführen, um einen Beacon oder anderes Signal auszugeben, um einen Beacon zu erfassen) für den Rest der Zeit, die auf dem eingestellten Kanal verbracht wird, kann die Vorrichtung weiterhin Daten mit einem Peer übertragen, der in der Lage ist, einige oder alle der Frequenzänderungen zu beherbergen.
• In einigen Ausführungsformen kann ein Paar von Peer-Vorrichtungen sich arrangieren zum Austauschen von Daten, um eine Datei zu übertragen, zum Spielen eines Spiels, zum Ermitteln von Diensten und/oder aus anderen Gründen. Um den Datenaustausch zu unterstützen kann in unterschiedlichen Implementierungen das Paar von Vorrichtungen einen privaten Verbund formieren innerhalb ihrer synchronisierten Gruppe, wobei einer von ihnen ein Nichtauswahl-Master werden kann, in welchem Fall die andere sich mit ihr synchronisieren wird, sie können sich in bandexterner Kommunikationen engagieren oder es können einige andere Formen von Kooperation durchgeführt werden.
• Zum Zwecke einiger Ausführungsformen zu erklären, wird angenommen werden, dass die Vorrichtungen synchronisiert sind- entweder hat sich eine mit der anderen synchronisiert oder sie haben sich beide mit einer oder mehreren Synchronisationsstationen synchronisiert innerhalb der gleichen hierarchischen Gruppe. Sie können einen Verbund oder ein Teil eines Verbunds sein, wobei die eine ein Nichtauswahl-Master sein kann oder sie können einige andere Formen von einer Eins-zu-Eins-Synchronisation implementiert haben.
• Weil sie Teil von einer Hierarchie sind, haben sie eine gemeinsame Verpflichtung zum Beibehalten einer Synchronisation mit dieser Gruppe, welche in diesen beispielhaften Ausführungsformen von ihnen verlangen, spezifizierte Kanäle einzustellen, um DB zu empfangen und/oder an Verfügbarkeitsfenstern teilzunehmen. Zum Zwecke der Veranschaulichung haben sie alle auch getrennte Anforderungen, um unterschiedliche Zugriffspunkte oder andere Infrastrukturvorrichtungen regelmäßig zu kontaktieren.
• 4A veranschaulicht Kanalsequenzen für zwei Peer-Vorrichtungen, die in einer Übermittlung von Daten engagiert sind innerhalb einer Peer-to-Peer-Netzwerkumgebung, wie hierin beschrieben, entsprechend einiger Ausführungsformen.
• In diesem veranschaulichenden Szenario ist eine Modellsequenz 410 eine Vorlage, die eine Sequenz von Funktionen zeigt, zu welchen eine Vorrichtung ihre drahtlosen Kommunikationsressourcen in einem Betriebszyklus zuordnen soll. In diesem Szenario dauert ein ganzer Zyklus 960 ms und ist in 16 Zeitschlitze geteilt, die alle 60ms lang sind. Die Funktionen sind folgender Massen abgekürzt:

  Funktion	Kanal der Vorrichtung A	Kanal der Vorrichtung B
  Si: sozialer Kanal 1	6	6
  S2: sozialer Kanal 2	112	112
  D: Datenkanal	157	157
  I: Infrastrukturkanal	36	5

• Weil Vorrichtung A und B innerhalb der gleichen Hierarchie synchronisiert sind (oder miteinander), verwenden sie die gleichen sozialen Kanäle „Si“ und „S2“ - Kanal 6 und 112. Wie oben beschrieben ist ein sozialer Kanal ein Kanal, auf welchem ein oder mehrere Masterstationen Ermittlungsbeacons ausstrahlen. Peer-Vorrichtungen werden deshalb einen sozialen Kanal einstellen, um einen DB zu empfangen. Veranschaulichend können ein oder zwei soziale Kanäle (z.B. S1) in dem 2,4 GHz Band sein und der andere (z.B. S2) in dem 5 GHz Band sein. Vorrichtungen A und B können Dualbandvorrichtungen sein und deshalb beide Kanäle überwachen.
• Datenkanal „D“ ist der Kanal, der für Vorrichtungen A und B ausgewählt ist zum Verwenden, um ihren Datenaustausch durchzuführen. Der spezifizierte Kanal (z.B. Kanal 157) kann einer aus einer vorbestimmten Liste von Kanälen sein, für den Versuch zum Verwenden, wobei eine von den zwei Vorrichtungen den Kanal spezifiziert oder angefragt haben kann, wobei er in einem DB oder SB identifiziert sein kann oder er in einer anderen Art ausgewählt oder spezifiziert werden kann.
• Infrastrukturkanäle „I“ werden durch Vorrichtungen A und B verwendet zum Beibehalten von Kontakt mit ihren entsprechenden Zugriffspunkten oder einigen anderen Infrastrukturkomponenten. Wie in der Modellsequenz 410 gezeigt, muss jede Vorrichtung periodisch ihre Hochfrequenzeinrichtung verwenden, um die Infrastrukturverbindung zu unterstützen. Weil von ihnen angenommen wird, dass sie in getrennten Basisdienstmengen (basic service sets, BSS) teilnehmen, hat jede eine unterschiedliche Infrastrukturverpflichtung (d.h. Kanal 36 für Vorrichtung A und Kanal 5 für Vorrichtung B).
• Kanalsequenzen 430, 450 veranschaulichen die Sequenz von Kanalwechsel, die jeweils durch Vorrichtungen A und B implementiert sind, und sind gemäß der Modellsequenz 410 konfiguriert. Es ist zu beachten, dass die Vorrichtungen eine Verwendung von dem Datenkanal für die gleichen Schlitze geplant haben und werden diese Schlitze verwenden, um ihren Datenaustausch durchzuführen.
• In einigen Ausführungsformen stimmen Kanalsequenzen 430, 450 mit einem Zeitplan von Verfügbarkeitsfenstern, die von dem Master ausgegeben sind, überein. Zum Beispiel können einige oder alle von den Zeitschlitzen, die für Datenaustausch auf dem Kanal 157 geplant sind mit geplanten Verfügbarkeitsfenstern auf diesem Kanal übereinstimmen. Wie in vorangegangenen Abschnitten beschrieben, kann eine Sequenz von Verfügbarkeitsfenstern relativ lang sein (z.B. mehrere Sekunden) und eine Vorrichtung braucht nicht an jedem Verfügbarkeitsfenster teilzunehmen. Deswegen können die Kanalsequenzen 430, 450 einen oder mehrere Zeitschlitze beinhalten, die mit den Verfügbarkeitsfenstern zusammenfallen.
• In einigen Ausführungsformen kennt jede Vorrichtung die Zeitpläne ihrer Peers betreffend ihrer Kanalsequenzen. Deswegen weiß jede der Vorrichtungen A, B, dass die andere Vorrichtung die gleichen Sozialkanäle eingestellt hat, während der 1., 3., 9. und 11. Zeitschlitze von einem Kommunikationszyklus. Zusätzlich wissen sie, weil jeder der Vorrichtungen A, B den Anwesenheitsmoduswert der anderen Vorrichtung weiß, an welchem Verfügbarkeitsfenster die andere Vorrichtung teilnehmen wird.
• In einigen Implementierungen, während eines Zeitschlitzes, der gedacht ist, um ein DB zu erfassen, können die Vorrichtungen mit ihrem Datenaustausch fortfahren, nachdem sie den Beacon empfangen haben oder können ihren Datenaustausch wie gewohnt während diesen Zeitschlitzen durchführen und ermöglichen dem Master, der die DB senden soll, sich mit den Peers um die Verwendung des Kanals zu bewerben. In noch anderen Implementierungen können die vollen Zeitschlitze allerdings zugeordnet sein, um Ermittlungsbeacons zu empfangen und/oder an einem Verfügbarkeitsfenster während den Zeitschlitzen der sozialen Kanäle teilzunehmen.
• In der Sequenz von Kommunikationsoperationen, die in 4A dargestellt ist, werden Kanalwechsel verlangt, aber nur mit begrenzter Konkurrenz zwischen unterschiedlichen Kommunikationsfunktionen. Insbesondere hat jede Vorrichtung eine Verpflichtung zum Beibehalten einer Infrastrukturverbindung; diese Verbindungen sind auf unterschiedlichen Kanälen und erlauben deshalb keinen opportunistischen Datenaustausch. Allerdings, weil diese Infrastrukturanforderungen geplant sind, während der gleichen Zeitschlitze, genügen beide Vorrichtungen ihnen nebeneinander.
• Jede Vorrichtung nimmt auch in einer Peer-to-Peer Communications-Umgebung teil, welche von ihnen verlangt, periodisch Beacons zu erfassen und/oder andere Aktionen durchzuführen (z.B. an Verfügbarkeitsfenstern teilzunehmen). Schlussendlich engagieren sich Vorrichtungen in einer Datenaustauschoperation, die direkt in Konflikt steht zu den Infrastrukturverbindungsanforderungen und welche auch in Konflikt stehen kann zu den Peer-to-Peer Synchronisationsanforderungen. Insbesondere können die Synchronisationsanforderungen des Peer-to-Peer Netzwerks einen opportunistischen Datenaustausch berücksichtigen, aber die Infrastrukturanforderungen können das nicht.
• 4B stellt eine weitere Änderung der Vorrichtungsoperationen dar, in dem Vorrichtung A nun eine Anforderung hat zum Durchführen von Scans auf mehreren unterschiedlichen Kanälen - Kanälen 1, 7 und 11. Zum Zwecke der Veranschaulichung wird angenommen, dass jeder Scan innerhalb von einem Zeitschlitz beendet werden kann. Auf diese Weise, in welcher die Vorrichtungen kooperieren zum opportunistischen Weiterführen ihres Datenaustauschs, während eine von ihnen Kanalscans durchführt, kann auch angewendet werden, wenn eine oder beide Vorrichtungen einer unterschiedlichen Art von Nachfrage für eine Kommunikationsressource, die unter mehreren Funktionen der Vorrichtung geteilt wird, genügen muss.
• In einem traditionellen Peer-to-Peer Kommunikationsschema würde der Datenaustausch zwischen Vorrichtungen A, B ausgesetzt werden, während Vorrichtung A Kanäle 1, 7 und 11 einstellt und die notwendigen Scans durchführt. In der veranschaulichten Implementierung würde dies den Durchsatz des Datenaustauschs um 25% absenken. Wohingegen sie während 12 von den 16 Zeitschlitzen von einem Zyklus in 4A Daten ausgetauscht hatten, werden nun 3 von den 12 Zeitschlitzen für eine unvereinbare Funktion verwendet.
• Allerdings gemäß einigen Ausführungsformen wird Vorrichtung A Vorrichtung B über die neue Kanalsequenz 470 der Vorrichtung A berichten im Voraus zu ihrer Implementierung. Zum Beispiel kann Vorrichtung A die Sequenz 470 beschreiben (oder nur ihren Delta von der Sequenz 430 beschreiben) und angeben, wann sie implementiert wird (z.B. zum Start von dem nächsten Kommunikationszyklus). Vorrichtung A kann diese Information an Vorrichtung B im Verlauf von ihrem Datenaustausch übergeben, kann eine bandexterne Kommunikation durchführen, kann ihre neue Kanalsequenz während eines Verfügbarkeitsfensters ankündigen, kann einen Synchronisationsbeacon (SB) ausgeben, usw.
• In Reaktion auf diese Benachrichtigung, wird Vorrichtung B bestimmen, ob sie einige oder alle der Kanalwechsel beherbergen kann. Zu dem Ausmaß wo sie es kann, wird sie es tun, und die Vorrichtungen werden ihren Datenaustausch während diesen Zeitschlitzen auf den neuen Kanälen weiterführen.
• In einigen Ausführungsformen wird Vorrichtung A versuchen die Unterbrechung einer Datenaustauschoperation zu minimieren, welche durch Genügen von einer in Konflikt stehenden Nachfrage auf einer geteilten Kommunikationsressource veranlasst wird, durch Genügen dieser Nachfrage über mehrere Kommunikationszyklen anstelle von nur einem Zyklus wie in 4B veranschaulicht. Zum Beispiel anstelle alle 3 Kanalscans in die Sequenz 470 zu legen, könnte Vorrichtung A stattdessen einen Scan auf einem der 3 spezifizierten Kanäle durchführen (d.h. Kanäle 1, 7, 11), während jedem von drei getrennten Kommunikationszyklen, welche auf einander folgen können oder nicht. Dies wird die Vervollständigung der Kanalscans verzögern, aber verursacht weniger Unterbrechungen des Datenaustauschs.
• In diesen Ausführungsformen könnte Vorrichtung A Vorrichtung B vorzeitig über alle drei Sequenzänderungen informieren oder Vorrichtung B jeweils über eine Änderung informieren. In beiden Fällen kann Vorrichtung B beim Einstellen des Zielkanals zu einer spezifischen Zeit begleiten und ihren Datenaustausch weiterführen, während Vorrichtung A ihre Scans durchführt.
• Ähnlicher Weise falls Vorrichtung A mehr als einen Zeitschlitz für einen Scan verlangt - wie beispielsweise ein passiver Scan, der zwei aufeinanderfolgende Zeitschlitze verlangt - wird sie eine geänderte Kanalsequenz planen und Vorrichtung B informieren. In dem Umfang, in dem die Vorrichtung B die Änderungen beherbergen kann, wird sie es tun und der Datenaustausch wird weitergeführt.
• In einigen Implementierungen kann ein Ermittlungsbeacon oder ein Synchronisationsbeacon, der durch eine Peer-Vorrichtung ausgegeben wird (z.B. Vorrichtung A) ein „Einladungsfeld“ beinhalten, das dazu dient, um andere Vorrichtungen einzuladen zum Beitreten der Vorrichtung zu einer spezifizierten Sequenz von Kanälen, falls sie z.B. eine Notwendigkeit haben mit der Vorrichtung zu kommunizieren. Das Einladungsfeld kann ein oder mehrere spezifische Peer-Vorrichtungen identifixieren, die eingeladen sind, um der ausgebenden Peer-Vorrichtung beizutreten oder kann eine generelle Einladung für alle Peer-Vorrichtungen sein.
• 5 stellt ein Paar von Peer-Vorrichtungen dar, die einen Zeitplan von Kanalwechseln teilen gemäß einigen Ausführungsformen. In diesen Ausführungsformen müssen beide Vorrichtungen Infrastrukturverbindungen beibehalten und periodisch an sozialen Kanälen teilnehmen, wie oben beschrieben.
• Allerdings, anstelle sich auf einem getrennten Kanal (einem Datenkanal) zu treffen, um ihren Datenaustausch durchzuführen, wechseln sie in diesen Ausführungsformen zwischen ihren entsprechenden Infrastrukturkanälen, um Daten auszutauschen, während sie ihre Infrastrukturanforderungen beherbergen. Deshalb sind Kanalsequenzen 520 und 530 gleichwertig und involvieren zwei unterschiedliche Sozialkanäle, wie zuvor, und ein Wechselmuster von Infrastrukturkanalwechsel.
• Vorrichtung A und B können Teil der gleichen Gruppe sein, in welchem Fall sie periodisch den Sozialkanal 1 und 2 unabhängig von ihrem Datenaustausch einstellen. Alternativ kann nur eine der Vorrichtungen Teil der Gruppe sein, die diese Sozialkanäle verwendet und die andere Vorrichtung kann die gleichen Kanäle einstellen, um opportunistischen Datenaustausch mit ihrem Kommunikationspartner durchzuführen.
• In der in 5 dargestellten Umgebung kann Datenübertragung während allen 16 Zeitschlitzen von einem 16 Schlitzzeitplan durchgeführt werden, statt Pausieren zu müssen, um Infrastrukturanforderungen zu beherbergen. Vorteilhafterweise könnten eine oder mehrere zusätzliche Vorrichtungen an dem Datenaustausch teilnehmen, wobei jede noch unterschiedliche Infrastrukturkanäle hat, an denen sie teilnehmen muss und diese Kanäle könnten in den gemeinsamen Zeitplan eingebunden werden.
• Peer-to-Peer Kommunikationen auf einem beschränkten Kanal
• In einigen Ausführungsformen können eine oder mehrere beschränkte Kanäle benutzt werden als soziale Kanäle (z.B. zum Ausgeben und Konsumieren von Ermittlungsbeacons), Zusammentreffkanälen (z.B. zum Durchführen von Verfügbarkeitsfenstern), Datenkanälen (z.B. zum Durchführen von Peer-to-Peer Datenaustausch) und/oder Infrastrukturkanälen (zum Beibehalten von Infrastrukturverbindungen mit einem Zugriffspunkt). Eine Verwendung von einem Kanal kann beschränkt sein durch eine Regulierungsbehörde (z.B. die Federal Communications Commission oder FCC), eine Behörde, die einen Teil von Hochfrequenz-(HF)-Spektrum verwaltet oder kontrolliert oder durch irgendeine andere Einheit.
• In einigen Implementierungen hostet ein beschränkter Kanal einen bevorzugten oder privilegierten Signalemitter oder Sendeempfänger (z.B. ein Wetterradarsystem) und eine Verwendung von diesem Kanal muss sich dieser bevorzugten Quelle fügen. Zum Beispiel kann von einer Vorrichtung verlangt werden, einen beschränkten Kanal, kurz nachdem eine Verwendung von dem Kanal durch eine bevorzugte Quelle entdeckt wird, zu verlassen oder zumindest ruhig zu bleiben, während sie auf diesem Kanal ist und es kann von ihr verlangt werden, ihre Verwendung zu konfigurieren, um eine Entdeckung von dieser Quelle zu erleichtern (oder zumindest die Fähigkeit zum Entdecken dieser Quelle nicht zu verschlechtern).
• DFS (Dynamische Frequenzauswahl, Dynamic Frequency Selection) ist ein Schema zum Auswählen und Wechseln von drahtlosen Kommunikationskanälen und wird in einigen Situationen verlangt (z.B. für Teile von dem 5 GHz Frequenzband, das von einigen Radarsystemen verwendet wird). Ausführungsformen von Peer-to-Peer Kommunikationsverfahren, die in diesem Abschnitt beschrieben werden, sind konfiguriert zum Genügen der Kommunikationsanforderungen der Peer-Vorrichtungen, während einer DFS-Verwendung und eines Einhaltens von Beschränkungen eines Kanals (z.B. für Radarvermeidung).
• In diesen Ausführungsformen sind zwei Peer-Vorrichtungen zu unterschiedlichen Infrastrukturkomponenten (z.B. Zugriffspunkten) verbunden und kommunizieren (oder vereinbaren zu kommunizieren), zum Durchführen eines Dateitransfers, zum Mediastreamen, zum Spielen eines Spiels oder zum Durchführen von irgendeiner anderen Aktivität, die eine erweiterte Interaktionsperiode verlangt. Sie müssen auch periodisch ihre Infrastrukturkanäle besuchen.
• Wie in vorangegangenen Abschnitten beschrieben, können die Peer-Vorrichtungen ihre Kommunikationen durchführen, indem sie zwischen mehreren unterschiedlichen Kanälen springen, möglicher Weise mit opportunistischer Kooperation, während sie den Infrastrukturanforderungen genügen und periodisch einen sozialen Kanal zur Ermittlung besuchen. Generell werden Zeitschlitze von fixer Länge in vorangegangenen Beschreibungen benutzt, was bedeutet, dass jedes Mal wenn die Vorrichtungen zu einem unterschiedlichen Kanal gesprungen sind, sie dort für eine Zeitperiode von einer festen Länge bleiben. Nun müssen sie jedoch auch Beschränkungen auf einem oder mehreren Kanälen beherbergen, welche wahrscheinlich ihren geplanten Zeitplan unterbrechen.
• In einigen Ausführungsformen sind ein oder beide der Zugriffspunkte der Peer-Vorrichtungen DFS-Master, die ein bevorzugtes oder privilegiertes Hochfrequenzsignal (z.B. eine geschützte Signatur eines Radarsystems) erkennen können, wenn sie auf einen beschränkten Kanal eingestellt sind und werden DFS-Slave-Vorrichtungen anweisen (wie beispielsweise die Peers) den Kanal zu verlassen oder still zu sein. Eine Peer-Vorrichtung, die solch eine Anweisung erkennt, wird diese einhalten, sogar falls der ausgebende Zugriffspunkt nicht der Zugriffspunkt ist, der mit dieser Peer-Vorrichtung verbunden ist. Beide Peer-Vorrichtungen (oder falls mehr als zwei miteinander kommunizieren, dann alle Vorrichtungen) sind in der Lage, Übermittlungen von beiden (oder allen) Zugriffspunkten zu hören und werden alle Kanalwechselbenachrichtigungen hinnehmen, die sie von den Zugriffspunkten hören. Somit kann von einer Peer-Vorrichtung verlangt werden, Beschränkungen, die durch einen Zugriffspunkt durchgesetzt werden, mit welchem sie nicht verbunden ist, zu befolgen.
• Zusätzlich versichern Ausführungsformen, die in diesem Abschnitt beschrieben sind, dass eine Wahrscheinlichkeit einer Vorrichtung zum Erkennen eines bevorzugten HF-Signals auf einem beschränkten Kanal oder zum Erkennen einer Anweisung zum Verlassen oder Unterlassen einer Verwendung des beschränkten Kanals, so gut ist, als es sein würde, ohne das entsprechende Verfahren der Peer-to-Peer Kommunikationen zu implementieren. Peer-to-Peer Kommunikationen kommen inhärent unabhängig von (und ohne Wissen von) DFS-Mastern vor und so können sie diese Kommunikationen nicht beeinflussen oder formen. Deshalb kann es wichtig sein sicherzustellen, dass die Peer-to-Peer Kommunikationen nicht mit existierenden DFS-Vermeidungsverfahren interferieren. Wie unten beschrieben werden wird, kann dies eine intelligente Zeitplanung von Kanalsprüngen und eine Implementierung von Ruheperioden zu bestimmten Zeiten auf einem beschränkten DFS-Kanal beinhalten.
• 6 stellt Peer-to-Peer Kanalsprungkommunikationen auf zwei drahtlosen Kanälen entsprechend einiger Ausführungsformen dar. Diese Ausführungsformen demonstrieren wie Peer-to-Peer Kommunikationen auf unbeschränkten Kanälen durchgeführt werden können; Verfahren zum Durchführen von Peer-Kommunikationen auf einem oder mehreren beschränkten Kanälen werden dann beschrieben. Zum Veranschaulichen wie ein Peer-to-Peer Kommunikationsschema modifiziert werden kann, um sich den Beschränkung(en) zu fügen.
• In Ausführungsformen, die in 6 widergespiegelt werden, kommunizieren zwei oder mehr Peer-Vorrichtungen während eines Kanalspringens. Veranschaulichend kann eine der Vorrichtungen ein Smartphone (z.B. ein IPhone^®) während die andere eine Medienvorrichtung (z.B. ein Apple TV^® Vorrichtung) ist, die Medien zu (oder von) dem Smartphone streamt, unter Verwendung von Airplay oder irgendeinem anderen Mediastream-Programm, das mit dem Peer-to-Peer Kommunikationsprotokoll kompatibel ist. Während das Kanalspringen der Vorrichtungen begrenzt ist auf zwei Kanäle in 6, können die beschriebene Verfahren leicht modifiziert werden zum Springen zwischen mehr als zwei Kanälen.
• In 6 sind Kanal 1 und Kanal 2 durch Zugriffspunkte (APs) belegt, welche Master von getrennten und eindeutigen Basisdienstmengen (BSS) sind. Insbesondere arbeitet Zugriffspunkt 1 (oder AP1) auf Kanal 1 und ist Master von einem ersten BSS, welcher eine von den Peer-Vorrichtungen beinhaltet, während Zugriffspunkt 2 (oder AP2) auf Kanal 2 arbeitet und Master von einem zweiten BSS ist, welcher die andere Vorrichtung beinhaltet (oder eine von den anderen Vorrichtungen, falls mehr als zwei Peer-Vorrichtungen kommunizieren).
• Beide Zugriffspunkte geben Beaconframes (oder Beacons) in regelmäßigen Intervallen aus, welche nahe an 100ms Dauer sind, aber nicht ausgerichtet sind. Zum Beispiel kann das Beaconintervall von AP1 ungefähr 102,4ms sein, während das Beaconintervall von AP2 ungefähr 104ms sein kann. Somit sind Beaconframes nicht auf den zwei Kanälen synchronisiert.
• Wie vorher beschrieben, können die Peer-Vorrichtungen weiterhin kommunizieren, während sie synchron zwischen Kanal 1 und 2 springen und genügen ihren Infrastrukturverbindungsanforderungen. In 6 benutzen die Vorrichtungen eine Kanalsprungsequenz von 256ms, die in zwei gleich große Zeitschlitze geteilt wird (128ms), während welcher die Vorrichtungen auf den zwei getrennten Kanälen verweilen. Die Zeitschlitze sind nicht mit beiden Intervallen der Zugriffspunkte synchronisiert und werden deshalb mit variablen Offsets von den Zielbeacon-Übermittlungszeiten (Target Beacon Transmission Times, TBTT) der APs vorkommen.
• Angenommen eine der Peer-Vorrichtungen agiert als ein Nichtauswahlmaster (oder als Master von einem privaten Verbund, der die kommunizierenden Peers umfasst) kann diese Vorrichtung versuchen, sich mit den Beacons von ihrem AP oder von einem normalen Gruppenmaster zu synchronisieren (z.B. der Ankermaster, ein Zweigmaster) mit welchem sie synchronisiert ist, die anderen Peer-Vorrichtung(en) werden aber dann notwendigerweise sich mit der einen Peer-Vorrichtung synchronisieren.
• Weil weder Kanal 1 noch Kanal 2 beschränkt ist, können die Peer-Vorrichtungen ihr Kanalspringen nach festem Zeitplan weiterführen, mit Zeitschlitzen von fester Länge, solange wie es notwendig ist, um ihre Datenübertragung durchzuführen. Da sie nacheinander zu jedem Kanal wechseln, können sie sofort ihre Übertragung beginnen oder weiterführen, mit minimaler Latenz, und können ihre Übertragung weiterführen bis es Zeit wird, um auf den anderen Kanal zu wechseln. Beacons, die von dem AP des aktuellen Kanals ausgegeben werden, können sich leicht für den Kanal bewerben, wegen ihrer kurzen Länge, obwohl es eine Möglichkeit gibt, dass die Peers auf die Beacon des APs treten können, aber weder die Beacons noch die Datenübertragung der Vorrichtungen hängt voneinander ab oder verlangen Berücksichtigung voneinander.
• Allerdings falls einer von den Kanälen, der von Peer-Vorrichtungen für Peer-to-Peer Kommunikationen übernommen wurde, ein DFS-Kanal ist oder falls beide DFS-Kanäle sind, gibt es eine Gefahr, dass das Kanalsprungschema aus 6 eine Beschränkung verletzen wird. Zum Beispiel, falls Kanal 1 ein DFS-Kanal war und AP1 (als ein DFS-Master agierend) einen Beacon mit einem Kanalwechselbenachrichtigungselement ausgegeben hat, während die Peer-Vorrichtungen auf Kanal 2 eingestellt waren, würden die Peers die Kanalwechselbenachrichtigung nicht empfangen und würden ihre Datenübertragung beim Rückkehren auf Kanal 1 sofort wieder aufnehmen. Dieses würde die DFS-Anforderungen/Beschränkungen verletzen, weil die Peers Datenframes auf Kanal 1 übermitteln würden, nachdem eine Kanalwechselbenachrichtigung auf diesem Kanal durch den DFS-Master ausgegeben wurde, die sie befolgen müssen.
• Zusätzlich kann eine weitergeführte Peer-to-Peer Datenübertragung auf einem beschränkten Kanal die Peer-Vorrichtungen dazu veranlassen, einen oder mehrere Beacons zu verpassen, die die Kanalwechselbenachrichtigung berichten. Insbesondere können ihre Peer-to-Peer Kommunikationen mit der Kanalwechselbenachrichtigung kollidieren oder die Kanalwechselbenachrichtigung verzögern. Somit können sie sogar, während sie auf Kanal 1 eingestellt gewesen wären (und in Peer-to-Peer Kommunikationen engagiert gewesen wären) wenn die erste Kanalwechselbenachrichtigung gemacht wurde, sie sogar verpassen und scheitern, sich den beschränkten Signal(en) zu fügen.
• Deshalb sind in einigen Ausführungsformen, in welchen eine oder mehrere DFS-Kanäle in einer Kanalsprungsequenz enthalten sind, die durch Vorrichtungen für Peer-to-Peer Kommunikation verwendet werden, eine oder mehrere Vorsichtsmaßnahmen implementiert.
• Eine Vorsichtsmaßnahme verlangt von den Peer-Vorrichtungen, wenn sie zu einem DFS-Kanal wechseln, still zu bleiben bis sie einen Beacon von dem AP oder DFS-Master, der mit diesem Kanal verbunden ist oder irgendein anderes geeignetes Verwaltungsframe oder Aktionsframe, welches angibt, ob der Kanal frei von Beschränkungen ist, empfangen. Die Vorrichtungen werden also auch um die TBTT des AP herum ruhig sein, vielleicht für insgesamt 5-10ms, um ein Kollidieren mit einem Beacon zu verhindern.
• Falls ein Beacon oder ein anderes Frame, das von der Vorrichtung empfangen wird, angibt, dass der Kanal frei ist (z.B. beinhaltet es kein Kanalwechselbenachrichtigungselement) oder falls kein Beacon empfangen wird, nahe der Zeit von dem TBTT und falls Vorsichtsmaßnahmen vorhanden sind, um sicherzustellen, dass die Peer-to-Peer Kommunikationen der Vorrichtungen die Wahrscheinlichkeit zum erfolgreichen Empfangen von Kanalwechselbenachrichtigungen nicht vermindern (z.B. Ruheperioden um TBTTs herum), können die Vorrichtungen ihre Peer-to-Peer Datenübertragung beginnen oder weiterführen.
• Um dieses Schema zu ergänzen, wenn Peer-Vorrichtungen einen beschränkten DFS-Kanal in ihrer Kanalsprungsequenz beinhalten, können sie die Sequenz an den TBTT von einem AP, der mit dem DFS-Kanal verbunden ist, ausrichten. Falls mehrere DFS-Kanäle verwendet werden, können sie sich an TBTTs von allen Kanälen ausrichten (oder versuchen, sich auszurichten). Wie diskutiert werden wird, kann dies Kommunikationszeitschlitze von dynamischer Größe verlangen, anstelle von Zeitschlitzen mit fester Größe wie in 6 demonstriert, weil die unterschiedlichen TBTTs der APs voneinander abweichen werden.
• 7A stellt Peer-to-Peer Kanalsprung-Kommunikationen auf zwei drahtlosen Kanälen dar, wobei einer von diesen ein beschränkter Kanal ist entsprechend einiger Ausführungsformen. In diesen Ausführungsformen ist Kanal 1 ein beschränkter DFS-Kanal; deshalb richten die Peer-Vorrichtungen ihre Kanalsequenz-Periode an einem Vielfachen von Beaconintervallen des Zugriffspunkts 1 (AP1) aus. In diesem Beispiel ist die Kanalsequenz-Periode dreimal die Länge von dem Beaconintervall: 307,2ms (oder 300 TU). In anderen Implementierungen können andere Vielfache verwendet werden (z.B. zwischen 1 und 4 einschließlich). Unterschiedliche Vielfache können die Notwendigkeit der Peers erleichtern zum Ausrichten an unterschiedlichen TBTTs oder an unterschiedlichen Kombinationen von TBTTs auf mehreren Kanälen.
• Weil die Beaconintervalle von AP1 und AP2 nicht synchronisiert sind, werden die Kanalsequenzperioden der Peer-Vorrichtungen und die Zeitschlitze, die sie auf Kanal 2 verbringen, nicht an TBTT des AP2 ausgerichtet sein. Allerdings weil Kanal 2 kein beschränkter Kanal ist, brauchen die Vorrichtungen sich nicht einer anderen Signalquelle auf diesem Kanal zu fügen und können stattdessen sofort ihre Datenübertragung initiieren/weiterführen, wenn sie auf Kanal 2 wechseln.
• Jedes Mal, wo sie auf Kanal 1 wechseln, nahe der Zeit eines geplanten Beacon-Frames beobachten sie jedoch eine Ruhe-Periode von ungefähr 5-10ms, um den Beacon zu erfassen. In einigen Implementierungen ist die Kanalsprungsequenz konfiguriert, so dass die Vorrichtungen zu dem beschränkten Kanal kurz zuvor (z.B. 1-3ms) dem TBTT des AP1 wechseln. Das synchrone Kanalspringen, welches in 7A veranschaulicht ist, ist konfiguriert, so dass alle Zeitschlitze der Datenübertragung ungefähr gleich von einer Hälfte der Kanalsprungs-Basisperiode sind. Allerdings in anderen Implementierungen können die Zeitschlitze von unterschiedlichen Größen sein.
• Zum Beispiel weil Kommunikationen effizienter auf Kanal 2 sein können, können Zeitschlitze auf Kanal 1 kürzer sein als jene auf Kanal 2. Sogar mit einer Kanalsprungperiode von dem dreifachen des Beaconintervalls des AP1, können Zeitschlitze auf Kanal 1 weniger als das Beaconintervall sein, solange die Vorrichtungen zu Kanal 1 zurückkehren entsprechend dem Zeitplan. Umgekehrt falls Kanal 1 weniger überlastet ist als Kanal 2, können Zeitschlitze auf Kanal 1 zum Beispiel erheblich länger sein, als Zeitschlitze auf Kanal 2.
• Wie oben angegeben werden die Peer-Vorrichtungen nicht nur still sein, wenn sie auf Kanal 1 wechseln nahe an der Zeit von einem TBTT des AP1, sondern werden auch still sein, immer wenn sie auf Kanal 1 sind (und aktiv kommunizieren) und ein TBTT sich annähert. Datenübertragung kann wieder aufgenommen werden, falls ein Beacon oder anderes Frame angibt, dass der Kanal frei ist oder wenn kein Beacon empfangen wird. Falls der Kanal nicht frei ist, können sie ihre Übertragung auf Kanal 1 nicht wieder aufnehmen. In diesem Fall können sie die Kanalsprungsequenz ändern, um mehr Zeit auf Kanal 2 zu verbringen, aber periodisch auf Kanal 1 zurückkehren (z.B. jedes dritte TBTT), um zu bestimmen, ob der Kanal freigeworden ist oder andere Aktionen durchzuführen, um ihre Datenübertragung weiterzuführen während sie in der Lage sind, zu erkennen, wann Kanal 1 verfügbar wird.
• 7B stellt Peer-to-Peer Kanalsprung-Kommunikationen auf zwei beschränkten drahtlosen Kanälen entsprechend einiger Ausführungsformen dar. In diesen Ausführungsformen richten die Peer-Vorrichtungen ihre Sprünge nach Kanal 2 aus, um mit Zielbeacon-Übermittlungszeiten des AP2 zusammenzufallen, so dass Kanalwechselbenachrichtigungen (und/oder andere Beschränkungsnachrichten) auf beiden Kanälen erfasst werden können und illegale Übermittlungen vermieden werden können.
• In Ausführungsformen, die in 7B widergespiegelt werden, sind alle Kanalwechsel an TBTTs von den Zielkanälen ausgerichtet und Ruheperioden werden um jedes TBIT herum beobachtet. Deshalb ist die Wahrscheinlichkeit eine Beschränkungsnachricht zu erkennen (z.B. ein Beacon mit einer Kanalwechselbenachrichtigung) nicht schlechter als wenn die Vorrichtungen nicht Peer-to-Peer auf diesen Kanälen kommunizieren würden.
• In diesen Ausführungsformen ist die Berechnung von Wechselzeiten dynamisch, um nicht nur die unterschiedlichen Beaconintervalle zu beherbergen, sondern auch um Abweichungen zwischen den APs zu berücksichtigen. Minimale Verweilzeiten können auf einem Kanal, beiden Kanälen oder keinem Kanal implementiert sein (z.B. ungefähr ein Beaconintervall). Weil die Kanalsprungbasisperiode dreimal das Beaconintervall des AP1 ist (d.h. N=3 in 7A und 7B) und weil beide Beaconintervalle sehr ähnlich in der Dauer sind, können die Vorrichtungen auf jedem Kanal für zumindest ein vollständiges Beaconintervall verweilen und werden deshalb fast sicher zumindest ein Beacon auf jedem Kanal, während jeder Kanalsprungperiode erfassen.
• Um zu bestimmen, wann auf den anderen Kanal in den Ausführungsformen von 7B gewechselt werden soll, nehmen die Peer-Vorrichtungen die Zeit des letzten Beacons auf, den sie auf jedem Kanal erfasst haben und verwenden die Zeit, um zukünftige TBTTs auf dem gleichen Kanal zu berechnen. Diese Werte werden verwendet um zu bestimmen, wann auf diesen Kanal zurückgewechselt werden soll, nachdem von ihm weggewechselt wurde. Ein Beispiel davon wird mit Bezug auf 7B erklärt.
• Die Peer-Vorrichtungen verfolgen bereits die TBTTs des Kanal 1, so dass sie wissen, wann jede Kanalsprungperiode beginnt/endet und wann sie zurück zu Kanal 1 wechseln müssen (z.B. zu der Zeit T₂ ). Währenddessen, während dem vorangegangenen Zeitschlitz auf Kanal 2, notieren sich die Vorrichtungen die Zeit T₁ zu welcher ein Beacon auf Kanal 2 ausgegeben wurde. Weil sie das Beaconintervall von Kanal 2 wissen (d.h. 104ms) können die Vorrichtungen deshalb einen oder mehrere zukünftige TBTTs des AP2 berechnen (z.B. die nächsten zwei oder drei).
• Diese Zeiten, wenn sie mit der Zeit T₂ betrachtet werden, ermöglichen den Vorrichtungen die richtige oder angemessene Zeit T₃ , zu welcher sie zu Kanal 2 zurückkehren sollen zu identifizieren. Veranschaulichend können die Vorrichtungen als Rückkehrzeit zu Kanal 2 die erste TBTT auswählen, die nach einer Standard oder einer minimalen Zeitperiode vorkommt, die T₂ folgt, so dass die Vorrichtungen auf Kanal 1 für eine Zeitperiode, die ausreichend ist, um zumindest eine TBTT zu erfassen, verweilen werden. Veranschaulichend kann diese Zeitperiode durch das Beaconintervall von dem Kanal bestimmt werden, durch einen fixen Wert, wie beispielsweise 100ms, usw. Wie oben beschrieben können Kanalwechsel tatsächlich vorkommen, kurz vor der TBTTs des Zielkanals.
• Unabhängig von der Reihenfolge und Dauer der Kanalsprünge verbleiben die Peer-Vorrichtungen, die in der Datenübertragung von 8 involviert sind, ausreichend Zeit auf Kanälen 1 und 2, um sicherzustellen, dass sie zumindest einen Beacon von jeder der AP1 und AP2 alle paar oder wenige Sekunden empfangen. Weil Uhren für typische Vorrichtungen (z.B. Vorrichtungen, die WiFi- und/oder Bluetoothfähigkeiten aufweisen) Genauigkeiten von der Größenordnung von +/- 20ppm von ihren Nominalwerten auf weisen, ist es recht leicht für die Vorrichtungen, um die Beaconübertragungsuhren der Zugangspunkte zu verfolgen und um zuverlässig zukünftige TBTTs mit einer Genauigkeit innerhalb von einigen Hundert Mikrosekunden vorauszusagen.
• Obwohl die Datenübertragungsperioden auf beschränkten DFS-Kanälen in 7A und 7B als ununterbrochene Kästen veranschaulicht sind, ist zu verstehen, dass die Datenübertragung, die während jeder Periode vorkommt, die ein TBTT des APs oder DFS-Masters beinhaltet, um jede TBTT herum pausieren wird, wie es beschrieben wurde.
• In einigen Ausführungsformen können von einigen oder allen Vorrichtungen, die Peer-to-Peer-Kommunikationen auf einem oder mehreren beschränkten Kommunikationskanälen durchführen, verlangt werden auch Zeit auf einem sozialen Kanal zu verbringen (z.B. ein getrennter Kanal, der verwendet wird, um eine Gruppe zu synchronisieren, die die Peer-Vorrichtungen beinhaltet). Veranschaulichend könnte eine Vorrichtung einen sozialen Kanal einstellen müssen, um einen Ermittlungsbeacon zu senden oder zu empfangen (oder Synchronisationsbeacon) oder an einem Verfügbarkeitsfenster teilzunehmen (angenommen, dass Verfügbarkeitsfenster auf einem sozialen Kanal durchgeführt werden). Falls Verfügbarkeitsfenster nicht auf einem sozialen Kanal durchgeführt werden, kann auch von einer Vorrichtung verlangt werden, periodisch einen Zusammentreffkanal einzustellen, um zumindest an so vielen Verfügbarkeitsfenstern teilzunehmen wie durch ihren Einstellungswert angegeben.
• Um sich diesen Anforderungen zu neigen, wird keine große Zeitanzahl von einem direkten Peer-to-Peer Kommunikationsschema der Vorrichtung abgeleitet. Zum Beispiel um einen regelmäßig geplanten Ermittlungsbeacon zu erfassen, kann ungefähr 5-15ms alle 150ms beanspruchen, während ein Teilnehmen an einem Verfügbarkeitsfenster ungefähr 100-120ms alle 1-2 Sekunden beanspruchen kann.
• In den gerade besprochenen Ausführungsformen ist ein sozialer Kanal nie ein beschränkter Kanal. Deshalb kann eine Peer-Vorrichtung einen sozialen Kanal zu einer beliebigen Zeit einstellen, das bedeutet, dass eine Teilnahme an einem sozialen Kanal mit dem Beaconintervall eines Zugriffspunktes von einem beliebigen anderen Kanal synchronisiert werden kann (z.B. ein beschränkter DFS-Kanal, auf welchem die Vorrichtung die Peer-to-Peer Kommunikationen durchführt). Allerdings, wenn eine Vorrichtung einen sozialen Kanal verlässt, kann sie einen beschränkten Kanal einstellen, in welchem Fall die Zeit dieses Wechsels nicht beliebig ist (d.h. weil der Wechsel an einem TBTT des beschränkten Kanals ausgerichtet sein kann).
• 8 stellt Peer-to-Peer Kanalsprungkommunikationen zwischen einem sozialen Kanal und einem oder mehreren beschränkten Kanälen entsprechend einiger Ausführungsformen dar.
• Diese Ausführungsformen können als ähnlich zu den Ausführungsformen, die in 7B dargestellt werden, betrachtet werden, in denen eine Basiskanalsprungperiode berechnet wird, aus dem Beaconintervall von einem Zugriffspunkt eines beschränkten Kanals. In 8 wie in 7B ist die Basiskanalsprungperiode dreimal das Beaconintervall der AP1; andere Basisperioden können in anderen Ausführungsformen angenommen werden. Ein Gruppen-Master (z.B. der Anker-Master, ein Zweigmaster), welcher eine von den Peer-Vorrichtungen sein kann, gibt Ermittlungsbeacons (oder andere Beacons) auf dem sozialen Kanal mit einer Durchschnittsperiode von ungefähr 150ms aus.
• Die Peer-Vorrichtungen werden dynamisch die Länge von jedem Zeitschlitz berechnen, um verschiedenen Zielen zu genügen - einschließlich Zurückkehren zu Kanal 1 zum Start von jeder Periode, Synchronisieren von Sprüngen zu allen beschränkten Kanälen mit den TBTTs von diesen Kanälen, Teilnehmen an Verfügbarkeitsfenstern entsprechend ihren Anwesenheitswerten (die Peer-Vorrichtungen können den gleichen Einstellungswert annehmen, um ihnen zu helfen alle Kanalwechsel zu synchronisieren) und Ausgeben/Fangen von so vielen Beacons wie möglich auf den sozialen Kanälen.
• Somit können während jedem Zeitschlitz die Vorrichtungen einen oder mehrerer zukünftige Kanalwechsel berechnen und Prioritäten von jedem der oben aufgezählten Ziele (und/oder anderen) können die Kanalauswahl beeinflussen. Weil jeder Wechsel von einem sozialen Kanal weg zu einem beschränkten Kanal sein wird (in den Ausführungsformen von 8), sind die Enden von Zeitschlitzen auf den sozialen Kanälen nicht beliebig.
• In einigen Ausführungsformen kann ein Teilnehmen an Verfügbarkeitsfenstern Priorität über die meisten oder sogar alle anderen Ziele haben - oder zumindest Teilnahme an Verfügbarkeitsfenster Nummer 0 von jeder Verfügbarkeitsfenstersequenz. Wie in einem vorigen Abschnitt beschrieben, müssen alle synchronisierten Peer-Vorrichtungen an diesem Verfügbarkeitsfenster teilnehmen; dadurch sind die Peer-Vorrichtungen in der Lage Synchronisation beizubehalten und gegenwärtige Zeitplaninformationen zu erhalten.
• In diesen Ausführungsformen werden Kanalwechsel geplant, um sicherzustellen, dass die Peers an zumindest diesen Verfügbarkeitsfenstern teilnehmen, die an ihren Einstellungswerten vorgeschrieben sind. Vorzugsweise falls einer der Peers, der in der Kanalsprung-Datenübertragung von 8 beteiligt ist, der Anker-Master ist, der verantwortlich zum Einstellen des Verfügbarkeitsfensterzeitplans ist, kann diese Vorrichtung das Verfügbarkeitsfenster mit einer oder mehreren anderen Zielen synchronisieren.
• In 8 beendet Datenübertragung 810a auf Kanal 1 zu einer Zeit, die ausgewählt ist, um den Vorrichtungen zu ermöglichen, den sozialen Kanal einzustellen, einen Beacon auszugeben/zu empfangen und dann auf Kanal 2 zu wechseln, gerade vor dem TBTT des AP2. Datenübertragung 820a auf Kanal 2 ist terminiert um gerade vor dem nächsten sozialen Kanalbeacon zu enden, so dass die Vorrichtungen für den Beacon auf den sozialen Kanal wechseln können und dann auf Kanal 1 für Datenübertragung 810b zum Start von der nächsten Kanalsprungsequenz zurückkehren können.
• Nach Datenübertragung 810b stellen die Vorrichtungen den sozialen Kanal ein, um an Verfügbarkeitsfenster 830a teilzunehmen, während welcher ein Synchronisationsbeacon gesendet werden kann (z.B. anstelle von einem Ermittlungsbeacon). Nach dem Verfügbarkeitsfenster kehren die Vorrichtungen zu Kanal 1 zurück für die nächste Periode, welche mit der Datenübertragung 810c startet, gefolgt von einem anderen sozialen Kanalbeacon und dann einem Wechsel zu Kanal 2 für einen anderen Datenübertragungsschlitz.
• Wie in einem vorigen Abschnitt beschrieben, brauchen Ermittlungsbeacons, die auf einem sozialen Kanal ausgegeben wurden, nicht einen strengen periodischen Zeitplan einzuhalten. Deshalb falls die Beacons, die auf dem sozialen Kanal in 8 ausgegeben werden, durch einen von den Peers, der in der Datenübertragung teilnimmt, übermittelt werden, können diese Beacons flexibel und dynamisch geplant werden, um somit zumindest eine Schwelldichte bereitzustellen. Zum Beispiel kann die Kanalsprungsequenz wie in 8 gestaltet sein, um einen Ermittlungsbeacon auf einem sozialen Kanal vor jeder neuen Kanalsprungsequenz zu übermitteln (d.h. kurz vor dem Zurückkehren zu Kanal 1). Zusätzliche Ermittlungsbeacons können opportunistisch geplant werden, um nahe in der Zeit zu einem Sprung zu oder von Kanal 2 vorzukommen.
• In einigen Ausführungsformen können Zeitschlitze auf den sozialen Kanälen, welche geplant sind, um sozialen Kanalbeacons zu beherbergen (und nicht Verfügbarkeitsfenster) von der Größenordnung von 10ms sein - lange genug um einige Millisekunden vor der Beaconzeit auf den Kanal einzustellen, den Beacon zu übermitteln oder zu empfangen, einige Millisekunden mehr zu verweilen, und dann zu verlassen. Zeitschlitze von sozialen Kanälen, die geplant sind, um Verfügbarkeitsfenster zu beherbergen, sind länger, abhängig von der minimalen Zeitdauer, die die Vorrichtungen an dem Fenster teilnehmen müssen und/oder anderen Faktoren und können von der Größenordnung von 150ms zu 200ms sein.
• Falls Kanal 2 nicht ein beschränkter Kanal wäre, könnten Sprünge zu Kanal 2 beliebig geplant werden, anstatt mit den TBIT des AP2 synchronisiert zu sein. Einen unbeschränkten (und nicht sozialen) Kanal in der Kanalsprungsequenz aufzuweisen, kann die Effizienz oder den Durchsatz der Datenübertragung der Vorrichtungen in einigen Situationen erhöhen. Zum Beispiel obwohl die TBTT der AP1 und AP2 nicht vollständig synchronisiert werden können wegen den unterschiedlichen Beaconintervallen, wird es Zeiten geben, während welchen sie nahe in der Zeit zueinander vorkommen und während welchen ein sozialer Kanalbeacon geplant ist, um nahe dem Mittelpunkt der Beaconintervalle der zwei AP vorzukommen.
• In den Ausführungsformen von 8 (d.h. in welchen beiden Datenkanäle beschränkt sind) kann dieses Szenario von dem sozialen Kanalbeacon verlangen übersprungen zu werden, weil falls die Vorrichtungen den sozialen Kanal für den Beacon einstellen, können sie nicht für Zehnfache von Millisekunden zurückwechseln, bis zur nächsten TBTT. Mit einem unbeschränkten Kanal allerdings könnten die Vorrichtungen zu dem sozialen Kanal für den Beacon wechseln und dann zu dem unbeschränkten Kanal wechseln, um ihre Datenübertragung weiterzuführen. Alternativ könnten die Peer-Vorrichtungen natürlich eine opportunistische Datenübertragung auf dem sozialen Kanal durchführen bis sie in der Lage sind, zu einem beschränkten Kanal nahe der Zeit eines TBTTs zurückzukehren.
• Eine Peer-Vorrichtung
• 9 ist ein Blockdiagramm von einer Peer-Kommunikationsvorrichtung entsprechend einiger Ausführungsformen. Primäre Protokollschichten oder Betriebsschichten werden innerhalb einer Vorrichtung 900 dargestellt - die logische Verbindungsschicht (logical link layer) und die Datenverbindungsschicht (data link layer). Über der logischen Verbindungsschicht können eine oder mehrere Anwendungen und/oder Programme (z.B. mDNS, Bonjour) arbeiten; unter der Datenverbindungsschicht ist die physische Schicht (physical layer), verantwortlich zum Übermitteln von Frames über und Empfangen von Frames von dem Übermittlungsmedium.
• In einigen Ausführungsformen können die logische Verbindungsschicht und die Datenverbindungsschicht physisch implementiert sein durch getrennte Prozessoren oder durch integrierte Schaltungen, die auf einer einzelnen Komponente liegen. Einige Komponenten von der Vorrichtung 900 werden aus dem Interesse der Klarheit weggelassen, beispielsweise Prozessor, Speicher, Anzeige, Antenne und Kommunikationsanschlußkomponenten unter anderem.
• Innerhalb der Datenverbindungsschicht werden Synchronisationsframes (z.B. Ermittlungsbeacons oder DB, Synchronisationsbeacons oder SB) ausgegeben durch und/oder empfangen durch Synchronisationszustandsmaschine 910. Eintreffende Synchronisationsframes werden zu einer Masterdatenbank 920 geleitet und dann aufwärts zu der logischen Verbindungsschicht gereicht. Datenframes werden durch Paketwarteschlangen 922 behandelt.
• Die Synchronisationszustandsmaschine 910 hat zwei Modi - Master und Nichtmaster - und läuft in einigen Implementierungen kontinuierlich. Wie vorher beschrieben ist eine Mastervorrichtung eine Vorrichtung, die Ermittlungsbeacons ausgibt, um Vorrichtungssynchronisation zu erleichtern, während eine Nichtmastervorrichtung einige Arten von Beacons ausgeben kann und kann oder kann nicht andere Vorrichtungen erbitten, sich mit ihr zu synchronisieren.
• Die Synchronisationszustandsmaschine ist verantwortlich für eine Synchronisation der Peer-Vorrichtung mit ihrem gegenwärtigen Master. Falls die Vorrichtung 900 Master ist, verwaltet die Zustandsmaschine 910 ihre Übermittlungen von Ermittlungsbeacons und/oder Synchronisationsbeacons und verwaltet auch ihre Verfügbarkeitsfensteranwesenheit. Die Synchronisationszustandsmaschine 910 kann auch verantwortlich sein für eine Berechnung von Verweilzeiten und Wechselzeiten, wie beispielsweise wenn die Vorrichtung 900 in einer Datenübermittlung mit einer anderen Vorrichtung engagiert ist, während sie zwischen mehreren Kanälen springen.
• Eine Scanzustandsmaschine 912 scannt soziale Kanäle nach Beacons. Hochfrequenzkanalverwalter 914 verwaltet Hochfrequenzressourcen (z.B. eine geteilte Antenne) mit anderen Einheiten (z.B. einem Infrastrukturmodul) und zwischen unterschiedlichen Hochfrequenzeinrichtungen (z.B. WiFi, Bluetooth). Die Synchronisationszustandsmaschine 910 interagiert mit dem Hochfrequenzkanalverwalter 914, um die Hochfrequenzeinrichtung der Vorrichtung auf den richtigen Kanal zu wechseln zu der angemessenen Zeit für ein Verfügbarkeitsfenster, einen Datentransfer, um einen Beacon zu erfassen und/oder für andere Zwecken. Die Scanzustandsmaschine 912 und/oder andere Komponenten der Vorrichtung 900 können mit dem Hochfrequenzkanalverwalter für andere Zwecke interagieren (z.B. Scannen eines Kanals nach neuen Vorrichtungen).
• Peer-Zwischenspeicher 916 speichert relevante Informationen für eine begrenzte Anzahl von anderen Vorrichtungen, mit welchen die Host-Peer-Vorrichtung 900 kommuniziert oder anfangen wird zu kommunizieren. Eine Verwendung dieses Zwischenspeichers kann helfen Probleme zu mindern, die mit Speicherbeschränkungen in einigen Hardware/Firmware-Implementierungen verbunden sind. Zum Beispiel kann die Datenverbindungsschicht durch einen dedizierten WiFi-Chipsatz implementiert werden, welcher typischer Weise keinen Zugriff auf große Speicherbanken hat. Informationen in dem Peer-Zwischenspeicher 916 werden mit Informationen in einer Peer-Datenbank 936 synchronisiert.
• Masterauswahlcode 918 wird periodisch ausgeführt, um ein Auswahlverfahren zum Auswählen oder Identifizieren von Mastervorrichtungen durchzuführen, unter Verwendung von Informationen aus der Peer-Datenbank 936 und/oder anderen Informationen. Zum Beispiel kann ein Ausführen des Codes eine Bewertung der Vorrichtungen in einer Masterdatenbank 920 veranlassen, basierend auf ihrer Eignung ein Master zu sein.
• Die Masterdatenbank 920 speichert Daten, die alle Master betreffen, von denen die Vorrichtung 900 Kenntnis hat. Solche Daten können verwendet werden für Synchronisation und/oder Masterauswahl und können beinhalten, sind aber nicht beschränkt auf, RSSI (Empfangssignalstärkenhinweis, Received Signal Strength Indication) (z.B. von dem letzten Frame, ein Durchschnitt von mehreren Frames, Minimum, Maximum), Mastervorzugswerte, Auswahlmetriken, die verwendet werden, um Mastereinstellungswerte zu berechnen, Gruppengröße und Synchronisationsparameter.
• In einigen Ausführungsformen wird die Masterdatenbank 920 gefüllt oder aktualisiert und der Masterauswahlcode 980 ausgeführt beim Empfangen von jedem Ermittlungsbeacon.
• Die Paketwarteschlangen 922 von der Datenverbindungsschicht speichern eintreffende und/oder ausgehende Datenframes. Die Paketwarteschlangen 932 der logischen Verbindungsschicht speichern hier Verkehr, der eintrifft von oder ausgeht an andere Vorrichtungen.
• Ein Paketzeitplaner 930 plant Multicast-, Broadcast- und Unicast-Verkehr zu synchronisierten Vorrichtungen und bandexternen Anfragen/Antworten an Master, mit welchen der Peer nicht synchronisiert ist („nicht sychronisierte Master“) und zu Vorrichtungen, die mit nicht synchronisierten Mastern synchronisiert sind. Der Paketzeitplaner kann auch verantwortlich sein für eine Auswahl einer Sequenz von Kanälen für die Vorrichtung 900, zu welcher sie wechseln soll (z.B. um konkurrierende Nachfragen über die Hochfrequenzeinrichtung der Vorrichtung zu genügen, um eine Datenübertragung durchzuführen). Alternativ kann eine getrennte Komponente, wie beispielsweise eine optionale Kanalsequenzsteuerung 940 implementiert werden, um eine Sequenz von Kanälen für die Vorrichtung zu identifizieren.
• Die Peer-Vorrichtung 936 speichert Informationen, die Verfügbarkeitsfenster, Anwesenheitsmodi und andere Timing-bezogene Informationen des nicht-synchronisierten Masters, betreffen. Ein Anwesenheitsmodusverwalter 934 steuert den Anwesenheitsmodus der Vorrichtung, basierend auf Faktoren, die beinhalten, aber nicht beschränkt sind, auf: gegenwärtig aktive Datenverbindungen zu synchronisierten Vorrichtungen, gegenwärtige Datenraten zu diesen Vorrichtungen, Scananforderungen, bandexterne Anfrageanforderungen, Energieverfaltungszustand, Bluetoothanforderungen, andere Hochfrequenzanforderungen, usw.
• Die Peer-Datenbank 936 identifiziert alle Vorrichtungen, die der Peer-Vorrichtung 900 bekannt sind und speichert Informationen hinsichtlich jeder Vorrichtung. Diese Informationen können beinhalten, sind aber nicht beschränkt auf, ihre Identität (z.B. Netzwerkadresse), Identität ihres Ankermasters, Mastereinstellungswert, Fähigkeiten (z.B. unterstützte Frequenzbänder, Kanalbandbreiten, Moderation/Datenraten), Anwesenheitsmodus, Dienste, die durch die Vorrichtung unterstützt werden, ausstehende Block-ACK-Vereinbarungen, usw. Die Peer-Datenbank 936 kann somit in einem Masterauswahlverfahren assistieren durch Bereitstellen einer Liste von Kandidatenvorrichtungen, die anhand ihres Einstellungswerts und/oder anderen Kriterien geordnet werden können.
• Eine Anwendungsschnittstelle(en) 938 beinhalten Schnittstellen zu höheren Systemschichten und Modulen, welche beinhalten können, aber nicht beschränkt sind, auf: Konfigurationen und Netzwerkverwaltung, eine grafische Benutzerschnittstelle (Graphical Use Interface, GUI), Dienst-Bewerbung und -Ermittelung, usw. Die GUI kann einem Vorrichtungsbenutzer eine Liste darstellen von umliegenden Peers, ihrer physische Nähen, Reichweite oder Signalstärken, Listen von ihren Diensten und/oder andere Informationen.
• Die Konfiguration der Peer-Vorrichtung 900, die in 9 dargestellt ist, ist beispielhaft. In anderen Ausführungsformen kann eine Konfiguration einer Peer-Vorrichtung zu verschiedenen Ausmaßen abweichen. Zum Beispiel können Funktionen von den Komponenten der Vorrichtung 900 auf eine unterschiedlichen Art kombiniert werden, diese von einer einzelnen Komponente können unterteilt werden und/oder diese von mehreren Komponenten können zusammengefügt werden.
• In einigen Ausführungsformen beinhaltet eine Peer-Vorrichtung einen Anwendungsprozessor, um Anwendungen zu unterstützen (z.B. die Anwendungen und Werkzeuge, die in höheren Schichten der Vorrichtung 900 liegen). Der Anwendungsprozessor stellt Speicherverwaltung, Grafikverarbeitung und/oder andere Funktionen, die von den Anwendungen gebraucht werden, bereit. Die Peer-Vorrichtung beinhaltet in einigen Ausführungsformen auch eine drahtlose Schnittstelle, wie beispielsweise einen Basisbandprozessor, zum Durchführen von drahtlosen Kommunikationen zusammen mit entsprechendem Speicher und einem Sendeempfänger zum Unterstützen der drahtlosen Kommunikationen und Kommunikationsverarbeitungen.
• Die drahtlose Schnittstelle kann alle diese Komponenten beinhalten, die in der logischen Verbindungsschicht und der Datenverbindungsschichten der 9 dargestellt sind und die Funktionalitäten, die in Verbindung mit diesen Komponenten beschrieben werden. Die drahtlose Schnittstelle kann auch einige Aufgaben behandeln, die normalerweise mit der physischen Schicht verbunden sind (z.B. Kanalkodierung).
• Somit kann in einigen Ausführungsformen ein „Kommunikationsmodul“ oder „drahtloses Kommunikationsmodul“ einer Peer-Vorrichtung auf eine robuste drahtlose Schnittstellenkomponente Bezug nehmen, die direkt vorangegangen beschrieben wurde. In einigen anderen Ausführungsformen kann ein Kommunikationsmodul einen Basisbandprozessor und einen korrespondierenden drahtlosen Sendeempfänger zum Betreiben oder Verwalten einer Antenne der Vorrichtung und möglicherweise Speicher, der durch den Basisbandprozessor verwendet wird, umfassen. In noch anderen Ausführungsformen kann ein Kommunikationsmodul die Komponenten der logischen Verbindungsschicht und der Datenverbindungsschicht der Vorrichtung 900 und andere Komponenten, die notwendig sind, um Daten von der Vorrichtung zu übertragen und an der Vorrichtung zu empfangen, umfassen.
• Eine Umgebung, in welcher einige Ausführungsformen, die oben beschrieben wurden, ausgeführt werden, können einen Mehrzweckcomputer oder eine Spezialzweckvorrichtung, wie beispielsweise ein in der Hand-gehaltener Computer, Smartphone oder andere mobile Vorrichtung einbeziehen. Einige Details von solchen Vorrichtungen (z.B. Prozessor, Speicher, Datenspeicher, Anzeige) können aufgrund der Klarheit weggelassen werden. Eine Komponente, wie beispielsweise ein Prozessor oder Speicher, dem eine oder mehrere Aufgaben oder Funktionen zugewiesen sind, kann eine generelle Komponente sein, die temporär konfiguriert ist, um die spezifische Aufgabe oder Funktion durchzuführen oder kann eine spezifische Komponente sein, die hergestellt ist, um die Aufgabe oder Funktion durchzuführen. Der Begriff „Prozessor“, wie er hier verwendet wird, bezieht sich auf eine oder mehrere elektronische Schaltungen, Vorrichtungen, Chips, Verarbeitungskerne und/oder anderen Komponenten, die konfiguriert sind, um Daten und/oder Computerprogrammcode zu verarbeiten.
• Datenstrukturen und Programmcode, die in dieser detaillierten Beschreibung beschrieben werden, sind typischerweise auf einem nichtflüchtigen computerlesbaren Speichermedium gespeichert, welches irgendeine Vorrichtung oder Medium sein kann, das Code und/oder Daten für eine Verwendung durch ein Computersystem speichern kann. Nichtflüchtige computerlesbare Speichermedien beinhalten, sind aber nicht beschränkt auf, volatile Speicher, nichtvolatile Speicher, magnetische und optische Speichervorrichtungen, wie beispielsweise Plattenlaufwerke, Magnetband, CDs (compact disks) und DVDs (digital versatile disks oder digital video disks), Festkörperlaufwerk und/oder andere nichtflüchtige computerlesbare Medien, die jetzt bekannt sind oder später entwickelt werden.
• Methoden und Verfahren, die in der detaillierten Beschreibung beschrieben werden, können als Code und/oder Daten verkörpert werden, welche auf einem nichtflüchtigen computerlesbaren Speichermedium wie oben beschrieben, gespeichert werden können. Wenn ein Prozessor oder ein Computersystem den Code liest und ausführt und die Daten, die auf dem Medium gespeichert sind, manipuliert, führt der Prozessor oder das Computersystem die Verfahren und Prozesse, die als Code oder Datenstrukturen verkörpert sind und auf dem Medium gespeichert sind, aus.
• Außerdem können die Verfahren und Prozesse in Hardwaremodule programmiert werden, wie beispielsweise aber nicht beschränkt auf, anwendungsspezifische integrierte Schaltungs (application specific integrated circuit, ASIC) Chips, feldprogrammierbare Gateanordnungen (field programmable gate arrays, FPGAs) und andere programmierbare Logikvorrichtungen schon bekannt oder später entwickelt. Wenn solch ein Hardwaremodul aktiviert wird, führt es die Verfahren oder Prozesse, die in dem Modul enthalten sind, aus.
• Die vorangegangenen Ausführungsformen wurden nur zum Zwecke der Veranschaulichung und Beschreibung dargestellt. Sie sind nicht dazu gedacht, erschöpfend zu sein oder diese Offenbarung auf die offenbarten Formen zu begrenzen. Dementsprechend sind dem Fachmann viele Modifikationen oder Variationen offensichtlich. Der Umfang wird durch die anhängenden Ansprüche, nicht die vorangegangene Offenbarung, definiert.

Claims (15)

1. Vorrichtung zum Durchführen von Peer-to-Peer-Kommunikationen, wobei die Vorrichtung umfasst: einen Prozessor; einen Speicher; und einen drahtlosen Sendeempfänger zum Durchführen von drahtlosen Kommunikationen; wobei der Prozessor und der drahtlose Sendeempfänger konfiguriert sind zum: Bestimmen einer Zielbeaconübermittlungszeit (target beacon transmission time, TBTT) auf einem beschränkten Kanal, wobei der beschränkte Kanal einen Kanal umfasst, der Rücksichtnahme auf eine bevorzugte Signalquelle oder eine bevorzugte Signalart erfordert; Einstellen des beschränkten Kanals vor der TBTT; nach dem Einstellen des beschränkten Kanals: Unterlassen von Übertragen während eines Zeitintervalls, welches die TBTT beinhaltet; und Übermitteln auf dem beschränkten Kanal nur nachdem: Empfangen eines Beacon oder eines Verwaltungsframes, die angeben, dass der beschränkte Kanal frei ist; oder Scheitern einen Beacon oder ein Verwaltungsframe während dem Zeitintervall zu empfangen.
2. Vorrichtung nach Anspruch 1, wobei: der Speicher Identitäten von Frequenzen von mehreren Kanälen umfasst, den beschränkenden Kanal beinhaltend; und der Prozessor und der drahtlose Sendeempfänger ferner konfiguriert sind zum Springen zwischen den mehreren Kanälen in einer sich wiederholenden Sequenz während eines Durchführens der Peer-to-Peer-Kommunikationen.
3. Vorrichtung nach Anspruch 2, wobei die sich wiederholende Sequenz eine Periode aufweist, die äquivalent zu einem Vielfachen von einem Beaconintervall von einem zentralen Knoten ist, der auf dem beschränkten Kanal betrieben wird.
4. Verfahren zum Durchführen von Peer-to-Peer-Kommunikationen, wobei das Verfahren an einer ersten Kommunikationsvorrichtung umfasst: Bestimmen einer Sequenz von Kommunikationskanälen, auf welchen die Peer-to-Peer-Kommunikationen durchgeführt werden sollen, wobei die Sequenz einen ersten beschränkten Kanal beinhaltet, auf welchem eine erste Mastervorrichtung Beaconframes mit einem Beaconintervall ausgibt, wobei der beschränkte Kanal einen Kanal umfasst, der Rücksichtnahme auf eine bevorzugte Signalquelle oder eine bevorzugte Signalart erfordert; und wenn der erste beschränkte Kanal eingestellt ist: Unterlassen ein Übertragen für eine Zeitperiode, die jede erste Zielbeaconübermittlungszeit (TBTTi) umfasst; und nachfolgend zu der Zeitperiode, die jede TBTT1 umfasst, Durchführen der Peer-to-Peer-Kommunikationen auf dem ersten beschränkten Kanal nur falls: ein Beaconframe empfangen wird, das angibt, dass der erste beschränkte Kanal frei ist; oder kein Beaconframe während der Zeitperiode empfangen wird.
5. Verfahren nach Anspruch 4, ferner umfassend Springen zwischen den Sequenzen von Kommunikationskanälen, wobei das Springen beinhaltet: Berechnen einer Periode der Sprungsequenz, wobei die Periode ungefähr gleich zu einem Vielfach des ersten Beaconintervalls ist; Berechnen einer Zeit, um einen zweiten unbeschränkten Kanal von dem ersten beschränkten Kanal aus einzustellen; und Einstellen des ersten beschränkten Kanals für eine nächste Sprungperiode.
6. Verfahren nach Anspruch 5, wobei Einstellen des ersten beschränkten Kanals für eine nächste Sprungperiode beinhaltet, Einstellen des beschränkten Kanals ungefähr 1-3 Millisekunden vor einem TBTT1.
7. Verfahren nach Anspruch 5, wobei Berechnen einer Zeit zum Einstellen des zweiten unbeschränkten Kanals von dem ersten beschränkten Kanal aus beinhaltet, Berechnen von Zeitschlitzen fester Länge für die Peer-to-Peer-Kommunikationen auf dem ersten beschränkten Kanal und dem zweiten unbeschränkten Kanal.
8. Verfahren nach Anspruch 4 ferner umfassend Springen zwischen den Sequenzen von Kommunikationskanälen, wobei Springen beinhaltet: Berechnen einer Periode der Sprungsequenz, wobei die Periode ungefähr gleich zu einem Vielfachen von dem ersten Beaconintervall ist; Berechnen einer Zeit zum Einstellen eines zweiten beschränkten Kanals von dem ersten beschränkten Kanal aus; und Einstellen des ersten beschränkten Kanals für eine nächste Sprungperiode.
9. Verfahren nach Anspruch 8, wobei Berechnen einer Zeit zum Einstellen des zweiten beschränkten Kanals von dem ersten beschränkten Kanal aus beinhaltet: Identifizieren eines zweiten Beaconintervalls, mit welchem eine zweite Mastervorrichtung Beaconframes auf dem zweiten beschränkten Kanal ausgibt; basierend auf dem zweiten Beaconintervall, Berechnen einer oder mehrerer zweiter Zielbeaconübermittlungszeiten (TBTT2); und Auswählen einer ungefähren TBTT2 als Zeit zum Einstellen des zweiten beschränkten Kanals.
10. Verfahren nach Anspruch 9, wobei die ungefähre TBTT2 ungefähr 1-3 Millisekunden vor einer TBTT2 ist.
11. Verfahren zum Durchführen von Peer-to-Peer-Kommunikationen, wobei das Verfahren an einer ersten Peer-Vorrichtung umfasst: Identifizieren von zwei oder mehr Kommunikationskanälen, auf welchen die Peer-to-Peer-Kommunikationen durchgeführt werden sollen, wobei zumindest einer der zwei oder mehr Kommunikationskanäle einen beschränkten Kanal umfasst, der Rücksichtnahme auf eine bevorzugte Signalquelle oder eine bevorzugte Signalart erfordert; basierend auf einem Beaconintervall von einem ersten Kanal, Auswählen einer Zeitperiode zum Durchführen mehrerer Kanalsprungsequenzen zwischen den zwei oder mehr Kanälen; bei jedem Sprung zu einem ersten Kanal, Verschieben ein Übermitteln auf dem ersten Kanal bis: eine Kommunikation von einem ersten Verwaltungsknoten empfangen wird, die angibt, dass der erste Kanal frei ist; oder ein Zeitfenster von vorbestimmter Dauer vorbei ist, während welcher keine Kommunikation von dem ersten Verwaltungsknoten empfangen wird; und Terminieren eines Wechsels zu einem sozialen Kanal, um mit einem von folgenden zusammenzufallen: einem Peer-to-Peer-Beacon, auf dem sozialen Kanal zum Beibehalten einer Synchronisation mit einer Gruppe von anderen Peer-Vorrichtungen; oder einem Verfügbarkeitsfenster auf dem sozialen Kanal zum Ermitteln von anderen Peer-Vorrichtungen in der Gruppe.
12. Verfahren nach Anspruch 11 ferner umfassend Nachverschieben eines Übermittelns auf dem ersten Kanal: Wiederaufnehmen der Peer-to-Peer-Kommunikationen; und Wiederholen eines Verschiebens vor einer nächsten Zielbeaconübermittlungszeit (TBTT) von dem ersten Verwaltungsknoten.
13. Verfahren nach Anspruch 11 ferner umfassend: Terminieren eines Wechsels zu einem zweiten Kanal, um zu einer beliebigen Zeit vorzukommen; und Wiederaufnehmen der Peer-to-Peer-Kommunikationen direkt beim Wechseln zu dem zweiten Kanal.
14. Verfahren nach Anspruch 11, wobei: der erste Verwaltungsknoten ein Zugriffspunkt ist, der mit einer oder mehreren Peer-Vorrichtungen ausgenommen der ersten Peer-Vorrichtung verbunden ist; die erste Peer-Vorrichtung mit einem zweiten Verwaltungsknoten verbunden ist, der auf einem zweiten Kanal betrieben wird; und das Verfahren ferner umfasst: Befolgen einer Kanalwechselbenachrichtigung, die von dem ersten Verwaltungsknoten ausgegeben wird.
15. Verfahren nach Anspruch 11, ferner umfassend: falls die erste Peer-Vorrichtung ein Anchormaster der Gruppe ist, Synchronisieren eines Zeitplans von Verfügbarkeitsfenstern auf dem sozialen Kanal, das Beaconintervall auf dem ersten Kanal.

Images