DE112019002232T5

DE112019002232T5 - Intelligenter funk-arbiter mit konfliktlösung basierend auf zeitlicher vorhersehbarkeit

Info

Publication number: DE112019002232T5
Application number: DE112019002232.6T
Authority: DE
Inventors: Yifeng Yang
Original assignee: Microchip Technology Inc
Current assignee: Microchip Technology Inc
Priority date: 2018-04-30
Filing date: 2019-04-16
Publication date: 2021-03-04
Also published as: US11089609B2; CN113645155A; US20190335482A1; CN112055994A; US20200170025A1; CN113645155B; CN112055994B; WO2019212747A1; TW201946487A; US10652912B2

Abstract

Es werden ein Funk-Arbiter, ein elektronisches System und ein Verfahren zur drahtlosen Kommunikation offenbart, bei dem mindestens zwei HF-Anforderungen (Hochfrequenz-Anforderungen) über ein einziges Funkmodul empfangen werden. Der Funk-Arbiter führt eine prädiktive Arbitrierung basierend auf Zeitinformationen durch, die für eine HF-Anforderung vor dem Empfangen der HF-Anforderung bekannt sind. HF-Anforderungen können auf einer oder mehreren ZigBee-, Bluetooth Low Energy- oder WiFi-Kommunikationstopologien basieren.

Description

PRIORITÄTSANSPRUCH
Diese Anmeldung beansprucht den Vorteil gemäß der vorläufigen US-Patentanmeldung Serien-Nr. 62/664,828 , eingereicht am 30. April 2018, unter 35 U.S.C. §119(e) für „INTELLIGENTER FUNK-ARBITER MIT KONFLIKTLÖSUNG BASIEREND AUF ZEITLICHER VORHERSEHBARKEIT“ und beansprucht die Priorität des Anmeldedatums der anhängigen US-Patentanmeldung Serien-Nr. 16/037,599 , eingereicht am 17. Juli 2018, für „INTELLIGENTER FUNK-ARBITER MIT KONFLIKTLÖSUNG BASIEREND AUF ZEITLICHER VORHERSEHBARKEIT“ anhängig, die auch die Priorität der vorläufigen U.S.-Patentanmeldung Serien-Nr. 62/664,828 beansprucht, deren Inhalte und Offenbarung jeweils hiermit in ihrer Gesamtheit durch Bezugnahme aufgenommen sind.
TECHNISCHES GEBIET
Die vorliegende Offenbarung bezieht sich im Allgemeinen auf drahtlose Kommunikation und insbesondere auf ein drahtloses Subsystem, das verschiedene Verbindungen mit einer einzigen Hochfrequenz-Funkvorrichtung (HF-Funkvorrichtung) unterstützt.
STAND DER TECHNIK
Wenn drahtlose Subsysteme, die mit unterschiedlichen Protokollen arbeiten, sich einen gemeinsamen Kommunikationskanal teilen (z. B. drahtlose Hochfrequenz-Bänder (HF-Bänder)), können zusätzliche Verfahren wünschenswert sein, um den Paketverkehr innerhalb des drahtlosen Subsystems zu arbitrieren. Gemäß vordefinierten Standards können mehrere Kommunikationsmodule im gleichen (oder überlappenden) Frequenzband arbeiten. Infolgedessen können dazwischen physikalische Interferenzen entstehen. In einem dualen 802.11- und 802.15-Funksystem ist die IEEE 802.15.2 Packet Traffic Arbitration (PTA) eine konventionelle Methode zur Reduzierung der physikalischen Interferenzen zwischen dem WLAN-Modul und dem Bluetooth-Modul. Der PTA-Mechanismus ist ein prioritätsbasiertes Steuerungssystem mit einer Arbitrierungsschaltung, die mit dem WLAN-Modul und dem Bluetooth-Modul gekoppelt und konfiguriert ist, um jeder der beiden Module das Ausführen von HF-Aktivität zu ermöglichen. Die Arbitrierung kann auf einer Prioritätentabelle basieren, die die Prioritäten der verschiedenen Verkehrsarten definiert. Eine Anforderung einer Verkehrsart mit der höchsten Priorität kann uneingeschränkt gewährt werden, während eine Verkehrsart mit einer niedrigeren Priorität nur dann gewährt werden kann, wenn der Verkehr mit der höheren Priorität inaktiv ist.
OFFENBARUNG
In einigen Ausführungsformen umfasst ein Funk-Arbiter einen Prozessor und ein computerlesbares Medium. Das computerlesbare Medium schließt darauf gespeicherte Anweisungen ein, die, wenn sie durch den Prozessor ausgeführt werden, den Prozessor veranlassen, eine erste HF-Anforderung zu empfangen, die mit einem ersten drahtlosen Protokoll mit geringer Leistung verknüpft ist, eine zweite HF-Anforderung zu empfangen, die mit einem zweiten drahtlosen Protokoll mit geringer Leistung verknüpft ist, und die erste HF-Anforderung in einen Wartezustand zu versetzen, bis die zweite HF-Anforderung basierend auf einer prädiktiven Arbitrierungsbestimmung abgeschlossen ist, bevor die zweite HF-Anforderung empfangen wird.
In einigen Ausführungsformen umfasst ein elektronisches System ein drahtloses Subsystem, das ein Funkmodul, eine Vielzahl von Verbindungssteuerungen, die gemäß verschiedenen Topologien konfiguriert sind, und einen Funk-Arbiter einschließt. Der Funk-Arbiter ist konfiguriert, um Daten zwischen dem Funkmodul und der Mehrzahl von Verbindungssteuerungen zu senden und zu empfangen und eine erste HF-Anforderung in einen Wartezustand zu versetzen, bis eine zweite HF-Anforderung basierend auf einer prädiktiven Arbitrierungsbestimmung abgeschlossen ist, bevor die zweite HF-Anforderung empfangen wird.
In einigen Ausführungsformen umfasst ein Verfahren zur drahtlosen Kommunikation das Empfangen einer ersten HF-Anforderung durch ein Funkmodul mit einer ersten Priorität, das Empfangen einer zweiten HF-Anforderung durch das Funkmodul mit einer zweiten Priorität, die höher als die erste Priorität ist, und Versetzen der ersten HF-Anforderung in einen Wartezustand als Reaktion auf das Bestimmen, dass das Gewähren der ersten HF-Anforderung zu einer Kollision mit der zweiten HF-Anforderung führen würde.
Figurenliste
Während diese Offenbarung mit Ansprüchen endet, die bestimmte Ausführungsformen besonders hervorheben und deutlich beanspruchen, können verschiedene Merkmale und Vorteile von Ausführungsformen innerhalb des Umfangs dieser Offenbarung leichter aus der folgenden Beschreibung in Verbindung mit den beigefügten Zeichnungen ermittelt werden, in denen:

1 ist ein vereinfachtes Blockdiagramm eines drahtlosen Subsystems gemäß Ausführungsformen der vorliegenden Offenbarung.
2 ist ein Zeitdiagramm, das einen Betrieb eines Funk-Arbiters ohne die prädiktiven Zeitsteuerungsaspekte der Offenbarung zeigt.
3 ist ein Zeitdiagramm, das den Betrieb eines prioritätsbasierten Funk-Arbiters zeigt.
4 ist ein Zeitdiagramm, das den Betrieb eines auf Vorhersagbarkeit basierenden Funk-Arbiters zeigt.
5 ist ein Zeitdiagramm, das eine maximale Übertragungsverzögerung eines auf Vorhersagen basierenden Arbitrierungsereignisses gemäß einer Ausführungsform der Offenbarung zeigt.
6 ist ein Zeitdiagramm, das einen Betrieb des Funk-Arbiters ohne vorhergesagte Kollision gemäß einer Ausführungsform der Offenbarung zeigt.
7 bis 9 sind Zeitdiagramme, die einen Betrieb des Funk-Arbiters mit einer vorhergesagten Senderkollision für verschiedene Prioritätssituationen gemäß den Ausführungsformen der Offenbarung zeigen.
10 und 11 sind Zeitdiagramme, die einen Betrieb des Funk-Arbiters mit einer vorhergesagten Empfängerkollision für verschiedene Prioritätssituationen gemäß einer Ausführungsform der Offenbarung zeigen.

ART(EN) DER AUSFÜHRUNG DER ERFINDUNG
In der folgenden detaillierten Beschreibung wird auf die beigefügten Zeichnungen Bezug genommen, die einen Teil hiervon bilden und in denen zur Veranschaulichung spezifische Ausführungsformen gezeigt sind, in denen die Offenbarung ausgeführt werden kann. Diese Ausführungsformen werden ausreichend detailliert beschrieben, um es einem Durchschnittsfachmann zu ermöglichen, die Offenbarung auszuführen. Es versteht sich jedoch, dass die detaillierte Beschreibung und die spezifischen Beispiele, während sie Beispiele von Ausführungsformen der Offenbarung angeben, nur zur Veranschaulichung und nicht zur Einschränkung gegeben sind. Aus dieser Offenbarung können im Rahmen der Offenbarung verschiedene Ersetzungen, Modifikationen, Hinzufügungen, Umstellungen oder Kombinationen davon vorgenommen werden, die für einen Durchschnittsfachmann offensichtlich sind.
Gemäß der üblichen Praxis sind die verschiedenen in den Zeichnungen dargestellten Merkmale gegebenenfalls nicht maßstabsgetreu gezeichnet. Die hierin dargestellten Veranschaulichungen sollen keine tatsächlichen Ansichten einer bestimmten Vorrichtung (z. B. Vorrichtung, System usw.) oder eines bestimmten Verfahrens sein, sondern sind lediglich Darstellungen, die zur Beschreibung verschiedener Ausführungsformen der Offenbarung verwendet werden. Dementsprechend können die Abmessungen der verschiedenen Merkmale der Übersichtlichkeit halber beliebig erweitert oder reduziert werden. Außerdem können einige der Zeichnungen der Übersichtlichkeit halber vereinfacht sein. Somit zeigen die Zeichnungen möglicherweise nicht alle Komponenten einer gegebenen Vorrichtung oder alle Vorgänge eines bestimmten Verfahrens.
Hierin beschriebene Informationen und Signale können unter Verwendung verschiedener unterschiedlicher Technologien und Techniken dargestellt werden. Zum Beispiel können Daten, Anweisungen, Befehle, Informationen, Signale, Bits, Symbole und Chips, auf die in der Beschreibung Bezug genommen werden kann, durch Spannungen, Ströme, elektromagnetische Wellen, Magnetfelder oder -partikel, optische Felder oder Partikel oder eine beliebige Kombination davon dargestellt werden. Einige Zeichnungen können Signale zur Übersichtlichkeit der Darstellung und Beschreibung als ein einzelnes Signal veranschaulichen. Es sollte für einen Durchschnittsfachmann ersichtlich sein, dass das Signal einen Bus von Signalen darstellen kann, wobei der Bus eine Vielfalt von Bitbreiten aufweisen kann und die Offenbarung auf einer beliebigen Anzahl von Datensignalen, einschließlich eines einzelnen Datensignals, implementiert werden kann.
Es versteht sich, dass jede Bezugnahme auf ein Element in diesem Dokument unter Verwendung einer Bezeichnung wie „erste/r/s“, „zweite/r/s“ usw. die Menge oder Reihenfolge dieser Elemente nicht einschränkt, es sei denn, eine solche Einschränkung wird ausdrücklich angegeben. Vielmehr werden diese Bezeichnungen hierin als ein zweckmäßiges Verfahren zum Unterscheiden zwischen zwei oder mehr Elementen oder Instanzen eines Elements verwendet. Ein Verweis auf ein erstes und zweites Element bedeutet also nicht, dass nur zwei Elemente eingesetzt werden dürfen oder dass das erste Element dem zweiten Element in irgendeiner Weise vorhergehen muss. Ebenso kann ein Satz von Elementen, sofern nicht anders angegeben, ein oder mehrere Elemente umfassen. Ebenso können manchmal Elemente, auf die in der Singularform Bezug genommen wird, auch eine oder mehrere Instanzen des Elements einschließen.
Die Ausführungsformen schließen einen Funk-Arbiter ein, der konfiguriert ist, um die Zuständigkeiten der HF-Funkverbindung zwischen mindestens zwei verschiedenen Verbindungssteuerungen für mindestens zwei verschiedene Funkprotokolle (z. B. Zigbee und Bluetooth) zu arbitrieren. Da beide Verbindungen nicht 100 % der Sendezeit der Funkvorrichtung nutzen müssen, teilt der Funk-Arbiter die Sendezeit der Funkvorrichtung zwischen den beiden Verbindungssteuerungen durch intelligentes Umschalten der Zuständigkeiten zwischen den beiden basierend auf den Prioritäten ihrer individuellen Anforderungen auf. Die grundlegenden Prioritäten der einzelnen Anforderungen können durch programmierte inkrementelle Prioritäten geändert werden, die auf dem Status der Unteraufgaben für jede der Anforderungen basieren. Die inkrementellen Prioritäten der Unteraufgaben können die Effizienz der Funknutzung zwischen den beiden Verbindungen erhöhen, indem die Beendigung von Aufgaben basierend auf dem Unterzustand vermieden wird. Das Hardwareschema bietet programmierbare Prioritäten für Unteraufgaben in Kategorien: inkrementell, dekrementell und absolut.
Wie in dieser Offenbarung verwendet, bedeutet „drahtlose Kommunikationsverbindung‟ einen physischen Kommunikationskanal zwischen zwei Vorrichtungen, wobei das physische Kommunikationsmedium in erster Linie Hochfrequenzwellen (HF-Wellen) sind. Beispielsweise kann ein Kanal einer drahtlosen Kommunikationsverbindung ein frequenzspezifischer Kommunikationspfad zwischen den beiden Vorrichtungen sein. Ein Kanal kann Teil eines für die Kommunikation zugewiesenen Frequenzspektrums sein, das aus vielen möglichen Kanälen besteht. Eine drahtlose Kommunikationsverbindung kann tatsächlich mehrere Kanäle innerhalb eines Frequenzspektrums während der Kommunikation zwischen zwei Vorrichtungen nutzen, z. B. durch Verfahren wie Frequenzspringen und adaptives Frequenzspringen. Eine drahtlose Kommunikationsverbindung kann sowohl einseitig (z. B. eine Vorrichtung verfügt über einen Sender, aber keinen Empfänger oder ist nicht für den Empfang von Nachrichten konfiguriert, so dass die Verbindung unidirektional ist) als auch bidirektional (z. B. Vorrichtungen, die sowohl senden als auch empfangen können) sein. Wie in dieser Offenbarung verwendet, bedeutet „Kommunikationsnachricht(en)“ die administrativen Nachrichten (z. B. zum Aufbau einer drahtlosen Kommunikationsverbindung) und die Informationsnachrichten (z. B. Daten-Nutzlast), die über eine drahtlose Kommunikationsverbindung als ein oder mehrere Pakete gesendet werden.
Wie hierin verwendet, bedeutet „Kollision“, dass für eine bestimmte Zeit zwei oder mehr drahtlose Kommunikationsübertragungen stattfinden, die die gleichen oder mindestens teilweise überlappenden Funkfrequenzbänder verwenden.
Ausführungsformen der Offenbarung können darin bestehen, dass der Funk-Arbiter zwei oder mehr Kurzstrecken-HF-Topologien bedient. Die erste HF-Topologie kann entsprechend einem drahtlosen persönlichen Netzwerk mit niedrigem Stromverbrauch und niedriger Übertragungsrate konfiguriert werden. Als ein nicht einschränkendes Beispiel kann die erste HF-Topologie gemäß dem technischen Standard IEEE 802.15.4 arbeiten. Beispiele hierfür schließen ZigBee-, ISA100.11a-, WirelessHART-, WiWi-, SNAP- und Thread-Spezifikationen ein. Die zweite HF-Topologie kann gemäß einem anderen drahtlosen persönlichen Netzwerk mit niedrigem Stromverbrauch und niedriger Übertragungsrate konfiguriert werden, wie z. B. Bluetooth (z.B. Bluetooth Low Energy (BLE)), ANT, ANT+, usw. Zusätzliche Ausführungsformen können auch WiFi-Topologien einschließen. Während Ausführungsformen der Offenbarung primär als Bereitstellung einer Arbitrierung zwischen zwei Steuerungen beschrieben werden, die an eine einzige HF-Antenne gekoppelt sind, wird die Bereitstellung einer Arbitrierung für mehr als zwei Steuerungen und Topologien ebenfalls insbesondere in Betracht gezogen. Außerdem können ZigBee und Bluetooth als nicht einschränkende Beispiele bereitgestellt werden, um die Erörterung zu vereinfachen; es werden jedoch auch andere Topologien und Kombinationen von Topologien in Betracht gezogen. Während in den meisten Beispielen ein Funk-Arbiter erörtert wird, der mit zwei verschiedenen Topologien arbeitet, können Ausführungsformen der Offenbarung mehr als zwei verschiedene Arten von HF-Anforderungen einschließen. Infolgedessen kann der Funk-Arbiter Anforderungen mit drei, vier usw. Arten von HF-Anforderungen verwalten und Kollisionen zwischen jeder der verschiedenen Anforderungen vorhersagen. Das Bestimmen der Reihenfolge, in der HF-Anforderungen bedient und/oder in einen Wartezustand versetzt werden, kann von den verschiedenen Prioritäten abhängen, die für jede der drei oder mehr verschiedenen Topologien festgelegt sind.
Ausführungsformen der Offenbarung können auch Vorrichtungen und Verfahren zum Planen von Kommunikation einschließen, die mindestens zwei drahtlose Protokolltypen beinhaltet. Das Verfahren umfasst das Empfangen einer ersten HF-Anforderung einer ersten Art und einer zweiten HF-Anforderung einer zweiten Art, das Vorhersagen einer Kollision zwischen der ersten HF-Anforderung und der zweiten HF-Anforderung basierend auf einem oder mehreren Parametern der Anforderungen und das Planen der Gewährung der ersten HF-Anforderung und der zweiten HF-Anforderung basierend auf einer Prioritätsstufe, um die vorhergesagte Kollision zu vermeiden.
1 ist ein vereinfachtes Blockdiagramm eines drahtlosen Subsystems 100 gemäß Ausführungsformen der vorliegenden Offenbarung. Die Elemente können durch analoge Schaltungen, digitale Schaltungen, Anweisungen zur Ausführung durch einen Prozessor oder jede geeignete Kombination davon implementiert werden. Das drahtlose Subsystem 100 kann ein Funkmodul 110 einschließen, das über einen Funk-Arbiter 140 mit einer Vielzahl von HF-Verbindungssteuerungen 120, 130 operativ gekoppelt ist. Der ACLB (analoger Steuerlogikblock) 112, der in das Funkmodul 110 integriert ist, kann eine oder mehrere Funktionen für das Funkmodul 110 bereitstellen und Komponenten einschließen, die für komplexe analoge Filterung und Abtastung konfiguriert sind, wie Antennen, Mischer, Analog-Digital-Wandler, Filter, Modems usw., wie sie dem Durchschnittsfachmann bekannt sind. Die Verbindungssteuerungen 120, 130 kommunizieren auch mit dem größeren elektronischen System (nicht abgebildet) über eine Systemschnittstelle 150. Das drahtlose Subsystem 100 kann in größere Systeme und Vorrichtungen integriert werden, z. B. in Hausautomatisierungsvorrichtungen, medizinische Vorrichtungen, Smartphones, Spielkonsolen, PCs, Laptops, Tablet-Computer, Vorrichtungen in Kraftfahrzeugen, Audiosysteme (z. B. Kopfhörer, Headsets, Stereosysteme, tragbare Lautsprecher usw.), Videosysteme, Peripherievorrichtungen (z. B. Drucker) und andere Systeme mit niedrigem Stromverbrauch und geringer Bandbreite für die Datenübertragung über kurze Entfernungen.
Wie vorstehend erörtert, kann die erste Verbindungssteuerung 120 eine Bluetooth-Verbindungssteuerung (BLE-Verbindungssteuerung) und die zweite Verbindungssteuerung 130 eine Zigbee-Verbindungssteuerung (ZigBee-Verbindungssteuerung) sein. Verschiedene Arten von Verbindungssteuerungen (z. B. WiFi) werden ebenfalls in Betracht gezogen, und die Anzahl der verschiedenen Arten von Verbindungssteuerungen, die durch den Funk-Arbiter 140 unterstützt werden, kann auch größer als zwei (z. B. drei oder mehr) sein. Die Verbindungssteuerungen 120, 130 können ähnliche Schnittstellen mit den entsprechenden Firmware-Stacks (FW-Stacks) aufweisen. In der zweiten Verbindungssteuerung 130 kann anstelle eines einzelnen Sender-Empfänger-Puffers eine Doppelpuffer-Schnittstelle verwendet werden. Es kann eine parallele Systembusschnittstelle verwendet werden. Tx- und Rx-Aktivitätsereignis-Unterbrechungen können von den entsprechenden Verbindungssteuerungen 120, 130 erzeugt werden. Der Funk-Arbiter 140 kann zusätzliche Unterbrechungen im Zusammenhang mit Arbitrierungsausnahmen und Ereignissen erzeugen.
Die BLE-Verbindungssteuerung 120 kann Funktionsmodule wie ein Tx-Modem 122, ein Rx-Modem 124, eine automatische Verstärkungsregelung (AGC) 126 und einen Basisbandkern 128 und/oder andere für die BLE-Kommunikation erforderliche Elemente einschließen. Die ZigBee-Verbindungssteuerung 130 kann auch Funktionsmodule wie ACT 131, Basisband-Prozessor (BBP) 132, TOM 133, XAH 134, Host-Schnittstelle (HIF) 135 (einschließlich eines Sender-Empfänger-Puffers 136) und DCT-Steuermodul 137 (einschließlich einer Steuer-Final-Zustandsmaschine (FSM) 138 und Stromversorgung FSM 139) und/oder andere Elemente einschließen, die für die Handhabung der ZigBee-Kommunikation durch die BLE-Verbindungssteuerung 120 erforderlich sind.
In verschiedenen Ausführungsformen kann der Funk-Arbiter 140 konfiguriert sein, um ein flexibles Arbitrierungsschema für die Handhabung der Kommunikation zwischen einem einzelnen Funkmodul 110 und den verschiedenen Verbindungssteuerungen 120, 130 auszuführen. Der Arbiter verbindet sich an einem Ende mit dem Funkmodul 110 und am anderen Ende mit den Verbindungssteuerungen 120, 130. Der Funk-Arbiter 140 kann konfiguriert sein, um die Zuständigkeit für das Funkmodul 110 zwischen den Verbindungssteuerungen 120, 130 zu bestimmen und sicherzustellen, dass der entsprechende aktuelle Verantwortliche die Steuerungen für das Funkmodul 110 steuert.
Das Arbitrierungsschema kann Modi wie Bluetooth Low Energy (BLE) statisch, Zigbee (ZigBee) statisch oder dynamisch einschließen. Im statischen BLE-Modus ist die BLE-Verbindungssteuerung 120 für die Funkvorrichtung verantwortlich. Im statischen ZigBee-Modus ist die ZigBee-Verbindungssteuerung 130 für die Funkvorrichtung verantwortlich. Im dynamischen Modus wurde bei jedem Arbitrierungsereignis dynamisch über die Verantwortlichkeit über die Funkvorrichtung entschieden. Der Funk-Arbiter 140 kann jederzeit entweder im statischen BLE-Modus oder im statischen ZigBee-Modus konfiguriert werden. In diesen Modi wird keine Arbitrierung durchgeführt, und das Funkmodul 110 ist in der Verantwortlichkeit einer der beiden Verbindungssteuerungen 120, 130. Während des dynamischen Modus weisen die Verbindungssteuerungen 120, 130 dem Funk-Arbiter 140 jeweils eine Priorität für eine HF-Anforderung zu, und der Funk-Arbiter 140 schaltet zwischen HF-Anforderungen der beiden Protokollmodule basierend auf der zugewiesenen Priorität um. Wie nachstehend näher erörtert, kann bei der Konfliktlösung durch den Funk-Arbiter 140 auch die zeitliche Vorhersehbarkeit der verschiedenen HF-Anforderungen bei der Durchführung der Arbitrierung berücksichtigt werden.
2 ist ein Zeitdiagramm 200, das einen Betrieb eines Funk-Arbiters ohne die prädiktiven Zeitsteuerungsaspekte der Offenbarung zeigt. Wie vorstehend erörtert, koordiniert der Funk-Arbiter HF-Betriebe auf zwei oder mehr separaten Steuerungsimplementierungen. Wenn mehrere Betriebe mit begrenzten Ressourcen miteinander konkurrieren, wird jedem Betrieb eine Prioritätsstufe zugewiesen. Ein Betrieb mit höherer Priorität könnte den Betrieb mit niedrigerer Priorität unterbrechen, so dass die begrenzte Ressource je nach Dringlichkeit des Bedarfs mehrere Betriebe bedienen könnte. Sobald ein Ereignis einer drahtlosen Kommunikation unterbrochen ist, wird die Nachricht nicht übertragen. Als Beispiel in 2 kann eine BLE-Anforderung mit höherer Priorität einen anhängigen ZigBee-Betrieb mit niedrigerer Priorität unterbrechen. Dadurch wird die ZigBee-Kommunikation durch den Funk-Arbiter abgebrochen und die BLE-Kommunikation bis zum Abschluss durchgeführt, wonach die ZigBee Kommunikation erneut startet. Während der ZigBee-Kommunikation gibt es keine Möglichkeit, einen solchen HF-Betrieb fortzusetzen, nachdem die HF-Anforderung mit höherer Priorität abgeschlossen ist. Da der HF-Betrieb nicht abgeschlossen ist, gilt die Nachricht als nicht über Funk gesendet. Infolgedessen wurde die Energie, die vor der Unterbrechung zur Übertragung der Daten verwendet wurde, verschwendet. Des Weiteren besetzte die fehlgeschlagene Übertragung die Ätherwelle; und verhinderte damit die Nutzung des Frequenzkanals durch eine andere Vorrichtung. Eine solche Lose-Lose-Situation sollte möglichst vermieden werden.
Da die Eigenschaften von BLE- und ZigBee-Protokollen (und anderen ähnlichen Protokollen) vorhersehbar sind, kann der Funk-Arbiter entsprechend den Ausführungsformen der Offenbarung, der konfiguriert ist, um HF-Anforderungen aus zwei Protokollen zu behandeln, konfiguriert sein, um die zeitliche Vorhersehbarkeit der HF-Anforderungen zu berücksichtigen. BLE und andere Time Division Multiple Access-Protokolle (TDMA-Protokolle) und dynamische TDMA-Protokolle, so dass das Verhalten des BLE-Moduls sehr gut vorhersagbar ist.
In einem verbundenen Zustand kommunizieren die zentralen und peripheren Vorrichtungen mit einem festen Verbindungsintervall. Wenn die aktuelle HF-Anforderung für ein Verbindungsereignis ausgegeben wird, weiß das BLE-Modul mit großer Genauigkeit, dass das nächste BLE-Verbindungsereignis nach einem Verbindungsintervall eintreten wird.
In einem nicht verbundenen Anzeigenzustand zeigt die Peripherievorrichtung (z. B. ein Sender wie eine Bluetooth-Beacon) in einem festen Intervall an. In einer Ausführungsform kann die zufällige Verzögerung einer Anzeige vorab ausgewertet und zu einem Anzeigenintervall-Parameter hinzugefügt werden. Daher weiß das BLE-Modul bei der Ausgabe der aktuellen BLE-Anforderung auch sehr genau, wann das nächste Anzeigenereignis stattfinden wird.
Bei einem nicht verbundenen Abtastzustand weiß der Beobachter beim Starten der aktuellen Abtastanforderung, dass die nächste Abtast-HF-Anforderung nach einem Abtastintervall ausgegeben wird. Es weiß auch, dass die aktuelle HF-Anforderung für einen Zeitraum eines Abtastfensters andauert.
Ein Protokoll nach IEEE 802.15.4 (z. B. ZigBee) kann als TDMA-System im GTS-Modus (Guaranteed Time Slot-Modus) oder im Direktzugriffsmodus betrieben werden. Wenn es nur im Direktzugriffsmodus betrieben wird, ist der Beginn einer ZigBee-HF-Anforderung nicht bekannt, aber die Dauer der aktuellen HF-Anforderung und die Dauer ihrer Dauer sind bekannt. Unter der Annahme einer Nutzlast von X (X <=127) Bytes kann die Gesamtübertragungszeit beispielsweise (8 (CCA)+ 12 (Präambel+ PHY header)+ X*2) Symbole betragen. Wenn eine Bestätigung erforderlich ist, werden zusätzliche 54 Symbole hinzugefügt, um die Bestätigung zu handhaben. Bei 2,4-GHz O-QPSK-Modulation beträgt ein Symbol 16 Mikrosekunden. Es kann eine weitere feste Verarbeitungszeit (wie z. B. Tx-Rx-Wenden) basierend auf dem Siliziumdesign hinzugefügt werden.
3 und 4 sind die Zeitdiagramme 300, 400, die einen Vergleich des Betriebs eines auf Prioritäten basierenden Funk-Arbiters (3) und eines auf Vorhersagbarkeit basierenden Funk-Arbiters (4) zeigen. In 3 ist eine aktive BLE-Verbindung mit einem festen Verbindungsintervall vorhanden. Das ZigBee-Modul versucht, ein Paket zu senden, das die Zeit t, beginnend bei T_A, andauert. Es gibt jedoch eine geplante BLE-Kommunikation bei T_B, wobei (T_B-T_A) < t ist. Wenn die Übertragung des ZigBee-Pakets bei T_A beginnt, kann das ZigBee-Paket mit der BLE-HF-Anforderung bei T_B kollidieren, weshalb das ZigBee-Paket die Übertragung aufgrund der Priorität der BLE-Kommunikation nicht beenden könnte. Daher kann die BLE-Anforderung die ZigBee-Übertragung unterbrechen und die BLE-Kommunikation bei T_B starten, wodurch die Tx-Energie zwischen T_A und T_B vergeudet und die Luftwege zwischen T_A und T_B ohne wesentlichen positiven Effekt belegt werden.
Unter Bezugnahme auf 4 ist der Funk-Arbiter konfiguriert, um bekannte Informationen über die Anforderungen zu nutzen, um vorherzusagen, dass ein Konflikt bei T_B bestehen könnte. Infolgedessen setzt der Funk-Arbiter die ZigBee-Übertragung, die sonst bei T_A begonnen hätte, bis nach dem Ende der geplanten BLE-Kommunikation bei Tc aus. Der Funk-Arbiter beginnt dann mit der Übertragung des ZigBee-Pakets bei T_D, wobei (T_D-T_C) je nach Siliziumdesign kurz sein kann. Darüber hinaus darf die Paket-Latenzzeit für die ZigBee-Kommunikation nicht erhöht werden.
Zusammenfassend kann der Funk-Arbiter konfiguriert sein: bei T_A, um vorherzusagen, ob die aktuelle ZigBee-Anforderung zukünftig mit der anhängigen HF-Anforderung bei T_B kollidieren wird; bei T_A, um die aktuelle Anforderung von ZigBee abzulehnen; bei T_B, um die BLE-Anforderung wie erwartet zu bedienen; und bei Tc, um die ZigBee-Anforderung zu starten, nachdem die BLE-Anforderung beendet wurde. Um eine solche Intelligenz und Vorhersagbarkeit zu ermöglichen, können zusätzlich zu den vorstehend definierten Eingaben an den Funk-Arbiter weitere Parameter durch den Funk-Arbiter verwendet werden: HF-Anforderungsart, die erwartete Dauer der aktuellen HF-Anforderung, die Zeit bis zur nächsten anhängigen HF-Anforderung und die Priorität der nächsten anhängigen HF-Anforderung. Wie vorstehend erörtert, kann die erwartete Dauer der aktuellen HF-Anforderung sowohl für BLE (fest) als auch für ZigBee (abhängig von der Größe der Übertragungspakete) vorhersehbar sein.
Da das BLE-Protokoll ein TDMA-Protokoll ist und seine HF-Aktivität in hohem Maße vorhersehbar ist, ist dem BLE-Modul die Zeit bis zur nächsten anstehenden HF-Anforderung bekannt, wenn es eine Anforderung für die aktuelle stellt. Wenn sich ZigBee im Direktzugriffsmodus befindet, ist die nächste anhängige HF-Anforderung unbekannt, daher kann der Funk-Arbiter 0 eingeben, um eine unbekannte anhängige Anforderung anzuzeigen. Die Vorhersagbarkeit des Zeitpunkts der nächsten Anforderung eines Protokolls kann ausreichen, um einen HF-Anforderungsbetrieb ohne Übertragungsunterbrechung zwischen zwei Protokollen zu ermöglichen.
Bei BLE-Betrieben für bestimmte Anwendungen (z. B. Streaming-Daten) können die HF-Anforderungen zur Übertragung von Daten unmittelbar nacheinander erfolgen. In dieser Situation kann die Priorität der ZigBee-Übertragung im Laufe der Zeit erhöht werden. Sobald die Priorität der ZigBee-Übertragung höher ist als die der nächsten anhängigen BLE-Anforderung, kann die nächste anhängige BLE-Anforderung möglicherweise nicht starten und den HF-Pfad für die ZigBee-Kommunikation offen lassen. Das BLE-Verbindungsereignis kann neu gestartet werden, nachdem die ZigBee-Kommunikation abgeschlossen ist. Die Entscheidung, zwischen BLE- und ZigBee-Übertragungen umzuschalten, wird nach Abschluss jedes HF-Anforderungsereignisses getroffen. Dadurch gibt es keine Unterbrechung einer laufenden HF-Anforderung und keine unvollständige Übertragung.
Damit der Funk-Arbiter in der Lage ist, anhängige HF-Anforderungsereignisse vorherzusagen und mit ihnen zu arbeiten, werden nachstehend mehrere Eingabeparameter definiert.
Die Nachricht „Funkzugriffsanforderung“ schließt eine Anforderung ein, den HF-Pfad zum Funk-Arbiter zu benutzen. Die Funk-Arbiter-Hardware kann bestimmen, ob und wann eine solche Anforderung genehmigt werden kann. Nachfolgend ist eine beispielhafte Liste von Eingabeparametern und deren Beschreibungen aufgeführt:

Die „Anforderungsart“ kann klassifiziert werden als eine neue Anforderung, eine Anforderungsaktualisierung einer laufenden HF-Anforderung (die z. B. zum Anhalten des HF-Betriebs oder zur Aktualisierung der Priorität und/oder Dauer für aktuelle HF-Anforderungsparameter führen kann) und eine Anforderungsaktualisierung einer laufenden HF-Anforderung (die z. B. zum Abbrechen der laufenden Anforderung, zur Aktualisierung der laufenden Anforderung und/oder zur Aktualisierung der nächsten anhängigen HF-Anforderungsparameter führen kann).
Die „Anforderungssteuerung“ kann bestimmte Feinsteuerungsparameter für die HF-Anforderung einschließen. Beispielsweise können je nach dem Anforderungssteuerungsparameter eines oder mehrere der folgenden Ergebnisse auftreten. In einigen Situationen kann die Priorität der aktuellen Anforderung bei jedem außerplanmäßigen Ereignis geändert (z. B. erhöht) werden, wenn der Anforderungsrückmeldungsstatus „im Wartezustand“ ist. Dies kann in erster Linie bei 802.15.4 HF-Anforderungen verwendet werden. In einigen Situationen kann die Priorität der nächsten anstehenden Anforderung geändert werden (z. B erhöht), wenn der Anforderungsrückmeldungsstatus „im Wartezustand“ ist. Dies kann in erster Linie bei BLE-HF-Anforderungen verwendet werden. In einigen Situationen kann eine aktuelle Anforderung entfernt werden, wenn kein HF-Zugriff gewährt wird. Dies kann in erster Linie für BLE-Anforderungen verwendet werden, da jede BLE-Anforderung eine strenge Zeitanforderung hat.
Die „Basispriorität der aktuellen HF-Anforderung“ kann eine definierte Prioritätsreihenfolge für HF-Anforderungen unterschiedlicher Art sein.
Die „Burst-Anforderung“ kann auf die Absicht der Burst-Modus-Definition hinweisen, um ein „Small Packet Radio Thrashing“ zu vermeiden. In einigen Ausführungsformen kann die Möglichkeit des „Radio Thrashings“ reduziert oder im Wesentlichen eliminiert werden.
Die „sofortige Markierung“ kann ein Parameter für IEEE 802.15.4 sein, um einen zufälligen Back-Off- und CSMA-CA-Mechanismus anzuzeigen. BLE kommuniziert an Ankerpunkten mit Verbindungsintervall. Beide Protokolle sind nicht als Echtzeitprotokolle konzipiert. Darüber hinaus kann eine sofortige Markierung als höchste Priorität behandelt werden, um eine Übertragung mit geringster Latenzzeit zu gewährleisten. Die Funktionalität dieser Markierung kann nach der Priorität der Anforderung behandelt werden.
Die „Zeit bis zur nächsten anhängigen HF-Anforderung“ kann von BLE-Anforderungen verwendet werden, da nachfolgende HF-Anforderungen für BLE vorhersehbar sind. Für 802.15.4 im Direktzugriffsmodus können HF-Anforderungen möglicherweise nicht vorhersehbar sein. Daher kann der Funk-Arbiter diesen Parameter für 802.15.4-Anfragen, die anzeigen, dass keine anhängige HF-Anforderung bekannt ist, auf Null setzen. Die Zeit bis zur nächsten HF-Anforderung kann vom Funk-Arbiter verfolgt werden und nimmt mit der Systemzeit ab.
Die „Priorität der nächsten anhängigen HF-Anforderung“ kann vom Funk-Arbiter verwendet werden, um zu entscheiden, ob die anhängige HF-Anforderung die 802.15.4-Übertragung zum Zeitpunkt T_A verhindern sollte (siehe z. B. 3, 4).
Die „Dauer der aktuellen HF-Anforderung“ kann vom Funk-Arbiter verwendet werden, um festzustellen, ob die aktuelle HF-Anforderung die nächste anhängige HF-Anforderung beeinträchtigt, und dann eine entsprechende Entscheidung zu treffen. Wenn dieser Wert auf Null gesetzt wird, kann dies auf eine unbekannte Dauer hindeuten, die zur Einleitung des Rx-Betriebs nach 802.15.4 verwendet werden kann. Dadurch wird sichergestellt, dass die 802.15.4 Rx-Betrieb ohne Berücksichtigung von Interferenzen sofort beginnen kann. Die Rx-Anforderung könnte mit einer neuen Dauer aktualisiert werden, sobald ein 802.15.4-Header empfangen wird.
Die „Funk-Arbiter-Feedback-Informationen“ können vom Funk-Arbiter verwendet werden, um einen reibungslosen Betrieb zwischen dem Funk-Arbiter und den Verbindungssteuerungen zu gewährleisten. Funk-Arbiter-Feedback-Informationen können in mindestens einer von zwei Situationen ausgegeben werden: 1) wenn auf eine „Funkzugriffsanforderung“ an den Anfordernden geantwortet wird, oder 2) wenn an eine der beiden Verbindungssteuerungen mit HF-Halteanforderung gesendet wird, nachdem ein HF-Betrieb abgeschlossen ist und der HF-Pfad wieder verfügbar ist.
Das Funk-Arbiter-Feedback kann entweder als Reaktion auf die HF-Anforderung den Zugang zum HF-Pfad gewähren oder den Zugang bis auf weiteres vorübergehend auf Eis legen. Beispiele für Parameter für die Rückmeldung des Funk-Arbiters sind nachstehend aufgeführt:
- Der „aktualisierte Status“ kann eine Boolesche Markierung einschließen, die anzeigt, ob die letzte HF-Anforderung gewährt wurde. Wenn der aktualisierte Status gewährt wird, kann der Funk-Arbiter den HF-Pfad für die anfordernde Verbindungssteuerung reservieren und der HF-Betrieb kann sofort beginnen. Wenn der Status auf Wartezustand steht, kann die jeweilige Verbindungssteuerung die HF-Anforderung aktualisieren, z. B. durch Erhöhung ihrer Prioritätsstufe und Änderung der nächsten anhängigen HF-Anforderungsdaten.
- Die „aktuelle HF-Priorität“ kann die Prioritätsstufe des HF-Ereignisses einschließen, die verhindert, dass die letzte HF-Anforderung gewährt wird. Diese Prioritätsstufe kann entweder der aktuelle laufende HF-Betrieb oder die nächste anhängige HF-Anforderung sein. Basierend auf dieser Prioritätsstufe und der aktualisierten lokalen Prioritätsstufe kann das lokale Protokollmodul bestimmen, ob die HF-Anforderung im Wartezustand mit einer höheren Priorität aktualisiert werden soll. Dieser Parameter darf keinen Einfluss darauf haben, ob der Aktualisierungsstatus „gewährt“ ist.

5 ist ein Zeitdiagramm 500, das eine maximale Übertragungsverzögerung eines auf Vorhersagen basierenden Arbitrierungsereignisses gemäß einer Ausführungsform der Offenbarung zeigt. Das Szenario von 5 ist das gleiche wie das vorstehend in Bezug auf 4 beschriebene, zeigt aber jetzt die maximale Übertragungszeit, die als Differenz zwischen T_D und T_A definiert ist. In einigen Ausführungsformen kann die ZigBee-Übertragung eine maximale Verzögerung der Übertragungszeit plus zwei BLE-Zeitfenster plus Silizium-Wechselzeit aufweisen. In einem Beispielszenario für die Übertragung eines 127-Byte-Pakets mit Quittung beträgt die maximale Verzögerung etwa 6,5 Millisekunden plus Silizium-Verarbeitungszeit. Andererseits ist das IEEE-802.15.4-Protokoll nicht als Echtzeit-Kommunikationsmechanismus mit niedriger Latenz ausgelegt. Vielmehr gilt sie als erfolgreiche Übertragung mit einer Latenzzeit von bis zu 23,95 Millisekunden bei maximalen CCA-Wiederholungen und Neuübertragungen. Als Vergleich ist die maximale Übertragungsverzögerung von ca. 6,5 Millisekunden unter den meisten Umständen tolerierbar.
Die BLE-Übertragung könnte eine maximale Verzögerung aufweisen, die durch das Verbindungsintervall im verbundenen Zustand bestimmt wird. Beim Design der BLE-Spezifikation kann das Fehlen eines Verbindungsereignisses tolerierbar sein, und die Spezifikation definiert mehrere Möglichkeiten zur Neusynchronisierung der Verbindung. Daher sollte die maximale Verzögerung bei BLE in den meisten Situationen kein Problem darstellen.
6 ist ein Zeitdiagramm 600, das einen Betrieb des Funk-Arbiters ohne vorhergesagte Kollision gemäß einer Ausführungsform der Offenbarung zeigt. Der Funk-Arbiter empfängt eine HF-Anforderung für die BLE-Verbindungssteuerung (d. h. er erhält eine Nachricht „Funkzugriffsanforderung“) und stellt fest, dass kein Konflikt mit der ZigBee-Verbindungssteuerung vorhergesagt wird. Dadurch kann der Funk-Arbiter die HF-Anforderung gewähren (d. h. eine Nachricht „Funkzugriffs-Feedback“ senden). Die BLE-Verbindungssteuerung kann dann den HF-Betrieb starten. Nach Abschluss der BLE-Übertragung empfängt der Funk-Arbiter eine HF-Anforderung für die ZigBee-Verbindungssteuerung (d. h. er erhält eine Nachricht „Funkzugriffsanforderung“) und stellt fest, dass kein Konflikt mit der HF-Verbindungssteuerung vorhergesagt wird. Dadurch kann der Funk-Arbiter die HF-Anforderung gewähren (d. h. eine Nachricht „Funkzugriffs-Feedback“ senden). Die ZigBee-Verbindungssteuerung kann dann den HF-Betrieb starten.
7 ist ein Zeitdiagramm 700, das einen Betrieb des Funk-Arbiters mit einer vorhergesagten Senderkollision gemäß einer Ausführungsform der Offenbarung zeigt. In diesem Beispiel hat die BLE-Kommunikation für den Funk-Arbiter Priorität. In dieser Situation, wenn die ZigBee-Verbindungssteuerung eine HF-Anforderung (d. h. die Nachricht „Funkzugriffsanforderung“) an T_A sendet, prognostiziert der Funk-Arbiter, dass es bei T_B zu einer Kollision kommen wird. Diese Vorhersage kann auf den Eingabeparametern „Aktuelle Dauer der HF-Anforderung“ und „Nächste anhängige HF-Anforderungszeit“ basieren, die in einer vorherigen BLE-Anforderung empfangen wurden. Da der BLE-Betrieb eine höhere Priorität hat, gewährt der Funk-Arbiter die HF-Anforderung nicht. Vielmehr setzt der Funk-Arbiter die ZigBee-Übertragung aus, indem er mit „Funkzugriffs-Feedback“ mit dem Status „im Wartezustand“ antwortet. Der Funk-Arbiter wartet, bis das Ende des anhängigen HF-Betriebs mit höherer Priorität bei Tc, abgeschlossen ist, und sendet dann eine Nachricht „Funkzugriffs-Feedback“ an die ZigBee-Verbindungssteuerung mit dem Status „gewährt“. Die nächste anhängige HF-Anforderung kann eine geplante BLE-Anforderung bei T_D sein, bei der kein Konflikt mit der ZigBee-Übertragung vorhergesagt wird.
8 ist ein Zeitdiagramm 800, das einen Betrieb des Funk-Arbiters mit einer vorhergesagten Senderkollision gemäß einer Ausführungsform der Offenbarung zeigt. In diesem Beispiel hat die ZigBee-Kommunikation für den Funk-Arbiter Priorität. In dieser Situation empfängt der Funk-Arbiter bei T_A eine HF-Anforderung (d. h. die Nachricht „Funkzugriffsanforderung“) von der ZigBee-Verbindungssteuerung. Der Funk-Arbiter bestimmt eine Kollision bei T_B. Da die ZigBee-Kommunikation eine höhere Priorität als die nächste anhängige HF-Anforderung bei T_B hat, wird der HF-Zugriff gewährt (d. h. die Nachricht „Funkzugriffs-Feedback“ wird mit dem Aktualisierungsstatus „gewährt“ zurückgegeben). Zum Zeitpunkt T_B sendet BLE die HF-Anforderung an den Funk-Arbiter. Da die BLE-Kommunikation eine niedrigere Priorität hat, hält der Funk-Arbiter die BLE-HF-Anforderung zurück. Da der BLE-Betrieb zeitliche Anforderungen hat, wird die aktuelle HF-Anforderung von BLE annulliert und die nächste anhängige HF-Anforderung von BLE kann optional die Prioritätsstufe relativ zur anderen Prioritätsstufe erhöhen. Eine höhere Priorität bei den nachfolgenden BLE-HF-Anforderungen kann dazu beitragen, zu verhindern, dass die ZigBee-Kommunikation den HF-Pfad auf unbestimmte Zeit belegt. Natürlich ist die Erhöhung der Priorität relativ zur anderen Prioritätsstufe zu verstehen. Beispielsweise kann in einigen Ausführungsformen die Prioritätsstufe der einen Art von HF-Anforderung erhöht werden, während in anderen Ausführungsformen die Prioritätsstufe der anderen Art von HF-Anforderung verringert werden kann. Einige Ausführungsformen können die Erhöhung der Priorität einer Art von HF-Anforderung bei gleichzeitiger Verringerung der Priorität der anderen Art von HF-Anforderung einschließen. Andere Verfahren zur Unterbrechung des Daten-Streamings nach Ablauf einer vorbestimmten Zeitspanne ohne Bedienung der ersten HF-Anforderung werden ebenfalls in Betracht gezogen, wie z. B. die Integration eines Zeitgebers, der eine Zeitspanne verfolgt, während der eine HF-Anforderung im Wartezustand ist, und die Unterbrechung des Daten-Streamings, wenn ein vorbestimmter Schwellenwert erreicht wurde.
9 ist ein Zeitdiagramm 900, das einen Betrieb des Funk-Arbiters mit einer vorhergesagten Senderkollision gemäß einer Ausführungsform der Offenbarung zeigt. In diesem Beispiel hat die BLE-Kommunikation Priorität für den Funk-Arbiter, wobei sich die Priorität für die ZigBee-Kommunikation erhöht, nachdem sie beim Daten-Streaming im Wartezustand ist. Ursprünglich hat die HF-Anforderung von der ZigBee-Verbindungssteuerung eine niedrigere Priorität und wird in einen Wartezustand versetzt, während die BLE-Verbindungssteuerung Daten streamt. Immer wenn ein HF-Betrieb bei T_B, Tc und T_D für die BLE-Kommunikation abgeschlossen ist, kann der Funk-Arbiter die Priorität der HF-Wartezustandsanforderung für die ZigBee-Kommunikation erhöhen, bis die HF-Wartezustandsanforderung eine höhere Priorität hat. Bei T_D ist die Wartezustands-HF-Anforderung für ZigBee-Kommunikation so weit angestiegen, dass sie über die Priorität der laufenden HF-Anforderung für BLE-Streaming von Daten hinausgeht. Der Funk-Arbiter sendet eine Nachricht „Funkzugriffs-Feedback“ mit dem Status „gewährt“ an die ZigBee-Verbindungssteuerung, die dann mit der Datenübertragung beginnt. Wenn die nächste Streaming-HF-Anforderung von der BLE-Verbindungssteuerung an T_E ausgegeben wird, kann der Funk-Arbiter die BLE-Kommunikation in einen Wartezustand versetzen. Das BLE-Daten-Streaming kann nach dem Verbindungsintervall bei T_F neu gestartet werden, wenn die ZigBee-Kommunikation abgeschlossen ist, oder wenn die Priorität der BLE-Wartezustand-Kommunikation erhöht wird, falls die ZigBee-Kommunikation nicht rechtzeitig abgeschlossen wird.
10 und 11 sind Zeitdiagramme 1000, 1100, die einen Betrieb des Funk-Arbiters mit einer vorhergesagten Empfängerkollision mit verschiedenen Prioritätseinstufungen gemäß Ausführungsformen der Offenbarung zeigen. Wie vorstehend erörtert, verhindert die Vorhersehbarkeit des Funk-Arbiters eine Kollision der Tx-Betriebe zwischen BLE- und ZigBee-Kommunikationen. Bei empfangenen Daten können die Kollisionen jedoch möglicherweise nicht vollständig verhindert werden, da die Übertragung dieser Daten nicht die Kontrolle über das drahtlose Subsystem hat, das die Daten empfängt. Dennoch kann der Empfang von Daten über BLE-Kommunikationen ähnlich wie im Übertragungsmodus gehandhabt werden, da BLE-Anforderungen zwischen zwei Vorrichtungen genau terminiert werden. Andererseits kann aufgrund der Tatsache, dass die ZigBee-Kommunikation im Direktzugriffsmodus arbeiten kann, der Zeitpunkt, zu dem der Peer eine Nachricht sendet, unbekannt sein. Daher ist eine Vorausplanung der ZigBee-Kommunikation in vielen Fällen nicht möglich.
Um in den Empfangsmodus überzugehen, kann der Funk-Arbiter eine HF-Anforderung empfangen. Die HF-Anforderung kann den Parameter „Dauer für aktuelle HF-Anforderung“ einschließen, der entweder spezifiziert ist, wenn die Empfangsbetriebszeit bekannt ist, oder der Parameter kann unspezifiziert (häufiger) sein. Sobald jedoch die 802.15.4-Header eines Pakets empfangen werden, können dem Funk-Arbiter folgende Informationen bekannt sein: 1) die Paketlänge ist aus dem PDU-Header bekannt, 2) die Adresse ist aus dem MAC-Header bekannt, um zu entscheiden, ob die lokale Vorrichtung der bestimmte Empfänger ist, und 3) ob eine Bestätigung durch den MAC-Header erforderlich ist. Basierend auf diesen Informationen kann die gesamte verbleibende Zeitdauer bestimmt werden, die im Empfangsmodus verbleibt, um das Paket zu empfangen und optional zu bestätigen. Der Funk-Arbiter kann dann eine Aktualisierung der aktuellen Rx-Anforderung mit höherer Priorität senden. Mit den neuen Informationen vergleicht der Funk-Arbiter die Dauer mit der nächsten anhängigen HF-Anforderung von der BLE-Verbindungssteuerung. Wenn eine Kollision vorhergesagt wird, bestimmt der Funk-Arbiter dann, ob der ZigBee-Empfangsbetrieb eine höhere Priorität haben wird, wenn die nächste anstehende HF-Anforderung von BLE ausgegeben wird, dann wird das drahtlose Subsystem weiter im ZigBee-Empfangsmodus arbeiten. Wenn eine BLE-HF-Anforderung empfangen wird, kann die BLE-HF-Anforderung in einen Wartezustand versetzt werden. Wenn der Funk-Arbiter bestimmt, dass der ZigBee-Empfangsbetrieb eine niedrigere Priorität hat, wenn die nächste anhängige HF-Anforderung von BLE ausgegeben wird, sendet der Funk-Arbiter die Nachricht „Funkzugriffs-Feedback“ an die ZigBee-Verbindungssteuerung, um den Betrieb im Empfangsmodus zu beenden und in den Ruhemodus überzugehen.
Da die gesamte Empfangszeit für ein ZigBee-Paket bekannt sein kann, nachdem der MAC-Header empfangen und geparst wurde, kann eine Prioritätserhöhung gemäß der Menge der empfangenen Daten zugewiesen werden. Beispielsweise kann eine Priorität für jeweils 20 % oder 10 % des empfangenen Pakets um eine Stufe erhöht werden. Daher kann es einfacher sein, den Empfang eines ZigBee-Pakets zu einem frühen Zeitpunkt einzustellen, wenn nur wenige Ressourcen verbraucht wurden, aber schwieriger, zu einem späten Zeitpunkt einzustellen, wenn viele Ressourcen verbraucht wurden, die neu gestartet werden müssten. Für den gesamten vollständigen ZigBee-Paketempfangsprozess kann der Funk-Arbiter konfiguriert sein, um jederzeit die Priorität vorherzusagen und entsprechend zu entscheiden.
10 ist ein Zeitdiagramm 1000, das einen Betrieb des Funk-Arbiters mit einer vorhergesagten Empfängerkollision gemäß einer Ausführungsform der Offenbarung zeigt. In diesem Beispiel hat die ZigBee-Kommunikation für den Funk-Arbiter Priorität gegenüber der BLE-Kommunikation. Bei T_A sendet die ZigBee-Verbindungssteuerung eine Anforderung zur Ausführung des Rx-Betriebs und sie wird gewährt. Bei T_B werden der Oberbegriff, SDF und die Header eines Pakets von der ZigBee-Verbindungssteuerung empfangen. Die empfangenen Informationen zeigen an, dass die lokale Vorrichtung der beabsichtigte Empfänger ist, sowie die Gesamtlänge und die Bestätigungsanforderung für das empfangene Paket. Zu diesem Zeitpunkt kann die verbleibende Zeit zum Empfangen des vollständigen Pakets bekannt sein. Eine Nachricht „Funkzugriffsanforderung“ kann dann an den Funk-Arbiter gesendet werden, um den aktuellen laufenden ZigBee-Rx-Betrieb mit höherer Priorität und seiner erwarteten Dauer zu aktualisieren. Basierend auf der voraussichtlichen Dauer sagt der Funk-Arbiter voraus (z. B. berechnet er), dass bei Tc, wenn die nächste anhängige BLE-HF-Anforderung geplant ist, der ZigBee-Rx-Betrieb eine höhere Priorität als der geplante BLE-Betrieb haben wird. Daher kann der ZigBee Rx-Betrieb fortgesetzt werden. Das BLE-Verbindungsereignis kann bei Tc in einen Wartezustand versetzt werden. Nachdem der Rx-Betrieb des ZigBee-Pakets abgeschlossen ist, kann eine neue HF-Anforderung für den Rx-Modus für ZigBee-Kommunikation bei T_D empfangen werden. In einigen Ausführungsformen können die neuen ZigBee-Kommunikationen eine niedrigere Priorität als die BL-Kommunikation aufweisen (z. B. BL-Priorität kann seit der letzten Anforderung erhöht worden sein). Daher kann der Funk-Arbiter die ZigBee-Kommunikation zugunsten einer BLE HF-Anforderung höherer Priorität bei T_E unterbrechen und in einen Wartezustand versetzen. Somit kann der Funk-Arbiter die ZigBee-Kommunikation aufgrund der vorhergesagten Kollision, die anhand der Anfangsparameter der verschiedenen HF-Anforderungen bestimmt wird, nicht gemäß seinen Anfangsparametern bedienen.
11 ist ein Zeitdiagramm 1100, das einen Betrieb des Funk-Arbiters mit einer vorhergesagten Empfängerkollision gemäß einer Ausführungsform der Offenbarung zeigt. In diesem Beispiel hat die BLE-Kommunikation für den Funk-Arbiter Priorität. Bei T_A empfängt der Funk-Arbiter eine HF-Anforderung, den ZigBee-Rx-Betrieb auszuführen, und die Anforderung wird gewährt. Bei T_B werden der Oberbegriff, SDF und die Header eines Pakets von der ZigBee-Verbindungssteuerung empfangen. Die empfangenen Informationen zeigen an, dass die lokale Vorrichtung der beabsichtigte Empfänger ist, sowie die Gesamtpaketlänge und die Bestätigungsanforderung für das empfangene Paket. Zu dieser Zeit kann die verbleibende Zeit zum Empfangen des vollständigen Pakets bekannt sein. Eine Nachricht „Funkzugriffsanforderung“ kann dann an den Funk-Arbiter gesendet werden, um den aktuellen laufenden Rx-Betrieb mit höherer Priorität und erwarteter Dauer zu aktualisieren. Basierend auf der Dauer bestimmt (z. B. berechnet) der Funk-Arbiter, dass bei Tc der ZigBee-Rx-Betrieb eine niedrigere Priorität hat als die nächste geplante BLE-Anforderung. Wenn also der Rx-Betrieb fortgesetzt wird, würde die ZigBee-Kommunikation durch die geplante BLE-Anforderung unterbrochen werden. Da die ZigBee-Kommunikation eine niedrigere Priorität hat, kann der Funk-Arbiter einen Parameter „Funkzugriffs-Feedback“ mit einem Status „im Wartezustand“ senden, um die ZigBee-Verbindungssteuerung in den Ruhemodus zu versetzen. Wie erwartet, gibt die BLE-Verbindungssteuerung bei Tc die HF-Anforderung aus und gewährt den Zugriff. Am Ende der BLE-Kommunikation bei T_D sendet der Funk-Arbiter eine Nachricht „Funkzugriffs-Feedback“ an die ZigBee-Verbindungssteuerung, um den allgemeinen Rx-Betrieb fortzusetzen.
Zusätzliche nicht einschränkende Ausführungsformen schließen ein:

Ausführungsform 1. Funk-Arbiter, umfassend: einen Prozessor; und ein computerlesbares Medium, das darauf gespeicherte Anweisungen einschließt, die, wenn sie durch den Prozessor ausgeführt werden, den Prozessor veranlassen zum: Empfangen einer ersten HF-Anforderung, die einem ersten drahtlosen Protokoll zugeordnet ist;
Empfangen einer zweiten HF-Anforderung, die einem zweiten drahtlosen Protokoll zugeordnet ist; und Versetzen der ersten HF-Anforderung in einen Wartezustand, bis die zweite HF-Anforderung basierend auf einer prädiktiven Arbitrierungsentscheidung abgeschlossen ist, bevor die zweite HF-Anforderung empfangen wird.
Ausführungsform 2. Funk-Arbiter nach Ausführungsform 1, wobei das erste drahtlose Protokoll und das zweite drahtlose Protokoll mindestens eines von Bluetooth Low Energy, ZigBee oder WiFi einschließen.
Ausführungsform 3. Funk-Arbiter nach Ausführungsform 1, wobei die Anweisungen, wenn sie von dem Prozessor ausgeführt werden, den Prozessor veranlassen, die erste HF-Anforderung in einen Wartezustand zu versetzen, indem er die erste HF-Anforderung auf eine Weise bedient, die sich von ihren Ausgangsparametern unterscheidet.
Ausführungsform 4. Funk-Arbiter nach Ausführungsform 3, wobei die Anweisungen, wenn sie von dem Prozessor ausgeführt werden, den Prozessor veranlassen, die zweite HF-Anforderung gemäß seinen Ausgangsparametern zu bedienen.
Ausführungsform 5. Funk-Arbiter nach Ausführungsform 1, wobei die Anweisungen, wenn sie von dem Prozessor ausgeführt werden, den Prozessor ferner veranlassen zum: Empfangen der ersten HF-Anforderung; Bestimmen, dass die erste HF-Anforderung mit der zweiten HF-Anforderung gemäß den Ausgangsparametern entweder der ersten HF-Anforderung oder der zweiten HF-Anforderung kollidiert; und Beginnen der Bedienung der ersten HF-Anforderung, nachdem die Bedienung der zweiten HF-Anforderung beendet wurde.
Ausführungsform 6. Funk-Arbiter nach Ausführungsform 5, wobei die Ausgangsparameter mindestens eines von einer HF-Anforderungsart, einer erwarteten Dauer der HF-Anforderung, einer Anforderungspriorität, einer Zeitdauer bis zur nächsten HF-Anforderung oder einer Kombination davon einschließen.
Ausführungsform 7. Funk-Arbiter nach Ausführungsform 6, wobei die erwartete Dauer der ersten HF-Anforderung von einer Größe von Sendepaketen abhängt und die erwartete Dauer der zweiten HF-Anforderung festgelegt ist.
Ausführungsform 8. Elektronisches System, umfassend: ein drahtloses Subsystem, einschließlich: ein Funkmodul; eine Vielzahl von Verbindungssteuerungen, die gemäß zwei oder mehr verschiedenen Topologien konfiguriert sind; einen Funk-Arbiter, der konfiguriert ist zum: Senden und Empfangen von Daten zwischen dem Funkmodul und der Vielzahl von Verbindungssteuerungen; und Versetzen einer ersten HF-Anforderung in einen Wartezustand, bis eine zweite HF-Anforderung basierend auf einer prädiktiven Arbitrierungsentscheidung abgeschlossen ist, bevor die zweite HF-Anforderung empfangen wird.
Ausführungsform 9. Elektronisches System nach Ausführungsform 8, wobei die Vielzahl von verschiedenen Topologien eine erste Topologie und eine zweite Topologie einschließt, die Topologien mit niedriger Leistung und niedriger Topologie sind.
Ausführungsform 10. Elektronisches System nach Ausführungsform 9, wobei die erste Topologie Bluetooth Low Energy ist und die zweite Topologie konfiguriert ist, gemäß dem technischen Standard 802.15.4 zu arbeiten.
Ausführungsform 11. Elektronisches System nach Ausführungsform 9, wobei die zweite Topologie aus der Gruppe bestehend aus ZigBee, ISA100.11a, WirelessHART, WiWi, SNAP und Threadspezifikationen ausgewählt ist.
Ausführungsform 12. Elektronisches System nach Ausführungsform 8, wobei die mindestens eine der zwei oder mehr verschiedenen Topologien WiFi einschließt.
Ausführungsform 13. Elektronisches System nach Ausführungsform 8, wobei das elektronische System eine Vorrichtung einschließt, die das drahtlose Subsystem einschließt, das aus der Gruppe bestehend aus einer Hausautomatisierungsvorrichtung, einer medizinischen Vorrichtung, einem Smartphone, einer Spielkonsole, einem PC, einem Laptop, einem Tablet-Computer, einer Vorrichtung in Kraftfahrzeugen, einem Audiosystem, einem Videosystem und einer Peripherievorrichtung ausgewählt ist.
Ausführungsform 14. Verfahren zur drahtlosen Kommunikation, das Verfahren umfassend: Empfangen einer ersten HF-Anforderung durch ein Funkmodul mit einer ersten Priorität; Empfangen einer zweiten HF-Anforderung durch das Funkmodul mit einer zweiten Priorität, die höher als die erste Priorität ist; und Versetzen der ersten HF-Anforderung in einen Wartezustand als Reaktion auf das Bestimmen, dass das Gewähren der ersten HF-Anforderung zu einer Kollision mit der zweiten HF-Anforderung führen würde. Ausführungsform 15. Verfahren nach Ausführungsform 14, ferner umfassend das Erhöhen der ersten Priorität auf eine höhere Priorität als die zweite Priorität während des Datenstreamings, das der zweiten HF-Anforderung zugeordnet ist.
Ausführungsform 16. Verfahren nach Ausführungsform 14, wobei das Versetzen der ersten HF-Anforderung in einen Wartezustand das Überspringen der ersten HF-Anforderung einschließt.
Ausführungsform 17. Verfahren nach Ausführungsform 14, ferner umfassend das Erhöhen einer Prioritätsstufe der ersten Priorität relativ zu der zweiten Priorität, während die erste HF-Anforderung für einen vorbestimmten Zeitraum in einen Wartezustand versetzt wurde.
Ausführungsform 18. Verfahren nach Ausführungsform 17, wobei das Erhöhen der Prioritätsstufe der ersten Priorität relativ zu der zweiten Priorität periodisch durchgeführt wird, bis die erste Priorität größer als die zweite Priorität ist.
Ausführungsform 19. Verfahren nach Ausführungsform 18, ferner umfassend das Bedienen der ersten Prioritätsanforderung als Reaktion darauf, dass die erste Priorität eine Prioritätsstufe erreicht, die größer als die zweite Priorität ist.
Ausführungsform 20. Verfahren nach Ausführungsform 14, ferner umfassend das Unterbrechen von Datenstreaming gemäß der zweiten HF-Anforderung als Reaktion darauf, dass ein vorbestimmter Zeitraum abläuft, ohne dass die erste HF-Anforderung bedient wird.
Ausführungsform 21. Verfahren nach Ausführungsform 14, ferner umfassend: Empfangen einer dritten HF-Anforderung durch ein Funkmodul mit einer dritten Priorität, die eine höhere Priorität als die erste Priorität und die zweite Priorität aufweist; und Versetzen der ersten HF-Anforderung und/oder der zweiten HF-Anforderung in einen Wartezustand als Reaktion auf das Bestimmen, dass das Gewähren der ersten HF-Anforderung und/oder der zweiten HF-Anforderung zu einer Kollision der dritten HF-Anforderung mit der ersten HF-Anforderung und/oder der zweiten HF-Anforderung führen würde.
Ausführungsform 22. Verfahren zum Planen von Kommunikation, die mindestens zwei Drahtlosprotokolltypen beinhaltet, das Verfahren umfassend: Empfangen einer ersten HF-Anforderung einer ersten Art und einer zweiten HF-Anforderung einer zweiten Art; Vorhersagen einer Kollision zwischen der ersten HF-Anforderung und der zweiten HF-Anforderung basierend auf einem oder mehreren Parametern der Anforderungen; Planen der Gewährung der ersten HF-Anforderung und der zweiten HF-Anforderung basierend auf einer Prioritätsstufe, um die vorhergesagte Kollision zu vermeiden.
Ausführungsform 23. Verfahren nach Ausführungsform 22, ferner umfassend das Anpassen der Prioritätsstufen der verschiedenen Arten von HF-Anforderungen.
Ausführungsform 24. Verfahren nach Ausführungsform 23, wobei das Anpassen der Prioritätsstufen der verschiedenen Arten von HF-Anforderungen das Erhöhen der Prioritätsstufe der ersten Art von HF-Anforderung einschließt.
Ausführungsform 25. Verfahren nach Ausführungsform 23, wobei das Anpassen der Prioritätsstufen der verschiedenen Arten von HF-Anforderungen das Verringern der Prioritätsstufe der ersten Art von HF-Anforderung einschließt.
Ausführungsform 26. Verfahren nach Ausführungsform 23, wobei das Anpassen der Prioritätsstufen der verschiedenen Arten von HF-Anforderungen das Erhöhen der Prioritätsstufe der zweiten Art von HF-Anforderung einschließt.
Ausführungsform 27. Verfahren nach Ausführungsform 23, wobei das Anpassen der Prioritätsstufen der verschiedenen Arten von HF-Anforderungen das Verringern der Prioritätsstufe der zweiten Art von HF-Anforderung einschließt.
Ausführungsform 28. Verfahren nach Ausführungsform 23, wobei das Anpassen der Prioritätsstufen der verschiedenen Arten von HF-Anforderungen das Erhöhen der Prioritätsstufe der ersten Art von HF-Anforderung und das Verringern der Prioritätsstufe der zweiten Art von HF-Anforderung einschließt.
Ausführungsform 29. Verfahren nach Ausführungsform 23, wobei mindestens eine der ersten Art von HF-Anforderung oder der zweiten Art von HF-Anforderung eine Bluetooth-Anforderung ist.
Ausführungsform 30. Verfahren nach Ausführungsform 29, wobei die Bluetooth-Anforderung eine Bluetooth Low Energy-Anforderung (BLE-Anforderung) ist.
Ausführungsform 31. Verfahren nach Ausführungsform 23, wobei mindestens eine der ersten Art von HF-Anforderung oder der zweiten Art von HF-Anforderung eine ZigBee-Anforderung ist.
Ausführungsform 32. Verfahren nach Ausführungsform 23, wobei mindestens eine der ersten Art von HF-Anforderung oder der zweiten Art von HF-Anforderung eine WiFi-Anforderung ist.
Ausführungsform 33. Verfahren nach Ausführungsform 23, wobei mindestens eine der ersten Art von HF-Anforderung oder der zweiten Art von HF-Anforderung eine WiFi-Anforderung ist.
Ausführungsform 34. Planer zum Lösen eines Konflikts zwischen HF-Anforderungen an eine Kommunikationsvorrichtung, wobei der Planer konfiguriert ist zum: Empfangen einer ersten HF-Anforderung einer ersten Art und einer zweiten HF-Anforderung einer zweiten Art; Vorhersagen einer Kollision zwischen der ersten HF-Anforderung und der zweiten HF-Anforderung basierend auf einem oder mehreren Parametern der Anforderungen; Planen der Gewährung der ersten HF-Anforderung und der zweiten HF-Anforderung basierend auf einer Prioritätsstufe, um die vorhergesagte Kollision zu vermeiden.
Ausführungsform 35. Planer nach Ausführungsform 34, ferner umfassend einen Funk-Arbiter, der konfiguriert ist, um die erste HF-Anforderung und die zweite HF-Anforderung zu empfangen und die Vorhersage durchzuführen.
Ausführungsform 36. Planer nach Ausführungsform 34, wobei der eine oder die mehreren Parameter eine erwartete Dauer der Bedienung der ersten HF-Anforderung und der zweiten HF-Anforderung einschließen.
Ausführungsform 37. Planer nach Ausführungsform 34, wobei der eine oder die mehreren Parameter mindestens eines von einer HF-Anforderungsart, einer erwarteten Dauer einer aktuellen HF-Anforderung, einer Zeit bis zur nächsten anhängigen HF-Anforderung, einer Priorität der nächsten anhängigen HF-Anforderung oder einer beliebigen Kombination davon einschließen.
Ausführungsform 38. Planer nach Ausführungsform 34, wobei die erwartete Dauer der aktuellen HF-Anforderung eine festgelegte Dauer ist.
Ausführungsform 39. Planer nach Ausführungsform 34, wobei die erwartete Dauer der aktuellen HF-Anforderung eine variable Dauer ist.
Ausführungsform 40. Planer nach Ausführungsform 39, wobei die variable Dauer von einer Größe von Sendepaketen abhängig ist.

Während bestimmte veranschaulichende Ausführungsformen in Verbindung mit den Figuren beschrieben wurden, wird ein Durchschnittsfachmann erkennen und anerkennen, dass der Umfang dieser Offenbarung nicht auf die Ausführungsformen beschränkt ist, die in dieser Offenbarung explizit gezeigt und beschrieben sind. Vielmehr können viele Ergänzungen, Streichungen und Modifikationen an den in dieser Offenbarung beschriebenen Ausführungsformen vorgenommen werden, um Ausführungsformen innerhalb des Umfangs dieser Offenbarung zu erzeugen, wie diejenigen, die speziell beansprucht werden, einschließlich gesetzlicher Äquivalente. Zusätzlich können Merkmale einer offenbarten Ausführungsform mit Merkmalen einer anderen offenbarten Ausführungsform kombiniert werden, während sie immer noch im Umfang dieser Offenbarung liegen, wie er von den Erfindern in Betracht gezogen wird.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 62/664828 [0001]
US 16/037599 [0001]

Claims

Funk-Arbiter, umfassend: einen Prozessor; und ein computerlesbares Medium, das darauf gespeicherte Anweisungen einschließt, die, wenn sie durch den Prozessor ausgeführt werden, den Prozessor veranlassen zum: Empfangen einer ersten HF-Anforderung, die einem ersten drahtlosen Protokoll zugeordnet ist; Empfangen einer zweiten HF-Anforderung, die einem zweiten drahtlosen Protokoll zugeordnet ist; und Versetzen der ersten HF-Anforderung in einen Wartezustand, bis die zweite HF-Anforderung basierend auf einer prädiktiven Arbitrierungsentscheidung abgeschlossen ist, bevor die zweite HF-Anforderung empfangen wird.
Funk-Arbiter nach Anspruch 1, wobei das erste drahtlose Protokoll und das zweite drahtlose Protokoll mindestens eines von Bluetooth Low Energy, ZigBee oder WiFi einschließen.
Funk-Arbiter nach Anspruch 1, wobei die Anweisungen, wenn sie von dem Prozessor ausgeführt werden, den Prozessor veranlassen, die erste HF-Anforderung in einen Wartezustand zu versetzen, indem er die erste HF-Anforderung auf eine Weise bedient, die sich von ihren Ausgangsparametern unterscheidet.
Funk-Arbiter nach Anspruch 3, wobei die Anweisungen, wenn sie von dem Prozessor ausgeführt werden, den Prozessor veranlassen, die zweite HF-Anforderung gemäß seinen Ausgangsparametern zu bedienen.
Funk-Arbiter nach Anspruch 1, wobei die Anweisungen, wenn sie durch den Prozessor ausgeführt werden, den Prozessor ferner veranlassen zum: Empfangen der ersten HF-Anforderung; Bestimmen, dass die erste HF-Anforderung mit der zweiten HF-Anforderung gemäß den Ausgangsparametern entweder der ersten HF-Anforderung oder der zweiten HF-Anforderung kollidiert; und Beginnen, die erste HF-Anforderung zu bedienen, nachdem die Bedienung der zweiten HF-Anforderung beendet wurde.
Funk-Arbiter nach Anspruch 5, wobei die Ausgangsparameter mindestens eines von einer HF-Anforderungsart, einer erwarteten Dauer der HF-Anforderung, einer Anforderungspriorität, einer Zeitdauer bis zur nächsten HF-Anforderung oder einer Kombination davon einschließen.
Funk-Arbiter nach Anspruch 6, wobei die erwartete Dauer der ersten HF-Anforderung von einer Größe von Sendepaketen abhängt und die erwartete Dauer der zweiten HF-Anforderung festgelegt ist.
Elektronisches System, umfassend: ein drahtloses Subsystem, einschließlich: ein Funkmodul; eine Vielzahl von Verbindungssteuerungen, die gemäß zwei oder mehr verschiedenen Topologien konfiguriert sind; und ein Funk-Arbiter, der konfiguriert ist zum: Senden und Empfangen von Daten zwischen dem Funkmodul und der Vielzahl von Verbindungssteuerungen; und Versetzen einer ersten HF-Anforderung in einen Wartezustand, bis eine zweite HF-Anforderung basierend auf einer prädiktiven Arbitrierungsentscheidung abgeschlossen ist, bevor die zweite HF-Anforderung empfangen wird.
Elektronisches System nach Anspruch 8, wobei die Vielzahl von verschiedenen Topologien eine erste Topologie und eine zweite Topologie einschließt, die Topologien mit niedriger Leistung und niedriger Topologie sind.
Elektronisches System nach Anspruch 9, wobei die erste Topologie Bluetooth Low Energy ist und die zweite Topologie konfiguriert ist, gemäß dem technischen Standard 802.15.4 zu arbeiten.
Elektronisches System nach Anspruch 9, wobei die zweite Topologie aus der Gruppe bestehend aus ZigBee, ISA100.11a, WirelessHART, WiWi, SNAP und Threadspezifikationen ausgewählt ist.
Elektronisches System nach Anspruch 8, wobei die mindestens eine der zwei oder mehr verschiedenen Topologien WiFi einschließt.
Elektronisches System nach Anspruch 8, wobei das elektronische System eine Vorrichtung einschließt, die das drahtlose Subsystem einschließt, das aus der Gruppe bestehend aus einer Hausautomatisierungsvorrichtung, einer medizinischen Vorrichtung, einem Smartphone, einer Spielkonsole, einem PC, einem Laptop, einem Tablet-Computer, einer Vorrichtung in Kraftfahrzeugen, einem Audiosystem, einem Videosystem und einer Peripherievorrichtung ausgewählt ist.
Verfahren zur drahtlosen Kommunikation, das Verfahren umfassend: Empfangen einer ersten HF-Anforderung durch ein Funkmodul mit einer ersten Priorität; Empfangen einer zweiten HF-Anforderung durch das Funkmodul mit einer zweiten Priorität, die höher als die erste Priorität ist; und Versetzen der ersten HF-Anforderung in einen Wartezustand als Reaktion auf das Bestimmen, dass das Gewähren der ersten HF-Anforderung zu einer Kollision mit der zweiten HF-Anforderung führen würde.
Verfahren nach Anspruch 14, ferner umfassend das Erhöhen der ersten Priorität auf eine höhere Priorität als die zweite Priorität während des Datenstreamings, das der zweiten HF-Anforderung zugeordnet ist.
Verfahren nach Anspruch 14, wobei das Versetzen der ersten HF-Anforderung in einen Wartezustand das Überspringen der ersten HF-Anforderung einschließt.
Verfahren nach Anspruch 14, ferner umfassend das Erhöhen einer Prioritätsstufe der ersten Priorität relativ zu der zweiten Priorität, während die erste HF-Anforderung für einen vorbestimmten Zeitraum in einen Wartezustand versetzt wurde.
Verfahren nach Anspruch 17, wobei das Erhöhen der Prioritätsstufe der ersten Priorität relativ zu der zweiten Priorität periodisch durchgeführt wird, bis die erste Priorität größer als die zweite Priorität ist.
Verfahren nach Anspruch 18, ferner umfassend das Bedienen der ersten Prioritätsanforderung als Reaktion darauf, dass die erste Priorität eine Prioritätsstufe erreicht, die größer als die zweite Priorität ist.
Verfahren nach Anspruch 14, ferner umfassend das Unterbrechen von Datenstreaming gemäß der zweiten HF-Anforderung als Reaktion darauf, dass ein vorbestimmter Zeitraum abläuft, ohne dass die erste HF-Anforderung bedient wird.
Verfahren nach Anspruch 14, ferner umfassend: Empfangen einer dritten HF-Anforderung durch ein Funkmodul mit einer dritten Priorität, die eine höhere Priorität als die erste Priorität und die zweite Priorität aufweist; und Versetzen der ersten HF-Anforderung und/oder der zweiten HF-Anforderung in einen Wartezustand als Reaktion auf das Bestimmen, dass das Gewähren der ersten HF-Anforderung und/oder der zweiten HF-Anforderung zu einer Kollision der dritten HF-Anforderung mit der ersten HF-Anforderung und/oder der zweiten HF-Anforderung führen würde.
Verfahren zum Planen von Kommunikation, die mindestens zwei drahtlose Protokollarten beinhaltet, das Verfahren umfassend: Empfangen einer ersten HF-Anforderung einer ersten Art und einer zweiten HF-Anforderung einer zweiten Art; Vorhersagen einer Kollision zwischen der ersten HF-Anforderung und der zweiten HF-Anforderung basierend auf einem oder mehreren Parametern der Anforderungen; und Planen der Gewährung der ersten HF-Anforderung und der zweiten HF-Anforderung basierend auf einer Prioritätsstufe, um die vorhergesagte Kollision zu vermeiden.
Planer zum Lösen eines Konflikts zwischen HF-Anforderungen an eine Kommunikationsvorrichtung, wobei der Planer konfiguriert ist zum: Empfangen einer ersten HF-Anforderung einer ersten Art und einer zweiten HF-Anforderung einer zweiten Art; Vorhersagen einer Kollision zwischen der ersten HF-Anforderung und der zweiten HF-Anforderung basierend auf einem oder mehreren Parametern der Anforderungen; und Planen der Gewährung der ersten HF-Anforderung und der zweiten HF-Anforderung basierend auf einer Prioritätsstufe, um die vorhergesagte Kollision zu vermeiden.