DE102020133128A1

DE102020133128A1 - Verfahren und vorrichtungen zur koordinierung von netzverkehr zwischen funknetzgeräten und computerplattformen

Info

Publication number: DE102020133128A1
Application number: DE102020133128.2A
Authority: DE
Inventors: Shahrnaz Azizi; Ashraf H. Wadaa; Nir YizHak Balaban; Leor Rom; Ajay Gupta; Ravikumar Balakrishnan; Venkateshan Udhayan; Ariela Zeira
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2020-07-23
Filing date: 2020-12-11
Publication date: 2022-01-27
Also published as: US20200359265A1

Abstract

Es werden Verfahren, Vorrichtungen, Systeme und Erzeugnisse offenbart, die Netzverkehr zwischen einem Funknetzgerät und einer Computerplattform koordinieren. Eine beispielhafte Vorrichtung enthält einen Reaktivierungswähler zum Generieren eines Zielwartezeitparameters basierend auf einem Arbeitslasttyp einer Anzahl von Paketen, die von einem Netzgerät erhalten werden, und einer Benutzerpräferenz, wobei der Zielwartezeitparameter ein Zeitintervall angibt, das, wenn es eingehalten wird, bewirkt, dass ein Modem die Anzahl von Paketen abruft, einen Datenrahmengenerator zum Generieren eines Datenrahmens, der bewirkt, dass das Netzgerät die Anzahl von Paketen im Zeitintervall puffert, und eine Netzpaketsteuereinheit zum Aushandeln des Zielwartezeitparameters mit einem Netzgerät unter Nutzung des Datenrahmens.

Description

GEBIET DER OFFENBARUNG
Diese Offenbarung betrifft allgemein Computerplattformen und Netzgeräte und insbesondere Verfahren und Vorrichtungen zur Koordinierung von Netzverkehr zwischen Funknetzgeräten und Computerplattformen.
ALLGEMEINER STAND DER TECHNIK
Viele Orte stellen Wi-Fi zum Verbinden Wi-Fi-fähiger Geräte mit Netzen wie dem Internet bereit. Wi-Fi-fähige Geräte sind etwa PCs, Videospielkonsolen, Mobiltelefone, Digitalkameras, Tablets, Smart-TVs oder digitale Audioplayer. Durch Wi-Fi können die Wi-Fi-fähigen Geräte über ein WLAN (Wireless Local Area Network) drahtlos auf das Internet zugreifen. Um eine Wi-Fi-Verbindung zu einem Gerät bereitzustellen, tauscht ein WLAN-Access-Point hochfrequente Wi-Fi-Signale mit dem Wi-Fi-fähigen Gerät innerhalb des Signalbereichs des Access-Points (z. B. eines Hotspots) aus. Wi-Fi wird unter Nutzung eines Satzes von MAC- und PHY-Spezifikationen (MAC = Media Access Control, PHY = Physical Layer) (z. B. des IEEE-802.11-Protokolls (IEEE = Institute of Electrical and Electronics Engineers)) implementiert.
Figurenliste

1 ist ein Blockschaltbild einer beispielhaften Computergerätplattform, die in einem Funknetzsystem betrieben wird.
2 ist ein Blockschaltbild der beispielhaften Computergerätplattform gemäß 1 zum Generieren dynamischer Latenzwerte basierend auf Netzverkehr.
3 ist ein Blockschaltbild eines beispielhaften Modems der beispielhaften Computergerätplattform gemäß 2 zum Generieren der dynamischen Latenzwerte basierend auf Netzverkehr.
4 ist ein Blockschaltbild einer beispielhaften Trainingssteuereinheit des beispielhaften Modems gemäß 2 und 3 zum Trainieren eines Modells zum Klassifizieren von Netzdatenpaketen nach Arbeitslastkategorien.
5 und 6 sind Ablaufschemata, die repräsentativ für maschinenlesbare Befehle sind, die zum Implementieren der beispielhaften Trainingssteuereinheit gemäß 4 zum Trainieren eines Modells zum Klassifizieren von Netzdatenpaketen nach Arbeitslastkategorien ausgeführt werden können.
7 und 8 sind Ablaufschemata, die repräsentativ für maschinenlesbare Befehle sind, die zum Implementieren des beispielhaften Modems gemäß 2 und 3 zum Generieren dynamischer Latenzwerte in Echtzeit ausgeführt werden können.
9 ist ein Blockschaltbild einer beispielhaften Netzverkehrssteuereinheit gemäß 3 zum Generieren von Zeitparametern basierend auf Netzverkehr und Benutzeranforderungen.
10 ist ein Ablaufschema, das repräsentativ für maschinenlesbare Befehle ist, die zum Implementieren eines beispielhaften Benutzeranforderungswählers gemäß 3 zum Bestimmen von Benutzerpräferenzstatus ausgeführt werden können.
11 und 12 sind Ablaufschemata, die repräsentativ für maschinenlesbare Befehle sind, die zum Implementieren der beispielhaften Netzverkehrssteuereinheit gemäß 3 und 9 zum Generieren von Zeitparametern basierend auf Netzverkehr und Benutzeranforderungen ausgeführt werden können.
13 ist ein Blockschaltbild einer beispielhaften Verarbeitungsplattform, die so strukturiert ist, dass sie die Befehle gemäß den 5-8 und den 10-12 zur Implementierung des beispielhaften Modems gemäß den 2, 3, 4 und 9 ausführt.

Die Figuren sind nicht maßstabsgerecht. Im Allgemeinen werden in der einen oder den mehreren Zeichnungen und der begleitenden schriftlichen Beschreibung jeweils dieselben Bezugszeichen genutzt, um dieselben oder ähnliche Teile zu bezeichnen.
Die Ordinalzahlen „erster“, „zweiter“, „dritter“ etc. werden hierin genutzt, wenn mehrere Elemente oder Komponenten, auf die einzeln Bezug genommen werden kann, identifiziert werden. Sofern nicht anders angegeben oder aus dem Kontext, in dem sie genutzt werden, nichts Anderes hervorgeht, wird durch diese Ordinalzahlen keine Priorität, physische Reihenfolge oder Anordnung in einer Liste und auch keine zeitliche Reihenfolge vorgegeben, sondern sie werden nur als Bezeichnungen dafür genutzt, um auf mehrere Elemente oder Komponenten einzeln Bezug zu nehmen, damit die offenbarten Beispiele besser verständlich sind. In einigen Beispielen kann die Ordinalzahl „erster“ etwa dazu genutzt werden, um auf ein Element in der ausführlichen Beschreibung Bezug zu nehmen, während auf dieses Element in einem Anspruch hingegen möglicherweise mit einer anderen Ordinalzahl, etwa „zweiter“ oder „dritter“, Bezug genommen wird. In einem solchen Fall versteht es sich, dass diese Ordinalzahlen lediglich zur vereinfachten Bezugnahme auf mehrere Elemente oder Komponenten genutzt werden.
AUSFÜHRLICHE BESCHREIBUNG
Drahtlose Netze senden und empfangen Informationen unter Verwendung verschiedener Techniken. Zwei häufige und weitverbreitete Techniken, die für die drahtlose Kommunikation genutzt werden, sind zum Beispiel die Techniken gemäß den IEEE-802.11-Standards (IEEE = Institute of Electrical and Electronics Engineers), etwa dem IEEE-802.11n-Standard oder dem IEEE-802.11ac-Standard.
Die IEEE-802.11-Standards spezifizieren eine gemeinsame MAC-Schicht (MAC = Medium Access Control), die diverse Funktionen zum Unterstützen des Betriebs von auf IEEE 802.11 basierenden WLANs bereitstellt. Die MAC-Schicht verwaltet und erhält die Kommunikation zwischen IEEE-802.11-Stationen aufrecht, etwa zwischen einem Modem (z. B. Funknetzkarten (NICs) in einem PC, einem oder mehreren anderen drahtlosen Geräten oder Stationen (STAs)) und Access-Points (APs), indem sie den Zugang zu einem gemeinsamen Funkkanal koordiniert und Protokolle verwendet, die die Kommunikation über ein drahtloses Medium verbessern.
Die Energieverwaltung mobiler Plattformen ist von wesentlicher Relevanz für batteriebetriebene Plattformen mit einem kleinen Formfaktor wie Smartphones, Tablets, Wearables oder IoT-Geräte. Die meisten Arbeitslasten mobiler Plattformen sind kommunikationsgesteuert, und das Modem (z. B. eine Funknetzkarte) verbraucht in einer Plattform oft am meisten Strom. Aufgrund des anhaltenden Bedarfs an einer Verlängerung der Batterielebensdauer von Clientplattformen (mobilen Plattformen, nicht mobilen Plattformen etc.) nebst der Definition neuer Leistungskennzahlen (Key Performance Indicators, KPIs) für die Latenz und die Ansprechempfindlichkeit über drahtlose Verbindungen (z. B. ein Funkverteilungsverfahren, das durch einen Access-Point (AP) eine Verbindung zwischen dem Internet und der Clientplattform bereitstellt), besteht zunehmend ein Bedarf daran, dass der Stromverbrauch von Plattformen insgesamt reduziert wird, ohne dass dies Auswirkungen auf die Benutzerfreundlichkeit hat.
Ein Modem ist ein Gerät, das Daten in ein für ein Übertragungsmedium geeignetes Format umwandelt, sodass die Daten von einem Computersystem an ein anderes übertragen werden können. Modems werden seit einigen Jahren in Plattformen von Personal-Computing-Geräten wie Laptops, Tablets, Mobiltelefonen etc. integriert, um Datenübertragungen und Datenverbindungen zwischen den Personal-Computing-Geräten und einem Netz zu ermöglichen. Modems wandeln zum Beispiel Daten aus einem Netz (z. B. von einem AP) in ein Format um, das Prozessoren des Personal-Computing-Geräts verstehen können, und senden die Daten dann an einen Speicher, auf den von den Prozessoren zugegriffen wird. Die Entwickler der integrierten Plattformen haben Hardware- und Softwarefunktionen entwickelt und hergestellt, die eine solche integrierte Plattform mit der Fähigkeit zum effizienten Verschieben von Daten zwischen einem Netz und der Hauptverarbeitungskomponente (z. B. einem Hauptprozessor oder einer Beschleunigerkarte) ausstatten. Diese Funktionen können ein Kommunikations- und/oder Koordinierungssystem zwischen der Hauptverarbeitungskomponente und dem Modem ermöglichen, wobei das Modem die jeweiligen Zeitpunkte zum Senden von Daten an einen Speicher, auf den von der Hauptverarbeitungseinheit zugegriffen wird, koordinieren kann.
In einigen Beispielen kann durch die Koordinierung zwischen der Hauptverarbeitungskomponente und dem Modem einfacher Strom gespart werden, indem die Hauptverarbeitungskomponente in Zuständen mit geringem Stromverbrauch betrieben werden kann, wenn das Modem bestimmt, dass kein Zugriff auf den Speicher nötig ist. Beim Interrupt Coalescing handelt es sich zum Beispiel um eine Koordinierungsfunktion, durch die unter bestimmten Umständen (z. B. Umständen mit einem hohen Durchsatz) die Anzahl von Interrupts (z. B. die Anzahl von Signalen, die vom Modem an die CPU gesendet werden) an die Hauptverarbeitungskomponente (z. B. die CPU) reduziert wird. Wenn das Modem zum Beispiel in einem aktiven Zustand ist, werden aufgrund der Interrupt-Coalescing-Funktion Interrupts an die CPU so lange zurückgehalten, bis ein Timeout-Timer ausgelöst wird, was relativ kleine oder große Latenzeinbußen nach sich zieht. In diesem Beispiel puffert das Modem Daten aus dem Netz (z. B. von einem AP), um die Anzahl von Interrupts an die Hauptverarbeitungskomponente zu reduzieren. Das Interrupt Coalescing ist jedoch kein effizientes Stromsparverfahren, da unterschiedliche Typen von Arbeitslasten (z. B. Datenpakete aus dem Netz) unterschiedliche Interrupt-Ebenen (z. B. unterschiedliche Latenzanforderungen) erfordern und unterschiedliche Personal-Computing-Geräte mehrere unterschiedliche Arbeitslasten (z. B. Anwendungen oder Programme) auf einmal ausführen (z. B. laufen lassen) können. Darüber hinaus wird die Effizienz dieser bisherigen Techniken (z. B. des Interrupt Coalescing) dadurch begrenzt, dass nach dem IEEE-802.11-WLAN-Protokoll (Wi-Fi) ein zufallsgesteuerter Zugriff erfolgt und die Fähigkeit des Modems zum Puffern von Daten im Gerät beschränkt ist. In einigen Beispielen besteht das Grundproblem beim Ausgleichen von Strom und Performanz zwischen dem Modem und der CPU darin, dass das Modem die (z. B. von einem AP) empfangenen Daten schnell vom Puffer des Modems, der eine begrenzte Größe hat, an den Speicher übertragen soll, um einen Pufferüberlauf zu vermeiden. In einigen Beispielen bewirkt ein Pufferüberlauf Datenverluste, was sich folglich negativ auf die Benutzerfreundlichkeit auswirkt.
Es werden zum Beispiel unterschiedliche Arbeitslastszenarios betrachtet. In einem ersten beispielhaften Szenario erhält das Modem Streaming-Arbeitslasten (z. B. Netflix® oder YouTube®) und die Plattform unterdrückt den Ton (z. B. wird der Audioteil der Streaming-Arbeitslast nicht an einen Benutzer der Plattform ausgegeben). Solche Streaming-Arbeitslasten ähneln einem Dateidownload, wobei der mit der Streaming-Arbeitslast korrespondierende Netzverkehr in den Hauptspeicher heruntergeladen (z. B. im Hauptspeicher gespeichert) wird und danach eine Zeit lang ungenutzt im Hauptspeicher liegt (z. B. solange bis der Prozessor den Netzverkehr der Streaming-Arbeitslast abruft). Die Streaming-Arbeitslast kann eine Zeit lang ungenutzt darin liegen (es wird z. B. nicht auf sie zugegriffen oder sie wird nicht dazu genutzt, um zu bewirken, dass das Computergerät eine Aktion durchführt), weil der Ton unterdrückt wird, sodass bei einem Verlust von Audiorahmen keine Performanzprobleme auftreten. In dem beispielhaften ersten Szenario könnten sowohl das Modem als auch die CPU während der Leerlaufzeit in Stromsparzustände eintreten (z. B. bestehen Einschränkungen für die CPU aufgrund anderer Geräte, etwa eines Displays), wenn sich eine optimale Koordinierung zwischen dem AP, dem Modem und der Plattform herstellen ließe. Jedoch wird auf diese Weise kein Strom gespart, weil (a) die Wi-Fi-Implementierung und die Wi-Fi-Konfiguration verhindern, dass das Modem in bestimmte Stromsparzustände eintritt, um Verzögerungen beim Übertragen von Daten vom AP an das Modem zu verhindern, und (b) das Modem verhindert, dass die CPU in bestimmte Stromsparzustände (z. B. C-States) eintritt, weil das Modem Latenzwerte konservativ auswählt.
Dahingegen enthält ein zweites beispielhaftes Szenario, dass das Modem latenzempfindliche Arbeitslasten (z. B. einen Skype®- oder WhatsApp®-Videoanruf oder Ton im Hintergrund) erhält. In diesem Beispiel kann weder das Modem noch die CPU aufgrund der Latenzanforderungen der Arbeitslast in einen Stromsparzustand eintreten. Die derzeitigen Wi-Fi- und Clientplattform-Funktionen unterscheiden nicht zwischen diesen zwei beispielhaften Szenarios, weil dem AP Benutzerpräferenzen (z. B. Strom- und Performanzanforderungen des Benutzers) und Arbeitslastanforderungen (z. B. Prioritätsanforderungen oder die QoS) nicht bekannt sind. Dem AP werden zum Beispiel keine Stromsparpräferenzen der Clientplattform und auch keine Latenz- und Performanzanforderungen der Arbeitslast mitgeteilt, und er übermittelt daher ungeachtet solcher Anforderungen kontinuierlich Netzdatenpakete an das Modem, sodass das Modem jedes Mal, wenn der AP die Netzdatenpakete bereitstellt, einen jeweiligen Stromsparzustand verlässt und in einen jeweiligen Stromausführungszustand eintritt. Wenn Clientplattformen in einigen Beispielen zusätzlich zu den Hauptarbeitslasten wie etwa einem Streaming oder einem Videoanruf Arbeitslasten im Hintergrund laufen lassen, bewirken die Arbeitslasten im Hintergrund, dass das Modem häufig in Stromsparzustände eintritt, um Push-Benachrichtigungen zu empfangen, Hintergrunddaten zu empfangen, Netzerkennungsnachrichten zu erfassen etc.
In Beispielen, die hierin offenbart werden, werden dynamische Latenzwerte und mithin dynamische Interrupts basierend darauf generiert, wie lange Netzdatenpakete im Modem gepuffert werden können, was abhängig von den Arbeitslasttypen, die in einem Prozessor (z. B. einer CPU, einem Grafikprozessor (GPU) oder einem Field Programmable Gate Array (FPGA) etc.) laufen gelassen werden, und der Pufferlänge des Modems ist. Latenzwerte, wie hierin genutzt, sind Zeitwerte, die angeben, wie lange das Modem Netzdatenpakete puffern kann, bis das Modem keinen weiteren verfügbaren Speicherplatz mehr hat. Die Latenzwerte geben also an, ob der Prozessor in einen Stromsparzustand oder einen Stromausführungszustand eintreten soll. Der Latenzwert informiert zum Beispiel den Prozessor und/oder den Speicher darüber, dass das Modem Netzdatenpakete eine Zeit lang (z. B. für eine maximale Dauer) speichern und das Modem erst dann versuchen wird, auf den Speicher zuzugreifen. Solche Latenzwerte und Interrupts können dynamisch sein, was den Durchsatz und die Toleranz betrifft, wobei der Durchsatz mit dem Durchsatz von Netzdatenpaketen korrespondiert und die Toleranz damit korrespondiert, wie viel Latenz für die Arbeitslast der Daten toleriert werden kann, ohne dass dies Auswirkungen auf die Benutzerfreundlichkeit hat. In Beispielen, die hierin offenbart werden, wird ein Modell zum Klassifizieren von Netzdatenpaketen nach einer Arbeitslastkategorie (z. B. einem Arbeitslasttyp) trainiert. Beispiele, die hierin offenbart werden, enthalten ein Modem, das, wenn es aktiv ist, den Typ ankommender Netzdatenpakete inferiert und eine Entscheidung über die zum Verarbeiten des Typs von Netzdatenpaketen erforderliche Latenz trifft.
In Beispielen, die hierin offenbart werden, werden eine Pufferung von Netzdaten und deren Übertragung zwischen einem AP und einem Modem basierend auf Arbeitslast- und Benutzeranforderungen koordiniert. Die Arbeitslastanforderungen korrespondieren mit Rechenressourcen, die zum Ausführen der Arbeitslast für eine optimale Performanz erforderlich sind, gewünscht werden etc. Zu diesen Rechenressourcen zählen in einigen Beispielen unter anderem die Latenz, der Durchsatz, die Bitrate etc. Die Benutzeranforderungen korrespondieren mit einer Benutzerpräferenz für eine Verlängerung der Batterielebensdauer oder eine optimale Performanz. In einigen Beispielen enthalten die Präferenzen ein Verhältnis zugunsten des Sparens von Strom, ein Verhältnis zugunsten einer Performanzerhöhung, ein Verhältnis sowohl zugunsten des Sparens von Strom als auch zugunsten einer Performanzerhöhung oder andere Stromverbrauch-Performanz-Verhältnisse. Ein Verhältnis kann eine Präferenz stärker als eine andere Präferenz oder beide Präferenzen gleich gewichten. In Beispielen, die hierin offenbart werden, wird zum Beispiel eine Reaktivierungszeit ausgewählt, die einen Ausgleich zwischen einem Stromsparzustand des Modems und einem Reaktivierungszustand des Modems für den Empfang von Netzdaten vom AP ermöglicht. In Beispielen, die hierin offenbart werden, werden basierend auf Benutzer- und Arbeitslastanforderungen Parameter generiert, die einen AP darüber informieren, wie lange der AP Netzdaten puffern soll, Beacon-Intervalle festlegen soll etc. In diesen Beispielen kann der Prozessor, wenn das Sparen von Strom bevorzugt wird, in tiefe Stromsparzustände eintreten, mithin wird der Stromverbrauch des Prozessors reduziert, wenn kein Stromverbrauch nötig oder gewünscht ist.
Beispiele, die hierin offenbart werden, implementieren künstliche Intelligenz zum Generieren dynamischer Latenzwerte, aufgrund derer ein Prozessor in einen Stromsparzustand oder einen Zustand mit geringem Stromverbrauch eintreten kann. Durch künstliche Intelligenz (KI), die maschinelles Lernen (ML), Deep Learning (DL) und andere künstliche, automatisierte Logiken einschließt, können Maschinen (z. B. Systeme, Computer oder logische Schaltungen) ein Modell zum Verarbeiten von Eingabedaten nutzen, um basierend auf Mustern und/oder Assoziationen, die durch das Modell vorher über einen Trainingsprozess gelernt worden sind, eine Ausgabe zu generieren. Das Modell kann beispielsweise mit Daten trainiert werden, um Muster und/oder Assoziationen zu erkennen und diese Muster und/oder Assoziationen beim Verarbeiten von Eingabedaten zu befolgen, sodass aus einer oder mehreren weiteren Eingaben eine oder mehrere Ausgaben, die mit den erkannten Mustern und/oder Assoziationen übereinstimmen, resultieren.
Es gibt viele unterschiedliche Typen von Machine-Learning-Modellen und Machine-Learning-Architekturen. In Beispielen, die hierin offenbart werden, wird das Modell eines neuronalen Netzes genutzt. Die Nutzung des Modells eines neuronalen Netzes ermöglicht die Klassifikation von Netzdatenpaketen basierend auf ihren Paketmerkmalen wie der Länge (z. B. der Anzahl von Paketen, die mit demselben Arbeitslastfluss korrespondieren), der Zwischenankunftszeit, dem Ursprung, dem Ziel etc. Allgemein handelt es sich bei Machine-Learning-Modellen/-Architekturen, die zur Nutzung bei den beispielhaften, hierin offenbarten Ansätzen geeignet sind, um rekurrente neuronale Netze (RNNs). Jedoch könnten zusätzlich oder alternativ auch noch andere Machine-Learning-Modelltypen genutzt werden, etwa LSTM-Modelle (LSTM = Long/Short Term Memory), Radial-Basis-Function-Modelle, selbstorganisierende Karten (Kohonen-Modelle) etc.
Die Implementierung eines ML/KI-Systems involviert im Allgemeinen mindestens zwei Phasen, eine Lern-/Trainingsphase und eine Inferenzphase. In der Lern-/Trainingsphase wird ein Trainingsalgorithmus dazu genutzt, um ein Modell so zu trainieren, dass es gemäß Mustern und/oder Assoziationen, die zum Beispiel auf Trainingsdaten basieren, arbeitet. Im Allgemeinen enthält das Modell interne Parameter, die darauf verweisen, wie Eingabe- in Ausgabedaten überführt werden, etwa durch eine Reihe von Knoten und Verbindungen innerhalb des Modells zur Überführung von Eingabe- in Ausgabedaten. Darüber hinaus werden beim Trainingsprozess Hyperparameter genutzt, um zu steuern, wie das Lernen durchgeführt wird (z. B. eine Lernrate oder eine Anzahl von im Machine-Learning-Modell genutzten Schichten). Hyperparameter werden als Trainingsparameter definiert, die vor dem Einleiten des Trainingsprozesses bestimmt werden.
Das Training kann basierend auf dem ML/KI-Modelltyp und/oder der erwarteten Ausgabe auf unterschiedliche Arten durchgeführt werden. Bei einem überwachten Training werden zum Beispiel Eingaben und korrespondierende erwartete (z. B. beschriftete) Ausgaben zur Auswahl von Parametern (z. B. durch Iterieren über Kombinationen ausgewählter Parameter) für das ML/KI-Modell, die Modellfehler reduzieren, genutzt. Das Beschriften, wie hierin genutzt, bezieht sich auf eine erwartete Ausgabe des Machine - Learning-Modells (z. B. eine Klassifikation oder einen erwarteten Ausgabewert). Alternativ werden bei einem unüberwachten Training (das z. B. beim Deep Learning, einem Teilgebiet des maschinellen Lernens, genutzt wird) Muster aus Eingaben inferiert, um Parameter für das ML/KI-Modell auszuwählen (z. B. ohne den Nutzen aus erwarteten (z. B. beschrifteten) Ausgaben).
In Beispielen, die hierin offenbart werden, werden ML/KI-Modelle unter Nutzung eines stochastischen Gradientenabstiegs trainiert. Jedoch können zusätzlich oder alternativ auch noch andere Trainingsalgorithmen genutzt werden. In Beispielen, die hierin offenbart werden, wird das Training so lange durchgeführt, bis beim Vorhersagen und Klassifizieren von Netzdatenpaketen eine akzeptable Fehlermenge erreicht ist. In Beispielen, die hierin offenbart werden, wird das Training im Computergerät (z. B. lokal) durchgeführt. In einigen Beispielen wird das Training remote (z. B. in einer zentralen Anlage) durchgeführt. Das Training wird unter Nutzung von Hyperparametern (z. B. einer Lernrate oder einer Anzahl von Schichten zur Nutzung im Machine-Learning-Modell) durchgeführt, die steuern, wie das Lernen durchgeführt wird. In Beispielen, die hierin offenbart werden, werden Hyperparameter genutzt, die die Anzahl von Paketmerkmalen und Paketen pro Netzfluss steuern. Diese Hyperparameter werden zum Beispiel basierend auf den Rechenfähigkeiten des Computergeräts und/oder der zentralen Anlage und Echtzeitanforderungen ausgewählt. In einigen Beispielen wird möglicherweise ein erneutes Training durchgeführt. Ein solches erneutes Training kann als Reaktion auf unbekannte Paketmerkmale, neue Arbeitslastkategorien etc. durchgeführt werden.
Das Training wird unter Nutzung von Trainingsdaten durchgeführt. Die Trainingsdaten in den hierin offenbarten Beispielen stammen aus lokal generierten Daten. Weil ein überwachtes Training genutzt wird, werden die Trainingsdaten beschriftet. Die Beschriftung wird durch eine Vorverarbeitungssteuereinheit auf die Trainingsdaten angewendet. In einigen Beispielen werden die Trainingsdaten zum Beispiel unter Nutzung bekannter Merkmale, die einen Arbeitslasttyp von Netzdatenpaketen angeben, vorverarbeitet.
Sobald das Training abgeschlossen ist, wird das Modell zur Nutzung als ausführbares Konstrukt eingesetzt, das basierend auf dem Netz aus Knoten und Verbindungen, die im Modell definiert sind, eine Eingabe verarbeitet und eine Ausgabe bereitstellt. Das Modell ist im Modem des Personal-Computing-Geräts gespeichert. Daraufhin kann das Modell durch die Vorhersagesteuereinheit des Modems ausgeführt werden. In anderen Beispielen speichert eine Netzkarte (NIC) das Modell im Personal-Computing-Gerät, in dem der Host-Protokollstapel ausgeführt wird. Zusätzlich oder alternativ ist das Modell extern gespeichert, falls das Modem nicht über die Ressourcen (z. B. Rechenfähigkeiten) zum Ausführen eines solchen Modells verfügt.
Sobald das Modell trainiert worden ist, kann es nach dem Deployment in einer Inferenzphase zur Datenverarbeitung eingesetzt werden. In der Inferenzphase werden zu analysierende Daten (z. B. Live-Daten) in das Modell eingegeben, und das Modell wird ausgeführt, um eine Ausgabe zu erzeugen. Diese Inferenzphase ist gleichsam das „Denken“ der KI zum Generieren der Ausgabe basierend darauf, was sie bei dem Training gelernt hat (z. B. durch Ausführen des Modells, um die gelernten Muster der Live-Daten anzuwenden). In einigen Beispielen werden Eingabedaten vorverarbeitet, bevor sie als Eingabe in das Machine-Learning-Modell genutzt werden. Außerdem werden die Ausgabedaten in einigen Beispielen möglicherweise nachverarbeitet, nachdem sie durch das KI-Modell generiert worden sind, um die Ausgabe in ein brauchbares Ergebnis (z. B. eine Anzeige von Daten oder einen durch eine Maschine auszuführenden Befehl) zu überführen. Eine Arbeitslast lässt sich zum Beispiel als Echtzeit-Arbeitslast oder als Nicht-Echtzeit-Arbeitslast klassifizieren, wobei sich die Echtzeit-Arbeitslast ferner als ein Typ einer Echtzeit-Arbeitslast (z. B. nur Audio, Audio-Video oder Spiel) und die Nicht-Echtzeit-Arbeitslast ferner als ein Typ einer Nicht-Echtzeit-Arbeitslast klassifizieren lässt.
In einigen Beispielen kann die Ausgabe des für das Deployment ausgewählten Modells erfasst und als Rückkopplung bereitgestellt werden. Durch Analysieren der Rückkopplung kann die Genauigkeit des für das Deployment ausgewählten Modells bestimmt werden. Wenn die Rückkopplung darauf hinweist, dass die Genauigkeit des für das Deployment ausgewählten Modells unter einem Schwellenwert liegt oder ein anderes Kriterium nicht erfüllt, kann das Training eines aktualisierten Modells unter Nutzung der Rückkopplung und eines aktualisierten Trainingsdatensatzes, von Hyperparametern etc. ausgelöst werden, um ein aktualisiertes, für das Deployment ausgewähltes Modell zu generieren.
1 ist ein Blockschaltbild einer beispielhaften Computergerätplattform 100, die in einem Funknetzsystem betrieben wird. Das beispielhafte Funknetzsystem gemäß 1 enthält die beispielhafte Computergerätplattform 100, ein beispielhaftes Netz 102 und ein beispielhaftes Funknetzgerät 104. Das beispielhafte Funknetzgerät 104 enthält eine beispielhafte Reaktivierungssteuereinheit 106 und einen beispielhaften Puffer 108.
Die beispielhafte Computergerätplattform 100 in 1 ist eine zum Ausführen von Arbeitslasten wie Anwendungen, Programmen, Prozessen etc. in einem Computergerät implementierte Hardware und Software. Die beispielhafte Computergerätplattform 100 definiert eine Reihe von Fähigkeiten des Computergeräts. Bei der Computergerätplattform 100 kann es sich um eine beliebige Computer-Hardware handeln, etwa um ein Mobiltelefon, einen Laptop, ein Tablet, einen Desktop etc., eine beliebige Betriebssystemplattform, eine beliebige Client/Server-Plattform wie etwa einen Webserver, eine beliebige mobile Plattform wie etwa eine beliebige mobile Anwendungsplattform, eine beliebige Cloud-Plattform oder eine beliebige sonstige geeignete Plattform zum Ausführen von Datenpaketen. Die beispielhafte Computergerätplattform 100 wird in Verbindung mit 2 unten noch ausführlicher beschrieben.
Das beispielhafte Netz 102 in 1 ist das Internet. Das Netz 102 kann jedoch unter Nutzung eines oder mehrerer beliebiger geeigneter Kabel- oder kabelloser Netze implementiert werden, die zum Beispiel einen oder mehrere Datenbusse, ein oder mehrere LANs (Local Area Networks), ein oder mehrere WLANs (Wireless Local Area Networks), ein oder mehrere Mobilfunknetze, ein oder mehrere private Netze oder ein oder mehrere öffentliche Netze enthalten. Das beispielhafte Netz 102 ermöglicht in Verbindung mit dem beispielhaften Funknetzgerät 104, dass die Computergerätplattform 100 Netzinformationen, die von einem Benutzer der Computergerätplattform 100 angefordert wurden, sendet und empfängt.
Das beispielhafte Funknetzsystem in 1 enthält das beispielhafte Funknetzgerät 104, um zu ermöglichen, dass die beispielhafte Computergerätplattform 100 eine Verbindung zum beispielhaften Netz 102 herstellt. In 1 handelt es sich bei dem beispielhaften Funknetzgerät 104 um einen Access-Point (AP). Das beispielhafte Funknetzgerät 104 kann jedoch eine andere Hardware und Software von einem beliebigen Typ sein, die eine Verbindung zwischen der beispielhaften Computergerätplattform 100 und dem beispielhaften Netz 102 herstellt. Das beispielhafte Funknetzgerät 104 versorgt möglicherweise mehrere Computergerätplattformen. Das Funknetzgerät 104 kann zum Beispiel eine Verbindung zwischen beliebig vielen Clientplattformen, etwa Mobiltelefonen, Laptops oder Tablets, und dem Netz 102 für den Empfang von Internet- und/oder Netzdaten herstellen. In einigen Beispielen kommuniziert und/oder routet das Funknetzgerät 104 Internet- und/oder Netzdaten an die Computergerätplattform 100, sobald die Computergerätplattform 100 eine Verbindung gemäß Wi-Fi (802.11) zum Funknetzgerät 104 herstellt. Bislang ist die Wi-Fi-Verbindung zwischen dem Funknetzgerät 104 und der Computergerätplattform 100 generisch und am 802.11-Protokoll ausgerichtet (z. B. sind dem Funknetzgerät 104 keine Arbeitslast- und Benutzeranforderungen der Computergerätplattform 100 bekannt und es wird normal nach dem 802.11-Protokoll betrieben). Dahingegen werden von der beispielhaften Computergerätplattform 100 in den Beispielen, die hierin offenbart werden, basierend auf Arbeitslast- und Benutzeranforderungen Wi-Fi-Verbindungen zu dem beispielhaften Funknetzgerät 104 hergestellt sowie die Zeitpunkte des Abrufs und der Übertragung von Netzdaten koordiniert.
Das beispielhafte Funknetzgerät 104 in 1 enthält die beispielhafte Reaktivierungssteuereinheit 106 zum Generieren von Datenrahmen, die die beispielhafte Computergerätplattform 100 über verfügbare Netzdaten informieren. Die beispielhafte Reaktivierungssteuereinheit 106 kann Stromsparprotokolle, die im IEEE-802.11ax-Standard definiert sind, implementieren, indem sie für die Computergerätplattform 100 einen hohen Durchsatz und drahtlose Verbindungen mit niedriger Latenz bereitstellt und gleichzeitig den Stromverbrauch reduziert. Solche Stromsparprotokolle werden durch eine Kommunikation und/oder eine Verhandlung zwischen der Reaktivierungssteuereinheit 106 und der Computergerätplattform 100 implementiert, wobei die Reaktivierungssteuereinheit 106 die Computergerätplattform 100 darüber informiert, dass der beispielhafte Puffer 108 Netzdaten eine Zeit lang puffern wird, damit die Computergerätplattform 100 in Stromsparzustände eintreten kann. Jedoch ist die Pufferungszeit aufgrund des Typs der in der Computergerätplattform 100 ausgeführten Arbeitslast, der Benutzeranforderungen der Computergerätplattform 100 etc. möglicherweise nicht ausreichend dafür, dass die Computergerätplattform 100 in entsprechende Stromsparzustände eintreten kann. Daher empfängt die beispielhafte Reaktivierungssteuereinheit 106 in Beispielen, die hierin offenbart werden, Informationen von der beispielhaften Computergerätplattform 100, welche mit Zeiten korrespondieren, die zum Puffern von Netzdaten, das Senden von Netzdaten und/oder das Reaktivieren der beispielhaften Computergerätplattform 100 ausreichend sind. Der Begriff „reaktivieren“, wie hierin genutzt, bedeutet, dass ausgelöst wird, dass die Computergerätplattform 100 einen Leerlaufzustand oder Schlafmodus verlässt und in einen Ausführungszustand oder aktiven Modus eintritt.
Die beispielhafte Reaktivierungssteuereinheit 106 in 1 generiert beispielhafte AP-Datenrahmen 110, die für die beispielhafte Computergerätplattform 100 vorgesehene Informationen enthalten. Die beispielhafte Computergerätplattform 100 in 1 generiert beispielhafte Modemdatenrahmen 112, die für die beispielhafte Reaktivierungssteuereinheit 106 oder allgemeiner das beispielhafte Funknetzgerät 104 vorgesehene Informationen enthalten.
Bei dem beispielhaften AP-Datenrahmen 110 in 1 handelt es sich um einen Beacon-Rahmen. Ein Beacon-Rahmen ist ein Management-Rahmen, der von einem AP (z. B. dem Funknetzgerät 104) dazu genutzt wird, um die Eigenschaften der Verbindung, die der Computergerätplattform 100 angeboten wird, überall im Versorgungsbereich (z. B. im Funknetzsystem) zu kommunizieren. Zusätzlich oder alternativ kann die beispielhafte Reaktivierungssteuereinheit 106 oder allgemeiner das beispielhafte Funknetzgerät 104 auch beliebige andere Rahmen und einem durch den IEEE-Standard (Wi-Fi) definierten Protokoll senden. Der beispielhafte AP-Datenrahmen 110 wird in periodischen Abständen in Beacon-Intervallen an die Computergerätplattform 100 gesendet (ein Beacon-Standardintervall ist z. B. 102,4 Millisekunden lang). Der beispielhafte AP-Datenrahmen 110 enthält ein Rahmenformat, das die Eigenschaften der Verbindung zwischen dem Funknetzgerät 104 und der Computergerätplattform 100 kommuniziert. Das Rahmenformat des beispielhaften AP-Datenrahmens 110 enthält ein MAC-Header-Feld 114, ein Timestamp-Feld 116, ein Beacon-Interval-Feld 118, ein Capability-Information-Feld 120, ein SSID-Feld (SSID = Service Set Identifier) 122, ein Supported-Rates-Feld 124, ein TIM-Element (TIM = Traffic Indication Map) 126, optionale Felder 128 und ein FCS-Element (FCS = Frame Check Sequence) 130. Zur Erläuterung: Datenrahmen, die den AP-Datenrahmen 110 und den Modemdatenrahmen 112 enthalten, enthalten Informationsfelder und Informationselemente. Ein Informationsfeld ist ein Feld mit einer festen Länge, das im Frame-Body vorhanden sein muss, und ein Informationselement ist ein Element mit einer veränderlichen Länge im Frame-Body.
Das beispielhafte MAC-Header-Feld 114 ist ein drei Bytes langes Adressfeld, das eine Quelladresse, einen Quellport, eine Zieladresse, einen Zielport und ein Protokoll angibt. In einigen Beispielen informiert der MAC-Header 114 die Computergerätplattform 100 darüber, woher die Netzdaten stammen und für welche Rechenressource die Netzdaten vorgesehen sind.
Der Frame-Body des beispielhaften AP-Datenrahmens 110 enthält das beispielhafte Timestamp-Feld 116 mit einem 8-Byte-Wert, der die Zeit im Funknetzgerät 104 angibt, nämlich wie viele Mikrosekunden lang das Funknetzgerät 104 aktiv gewesen ist.
Der Frame-Body des beispielhaften AP-Datenrahmens 110 enthält das beispielhafte Beacon-Interval-Feld 118, ein zwei Byte langes Feld, das die Anzahl von Zeiteinheiten (Time Units, TUs) zwischen geplanten Beacon-Übertragungszeiten (TBTTs) angibt. Das Beacon-Intervall 118 bestimmt zum Beispiel die Dauer der Zeit zwischen dem Senden der Netzdaten vom Funknetzgerät 104 und dem Empfang der Netzdaten vom Funknetzgerät 104 in der Computergerätplattform 100. In einigen Beispielen beträgt der vorgegebene Beacon-Intervall-Wert 100 TU, was ungefähr 102,4 Millisekunden entspricht.
Der Frame-Body des beispielhaften AP-Datenrahmens 110 enthält das beispielhafte Capability-Information-Feld 120, ein zwei Byte langes Feld, das eine Anzahl von Subfeldern enthält, die dazu genutzt werden, um angeforderte oder bekannt gegebene optionale Fähigkeiten des Funknetzgeräts 104 anzugeben. Das Capability-Information-Feld 120 enthält zum Beispiel unter anderem Subfelder, die mit einer unmittelbaren Block Acknowledgement des Funknetzgeräts 104, einer verzögerten Block Acknowledgement des Funknetzgeräts 104, einer QoS-Unterstützung (QoS = Dienstqualität) des Funknetzgeräts 104, der Vertraulichkeit des Funknetzgeräts 104 etc. korrespondieren.
Der Frame-Body des beispielhaften AP-Datenrahmens 110 enthält das beispielhafte SSID-Element 122, ein Element mit einer veränderlichen Größe, das den Namen des Funknetzgeräts 104 angibt. Das SSID-Element ist zum Beispiel eine zur Unterscheidung dienende Kennung, die die Computergerätplattform 100 über den Namen des Funknetzgeräts 104 informiert. In einigen Beispielen wird das SSID-Element 122 von einem Benutzer der Computergerätplattform 100 dazu genutzt, um eine Verbindung zum richtigen und sicheren Funknetz herzustellen.
Der Frame-Body des beispielhaften AP-Datenrahmens 110 enthält das beispielhafte Supported-Rates-Element 124, ein Element mit einer (z. B. in der Bitlänge) veränderlichen Größe, das eine unterstützte Frequenzrate und/oder Datenrate des beispielhaften Funknetzgeräts 104 angibt. Das Supported-Rates-Element 124 identifiziert zum Beispiel die Anzahl von Bits pro Sekunde, die das Funknetzgerät 104 senden und empfangen kann. In einigen Beispielen unterstützt das Supported-Rates-Element 124 die Computergerätplattform 100 beim Bestimmen der Geschwindigkeit, mit der Netzdaten im Funknetzsystem empfangen werden (oder empfangen werden können).
Der Frame-Body des beispielhaften AP-Datenrahmens 110 enthält das beispielhafte TIM-Element 126, ein Element mit einer veränderlichen Größe, das Netzdatenpakete angibt, die in dem beispielhaften Puffer 108 gepuffert sind. Das TIM-Element 126 gibt zum Beispiel der Computergerätplattform 100 bekannt, ob die Computergerätplattform 100 zugehörige Netzdatenpakete, die im Puffer 108 gepuffert sind, enthält. In einigen Beispielen wird die Computergerätplattform 100 in jedem (z. B. durch das Beacon-Interval-Feld 118 festgelegten) Beacon-Intervall reaktiviert, um das TIM-Element 126 zu prüfen und zu bestimmen, ob die Computergerätplattform 100 Netzdaten beziehen soll.
Der Frame-Body des beispielhaften AP-Datenrahmens 110 enthält die beispielhaften optionalen Felder 128, die zusätzliche Informationen, die mit Parametern des beispielhaften Funknetzgeräts 104 korrespondieren, enthalten. Optionale Felder im AP-Datenrahmen 110 sind zum Beispiel unter anderem ein Frequency-Hopping-Parameterelement, Landesinformationen, ein Power-Constraint-Element, ein Channel-Switch-Element oder ein Quiet-Element.
Der beispielhafte AP-Datenrahmen 110 enthält das Frame-Check-Sequence-Element 130, das einen Fehlererkennungscode angibt, über den das beispielhafte Computergerät 100 bestimmen kann, ob in den Nutzdaten des AP-Datenrahmens 110 ein Fehler ist. In einigen Beispielen bewirkt das FCS-Element 130, dass der AP-Datenrahmen 110 beendet wird. Wenn der Zielknoten (z. B. die Computergerätplattform 100) zum Beispiel ein anderes FCS-Element im AP-Datenrahmen 110 generiert, wird der beispielhafte AP-Datenrahmen 110 von der Computergerätplattform 100 verworfen.
Bei dem beispielhaften Modemdatenrahmen 112 in 1 handelt es sich um einen Association-Rahmen. Ein Association Frame ist ein Management-Rahmen, der von einem Clientgerät (z. B. der Computergerätplattform 100) verwaltet wird, um einen Association Identifier (AID) vom Funknetzgerät 110 zu erhalten und Netzeigenschaften, die von der Computergerätplattform 100 benötigt werden, auszuhandeln und/oder zu kommunizieren. Das Rahmenformat des beispielhaften Modemdatenrahmens 112 enthält ein MAC-Header-Feld 132, ein Capability-Information-Feld 134, ein Listen-Interval-Feld 136, ein SSID-Feld 138, ein Supported-Rates-Feld 140 und ein FCS-Feld 142.
Das beispielhafte MAC-Header-Feld 132 ist ein drei Bytes langes Adressfeld, das eine Quelladresse, einen Quellport, eine Zieladresse, einen Zielport und ein Protokoll angibt. In einigen Beispielen informiert der MAC-Header 132 das Funknetzgerät 104 über das Ziel der in der Computergerätplattform 100 generierten Daten.
Der Frame-Body des beispielhaften Modemdatenrahmens 112 enthält das beispielhafte Capability-Information-Feld 134, ein zwei Byte langes Feld, das eine Anzahl von Subfeldern enthält, die dazu genutzt werden, um angeforderte oder bekannt gegebene optionale Fähigkeiten der Computergerätplattform 100 anzugeben. Das Capability-Information-Feld 134 enthält zum Beispiel unter anderem Subfelder, die mit dem Leistungsvermögen der Computergerätplattform 100, unterstützten Kanälen der Computergerätplattform 100, der QoS-Fähigkeit der Computergerätplattform 100, der QoS-Verkehrsfähigkeit der Computergerätplattform 100 oder einem TIM-Broadcast-Request für die Computergerätplattform 100 korrespondieren. In einigen Beispielen werden die Subfelder des Capability-Information-Felds 134 aufgefüllt, wenn der AP-Datenrahmen 110 über das Capability-Information-Feld 120 bestätigt, dass das Funknetzgerät 104 solche Fähigkeiten unterstützt.
Der Frame-Body des beispielhaften Modemdatenrahmens 112 enthält das beispielhafte Listen-Interval-Feld 136, über das dem beispielhaften Funknetzgerät 104 die Zielwartezeit der Computergerätplattform 100 angegeben wird. Das Listen-Interval-Feld 136 gibt dem Funknetzgerät 104 zum Beispiel an, wie oft die Computergerätplattform 100 reaktiviert wird, um auf Beacon-Management-Rahmen (z. B. AP-Datenrahmen 110) zu lauschen (z. B. um sie abzurufen). In einigen Beispielen wird das Listen-Interval-Feld 136 in Beacon-Intervall-Einheiten ausgedrückt. Das Listen-Interval-Feld 136 gibt zum Beispiel möglicherweise an, dass das Computergerät 100 in jedem dritten Beacon-Intervall (102,4 ms) in einen Stromausführungszustand eintreten wird, um AP-Datenrahmen 110 und zugehörige Netzdaten aus dem Funknetzgerät 104 abzurufen. In einigen Beispielen bestimmt das Funknetzgerät 104 basierend auf dem Listen-Interval-Feld 136 die Dauer der Pufferung von Netzdatenpaketen.
Der Frame-Body des beispielhaften Modemdatenrahmens 112 enthält das beispielhafte SSID-Element 138, ein Element mit einer veränderlichen Größe, das den Namen des Funknetzgeräts 104, das der Computergerätplattform 100 zugeordnet worden ist, angibt. Das SSID-Element 138 bestätigt zum Beispiel eine Zuordnung zwischen dem Funknetzgerät 104 und der Computergerätplattform 100.
Der Frame-Body des beispielhaften AP-Datenrahmens 110 enthält das beispielhafte Supported-Rates-Element 140, ein Element mit einer veränderlichen Größe, das die unterstützte Frequenzrate und/oder Datenrate des beispielhaften Funknetzgeräts 104 angibt. Die Computergerätplattform 100 bestätigt zum Beispiel die unterstützte Rate des Funknetzgeräts 104, wenn die Computergerätplattform 100 dem Funknetzgerät 104 zugeordnet ist.
Der beispielhafte Modemdatenrahmen 112 enthält das Frame-Check-Sequence-Element 142, das einen Fehlererkennungscode angibt, über den das beispielhafte Funknetzgerät 104 bestimmen kann, ob in den Nutzdaten des Modemdatenrahmens 112 ein Fehler ist.
Das beispielhafte Funknetzgerät 104 in 1 enthält den beispielhaften Puffer 108 zum Speichern und Allozieren von Netzdaten aus dem beispielhaften Netz 102. In einigen Beispielen ist der Puffer 108 ein Cachespeicher, ein oder mehrere Latches oder ein sonstiger geeigneter Speicher zum Speichern von Netzdaten. Der beispielhafte Puffer 108 wird durch die beispielhafte Reaktivierungssteuereinheit 106 gesteuert, sodass die Reaktivierungssteuereinheit 106 bestimmt, wenn Netzdaten im beispielhaften Puffer 108 zu speichern sind und wenn die Netzdaten der beispielhaften Computergerätplattform 100 zu allozieren und bereitzustellen sind. In einigen Beispielen analysiert die Reaktivierungssteuereinheit 106 den Modemdatenrahmen 112 zum Identifizieren des Listen-Interval-Felds 136, um zu bestimmen, wie lange die Netzdaten im Puffer 108 zu speichern sind. In Beispielen, die hierin offenbart werden, füllt die Computergerätplattform 100 den Modemdatenrahmen 112 (z. B. dem Listen-Interval-Feld 136 gefüllt) mit einer Pufferzeit (z. B. der Zeit, in der der Puffer 108 Netzdaten puffern soll) basierend auf einer Klasse von Netzdaten (z. B. einer QoS-Klasse oder einer Arbeitslastklasse) und einer Benutzerpräferenz (z. B. ob ein Benutzer das Sparen von Strom oder die Performanz der Computergerätplattform 100 vorzieht) auf.
2 ist ein Blockschaltbild der beispielhaften Computergerätplattform 100 gemäß 1 zum Generieren dynamischer Latenzwerte und dynamischer Interrupt-Auslöser basierend auf Netzverkehr und zum Koordinieren von Zielwartezeiten zwischen dem Funknetzgerät 104 und der Computergerätplattform 100 basierend auf dem Netzverkehr und Benutzeranforderungen. Bei den hierin genutzten Begriffen Netzverkehr, Netzdaten, Netzpaketdaten, ankommende Netzdaten und Paketdaten handelt es sich um Begriffe, die Daten definieren, die aus einem beispielhaften Netz 102 empfangen werden, in einem beispielhaften Speicher 204 zu speichern und durch einen beispielhaften Prozessor 206 auszuführen sind, um einen beispielhaften Vorgang durchzuführen. Bei den hierin genutzten Begriffen Interrupt-Auslöser und Interrupts handelt es sich um Begriffe, die Ereignisse definieren, die generiert werden, um auf den Speicher 204 der Computergerätplattform 100 zum Bereitstellen von Netzdaten zuzugreifen. Die beispielhafte Computergerätplattform 100 enthält den beispielhaften Speicher 204, den beispielhaften Prozessor 206, ein beispielhaftes Modem 208, einen beispielhaften lokalen Computerbus 210, ein beispielhaftes Stammkomplexbauelement 212 und einen beispielhaften Speichercontroller 214.
Die beispielhafte Computergerätplattform 100 in 2 enthält den beispielhaften Speicher 204 zum Speichern von Netzdaten zur darauffolgenden Ausführung durch den beispielhaften Prozessor 206. Bei dem beispielhaften Speicher 204 kann es sich um einen beliebigen geeigneten Speicher wie ein flüchtiges RAM (Random Access Memory), einen Cachespeicher etc. handeln. Der beispielhafte Speicher 204 ist mit dem beispielhaften Prozessor 206 und dem beispielhaften Speichercontroller 214 zum Speichern und Allozieren von Daten verbunden.
Die beispielhafte Computergerätplattform 100 in 2 enthält den beispielhaften Prozessor 206 zum Durchführen der Arbeitslastausführung von Netzdaten. Der beispielhafte Prozessor 206 kann eine CPU, ein FPGA, eine GPU, eine Beschleunigerkarte oder Hardware von einem beliebigen anderen Typ zur Ausführung von Arbeitslasten sein. Der beispielhafte Prozessor 206 enthält mehrere Energiemodi, die unter den Oberbegriffen „C-States“ und „C-Modi“ zusammengefasst werden. Die C-States ermöglichen ein Eintreten des beispielhaften Prozessors 206 in jeweilige Stromsparmodi. Ein erster C-State (C0) gibt zum Beispiel an, dass der Prozessor 206 bei hundertprozentiger Stromzufuhr betrieben wird. Ein zweiter C-State (C1) gibt an, dass nur ein Teil des beispielhaften Prozessors 206 bei hundertprozentiger Stromzufuhr betrieben wird, während hingegen ein anderer Teil abgeschaltet ist (dem also kein Strom zugeführt wird). Ein dritter C-State (C2) gibt an, dass über die Hälfte der Hardware im beispielhaften Prozessor 206 abgeschaltet ist, während hingegen ein kleinerer Teil der Prozessorhardware immer noch betrieben wird. Ein vierter C-State (C3) gibt an, dass der beispielhafte Prozessor 206 in einem Schlafzustand ist (die Hardware ist z. B. abgeschaltet und dem Prozessor 206 wird weniger Strom zugeführt). In einigen Beispielen tritt der Prozessor 206 in unterschiedliche C-States ein, die mit unterschiedlichen, oben nicht beschriebenen Stromsparstufen korrespondieren. Wenn der beispielhafte Prozessor 206 in einen C-State oberhalb des ersten C-State eintritt, verringert sich der Stromverbrauch der beispielhaften Computergerätplattform 100, wodurch mithin die Batterielebensdauer verlängert wird. Der beispielhafte Prozessor 206 wird basierend auf dem Typ von Arbeitslasten, die vom Prozessor 206 auszuführen sind, und basierend auf Benutzeranforderungen, die für die Arbeitslast und/oder die Computergerätplattform 100 ausgewählt werden, über die Stufe des C-State informiert, in den einzutreten ist. Der C-State wird zum Beispiel basierend auf Latenzwerten bestimmt, wobei Folgendes gilt: Je größer der Latenzwert, desto größer ist der C-State und desto weniger Strom wird mithin verbraucht.
Die beispielhafte Computergerätplattform 100 in 2 enthält das beispielhafte Modem 208 zum Vermitteln einer Datenkommunikation zwischen dem beispielhaften Netz 102 und dem beispielhaften Prozessor 206 sowie zum Koordinieren eines Datenaustausches zwischen dem beispielhaften Modem 208 und dem beispielhaften Funknetzgerät 104 gemäß 1. Das beispielhafte Modem 208 kann Netzdaten in von dem beispielhaften Prozessor 206 les- und ausführbare Informationen umwandeln. Das beispielhafte Modem 208 kann Typen empfangener Netzdaten (z. B. den Arbeitslast- oder Verkehrstyp) bestimmen und Nachrichten (z. B. Latenzwertnachrichten für den Prozessor 206 und Zielwartezeitnachrichten für das Funknetzgerät 104), die eine Koordinierung der Netzdaten basierend auf den bestimmten Typen ermöglichen, generieren. Zusätzlich oder alternativ kann der beispielhafte Prozessor 206 (z. B. eine CPU oder ein FPGA) die Typen empfangener Netzdaten bestimmen und die Typen dem Modem 208 zur Generierung von Latenznachrichten bereitstellen. Das beispielhafte Modem 208 kann Netzdaten puffern, sodass der beispielhafte Prozessor 206 in unterschiedliche C-States eintreten kann. Das beispielhafte Modem 208 kann Interrupts zum Reaktivieren des Speichers 204 und des Prozessors 206 zum Abrufen der Netzdaten generieren. In einigen Beispielen handelt es sich bei dem Modem 208 um eine Netzkarte (NIC). Zusätzlich oder alternativ ist das Modem 208 möglicherweise eine beliebige geeignete Hardware- und/oder Softwareschnittstelle, die eine Datenkommunikation zwischen dem beispielhaften Funknetzgerät 104, dem beispielhaften Modem 208 und dem beispielhaften Prozessor 206 vermittelt (z. B. eine Pufferung und Interrupts koordiniert). Das beispielhafte Modem 208 kann abhängig von unterschiedlichen Zuständen der beispielhaften Computergerätplattform 100 (z. B. an oder aus) in unterschiedlichen Zuständen sein. Wenn die beispielhafte Computergerätplattform 100 an ist, kann das beispielhafte Modem 208 in einem Schlaf-, Leerlauf- oder aktiven Zustand sein. Die Zustände des beispielhaften Modems 208 sind zudem abhängig vom Netzverkehr vom beispielhaften Funknetzgerät 104 oder allgemeiner aus dem beispielhaften Netz 102. Das Modem 208 ist zum Beispiel aktiv, wenn das Modem 208 Daten aus dem Netz 102 empfängt, wenn das Modem 208 Daten an den Speicher 204 sendet, wenn das Modem 208 Daten über das Netz 102 an ein anderes Computergerät sendet etc. Das beispielhafte Modem 208 ist im Leerlauf, wenn das Modem 208 Daten aus dem beispielhaften Netz 102 puffert, wenn das Modem 208 keine über das Funknetzgerät 104 an das Netz 102 zu sendenden Netzdaten enthält, wenn das Modem 208 über keine über das Funknetzgerät 104 aus dem Netz 102 zu empfangenden Netzdaten verfügt etc. Das beispielhafte Modem 208 ist in einem Schlafzustand, wenn das beispielhafte Modem 208 gerade keine Daten aus dem beispielhaften Netz 102 und/oder von dem beispielhaften Speicher 204 empfängt, wenn die beispielhafte Computergerätplattform 100 aus ist etc. In einigen Beispielen ist der Zustand des Modems 208 den C-States des Prozessors 206 zugeordnet.
In einigen Beispielen ist das Modem 208 in einem Edge Device implementiert. Zum Beispiel können Verarbeitungstasks (z. B. die Funktionalität oder Vorgänge) des Modems 208 an ein Edge Device ausgelagert werden. In anderen Beispielen ist das Modem 208 in einer Cloud-Plattform implementiert. Es können zum Beispiel Verarbeitungstasks des Modems 208 ausgelagert und/oder in einer Cloud-Plattform virtualisiert werden. In solchen Beispielen reduziert das Modem 208 den Stromverbrauch der in der Computergerätplattform 100 bei der Verarbeitung verbraucht wird und die in der Computergerätplattform 100 laufenden (z. B. ausgeführten) Verarbeitungstasks. Das beispielhafte Modem 208 wird in Verbindung mit den 3, 4 und 9 unten noch ausführlicher beschrieben.
Die beispielhafte Computergerätplattform 100 in 2 enthält den beispielhaften Computerbus 210 zum Verbinden des beispielhaften Modems 208 mit dem beispielhaften Speichercontroller 214 und dem beispielhaften Prozessor 206. Der beispielhafte Computerbus 210 ermöglicht die Kommunikation zwischen dem Modem 208 und den anderen Elementen der beispielhaften Computergerätplattform 100. Der Computerbus 210 erhält zum Beispiel Meldungen, Nachrichten, Informationen oder Daten vom Modem 208 und leitet die Daten an die entsprechenden Hardwarekomponenten der Computergerätplattform 100. In einigen Beispielen ist der Computerbus 210 im Modem 208 enthalten. Zusätzlich oder alternativ enthält die beispielhafte Computergerätplattform 100 beliebig viele weitere Computerbusse 210 zum Verbinden unterschiedlicher Hardwarekomponenten der Computergerätplattform 100. Der beispielhafte Computerbus 210 ist ein PCI-e-Bauelement (PCI-e = Peripheral Component Interconnect Express). Zusätzlich oder alternativ ist der beispielhafte Computerbus 210 ein Accelerated Graphics Port (AGP), ein PCI-X-Bauelement (PCI-X = Peripheral Component Interconnect Extended) oder ein beliebiger sonstiger geeigneter Bus für den beispielhaften Prozessor 206.
Die beispielhafte Computergerätplattform 100 in 2 enthält das beispielhafte Stammkomplexbauelement 212 zum Verbinden des beispielhaften Speichers 204 und des beispielhaften Prozessors 206 mit dem beispielhaften Computerbus 210. Das beispielhafte Stammkomplexbauelement 212 generiert Transaktionsanforderungen im Auftrag des beispielhaften Prozessors 206, der durch einen lokalen Bus verbunden ist. Das beispielhafte Stammkomplexbauelement 212 kann eine Stammkomplexfunktionalität sein, die als diskretes Bauelement implementiert oder in den beispielhaften Prozessor 206 integriert ist. In einigen Beispielen ist das Stammkomplexbauelement 212 möglicherweise eine Host Bridge, die den Host (z. B. den Prozessor 206) mit dem Computerbus 210 verbindet.
Die beispielhafte Computergerätplattform 100 in 2 enthält den beispielhaften Speichercontroller 214 zum Speichern und Abrufen von Daten aus dem beispielhaften Speicher 204 basierend auf Befehlen vom beispielhaften Prozessor 206 und/oder vom beispielhaften Modem 208. Der Speichercontroller 214 enthält zum Beispiel eine Logik, die eine Eingabe (z. B. Befehle) ausliest und die Speicherung und Entfernung von Daten basierend auf der Eingabe abwickelt. In einigen Beispielen weist das Modem 208 den Speichercontroller 214 dazu an, Netzdaten an den Prozessor 206 zu übergeben, Kommunikationen mit dem Prozessor 206 zu unterbrechen etc.
In 3, auf die nunmehr eingegangen wird, wird ein Blockschaltbild des beispielhaften Modems 208 zum Generieren von Latenzwerten basierend auf Daten aus dem beispielhaften Netz 102 veranschaulicht. Das beispielhafte Modem 208 enthält eine beispielhafte Netzpaketsteuereinheit 302, eine beispielhafte Trainingssteuereinheit 304, eine beispielhafte Vorhersagesteuereinheit 306, eine beispielhafte Aktivitätsstatussteuereinheit 308, einen beispielhaften Latenzwertgenerator 310, einen beispielhaften Puffer 312, eine beispielhafte Netzverkehrssteuereinheit 314 und einen beispielhaften Benutzeranforderungswähler 316. Die punktierten Ablauflinien repräsentieren die Trainingsphase zum Trainieren eines Modells zum Vorhersagen von Arbeitslasttypen basierend auf den Netzdatenpaketen. Zum Beispiel erfolgen die von der Netzpaketsteuereinheit 302 und der Trainingssteuereinheit 304 durchgeführten Vorgänge in einer Lern- und/oder Trainingsphase der Computergerätplattform 100. Die durchgezogenen Ablauflinien repräsentieren die Inferenzphase zum Vorhersagen der Arbeitslasttypen basierend auf dem trainierten Modell. Zum Beispiel erfolgen die von der Netzpaketsteuereinheit 302, der Aktivitätsstatussteuereinheit 308, der Vorhersagesteuereinheit 306, dem Latenzwertgenerator 310, der Netzverkehrssteuereinheit 314 und dem Benutzeranforderungswähler 316 durchgeführten Vorgänge in einer Inferenz- und/oder Vorhersagephase. Es versteht sich, dass die unten in Verbindung mit dem beispielhaften Modem 208 beschriebenen Vorgänge in Verbindung mit dem beispielhaften Prozessor 206 gemäß 2 durchgeführt werden können. Der Prozessor 206 enthält zum Beispiel möglicherweise die beispielhafte Netzpaketsteuereinheit 302, die beispielhafte Trainingssteuereinheit 304, die beispielhafte Vorhersagesteuereinheit 306, die beispielhafte Aktivitätsstatussteuereinheit 308, den beispielhaften Latenzwertgenerator 310, den beispielhaften Puffer 312, die beispielhafte Netzverkehrssteuereinheit 314 und den beispielhaften Benutzeranforderungswähler 316. In einem solchen Beispiel enthält ein Modem, etwa das Modem 208, möglicherweise nicht die Verarbeitungsfähigkeiten oder die Hardware zum Ausführen der unten beschriebenen Vorgänge, und mithin führt der Prozessor 206 (z. B. eine CPU, ein FPGA, eine GPU und/oder ansonst eine Beschleunigerkarte) neben anderen Vorgängen auch die Vorgänge zum Trainieren eines Modells, zum Inferieren einer Arbeitslast und von Verkehrstypen der Netzdatenpakete, zum Generieren von Latenzwerten und zum Kommunizieren von Pufferzeiten an das Funknetzgerät 104 durch.
Das beispielhafte Modem 208 in 3 enthält die beispielhafte Netzpaketsteuereinheit 302 zum Steuern von Netzdatenpaketflüssen, die vom beispielhaften Funknetzgerät 104 her ankommen. Ein Netzdatenpaket ist eine formatierte Dateneinheit, die vom Funknetzgerät 104 transportiert wird und aus Nutzdaten (z. B. Steuerinformationen und Benutzerdaten) und fünf Tupel besteht: einer Quelladresse, einem Quellport, einer Zieladresse, einem Zielport und einem Protokoll. Das Netzdatenpaket enthält zum Beispiel ein so ähnliches Format wie der AP-Datenrahmen 110 gemäß 1, wobei die Nutzdaten der Frame-Body sind und die fünf Tupel der MAC-Header 114 sind. Die beispielhafte Netzpaketsteuereinheit 302 kann Netzdatenpakete, die zu unterschiedlichen Tupeln gehören, identifizieren und/oder trennen. Die Netzpaketsteuereinheit 302 erfasst zum Beispiel Netzdatenpakete, die mit unterschiedlichen Arbeitslasten korrespondieren können (z. B. laufen in der Computergerätplattform gleichzeitig eine E-Mail-Anwendung und ein Konferenzanruf). Die beispielhafte Netzpaketsteuereinheit 302 kann die unterschiedlichen Netzdatenpakete basierend auf den fünf Tupeln (z. B. dem MAC-Header 114) identifizieren, wobei, wenn ein erstes Netzdatenpaket und ein zweites Netzdatenpaket übereinstimmende Tupel aufweisen, die Netzdatenpakete folglich mit derselben Arbeitslast korrespondieren. Die beispielhafte Netzpaketsteuereinheit 302 wird in einem Trainingsmodus oder einem Inferenzmodus betrieben. Im Trainingsmodus gibt die Netzpaketsteuereinheit 302 die Netzdatenpakete zum Beispiel an die Trainingssteuereinheit 304 weiter. In anderen Beispielen gibt die Netzpaketsteuereinheit 302 im Inferenzmodus die Netzdatenpakete (z. B. über die Aktivitätsstatussteuereinheit 308 oder ein anderes Mittel für drahtlose und/oder drahtgebundene Kommunikation) an die Vorhersagesteuereinheit 306 weiter. Die beispielhafte Netzpaketsteuereinheit 302 gemäß 3 kann ein Mittel zur Steuerung implementieren. Das Steuerungsmittel ist eine Hardware, die mindestens einen Prozessor enthält.
Das beispielhafte Modem 208 in 3 enthält die beispielhafte Trainingssteuereinheit 304 zum Trainieren eines Modells zum Klassifizieren von Netzdatenpaketen nach einer Arbeitslastkategorie. Die beispielhafte Trainingssteuereinheit 304 erhält Netzdatenpakete von der beispielhaften Netzpaketsteuereinheit 302 und verarbeitet die Netzdatenpakete vorher zu Samples mit zugewiesenen Beschriftungen, wobei die Samples auf einen einzigen Netzfluss (z. B. eine Arbeitslast) bezogen sind und mehrere Paketmerkmale enthalten. Die beispielhafte Trainingssteuereinheit 304 gibt die Proben in ein beispielhaftes neuronales Netz ein und ermöglicht, dass das Modell durch die Merkmale der Samples und die zugewiesenen Beschriftungen lernt, mit welchem Arbeitslasttyp das betreffende Netzdatenpaket korrespondiert. Die Trainingssteuereinheit 304 klassifiziert Netzdatenpakete zum Beispiel nach einer Videokategorie, einer Spielkategorie, einer Audiokategorie, einer Streaming-Kategorie, einer Stapelkategorie, einer Analysekategorie und/oder einer Transaktionskategorie. Neben den oben genannten Kategorien kann die beispielhafte Trainingssteuereinheit 304 noch weitere Kategorien enthalten. Nach dem Training generiert und veröffentlicht die beispielhafte Trainingssteuereinheit 304 das trainierte Modell und stellt das Modell der beispielhaften Vorhersagesteuereinheit 306 bereit. Die beispielhafte Trainingssteuereinheit 304 wird in Verbindung mit 4 unten noch ausführlicher beschrieben. Die beispielhafte Trainingssteuereinheit 304 gemäß 3 kann ein Mittel zur Generierung implementieren. Das Generierungsmittel ist eine Hardware, die mindestens einen Prozessor enthält.
Das beispielhafte Modem 208 in 3 enthält die beispielhafte Vorhersagesteuereinheit 306 zum Kategorisieren von Netzdatenpaketen nach Arbeitslasttypen und zum Zuweisen korrespondierender Beschriftungen zu den Netzdatenpaketen. Die beispielhafte Vorhersagesteuereinheit 306 wird in einem Inferenzmodus betrieben, sodass die beispielhafte Vorhersagesteuereinheit 306 Netzdatenpakete von der beispielhaften Netzpaketsteuereinheit 302 in Echtzeit erhält, das heißt, die Vorhersagesteuereinheit 306 erhält momentane (z. B. aktuelle) Netzdatenpakete. Die beispielhafte Vorhersagesteuereinheit 306 weist den Netzdatenpaketen basierend auf der Klassifikation Prioritätsbeschriftungen nebst Arbeitslastkategoriebeschriftungen zu. Die Vorhersagesteuereinheit 306 analysiert zum Beispiel in den Netzdatenpaketen enthaltene Informationen (z. B. das Capability-Information-Feld 120 und/oder das optionale Feld 128 des AP-Datenrahmens 110), die mit Prioritätsanforderungen (z. B. der Dienstqualität (QoS)) der Arbeitslast für die Zuweisung von Prioritätsstufen zu den Netzdatenpaketen korrespondieren. Zum Beispiel korrespondiert ein erstes Netzdatenpaket, das der Spielkategorie angehört, mit einer hohen Prioritätsstufe relativ zu einem zweiten Netzdatenpaket, das einer Stapelkategorie angehört. Die Prioritätsstufen korrespondieren mit den Zeit- und Performanzanforderungen der Arbeitslast. Für einen Sprachanruf (z. B. in einer Audiokategorie) sind zum Beispiel eine minimale Latenz und eine hohe Performanz vom Speicher 204 und vom Prozessor 206 erforderlich, während für eine E-Mail (z. B. in der Stapelkategorie) die hohe Performanz und die minimale Latenz vom Speicher 204 und vom Prozessor 206 nicht erforderlich sind. In einigen Beispielen weist die Vorhersagesteuereinheit 306 Arbeitslastkategoriebeschriftungen (z. B. Arbeitslasttypbeschriftungen) zu und identifiziert Prioritätsbeschriftungen (z. B. eine QoS-Beschriftung), die im Frame-Body der Netzdatenpakete markiert sind. Einige Netzdatenpakete enthalten solche Prioritätsbeschriftungen, andere Netzdatenpakete enthalten sie nicht. Daher dient die beispielhafte Vorhersagesteuereinheit 306 dazu, Prioritätsbeschriftungen basierend auf der Arbeitslastkategorie zu bestimmen, wenn die Netzdatenpakete keine Prioritätsinformationen enthalten. In einigen Beispielen identifiziert die Vorhersagesteuereinheit 306 mehr als eine Arbeitslastkategorie für mehr als ein in der Netzpaketsteuereinheit 302 empfangenes Netzdatenpaket. Die Vorhersagesteuereinheit 306 empfängt zum Beispiel Eingaben von Datenpaketen, die zu einem einzigen Netzfluss gehören, analysiert jedoch mehrere Netzflüsse, die möglicherweise gleichzeitig gerade im Prozessor 206 laufen. In diesem Beispiel ist die Vorhersagesteuereinheit 306 daran beteiligt, wenn basierend auf Arbeitslastkategorien und Prioritätsbeschriftungen identifiziert wird, welche Netzflüsse zu puffern und welche nicht zu puffern sind. In einigen Beispielen gibt die Vorhersagesteuereinheit 306 eine Klassifikation und beschriftete Netzdatenpakete an den beispielhaften Latenzwertgenerator 310 aus. In einigen Beispielen wird die Vorhersagesteuereinheit 306 durch die Aktivitätsstatussteuereinheit 308 ausgelöst, damit sie Netzdatenpaketvorhersagen trifft. Die beispielhafte Vorhersagesteuereinheit 306 gemäß 3 kann ein Mittel zur Vorhersage implementieren. Das Vorhersagemittel ist eine Hardware, die mindestens einen Prozessor enthält.
Das beispielhafte Modem 208 in 3 enthält die beispielhafte Aktivitätsstatussteuereinheit 308 zum Bestimmen des Zustands des Modems 208. Die beispielhafte Aktivitätsstatussteuereinheit 308 kann bestimmen, ob das beispielhafte Modem 208 aktiv, im Leerlauf oder inaktiv ist. Die Aktivitätsstatussteuereinheit 308 kann zum Beispiel Informationen aus Hardware-Registern des Modems 208, die den Zustand des Modems 208 angeben, erhalten. In anderen Beispielen kann die Aktivitätsstatussteuereinheit 308 das Stammkomplexbauelement 212 gemäß 2 nach Informationen über den mit dem Zustand des Modems 208 korrespondierenden oder assoziierten Zustand des Prozessors 206 gemäß 2 (z. B. an oder aus) abfragen. In einigen Beispielen erfolgt bei jeder Aktualisierung des Zustands des Modems 208 auch eine Aktualisierung der Aktivitätsstatussteuereinheit 308. In einigen Beispielen sendet die Aktivitätsstatussteuereinheit 308 einen Auslöseimpuls an die Vorhersagesteuereinheit 306, wenn das Modem 208 in einem aktiven Zustand ist. Die beispielhafte Aktivitätsstatussteuereinheit 308 gemäß 3 kann ein Mittel zur Bestimmung implementieren. Das Bestimmungsmittel ist eine Hardware, die mindestens einen Prozessor enthält.
Das beispielhafte Modem 208 in 3 enthält den beispielhaften Latenzwertgenerator 310 zum Generieren von Latenzwerten basierend auf der Klassifikation und/oder den Beschriftungen von Netzdatenpaketen. Der beispielhafte Latenzwertgenerator 310 kann entsprechende Latenzwerte für unterschiedliche Arbeitslasten bestimmen. Wie oben erwähnt, ist ein Latenzwert ein Wert für die Zeit, in der der beispielhafte Prozessor 206 in einem energiesparenden C-State (z. B. C1, C2 oder C3) sein kann. Darüber hinaus korrespondiert der Latenzwert mit einem Wert für die Zeit, in der das beispielhafte Modem 208 Netzpaketdaten puffern soll. In einigen Beispielen ermöglicht der Latenzwert, dass das Modem 208 bestimmt, wie lange das Funknetzgerät 104 Netzpaketdaten puffern soll. In einem solchen Beispiel können das Modem 208 und folglich die gesamte Computergerätplattform 100 so lange in einem Stromsparzustand sein, bis das Modem 208 reaktiviert wird, damit es die gepufferten Daten vom Funknetzgerät 104 empfängt. In einigen Beispielen korrespondiert die Zeit, in der das beispielhafte Modem 208 Netzpaketdaten puffern soll, mit einem Interrupt Coalescing (z. B. einer Zurückhaltung von Interrupts an den Speicher 204 und/oder den Prozessor 206). Wenn das Modem 208 Netzpaketdaten puffert, führt das Modem 208 zum Beispiel ein Interrupt Coalescing durch. In einigen Beispielen generiert das Modem 208 bei einem Timeout (z. B. beim Ablauf der Pufferzeit) einen Interrupt für das eine oder die mehreren im Modem 208 gepufferten Netzdatenpakete.
Der beispielhafte Latenzwertgenerator 310 ist in Kommunikation mit dem beispielhaften Computerbus 210, der beispielhaften Vorhersagesteuereinheit 306, der beispielhaften Aktivitätsstatussteuereinheit 308 und dem beispielhaften Puffer 312. In einigen Beispielen enthält der Latenzwertgenerator 310 vordefinierte Informationen darüber, welche Latenzwerte mit unterschiedlichen Arbeitslasttypen korrespondieren. Zum Beispiel kann eine Tabelle, die Arbeitslasttypen Latenzwerten zuordnet, in einem Speicher (nicht gezeigt) des Modems 208, im Speicher 204 etc. gespeichert sein. In einigen Beispielen generiert der Latenzwertgenerator 310 Latenzwerte basierend auf dem Zustand des Modems 208. Die Aktivitätsstatussteuereinheit 308 kann zum Beispiel den Latenzwertgenerator 310 auslösen, damit er Werte für eine hohe Latenz generiert, wenn das Modem 208 in einem Schlaf- oder Leerlaufzustand ist. In einigen Beispielen ist der Latenzwertgenerator 310 in außerhalb des Modems 208 befindlicher Hardware der Computergerätplattform 100 implementiert. Den beispielhaften Latenzwertgenerator 310 kann zum Beispiel der Computerbus 210 implementieren. Der beispielhafte Latenzwertgenerator 310 gemäß 3 kann ein Mittel zur Generierung implementieren. Das Generierungsmittel ist eine Hardware, die mindestens einen Prozessor enthält.
Das beispielhafte Modem 208 in 3 enthält den beispielhaften Puffer 312 zum Speichern von Netzdatenpaketen in einem vom beispielhaften Latenzwertgenerator 310 vorgegebenen Zeitraum. Der beispielhafte Puffer 312 kann ein Cachespeicher, ein oder mehrere Latches oder ein sonstiger geeigneter Speicher zum Speichern von Netzdatenpaketen sein. In einigen Beispielen speichert die Netzpaketsteuereinheit 302 die Netzdatenpakete im Puffer 312, und der Puffer 312 entfernt die Netzdatenpakete an den Speicher 204, solange kein Befehl vom Latenzwertgenerator 310 vorliegt. Ein solcher Befehl kann einen Interrupt zum Reaktivieren des Speichers 204 und/oder des Prozessors 206 zum Empfangen der Netzdatenpakete enthalten. In anderen Beispielen puffert das Funknetzgerät 104 die Netzdatenpakete, und mithin puffert der Puffer 312 die Netzdatenpakete nicht.
Das beispielhafte Modem 208 in 3 enthält die beispielhafte Netzverkehrssteuereinheit 314 zum Generieren von Zielwartezeitparametern und/oder -übersprungzeitparametern basierend auf den Arbeitslastanforderungen (z. B. Prioritätsanforderungen) und Benutzeranforderungen. Ein Zielwartezeitparameter, wie hierin genutzt, ist ein Zeitintervall, das in Zeiteinheiten definiert ist und angibt, wann das beispielhafte Modem 208 reaktiviert wird, um Netzverkehr von dem beispielhaften Funknetzgerät 104 zu empfangen. Ein Übersprungparameter, wie hierin genutzt, korrespondiert damit, wie oft das beispielhafte Modem 208 ein Beacon-Intervall überspringen (z. B. kein Netzpaket abrufen) wird. Die beispielhafte Netzverkehrssteuereinheit 314 empfängt Vorhersagen von der beispielhaften Vorhersagesteuereinheit 306, um Zielwartezeitparameter und/oder Übersprungparameter zu bestimmen. In einigen Beispielen empfängt die Netzverkehrssteuereinheit 314 Latenzwerte vom Latenzwertgenerator 310, um Zielwartezeitparameter und/oder Übersprungparameter zu bestimmen. Die beispielhafte Netzverkehrssteuereinheit 314 ist über die beispielhafte Netzpaketsteuereinheit 302 in Kommunikation mit dem Funknetzgerät 104. Die Netzverkehrssteuereinheit 314 handelt mit dem Funknetzgerät 104 über die Netzpaketsteuereinheit 302 zum Beispiel Zielwartezeitparameter und/oder -übersprungzeitparameter aus. In einigen Beispielen generiert die Netzverkehrssteuereinheit 314 aufgefüllte Datenrahmen, die den Zielwartezeitparameter enthalten, um mit dem Funknetzgerät 104 Wartezeiten auszuhandeln. Diese Wartezeiten (z. B. Zielwartezeiten und -übersprungzeiten) werden basierend auf einem Ausgleich zwischen dem Stromverbrauch und der Performanz oder genauer Arbeitslast- und Benutzeranforderungen bestimmt. Die beispielhafte Netzverkehrssteuereinheit 314 ermöglicht zufallsgesteuerte Zugriffe über Wi-Fi, sodass eine angemessene Koordinierung zwischen dem beispielhaften Funknetzgerät 104 und der Computergerätplattform 100 erfolgt. Die beispielhafte Netzverkehrssteuereinheit 314 wird in Verbindung mit 9 unten noch ausführlicher beschrieben.
Das beispielhafte Modem 208 in 3 enthält den beispielhaften Benutzeranforderungswähler 316 zum Auswählen und Aktualisieren eines Benutzeranforderungsstatus der Computergerätplattform 100. Der beispielhafte Benutzeranforderungswähler 316 kommuniziert mit dem beispielhaften Computerbus 210, um Benutzereingaben aus dem beispielhaften Prozessor 206 und/oder dem beispielhaften Speicher 204 abzurufen. In einigen Beispielen empfangen/empfängt der Prozessor 206 und/oder der beispielhafte Speicher 204 von einem Display der Computergerätplattform 100 Informationen über Benutzeranforderungen. Eine Benutzeranforderung, wie hierin genutzt, ist eine von einem Benutzer der Computergerätplattform 100 bestimmte Präferenz für das Verlängern der Batterielebensdauer oder eine optimale Performanz. In einigen Beispielen enthalten die Präferenzen ein Verhältnis zugunsten des Sparens von Strom, ein Verhältnis zugunsten einer Performanzerhöhung, ein Verhältnis sowohl zugunsten des Sparens von Strom als auch zugunsten einer Performanzerhöhung oder andere Stromverbrauch-Performanz-Verhältnisse. Ein Verhältnis kann eine Präferenz stärker als eine andere Präferenz oder beide Präferenzen gleich gewichten.
Der Benutzer gibt zum Beispiel über eine Benutzerschnittstelle wie einen Anzeigebalken an, dass auf dem Computergerät 100 ein Verhältnis von 70 % für das Sparen von Strom zu 30 % für die Arbeitslastperformanz optimal ist. In einem solchen Beispiel sitzt der Benutzer möglicherweise gerade im Flugzeug und hat keinen Zugriff auf eine Ladestation, und er möchte noch ein Arbeitsprojekt innerhalb einer Einreichungsfrist abschließen. In einem anderen Beispiel gibt der Benutzer zum Beispiel über die Benutzerschnittstelle wie etwa das Display der Computergerätplattform 100 an, dass auf dem Computergerät 100 ein Verhältnis von 65 % für die Arbeitslastperformanz zu 35 % für das Sparen von Strom optimal ist. In einem solchen Beispiel sitzt der Benutzer möglicherweise gerade im Flugzeug und sieht einen Film, den der Benutzer schon einmal gesehen hat, und er beschließt daher, ein Nickerchen zu machen oder ein Buch zu lesen, sobald der Film zu Ende ist. Diese Benutzeranforderungen informieren das Modem 208 oder genauer die beispielhafte Netzverkehrssteuereinheit 314 darüber, wie Zielwartezeitwerte oder -übersprungzeitwerte auszuwählen sind. Daher sendet der beispielhafte Benutzeranforderungswähler 316 Statusaktualisierungen, die mit den Benutzeranforderungsstatus korrespondieren, an die beispielhafte Netzverkehrssteuereinheit 314, damit sie beim Bestimmen von Zielwartezeitparametern oder -übersprungzeitparametern genutzt werden.
Im Folgenden wird ein beispielhafter Trainingsablauf des Modems 208 beschrieben. Während des Trainingsablaufs erhält die beispielhafte Netzpaketsteuereinheit 302 Datenpakete vom beispielhaften Funknetzgerät 104. In einigen Beispielen korrespondieren die Datenpakete nur mit einer Arbeitslast oder mit unterschiedlichen Arbeitslasten. In einigen Beispielen ist die Netzpaketsteuereinheit 202 derart konfiguriert, dass sie während des Trainingsmodus (z. B. als Packet Sniffer) Datenpakete aufzeichnet. Die Netzpaketsteuereinheit 202 wird zum Beispiel möglicherweise ausgelöst, damit sie eine oder mehrere jeweilige Arbeitslasten basierend auf einem Filter (z. B. einem von einem Betreiber, Entwickler etc. festgelegten Filter, das Netzdatenpakete filtert und diejenigen erfasst, die zu einer jeweiligen Arbeitslast gehören) erfasst, um den Typ einer Arbeitslast für das Training vorab zu identifizieren. Die Netzpaketsteuereinheit 202 ist zum Beispiel konfiguriert, um Typen von Datenpaketen, die zu der einen oder den mehreren jeweiligen Arbeitslasten gehören, zu erfassen. Die beispielhafte Netzpaketsteuereinheit 302 identifiziert Datenpakete, die mit einer einzigen Arbeitslast oder genauer einem einzigen Netzfluss korrespondieren. Ein Netzfluss ist definiert als alle Datenpakete (z. B. bidirektional), die zum selben 5-Tupel (z. B. Header) gehören. Daher identifiziert die beispielhafte Netzpaketsteuereinheit 302 Datenpakete mit demselben 5-Tupel (z. B. Quelladresse, Quellport, Zieladresse, Zielport und Protokoll) und erfasst sie, sodass eine Gruppe von mit einer Arbeitslast korrespondierenden Datenpaketen erzeugt wird. Die beispielhafte Netzpaketsteuereinheit 302 erfasst Datenpakete, die mit demselben Netzfluss korrespondieren, weil davon ausgegangen werden kann, dass die Datenpakete desselben Netzflusses dieselben Prioritätsanforderungen (z. B. QoS-Anforderungen) aufweisen und mithin Prioritätsanforderungen auf der Flussebene identifizierbar sind.
Die beispielhafte Netzpaketsteuereinheit 302 stellt die Datenpakete der beispielhaften Trainingssteuereinheit 304 für das Lernen und Klassifizieren der Datenpakete nach einer Arbeitslastkategorie bereit. Die Trainingssteuereinheit 304 erhält zum Beispiel die zu einem einzigen Fluss zusammengefassten Datenpakete und beginnt mit dem Prozess der Vorverarbeitung (z. B. dem Identifizieren eines Arbeitslasttyps) der Datenpakete und des Trainierens eines Modells, um den Arbeitslasttyp ohne die Unterstützung durch weitere Quellen (z. B. den Präprozessor, eine Datenbank oder Programmierer) zu identifizieren.
Die beispielhafte Trainingssteuereinheit 304 erhält Datenpakete von der beispielhaften Netzpaketsteuereinheit 302 und weist den Datenpaketen eine Prioritätsmarkierung und einen Arbeitslasttyp zu. Die Trainingssteuereinheit 304 bestimmt die Prioritätsmarkierung (z. B. die QoS) zum Beispiel möglicherweise basierend auf dem Frame-Body der Datenpakete. Es ist für unterschiedliche Arbeitslasten erforderlich, dass QoS-Markierungen ausführbar sind. Daher können Entwickler einer Anwendung (z. B. einer Arbeitslast) im Anwendungs-Header und/oder in den Metadaten den Typ der zum Ausführen der Funktionen der Anwendung erforderlichen Qualität definieren. Die Definition der Qualität kann bei der Übertragung durch ein Netz (z. B. das Netz 102) im Frame-Body der Datenpakete implementiert werden, und die beispielhafte Trainingssteuereinheit 304 kann den Frame-Body analysieren und die Dienstqualität identifizieren. Die QoS einer Arbeitslast kann definiert werden, indem Mindest- und/oder Höchstwerte, die die Computergerätplattform 100 während der Ausführung der Arbeitslast erreichen muss, definiert werden. Diese Werte korrespondieren möglicherweise mit dem Paketverlust, der Bitrate, dem Durchsatz, dem Jitter, der Übertragungsverzögerung, der Latenz, der Verfügbarkeit etc. Für Sprachanrufarbeitslasten kann zum Beispiel erforderlich sein, dass die Computergerätplattform 100 die Arbeitslast bei einem möglichst geringen Paketverlust und einer möglichst geringen Übertragungsverzögerung sowie einem hohen Durchsatz und einer hohen Bitrate ausführt. In einigen Beispielen handelt es sich bei der Prioritätsmarkierung (z. B. einer QoS-Markierung) um einen Zahlenwert, der mit einer Rangfolge korrespondiert, wobei ein kleinerer Wert angibt, dass für die Arbeitslast keine hohe Dienstqualität erforderlich ist, und ein größerer Wert angibt, dass für die Arbeitslast eine hohe Dienstqualität erforderlich ist. In einigen Beispielen definiert ein Anwendungs- oder Softwareentwickler möglicherweise keine Prioritätsanforderungen, oder das Funknetzgerät 104 unterstützt möglicherweise keine Prioritätsfeldfähigkeiten in den Datenpaketen. In einem solchen Beispiel kann die Trainingssteuereinheit 304 die Prioritätsmarkierung (z. B. eine Prioritätsanforderung) basierend auf dem Arbeitslasttyp identifizieren.
Die beispielhafte Trainingssteuereinheit 304 erhält Datenpakete von der beispielhaften Netzpaketsteuereinheit 302 (welche z. B. die QoS-Markierung enthalten oder nicht enthalten) und wählt n Paket-Samples aus den Datenpaketen aus, die mit demselben Netzfluss (z. B. einer Arbeitslast) korrespondieren, wobei n die Anzahl von Datenpaketen ist. Die Trainingssteuereinheit 304 bestimmt zum Beispiel die Anzahl n von Paket-Samples basierend auf den Rechenfähigkeiten des Modems 208. Das Modem 208 kann zum Beispiel beliebig groß sein und beliebig viele Hardwarekomponenten enthalten, die Daten in einer bestimmten Höchstmenge und bei einer jeweiligen Höchstgeschwindigkeit verarbeiten können. Daher wird n basierend auf Hardware- und/oder Softwarefunktionen des beispielhaften Modems 208 ausgewählt.
In einigen Beispielen wählt die Netzpaketsteuereinheit 302 n Paket-Samples aus, um sie der Trainingssteuereinheit 304 bereitzustellen. In einigen Beispielen weist die Netzpaketsteuereinheit 302 den n Paket-Samples die Arbeitslastbeschriftung vor der Bereitstellung der Samples für die Trainingssteuereinheit 304 basierend auf für diese Arbeitslast erfassten Paketverfolgungen zu. Zum Beispiel können die für die Netzpaketsteuereinheit 302 während des Trainingsmodus festgelegten Filter eine Speicherung oder Ablage von Paketverfolgungen in jeweiligen Dateien basierend auf den Paketeigenschaften erleichtern, wobei die Dateien basierend auf dem Arbeitslasttyp benannt werden. In der Datei packet_audio_streaming sind zum Beispiel möglicherweise Paket-Samples, die mit einer Audiostreaming-Arbeitslast korrespondieren, enthalten oder aufgenommen.
Die beispielhafte Trainingssteuereinheit 304 extrahiertfPaketmerkmale aus den n Samples, wobei f die Anzahl der Merkmale eines der n Paket-Samples ist. Die beispielhafte Trainingssteuereinheit 304 weist den n Paket-Samples und den ƒ Merkmalen basierend auf den für diese Arbeitslast erfassten Paketverfolgungen Arbeitslastbeschriftungen zu.
Wenn die beispielhafte Trainingssteuereinheit 304 die n Paket-Samples markiert oder ihnen Beschriftungen zuweist, trainiert die beispielhafte Trainingssteuereinheit 304 ein Modell mit den n Paket-Samples und ƒ Merkmalen. Die Trainingssteuereinheit 304 gibt zum Beispiel die n beschrifteten Paket-Samples mit ƒ korrespondierenden ƒ Merkmalen ein und ordnet die ƒ Merkmale den Arbeitslasttypen zu. Während des Trainings gibt die beispielhafte Trainingssteuereinheit 304 mehrere Mengen von n Paket-Samples ein, die mit unterschiedlichen Arbeitslasten korrespondieren. Die beispielhafte Trainingssteuereinheit 304 kann das Training unterbrechen, um das Modell im Vergleich mit einem Zufallsdatensatz (z. B. zufällig ausgewählten Datenpaketen) zu bewerten und/oder zu testen. Die Trainingssteuereinheit 304 nutzt zum Beispiel möglicherweise eine K-fache Kreuzvalidierung und teilt hierzu den Datensatz in eine Anzahl K von Teilmengen auf, wobei jede Teilmenge später als Testsatz genutzt wird. Stellt sich beim Testen und Bewerten des Modells heraus, dass eine bestimmte Fehlermenge erzielt worden ist, veröffentlicht die beispielhafte Trainingssteuereinheit 304 das Modell und stellt das veröffentlichte Modell der beispielhaften Vorhersagesteuereinheit 306 bereit.
In 4, auf die nunmehr eingegangen wird, ist ein Blockschaltbild der beispielhaften Trainingssteuereinheit 304 zum Trainieren des Modells zum Klassifizieren von Datenpaketen nach Arbeitslastkategorien veranschaulicht. Die beispielhafte Trainingssteuereinheit 304 enthält einen beispielhaften Präprozessor 402, einen beispielhaften Merkmalsextraktor 404, einen beispielhaften Modelltrainer 406, eine beispielhafte Fehler-Verlust-Steuereinheit 408 und einen beispielhaften Modellveröffentlicher 410.
Die beispielhafte Trainingssteuereinheit 304 in 4 enthält den beispielhaften Präprozessor 402 zum Zuweisen von Beschriftungen zu Datenpaketen. Der beispielhafte Präprozessor 402 erhält Datenpakete von der beispielhaften Netzpaketsteuereinheit 302 und wählt n Datenpakete, die zu einem einzigen Netzfluss gehören, zur Nutzung als Eingabe-Samples aus. In einigen Beispielen erhält der Präprozessor 302 n Datenpakete von der Netzpaketsteuereinheit 202. Der beispielhafte Präprozessor 302 weist den n Paket-Samples die Arbeitslastbeschriftung basierend auf den Paketverfolgungen und/oder Informationen zu, die mit den durch die beispielhafte Netzpaketsteuereinheit 202 erfassten Paketverfolgungen korrespondieren.
Der beispielhafte Präprozessor 402 extrahiert aus den n Paket-Samples ƒ Merkmale. Der Präprozessor 402 extrahiert zum Beispiel möglicherweise Merkmale wie die Paketlänge, die Zwischenankunftszeit, die Paketrichtung oder QoS-Markierungen. Der beispielhafte Präprozessor 402 extrahiert aus den Paket-Samples möglicherweise noch beliebige andere statistische Merkmale oder Eigenschaften, die beim Identifizieren des Arbeitslasttyps nützlich sind. In einigen Beispielen kann der Präprozessor 402 Merkmale extrahieren, die mit einem Header und/oder Frame-Body der Paket-Samples korrespondieren. Der Header von Paket-Samples kann für den Modelltrainer 306 beim Bestimmen des Arbeitslasttyps nützlich sein. Ein E-Mail-Paket enthält zum Beispiel möglicherweise eine bestimmte, speziell für E-Mails geltende Protokollkennung (die z. B. in dem optionale Feld 128 des AP-Datenrahmens 110 angegeben ist). In anderen Beispielen extrahiert der Präprozessor 402 mit den Zwischenpaketankunftszeiten der Paket-Samples korrespondierende Merkmale, die für den Modelltrainer 406 beim Bestimmen des Arbeitslasttyps nützlich sein können. Die Zwischenpaketankunftszeiten können zum Beispiel dazu genutzt werden, um zu inferieren, dass die Paket-Samples mit einer Audioarbeitslastkategorie korrespondieren. Wenn zum Beispiel Datenpakete im Durchschnitt alle 20 Millisekunden (ms) an das Modem 208 gesendet werden, kann die Zwischenpaketankunftszeit der n Paket-Samples ungefähr 20 ms mit einer normalen Abweichung betragen. In einem solchen Beispiel können Paket-Samples mit einer Zwischenpaketankunftszeit von ungefähr 20 ms mit einer Audiokategorie korrespondieren. Wenn die Paket-Samples darüber hinaus eine relativ kurze Länge (z. B. Bitlänge) sowie eine Zwischenpaketankunftszeit von 20 ms aufweisen, korrespondieren die Paket-Samples mit der Audiokategorie.
Der beispielhafte Präprozessor 402 in 4 weist die identifizierte Arbeitslastkategoriebeschriftung (die z. B. durch die erfassten Paketverfolgungen identifiziert worden ist) den n Paket-Samples zu und stellt die beschrifteten Paket-Samples dann dem beispielhaften Merkmalsextraktor 404 bereit. In einigen Beispielen werden den n Paket-Samples vom Präprozessor 402 Metadaten, die eine Zeichenfolge oder eine andere Kennung enthalten, angehängt oder vorangestellt. Darüber hinaus kann der beispielhafte Präprozessor 402 die n Paket-Samples mit einer mit den Prioritätsanforderungen des Netzflusses korrespondierenden Prioritätsmarkierung (z. B. einer QoS-Markierung) markieren. In einigen Beispielen erhält der Präprozessor 402 von der Netzpaketsteuereinheit 302 einen zweiten, einen dritten, einen vierten, einen fünften etc. Datensatz, die je mit unterschiedlichen Netzflüssen korrespondieren, und wählt n Paket-Samples und ƒ Merkmale aus, denen Arbeitslastbeschriftungen zugewiesen werden.
Die beispielhafte Trainingssteuereinheit 304 in 4 enthält den beispielhaften Merkmalsextraktor 404 zum Generieren eines Merkmalsvektors basierend auf vorverarbeiteten Paket-Samples und Merkmalen aus dem beispielhaften Präprozessor 402. Der beispielhafte Merkmalsextraktor 404 generiert oder bildet abgeleitete Werte von Merkmalsvektoren (die z. B. repräsentativ fürfMerkmale in n Paket-Samples sind), die informativ und nicht redundant sein sollen, um die Trainingsphase der Trainingssteuereinheit 304 zu vereinfachen. Ein Merkmalsvektor, wie hierin genutzt, ist ein n-dimensionales Array (z. B. ein Vektor) von Merkmalen, die eine beliebige Arbeitslastkategorie repräsentieren. Ein Merkmal könnte zum Beispiel eines der ƒ Merkmale sein, etwa eine Zwischenpaketankunftszeit, eine Protokollkennung, eine Paketrichtung, eine Quelle und ein Ziel, eine Paketlänge (z. B. eine Bitgröße) oder eine QoS. Der beispielhafte Merkmalsextraktor 404 reduziert verarbeitete Eingabedaten (z. B. die n Paket-Samples vom Präprozessor 402) zu einfacher überschaubaren Gruppen (z. B. Merkmalen) zur Verarbeitung und beschreibt gleichzeitig den ursprünglichen Netzfluss (z. B. Datenpakete) mit hinreichender Vollständigkeit und Genauigkeit. In dem veranschaulichten Beispiel von 4 identifiziert der Merkmalsextraktor 404 Merkmale in Datenpaketen, die mit der für sie vorgesehenen Einsatzweise (z. B. Arbeitslast) korrespondieren. Die vom Präprozessor 402 bereitgestellten Merkmalsdaten erleichtern das Training eines Modells durch den Modelltrainer 40 zum Klassifizieren eines Datenpakets nach einer Arbeitslastkategorie. Die Netzpaketsteuereinheit 302 gemäß 3 erfasst zum Beispiel eine Vielzahl von mit einem Videoanruf korrespondierenden Netzdatenpaketen vom Funknetzgerät 104. In einem solchen Beispiel extrahiert der Merkmalsextraktor 404 Datenpaketmerkmale, generiert Vektoren für die Datenpakete und stellt die Vektoren dem Modelltrainer 406 bereit. In einigen Beispielen extrahiert der Merkmalsextraktor 404 möglicherweise eine Vielzahl von mit großen Eingabedatenmengen korrespondierenden Merkmalen, er extrahiert möglicherweise weniger Merkmale, die mit einer kleineren Eingabedatenmenge korrespondieren, etc. Die Anzahl von fMerkmalen korrespondiert mit den Rechenfähigkeiten der beispielhaften Computergerätplattform 100. Nachdem der beispielhafte Merkmalsextraktor 404 Merkmale der Paket-Samples extrahiert hat, gibt der beispielhafte Merkmalsextraktor 404 einen Merkmalsvektor aus.
Die beispielhafte Trainingssteuereinheit 304 in 4 enthält den beispielhaften Modelltrainer 406 zum Trainieren eines Modells basierend auf dem ausgegebenen Merkmalsvektor (oder mehreren ausgegebenen Merkmalsvektoren) des Merkmalsextraktors 404. Der beispielhafte Modelltrainer 406 wird in einem Trainingsmodus betrieben, in dem er eine Vielzahl vorverarbeiteter Paket-Samples (z. B. einen oder mehrere Merkmalsvektoren) empfängt, eine Vorhersage generiert und basierend auf dieser Vorhersage ein Modell ausgibt. Damit der beispielhafte Modelltrainer 406 ein Modell trainieren kann, empfängt der Modelltrainer 406 Merkmalsvektoren, die mit vorverarbeiteten und bekannten Paket-Samples korrespondieren. Während eines Trainingsmodus wird zum Beispiel bestätigt, dass die Paket-Samples mit einer spezifischen Arbeitslast korrespondieren (es werden z. B. n Paket-Samples mit einer Arbeitslasttypmarkierung beschriftet), sodass die Datenpakete für das Lernen geeignet sind. Der Modelltrainer 406 empfängt zum Beispiel einen Merkmalsvektor, der die Merkmale der Paket-Samples angibt, und identifiziert ein Muster in den Merkmalen der Paket-Samples, das die Merkmale der Paket-Samples der Arbeitslastkategorie zuordnet, und gibt ein diese Muster erfassendes Modell aus. Der beispielhafte Modelltrainer 406 stellt das ausgegebene Modell der beispielhaften Fehler-Verlust-Steuereinheit 408 zur Bewertung des Modells bereit.
In einigen Beispielen implementiert der Modelltrainer 406 eine Aktivierungsfunktion, etwa eine ReLU-Funktion (ReLU = Rectified Linear Unit), damit in dem Modell Interaktionseffekte und nicht lineare Effekte besser berücksichtigt werden können. Ein Interaktionseffekt liegt vor, wenn sich eine Variable A auf eine Vorhersage (z. B. eine Arbeitslasttypvorhersage) abhängig vom Wert von B anders auswirkt. Nicht lineare Effekte bedeuten, dass sich der Wert einer Eingabe vergrößert, die Ausgabe sich aber nicht genauso schnell vergrößert, oder dass sich der Wert einer Eingabe verkleinert, was jedoch nicht bewirkt, dass sich die Ausgabe genauso schnell verkleinert. Die Aktivierungsfunktion kann eine Vielzahl von Aktivierungsschichten enthalten, die einen Vorhersagevektor an eine Softmax-Aktivierungsfunktion ausgeben. Eine solche Ausgabe kann ein vollverbundener Vektor sein, der Werte enthält, die Wahrscheinlichkeiten, dass die n Paket-Samples mit einer Video-Arbeitslast, einer Audio-Arbeitslast oder einer Streaming-Arbeitslast korrespondieren, angeben. Darüber hinaus können die Werte Wahrscheinlichkeiten, dass die n Paket-Samples mit einer weiteren Arbeitslast wie Webbrowsen, dem Herunterladen einer Datei etc. korrespondieren, angeben. Die Softmax-Aktivierungsfunktion ist eine Funktion, die einen Eingabevektor (z. B. den Vorhersagevektor oder einen vollverbundenen Vektor), der aus K reellen Zahlen besteht, verwendet und den Eingabevektor in eine Wahrscheinlichkeitsverteilung normalisiert, die aus K Wahrscheinlichkeiten, die proportional zu den Exponentialen der K reellen Zahlen sind, besteht. Einfacher ausgedrückt ermöglicht die Ausgabe der Softmax-Aktivierungsfunktion, dass die Ausgabevektoren der Aktivierungsfunktion als Wahrscheinlichkeiten interpretiert und hierzu die reellen Zahlen zu Werten zwischen 0 und 1 normalisiert werden. Der beispielhafte Modelltrainer 406 kann auch noch beliebige andere Verfahren implementieren, um zu lernen, wie Datenpakete nach einer Arbeitslastkategorie zu klassifizieren sind. In Beispielen, die hierin beschrieben werden, identifiziert der Modelltrainer 406 drei Kategorien: Video, Audio und Streaming. Der beispielhafte Modelltrainer 306 oder allgemeiner die beispielhafte Trainingssteuereinheit 304 ist jedoch nicht auf die drei oben genannten Kategorien beschränkt, sondern kann noch beliebige weitere Arbeitslasttypen identifizieren.
Die beispielhafte Trainingssteuereinheit 304 in 4 enthält die beispielhafte Fehler-Verlust-Steuereinheit 408 zum Bewerten der Performanz des Klassifikationsmodells. In einigen Beispielen implementiert die Fehler-Verlust-Steuereinheit 408 einen Kreuzentropieverlust. Bei einem Kreuzentropieverlust bestimmt die beispielhafte Fehler-Verlust-Steuereinheit 408, dass der Verlustwert um so größer ist, je mehr die vorhergesagte Wahrscheinlichkeit der Arbeitslastkategorie von der tatsächlichen Beschriftung, die vom beispielhaften Präprozessor 402 zugewiesen wird, abweicht. Bei einem Kreuzentropieverlust wäre der Verlust in einem perfekten Modell gleich null. Weil es jedoch hunderte verschiedene Arbeitslasttypen gibt, wäre es eventuell unpraktisch, wenn der erzielte Verlust gleich null wäre. Bestimmt daher die beispielhafte Fehler-Verlust-Steuereinheit 408, dass in dem Modell eine akzeptable Menge von Fehlern und/oder Verlusten enthalten ist, kann das Modell zur Veröffentlichung bereit sein. Bestimmt die beispielhafte Fehler-Verlust-Steuereinheit 408 in anderen Beispielen hingegen, dass das Modell keine hinreichende Menge von Fehlern und/oder Verlusten erreicht und/oder keine mit einer hinreichenden Menge von Fehlern und/oder Verlusten vereinbaren Wahrscheinlichkeiten ausgibt, kann die beispielhafte Fehler-Verlust-Steuereinheit 408 bestimmen, dass vom beispielhaften Modelltrainer 406 ein erneutes Training durchzuführen ist. Ein solches erneutes Training kann bewirken, dass das Modell die während der Aktivierung auf die n Datenpakete und die ƒ Merkmale angewendeten Gewichte anpasst, wobei die angepassten Gewichte einen Ausgabevektor, der eher den Erwartungen entspricht, generieren können. In einigen Beispielen ist die Fehler-Verlust-Steuereinheit 408 in Kommunikation mit dem Modelltrainer 406 und dem Modellveröffentlicher 410.
Die beispielhafte Trainingssteuereinheit 404 in 4 enthält den beispielhaften Modellveröffentlicher 410 zum Veröffentlichen des vom beispielhaften Modelltrainer 406 generierten Modells und zum Bereitstellen des Modells für die beispielhafte Vorhersagesteuereinheit 306 gemäß 3. Der Modellveröffentlicher 410 empfängt zum Beispiel ein Modell vom Modelltrainer 406 und wandelt es in ein verbrauchbares Format für die Veröffentlichung um. Ein verbrauchbares Format, wie hierin genutzt, ist definiert als ein Modell, das dafür vorgesehen ist, dass es genutzt und dann (z. B. durch ein aktualisiertes Modell) ersetzt wird. Der Modellveröffentlicher 410 wandelt das Modell in ein verbrauchbares Format um, um die Vorhersagesteuereinheit 306 während der Trainings- und Detektionsphase ständig zu aktualisieren. In einigen Beispielen bestimmt der Modellveröffentlicher 410, ob das empfangene Modell für eine Veröffentlichung akzeptabel ist. Der Modellveröffentlicher 410 empfängt zum Beispiel möglicherweise ein neues Modell, das mit Video-, Audio- oder Streaming-Arbeitslastklassen korrespondiert, jedoch ist dem Modellveröffentlicher 410 vorher möglicherweise bereits ein Modell bereitgestellt worden, das mit Video-, Audio- und Streaming-Arbeitslastklassen korrespondiert, für die dieses vorherige Modell von der Vorhersagesteuereinheit 306 nicht verbraucht (z. B. genutzt) worden ist. In diesem Beispiel bestimmt der Modellveröffentlicher 410 möglicherweise, dass das neue empfangene Modell nicht veröffentlicht werden kann (sondern z. B. erst dann, wenn das vorherige Modell verbraucht worden ist). Außerdem denkbar sind Beispiele, in denen ein Modell für eine Veröffentlichung nicht akzeptabel ist, wenn der Modellveröffentlicher 410 das Modell nicht in ein verbrauchbares Format umwandeln und daher das Modell der Vorhersagesteuereinheit 306 nicht bereitstellen kann.
Das beispielhafte Modem 208, um erneut auf das Modem 208 in 3 einzugehen, beginnt mit einem Inferenzvorgang, sobald die beispielhafte Trainingssteuereinheit 304 ein veröffentlichtes Modell an die beispielhafte Vorhersagesteuereinheit 306 ausgibt. Während der Inferenz prüft die beispielhafte Aktivitätsstatussteuereinheit 308 den Status des Modems 208. Die Aktivitätsstatussteuereinheit 308 bestimmt zum Beispiel, ob das Modem 208 in einem Schlaf, Leerlauf- oder aktiven Zustand ist. Die Aktivitätsstatussteuereinheit 308 prüft den Status des Modems 208, um zu bestimmen, ob dynamische Latenzwerte zu generieren sind. Wenn zum Beispiel bestimmt wird, dass das Modem 208 in einem Schlafzustand ist, muss der Latenzwertgenerator 310 keine Latenzwerte senden, sodass der Prozessor 206 mithin in den tiefstmöglichen Schlafzustand eintreten kann. Wenn die beispielhafte Aktivitätsstatussteuereinheit 308 bestimmt, dass das Modem 208 in einem Leerlaufzustand ist, benachrichtigt das beispielhafte Modem den Latenzwertgenerator 310, und der Latenzwertgenerator 310 generiert Latenzwerte, die damit korrespondieren, wie lange der beispielhafte Puffer 312 Daten maximal speichern kann. Der Puffer 312 wird zum Beispiel möglicherweise basierend auf einem Timer betrieben, der bewirkt, dass die im Puffer 312 gespeicherten Daten so lange gespeichert werden, bis ein Zeitgrenzwert erreicht ist, und dann entfernt werden. In einem solchen Beispiel legt der Zeitgrenzwert fest, wie lange der Puffer 312 Daten maximal speichern kann. Wenn das beispielhafte Modem 208 im Leerlauf ist (z. B. nicht ausgeschaltet ist, aber dennoch keine Befehle vom Prozessor 206 und/oder AP-Datenrahmen vom Funknetzgerät 104 empfängt), werden Arbeitslasten daher nicht ausgeführt, und das Modem 208 kann Daten puffern, sodass der Prozessor 206 in einen energiesparenden C-State eintreten kann. Bestimmt die beispielhafte Aktivitätsstatussteuereinheit 308, dass das Modem 208 im aktiven Zustand ist (z. B. bidirektionale Netzdatenpakete, die mit momentanen Arbeitslasten korrespondieren, empfängt), benachrichtigt die beispielhafte Aktivitätsstatussteuereinheit 308 die Vorhersagesteuereinheit 306, um Arbeitslasttypen zu inferieren.
Die beispielhafte Vorhersagesteuereinheit 306 kann Netzdatenpakete von der beispielhaften Netzpaketsteuereinheit 302 und/oder von der beispielhaften Aktivitätsstatussteuereinheit 308 erhalten. Erhält die Vorhersagesteuereinheit 306 in einigen Beispielen die Netzdatenpakete von der Netzpaketsteuereinheit 302, identifiziert die Netzpaketsteuereinheit 302 Datenpakete, die mit einem einzigen Netzfluss korrespondieren, und stellt sie der Vorhersagesteuereinheit 306 bereit. Die beispielhafte Vorhersagesteuereinheit 306 gibt die Netzdatenpakete, die mit einem einzigen Netzfluss korrespondieren, in das trainierte und veröffentlichte Modell ein. In einigen Beispielen extrahiert die Vorhersagesteuereinheit 306 Merkmale aus den Netzdatenpaketen. Die Merkmale unterstützen das Modell beim Bestimmen von Arbeitslastklassen/-typen des Netzflusses von Datenpaketen. Die beispielhafte Vorhersagesteuereinheit 306 generiert eine Ausgabewahrscheinlichkeit, die Wahrscheinlichkeiten von Arbeitslastklassen/-typen angibt. Die Vorhersagesteuereinheit 306 generiert zum Beispiel einen Wahrscheinlichkeitswert dafür, dass es sich bei dem Netzfluss um eine Audio-Arbeitslast handelt, einen Wahrscheinlichkeitswert dafür, dass es sich bei dem Netzfluss um eine Video-Arbeitslast handelt, oder einen Wahrscheinlichkeitswert dafür, dass es sich bei dem Netzfluss um eine Streaming-Arbeitslast handelt. In einigen Beispielen wird die Arbeitslastkategorie mit dem höchsten Wahrscheinlichkeitswert den Netzdatenpaketen des Netzflusses zugewiesen. Die Vorhersagesteuereinheit 306 generiert zum Beispiel ein Flag, eine Nachricht oder eine Meldung, das/die angibt, dass die momentanen Netzdatenpakete „Streaming“-Datenpakete sind, wenn die Netzdatenpakete mit einer Streaming-Arbeitslast korrespondieren.
Die beispielhafte Vorhersagesteuereinheit 306 stellt das Flag, die Nachricht oder die Meldung, das/die den momentanen Arbeitslasttyp angibt, dem beispielhaften Latenzwertgenerator 310 bereit. Der beispielhafte Latenzwertgenerator 310 generiert einen oder mehrere Latenzwerte basierend auf der Ausgabe der Vorhersagesteuereinheit 306. Der Latenzwertgenerator 310 bestimmt zum Beispiel, ob und wie lange die Netzdatenpakete gepuffert werden können. Bestimmt der Latenzwertgenerator 310 in einigen Beispielen, dass Netzdatenpakete dynamisch zu puffern sind, generiert der Latenzwertgenerator 310 zudem ein dynamisches Interrupt Coalescing. Ein Interrupt Coalescing und eine Latenztoleranzmeldung (z. B. das Melden von Latenzwerten) gehen Hand in Hand, das heißt, wenn die Latenzwerte größer werden, nimmt das Interrupt Coalescing zu (z. B. sendet das Modem 208 dann über längere Zeiträume keine Interrupt-Auslöser für den Zugriff auf den Speicher 204 und/oder den Prozessor 206 oder hält solche Interrupt-Auslöser zurück), und daher nimmt die Pufferung zu, und wenn die Latenzwerte kleiner werden, nehmen das Interrupt Coalescing und die Pufferung ab (z. B. sendet das Modem 208 dann über kürzere Zeiträume keine Interrupt-Auslöser für den Zugriff auf den Speicher 204 und/oder den Prozessor 206). Wenn der beispielhafte Latenzwertgenerator 310 einen oder mehrere Latenzwerte basierend auf der Ausgabe der Vorhersagesteuereinheit 306 generiert, generiert der beispielhafte Latenzwertgenerator 310 mithin auch Zeiten für das Unterbrechen eines C-State des Speichers 204 und/oder des Prozessors 206 (z. B. um sie zu reaktivieren).
In einigen Beispielen korrespondiert die Pufferung von Datenpaketen damit, wie zeitempfindlich der Arbeitslasttyp ist und/oder welche Prioritätsstufe des Arbeitslasttyps vorliegt. Daher bestimmt der beispielhafte Latenzwertgenerator 310 die Empfindlichkeitsstufe des Arbeitslasttyps. Der Latenzwertgenerator 310 bestimmt zum Beispiel, ob die Arbeitslast latenzempfindlich ist, wenn die Arbeitslast periodisch ist (z. B. werden Datenpakete in periodischen Abständen gesendet und erfordern Antworten in Echtzeit) und/oder interaktiv ist (z. B. wenn ein Anforderer wie der Prozessor 206 oder ein anderes mit dem Netz 102 verbundenes Bauelement an einer unmittelbaren Antwort interessiert ist und in der Regel vor dem Übergehen zu anderen Vorgängen auf die Ausführung der interaktiven Anforderung wartet). In anderen Beispielen bestimmt der Latenzwertgenerator 310, ob die Arbeitslast nicht latenzempfindlich ist. Der Latenzwertgenerator 310 bestimmt zum Beispiel, ob der Arbeitslasttyp mit einer aperiodischen Arbeitslast (z. B. einer Nicht-Echtzeit-Arbeitslast), einer nicht interaktiven Arbeitslast, einer Arbeitslast mit geringem Durchsatz oder einer zeitunempfindlichen Arbeitslast korrespondiert.
Sobald der beispielhafte Latenzwertgenerator 310 die Empfindlichkeitsstufe des Arbeitslasttyps inferiert, trifft der Latenzwertgenerator 310 eine Entscheidung darüber, welcher Latenzwert für den Arbeitslasttyp angemessen ist. Wenn die Arbeitslast zum Beispiel latenzempfindlich (z. B. zeitempfindlich) ist, generiert der Latenzwertgenerator 310 einen Wert für eine kurze Latenz, der ermöglicht, dass der Prozessor 206 in einen ersten oder zweiten Stromsparzustand eintritt. In einigen Beispielen basiert die Entscheidung auf einer C-State-Beendigungslatenz des Prozessors 206 sowie dem Arbeitslasttyp. Eine Beendigungslatenz ist die Zeit, die der Prozessor 206 benötigt, um einen Stromsparzustand zu verlassen (z. B. zu beenden) und in einen Stromausführungszustand einzutreten. Die Beendigungslatenzen sind zu berücksichtigen, wenn Pufferungsdauern bestimmt und Latenzwerte generiert werden, damit dem Prozessor 206 genügend Zeit für eine Reaktivierung (z. B. das Beenden des C-State) und das Abrufen gepufferter Datenpakete aus dem Puffer 312 gegeben wird. Wenn der Latenzwertgenerator 310 zum Beispiel liest, dass der Prozessor 206 eine Beendigungslatenz von 5 ms für den Übergang vom zweiten C-State in den ersten C-State aufweist, und (z. B. basierend auf dem Arbeitslasttyp) bestimmt, dass Datenpakete 20 ms lang gepuffert werden können, kann der Latenzwertgenerator 310 einen Latenzwert von 15 ms generieren, wodurch versucht wird auszulösen, dass der Prozessor 206 den zweiten C-State beendet und die Datenpakete binnen 20 ms ausführt.
Um die Dauer der Pufferung der Datenpakete zu bestimmen, inferiert der beispielhafte Latenzwertgenerator 310 die Empfindlichkeitsstufe der Arbeitslast. Die Vorhersagesteuereinheit 306 inferiert zum Beispiel, dass eine erste Menge von Netzdatenpaketen, die mit einem ersten Netzfluss korrespondieren, einen Videokonferenzanruf angeben. In einem solchen Beispiel bestimmt der Latenzwertgenerator 310, dass die Videoanrufarbeitslast periodisch und interaktiv, jedoch nicht besonders latenzempfindlich ist. So bestimmt der beispielhafte Latenzwertgenerator 310, dass es angemessen ist, die erste Menge von Datenpaketen eine kurze Zeit lang zu puffern, weil die Arbeitslast eine geringe Latenz zwischen dem Modem 208 und dem Prozessor 206 tolerieren kann. In einigen Beispielen bestimmt der Latenzwertgenerator 310 den Latenzwert (z. B. die Pufferzeit) basierend auf Merkmalen der ersten Menge von Datenpaketen. Der Latenzwertgenerator 310 kann zum Beispiel die für die Arbeitslast erforderliche Übertragungsverzögerung basierend auf der Prioritätsanforderung (z. B. einer QoS-Markierung) und basierend auf dem Latenzwert bei dieser minimal zulässigen Verzögerung der Paketübertragung bestimmen.
In anderen Beispielen inferiert die Vorhersagesteuereinheit 306, dass eine zweite Menge von Netzdatenpaketen, die mit einem zweiten Netzfluss korrespondieren, eine Videospielarbeitslast angeben. In einem solchen Beispiel bestimmt der Latenzwertgenerator 310, dass die Videospielarbeitslast latenzempfindlich und interaktiv ist. So bestimmt der beispielhafte Latenzwertgenerator 310, dass bei einer Pufferung der Datenpakete eine relativ hohe Anzahl von Performanzfehlern aufträte, und generiert mithin keine Latenzwerte. In einem solchen Beispiel kann der Latenzwertgenerator 310 die Netzpaketsteuereinheit 302 darüber informieren, dass die Netzdatenpakete über den Computerbus 210 und das Stammkomplexbauelement 212 direkt an den Prozessor 206 zu senden sind.
In noch einem weiteren Beispiel inferiert die Vorhersagesteuereinheit 306, dass eine dritte Menge von Netzdatenpaketen, die mit einem dritten Netzfluss korrespondieren, eine Stapelarbeitslast angeben. In einem solchen Beispiel bestimmt der Latenzwertgenerator 310, dass die Stapelarbeitslast aperiodisch, nicht interaktiv und nicht latenzempfindlich ist. So kann der beispielhafte Latenzwertgenerator 310 Latenzwerte generieren, die die dritte Menge von Datenpaketen eine angemessene Zeit lang puffern (z. B. bevor Performanzfehler der Stapelarbeitslast aufträten). Der beispielhafte Latenzwertgenerator 310 bestimmt den Latenzwert (z. B. und die Pufferzeit) basierend auf Merkmalen der dritten Menge von Datenpaketen. Der Latenzwertgenerator 310 bestimmt zum Beispiel möglicherweise die Zwischenpaketankunftszeit und basiert die Latenzwerte auf der Zeit zwischen den Paketankünften. In anderen Beispielen bestimmt der Latenzwertgenerator 310 möglicherweise die Paketlänge (z. B. die Bitgröße) und basiert die Latenzwerte auf dem für die Paketlänge erforderlichen Durchsatz.
Sobald der beispielhafte Latenzwertgenerator 310 den einen oder die mehreren Latenzwerte generiert, sendet der beispielhafte Latenzwertgenerator 310 über den beispielhaften Computerbus 210 eine Nachricht an das beispielhafte Stammkomplexbauelement 212, um den Prozessor 206 darüber zu informieren, dass er in einen bestimmten Stromsparzustand oder Stromausführungszustand eintreten soll. In einigen Beispielen implementiert der Latenzwertgenerator 310 oder allgemeiner das Modem 208 ein Latency Tolerance Reporting (LTR) und sendet hierbei die Latenzanforderungsnachrichten an den Prozessor 206 und den Speicher 204. Der LTR-Mechanismus ist zum Beispiel aufgrund der Implementierung der Vorhersagesteuereinheit 306 dynamisch, wodurch ein Ausgleich zwischen der Abwicklung von latenzempfindlichem Netzverkehr und dem Zulassen eines Schlafzustands des Prozessors 206 (der z. B. in einen Stromsparzustand eintritt) über längere Zeit geschaffen wird.
Darüber hinaus löst der beispielhafte Latenzwertgenerator 310, sobald der beispielhafte Latenzwertgenerator 310 den einen oder die mehreren Latenzwerte generiert, die Speicherung von Netzdatenpaketen im beispielhaften Puffer 312 aus (z. B. Interrupt Coalescing). Der Latenzwertgenerator 310 kann zum Beispiel einen mit dem Latenzwert korrespondierenden Timer starten, und die Netzpaketsteuereinheit 302 kann die Datenpakete im Puffer 312 speichern. In einigen Beispielen löst der Latenzwertgenerator 310 keine Datenpufferung aus. Wenn die Datenpakete zum Beispiel mit latenzempfindlichen Arbeitslasten korrespondieren, löst der Latenzwertgenerator 310 aus, dass die Netzpaketsteuereinheit 302 die Datenpakete an den Prozessor 206 und/oder den Speicher 204 sendet.
In den 3-4 ist veranschaulicht, wie sich das Modem 208 gemäß 2 beispielhaft implementieren lässt, jedoch können eines oder mehrere der Elemente, einer oder mehrere der Prozesse und/oder eines oder mehrere der Geräte, die in den 3-4 veranschaulicht sind, auch kombiniert, aufgeteilt, anders angeordnet, weggelassen, entfernt und/oder auf eine beliebige andere Weise implementiert werden. Ferner können die beispielhafte Netzpaketsteuereinheit 302, die beispielhafte Trainingssteuereinheit 304, die beispielhafte Vorhersagesteuereinheit 306, die beispielhafte Aktivitätsstatussteuereinheit 308, der beispielhafte Latenzwertgenerator 310, die beispielhafte Netzverkehrssteuereinheit 314, der beispielhafte Benutzeranforderungswähler 316, der beispielhafte Präprozessor 402, der beispielhafte Merkmalsextraktor 404, der beispielhafte Modelltrainer 406, die beispielhafte Fehler-Verlust-Steuereinheit 408, der beispielhafte Modellveröffentlicher 410 oder allgemeiner das beispielhafte Modem 208 gemäß 2 durch Hardware, Software, Firmware und/oder eine beliebige Kombination aus Hardware, Software oder Firmware implementiert werden. Mithin könnten die beispielhafte Netzpaketsteuereinheit 302, die beispielhafte Trainingssteuereinheit 304, die beispielhafte Vorhersagesteuereinheit 306, die beispielhafte Aktivitätsstatussteuereinheit 308, der beispielhafte Latenzwertgenerator 310, die beispielhafte Netzverkehrssteuereinheit 314, der beispielhafte Benutzeranforderungswähler 316, der beispielhafte Präprozessor 402, der beispielhafte Merkmalsextraktor 404, der beispielhafte Modelltrainer 406, die beispielhafte Fehler-Verlust-Steuereinheit 408, der beispielhafte Modellveröffentlicher 410 oder allgemeiner das beispielhafte Modem 208 zum Beispiel durch eine oder mehrere analoge oder digitale Schaltungen, eine oder mehrere logische Schaltungen, einen oder mehrere programmierbare Prozessoren, einen oder mehrere programmierbare Controller, einen oder mehrere Grafikprozessoren (GPU(s)), einen oder mehrere Digitalsignalprozessoren (DSP(s)), eine oder mehrere anwendungsspezifische integrierte Schaltungen (ASIC(s)), einen oder mehrere Logikbausteine (PLD(s)) und/oder einen oder mehrere vom Anwender programmierbare Logikbausteine (FPLD(s)) implementiert werden. Werden Vorrichtungs- oder Systemansprüche dieses Patents derart interpretiert, dass sie eine reine Software- und/oder Firmware-Implementierung abdecken, werden die beispielhafte Netzpaketsteuereinheit 302, die beispielhafte Trainingssteuereinheit 304, die beispielhafte Vorhersagesteuereinheit 306, die beispielhafte Aktivitätsstatussteuereinheit 308, der beispielhafte Latenzwertgenerator 310, die beispielhafte Netzverkehrssteuereinheit 314, der beispielhafte Benutzeranforderungswähler 316, der beispielhafte Präprozessor 402, der beispielhafte Merkmalsextraktor 404, der beispielhafte Modelltrainer 406, die beispielhafte Fehler-Verlust-Steuereinheit 408 und der beispielhafte Modellveröffentlicher 410 hiermit ausdrücklich so definiert, dass sie nichttransiente, computerlesbare, die Software und/oder die Firmware enthaltende Speicherelemente oder -platten wie etwa einen Speicher, eine DVD (Digital Versatile Disk), eine CD (Compact Disk), eine Blu-ray Disc etc. einschließen. Außerdem kann das beispielhafte Modem 208 gemäß 2 ein oder mehrere Elemente, einen oder mehrere Prozesse und/oder ein oder mehrere Geräte entweder zusätzlich zu denjenigen, die in den 3-4 veranschaulicht sind, oder an ihrer Stelle enthalten und/oder kann mehr als nur eines von beliebigen oder allen der veranschaulichten Elemente, mehr als nur einen von beliebigen oder allen der veranschaulichten Prozesse bzw. mehr als nur eines von beliebigen oder allen der veranschaulichten Geräte enthalten. Der Ausdruck „in Kommunikation“ sowie Varianten davon, wie hierin genutzt, schließt eine direkte oder indirekte Kommunikation durch eine oder mehrere Zwischenkomponenten ein, er setzt jedoch nicht voraus, dass eine direkte physische (z. B. drahtgebundene) und/oder ständige Kommunikation erfolgen muss, und kann darüber hinaus eine selektive Kommunikation in periodischen Intervallen, geplanten Intervallen, aperiodischen Intervallen und/oder durch einmalige Ereignisse enthalten.
In den 5-8 sind Ablaufschemata gezeigt, die repräsentativ für eine beispielhafte Hardwarelogik, beispielhafte maschinenlesbare Befehle, beispielhafte in Hardware implementierte Zustandsmaschinen oder beliebige Kombinationen davon zum Implementieren des Modems 208 gemäß den 2-4 sind. Bei den maschinenlesbaren Befehlen handelt es sich möglicherweise um ein oder mehrere ausführbare Programme oder einen oder mehrere Teile eines ausführbaren Programms zur Ausführung durch einen Computerprozessor oder eine Prozessorschaltung wie den Prozessor 1312, der in der beispielhaften Prozessorplattform 1300, die in Verbindung mit 13 unten erörtert wird, gezeigt ist. Das Programm kann in Software, die in einem nichttransienten, computerlesbaren Speichermedium, etwa auf einer CD-ROM, einer Diskette, einer Festplatte, einer DVD, einer Blu-ray Disc oder in einem zum Prozessor 1312 gehörenden Speicher gespeichert ist, realisiert sein, jedoch könnten das ganze Programm oder Teile davon statt durch den Prozessor 1312 alternativ auch durch andere Elemente ausgeführt werden und/oder in Firmware oder dedizierter Hardware realisiert sein. Ferner wird das beispielhafte Programm zwar mit Bezug auf die in den 5-8 veranschaulichte Ablaufschemata beschrieben, jedoch kommen alternativ noch viele weitere Verfahren zum Implementieren des beispielhaften Modems 208 in Frage. Zum Beispiel kann die Reihenfolge der Ausführung der Blöcke geändert werden, und/oder einige der beschriebenen Blöcke können geändert, entfernt oder kombiniert werden. Zusätzlich oder alternativ sind beliebige einzelne oder auch alle der Blöcke durch einen oder mehrere Hardwareschaltkreise (z. B. diskrete und/oder integrierte analoge und/oder digitale Schaltungsbauteile, ein FPGA, einen ASIC, einen Vergleicher, einen Operationsverstärker (OpAmp) oder einen Logikschaltkreis), die so strukturiert sind, dass sie den korrespondierenden Vorgang ohne Ausführung von Software oder Firmware durchführen, implementierbar. Die Prozessorschaltung kann über unterschiedliche Stellen in einem Netz verteilt oder lokal in einem der mehreren Geräten untergebracht sein (z. B. ein Mehrkernprozessor in einer einzigen Maschine oder mehrere über ein Server-Rack verteilte Prozessoren).
Die hierin beschriebenen maschinenlesbaren Befehle können in einem oder mehreren der folgenden Formate gespeichert sein: einem komprimierten Format, einem verschlüsselten Format, einem fragmentierten Format, einem kompilierten Format, einem ausführbaren Format, einem Paketformat etc. Maschinenlesbare Befehle, wie hierin beschrieben, können als Daten oder Datenstruktur (z. B. Abschnitte von Befehlen, Code oder Darstellungen von Code), die zum Erzeugen, Herstellen und/oder Produzieren maschinenlesbarer Befehle verwendet werden können, gespeichert sein. Die maschinenlesbaren Befehle sind zum Beispiel möglicherweise fragmentiert und in einem oder mehreren Speicherelementen und/oder einem oder mehreren Computergeräten (z. B. Servern), die sich an derselben Stelle oder an unterschiedlichen Stellen in einem oder mehreren Netzen (z. B. in der Cloud oder in Edge Devices) befinden, gespeichert. Damit die maschinenlesbaren Befehle von einem Computergerät oder einer anderen Maschine direkt gelesen, interpretiert und/oder ausgeführt werden können, erfordern sie möglicherweise eine oder mehrere der folgenden Aktionen: Installation, Modifizierung, Anpassung, Aktualisieren, Kombinieren, Ergänzen, Konfigurieren, Entschlüsselung, Dekomprimierung, Entpacken, Verteilung, Neuzuweisung, Kompilierung etc. Die maschinenlesbaren Befehle können zum Beispiel in mehreren Teilen, die einzeln komprimiert, verschlüsselt und in separaten Computergeräten gespeichert werden, gespeichert sein, wobei die Teile, wenn sie entschlüsselt, dekomprimiert und kombiniert werden, einen Satz ausführbarer Befehle bilden, die eine oder mehrere Funktionen, welche zusammen ein Programm wie das hierin beschriebene Programm bilden können, implementieren.
In einem weiteren Beispiel sind die maschinenlesbaren Befehle möglicherweise in einem Zustand gespeichert, in dem sie von einer Prozessorschaltung gelesen werden können, in dem jedoch zusätzlich, damit die Befehle in einem bestimmten Computergerät oder sonstigen Gerät ausgeführt werden können, eine Bibliothek (z. B. eine Dynamic Link Library (DLL)), ein Software-Development-Kit (SDK) oder eine Anwendungsprogrammierschnittstelle (API) nötig ist. In einem weiteren Beispiel müssen die maschinenlesbaren Befehle möglicherweise erst konfiguriert werden (z. B. müssen Einstellungen gespeichert, Daten eingegeben oder Netzadressen registriert werden), bevor die maschinenlesbaren Befehle und/oder das korrespondierende Programm (die korrespondierenden Programme) ganz oder teilweise ausgeführt werden können. Maschinenlesbare Medien, wie hierin genutzt, können mithin maschinenlesbare Befehle und/oder Programme unabhängig vom jeweiligen Format oder Zustand der maschinenlesbaren Befehle und/oder Programme, wenn diese gespeichert werden oder ansonst an einer anderen Stelle liegen oder gerade übertragen werden, enthalten.
Die hierin beschriebenen maschinenlesbaren Befehle sind durch eine beliebige frühere, aktuelle oder künftige Befehlssprache, Skriptsprache oder Programmiersprache darstellbar. Die maschinenlesbaren Befehle sind zum Beispiel unter Nutzung einer der folgenden Sprachen darstellbar: C, C++, Java, C#, Perl, Python, JavaScript, HyperText Markup Language (HTML), Structured Query Language (SQL), Swift etc.
Wie oben erwähnt, können die beispielhaften Prozesse gemäß den 5-8 unter Nutzung ausführbarer Befehle (z. B. computer- oder maschinenlesbarer Befehle) implementiert werden, die in einem nichttransienten, computer- oder maschinenlesbaren Medium, etwa auf einer Festplatte, in einem Flashspeicher, einem Festwertspeicher, auf einer CD, einer DVD, in einem Cache, einem Arbeitsspeicher oder einem beliebigen anderen Speicherelement oder einer beliebigen anderen Speicherplatte, in dem/der Informationen beliebig lang (z. B. über längere Zeitabschnitte, dauerhaft, kurz, vorübergehend bei einer Zwischenspeicherung und/oder bei einem Caching der Informationen) liegen können, gespeichert sind. Der Begriff nichttransientes, computerlesbares Medium, wie hierin genutzt, wird ausdrücklich so definiert, dass er computerlesbare Speicherelemente und -platten von einem beliebigen Typ einschließt, die Ausbreitung von Signalen und Übertragungsmedien aber ausschließt.
Die Begriffe „enthalten“ und „umfassen“ (einschließlich aller Formen und Zeiten) sind hierin als offene Begriffe zu verstehen. Es versteht sich also, dass, immer wenn in einem Anspruch einer der Begriffe „enthalten“ oder „umfassen“ in irgendeiner Form (z. B. umfasst, enthält, umfassend, enthaltend oder aufweisend) im Oberbegriff oder innerhalb einer Anspruchsdefinition verwendet wird, weitere Elemente, Begriffe etc. zusätzlich vorhanden sein können, ohne dass hierbei der Schutzbereich des betreffenden Anspruchs oder der betreffenden Definition verlassen wird. Wenn der Ausdruck „mindestens“ hierin dazu genutzt wird, um Wörter zum Beispiel im Oberbegriff eines Anspruchs aneinanderzureihen, ist er ebenso wie die Begriffe „umfassen“ und „enthalten“ als offener Begriff aufzufassen. Wird das Konjunktionspaar „und/oder“ zum Beispiel in der Form A, B und/oder C genutzt, kann eine beliebige Kombination oder Teilmenge aus A, B, C, etwa (1) nur A, (2) nur B, (3) nur C, (4) A mit B, (5) A mit C, (6) B mit C oder (7) A mit B und mit C, gemeint sein. Im Zusammenhang mit der Beschreibung von Strukturen, Komponenten, Einzelteilen, Objekten und/oder Dingen bezieht sich die Formulierung „mindestens eines von A und B“, wie hierin genutzt, auf Implementierungen, die Folgendes einschließen: (1) mindestens ein Element A, (2) mindestens ein Element B und (3) mindestens ein Element A und mindestens ein Element B. Analog bezieht sich die Formulierung „mindestens eines von A oder B“, wie hierin genutzt, im Zusammenhang mit der Beschreibung von Strukturen, Komponenten, Einzelteilen, Objekten und/oder Dingen auf Implementierungen, die Folgendes einschließen: (1) mindestens ein Element A, (2) mindestens ein Element B und (3) mindestens ein Element A und mindestens ein Element B. Im Zusammenhang mit der Beschreibung der Durchführung oder Abarbeitung von Prozessen, Befehlen, Aktionen, Vorgängen oder Schritten bezieht sich die Formulierung „mindestens eines von A und B“, wie hierin genutzt, auf Implementierungen, die Folgendes einschließen: (1) mindestens ein Element A, (2) mindestens ein Element B und (3) mindestens ein Element A und mindestens ein Element B. Analog bezieht sich im Zusammenhang mit der Beschreibung der Durchführung oder Abarbeitung von Prozessen, Befehlen, Aktionen, Vorgängen oder Schritten die Formulierung „mindestens eines von A oder B“, wie hierin genutzt, auf Implementierungen, die Folgendes einschließen: (1) mindestens ein Element A, (2) mindestens ein Element B und (3) mindestens ein Element A und mindestens ein Element B.
Werden hierin Wörter, die die Einzahl ausdrücken, genutzt (z. B. „ein“, „eine“, „erster“ oder „zweiter“), wird hierdurch nicht ausgeschlossen, dass auch die Mehrzahl gemeint sein könnte. Wird hierin auf „eine“ Einheit Bezug genommen, können eine oder mehrere dieser Einheit gemeint sein. Formulierungen mit den Wörtern „ein“ (oder „eine“), „ein oder mehrere“ oder „mindestens eines“ sind hierin untereinander austauschbar. Des Weiteren ist eine Vielzahl von Mitteln, Elementen oder Verfahrensschritten, selbst wenn diese einzeln aufgeführt werden, z. B. durch eine einzige Einheit oder einen einzigen Prozessor implementierbar. Darüber hinaus sind einzelne Merkmale möglicherweise in unterschiedlichen Beispielen oder Ansprüchen enthalten, sind aber trotzdem eventuell kombinierbar, denn dadurch, dass diese in unterschiedlichen Beispielen oder Ansprüchen enthalten sind, wird nicht stillschweigend angedeutet, dass eine Kombination von Merkmalen nicht möglich und/oder vorteilhaft ist.
5 veranschaulicht einen beispielhaften Vorverarbeitungsablauf D00 des beispielhaften Modems 208 gemäß den 2-4 zum Zuweisen von Arbeitslastbeschriftungen zu Datenpaketen eines einzigen Netzflusses. Am Block 502 erfasst die beispielhafte Netzpaketsteuereinheit 302 (3) Datenpakete vom beispielhaften Funknetzgerät 104 (2). Die Netzpaketsteuereinheit 302 verwendet zum Beispiel eine Capture-Packet-Trace-Funktion zum Abfangen von Datenpaketen zwischen dem Prozessor 206 (2) und anderen drahtlosen Clients. In einigen Beispielen ist die Netzpaketsteuereinheit 302 eine Schnittstelle (z. B. ein NIC), die Netzverkehr für die beispielhafte Computergerätplattform 100 erfasst.
Die beispielhafte Netzpaketsteuereinheit 302 identifiziert Datenpakete, die mit einem Netzfluss korrespondieren (Block 504). Die Netzpaketsteuereinheit 302 analysiert zum Beispiel den Header der Datenpakete, um übereinstimmende Tupel unter den Datenpaketen zu bestimmen. In einem solchen Beispiel gehören Datenpakete mit übereinstimmenden Tupeln (z. B. einer Liste mit einer Quelladressnummer, einer Quellportnummer, einer Zieladressnummer, einer Zielportnummer und einer Protokollnummer) zum selben Netzfluss. In einigen Beispielen speichert die Capture-Packet-Trace-Funktion abgefangene Datenpakete, die zum selben Netzfluss gehören, an jeweiligen Dateispeicherorten, die mit einer Arbeitslastkategorie korrespondieren.
Die beispielhafte Netzpaketsteuereinheit 302 stellt die Datenpakete, die mit einem einzigen Netzfluss korrespondieren, der beispielhaften Trainingssteuereinheit 304 oder genauer der beispielhaften Vorverarbeitungssteuereinheit 402 (4) bereit. Die beispielhafte Vorverarbeitungssteuereinheit 402 wählt n Paket-Samples aus den Datenpaketen, die mit dem Netzfluss korrespondieren, zur Nutzung als Eingabe-Samples aus (Block 506). Die Vorverarbeitungssteuereinheit 402 bestimmt zum Beispiel, wie viele Datenpakete analysiert und zum Trainieren eines Modells basierend auf den Rechenfähigkeiten des Modems 208 genutzt werden können. In einigen Beispielen wird für die Vorverarbeitungssteuereinheit 402 während der Implementierung (z. B. während der Entwicklung und der Fertigung) eine Sample-Höchstzahl vorgegeben. In anderen Beispielen fragt die Vorverarbeitungssteuereinheit 402 Hardware-Register, Modemspeicher etc. nach Informationen über Rechenfähigkeiten des Modems 208 ab.
Die beispielhafte Vorverarbeitungssteuereinheit 402 bestimmt einen Arbeitslasttyp der n Paket-Samples (Block 508). Die Vorverarbeitungssteuereinheit 402 analysiert zum Beispiel die Dateibenennung, Informationen und/oder sonstige Eigenschaften der Paketverfolgungen, die durch die Netzpaketsteuereinheit 302 erfasst werden. In einigen Beispielen bestimmt die Vorverarbeitungssteuereinheit 402 basierend auf den mit den Paketverfolgungen korrespondierenden Informationen, ob die Paket-Samples mit Echtzeit-Arbeitslasten, Nicht-Echtzeit-Arbeitslasten etc. korrespondieren. In anderen Beispielen bestimmt die Vorverarbeitungssteuereinheit 402, ob die n Paket-Samples mit einem spezifischeren Arbeitslasttyp wie etwa einem Videoanruf, einem Dateidownload oder einem Spiel korrespondieren.
Die beispielhafte Vorverarbeitungssteuereinheit 402 erhält ƒ Paketmerkmale aus den n Paket-Samples (Block 510). Die Vorverarbeitungssteuereinheit 402 analysiert zum Beispiel die Header und die Frame-Bodys der n Samples von Paketen hinsichtlich statistischer Informationen, etwa der Zwischenpaketankunftszeit, der Paketrichtung, der Protokollkennung, der Paketlänge oder der QoS-Klasse. In einigen Beispielen wird die Anzahl von Merkmalen ƒ basierend auf den Rechenfähigkeiten des Modems 208 ausgewählt.
Die beispielhafte Vorverarbeitungssteuereinheit 402 weist den n Paket-Samples und ƒ Paketmerkmalen eine Beschriftung zu (Block 512). Die Vorverarbeitungssteuereinheit 402 hängt zum Beispiel eine Kennung (z. B. eine Arbeitslasttypkennung), etwa eine Metadaten-Zeichenfolge, an die n Paket-Samples, die zum selben Netzfluss gehören, an. In einigen Beispielen ist die Beschriftung durch den beispielhaften Merkmalsextraktor 404 (4) und den beispielhaften Modelltrainer 406 (4) zum Trainieren eines Modells zum Lernen der Beschriftung basierend auf Merkmalen der Pakete identifizierbar.
Die beispielhafte Vorverarbeitungssteuereinheit 402 bestimmt, ob ein weiterer Arbeitsablauf vorhanden ist (Block 514). Die Vorverarbeitungssteuereinheit 402 hat zum Beispiel möglicherweise Datenpakete empfangen, die zu mehr als einem Netzfluss gehören und durch die Netzpaketsteuereinheit 302 getrennt oder zusammengefasst worden sind. Bestimmt die beispielhafte Vorverarbeitungssteuereinheit 402, dass ein weiterer Netzfluss, der zu beschriften ist, vorhanden ist (liefert der Block 514 z. B. den Wert JA zurück), wird bei der Steuerung zum Block 504 zurückgekehrt. Die Vorverarbeitungssteuereinheit 402 identifiziert zum Beispiel die nächste Menge von Datenpaketen, die zu einem einzigen Netzfluss gehören. Bestimmt die beispielhafte Vorverarbeitungssteuereinheit 402 hingegen, dass kein weiterer Netzfluss, der zu beschriften ist, vorhanden ist (liefert der Block 514 z. B. den Wert NEIN zurück), leitet die beispielhafte Vorverarbeitungssteuereinheit 402 den Trainingsprozess ein (Block 516). Die Vorverarbeitungssteuereinheit 402 löst zum Beispiel den Merkmalsextraktor 404 aus, indem sie beschriftete Samples von Datenpaketen sendet.
Der beispielhafte Vorverarbeitungsablauf 500 endet, sobald die beispielhafte Vorverarbeitungssteuereinheit 402 das Training eines Modells auslöst. Der beispielhafte Vorverarbeitungsablauf 500 wird hingegen wiederholt, wenn die beispielhafte Netzpaketsteuereinheit 302 Datenpakete, die mit einem unidentifizierten Netzfluss korrespondieren, erhält.
6 veranschaulicht einen beispielhaften Trainingsablauf 600 des beispielhaften Modems 208 gemäß den 2-4 zum Trainieren eines oder mehrerer Modelle zum Klassifizieren von Datenpaketen nach ihren jeweiligen Arbeitslastkategorien (z. B. basierend auf vorverarbeiteten Beschriftungen und Merkmalen). Am Block 602 erhält der beispielhafte Merkmalsextraktor 404 (4) eine Eingabe von n Paket-Samples, die mit einem Netzfluss korrespondieren. Der Merkmalsextraktor 404 erhält zum Beispiel n Paket-Samples von der Vorverarbeitungssteuereinheit 402 (4), die mit einem Arbeitslasttyp beschriftet worden sind.
Der beispielhafte Merkmalsextraktor 404 extrahiert ƒ Merkmale der n Paket-Samples und die korrespondierende Beschriftung (Block 604). Der Merkmalsextraktor 404 extrahiert zum Beispiel die ƒ Merkmale, die durch die Vorverarbeitungssteuereinheit 402 erhalten worden sind, wobeifeine Anzahl beschreibender Merkmale ist, die die statistischen Eigenschaften der n Paket-Samples beschreiben. Diese beschreibenden Merkmale kennzeichnen die vorgesehene Arbeitslast der Paket-Samples. Der beispielhafte Merkmalsextraktor 404 generiert einen Merkmalsvektor (Block 606). Der Merkmalsextraktor 404 generiert oder bildet zum Beispiel abgeleitete Werte von Merkmalsvektoren (die z. B. repräsentativ für ƒ Merkmale in n Paket-Samples sind), die informativ und nicht redundant sein sollen, um die Trainingsphase der Trainingssteuereinheit 304 zu vereinfachen.
Der beispielhafte Modelltrainer 406 (4) trainiert ein Modell zum Identifizieren des Arbeitslasttyps der n Paket-Samples basierend auf dem Merkmalsvektor (Block 608). Der Modelltrainer 406 empfängt zum Beispiel Merkmalsvektoren, die mit vorverarbeiteten und bekannten Paket-Samples korrespondieren, und identifiziert ein Muster in den Merkmalen der Paket-Samples, das die Merkmale der Paket-Samples der Arbeitslastkategorie zuordnet, und gibt ein diese Muster erfassendes Modell aus. In einigen Beispielen wird das ausgegebene Modell mit anderen Eingabe-Samples erneut trainiert, solange bis eine akzeptable Fehlermenge erreicht wird.
Der beispielhafte Modelltrainer 406 bestimmt, ob eine weitere Eingabe von n Paket-Samples verfügbar ist (Block 610). Der Modelltrainer 406 bestimmt zum Beispiel, ob Datenpakete, die mit anderen Arbeitslasten korrespondieren, verfügbar sind. Bestimmt der beispielhafte Modelltrainer 406, dass eine weitere Eingabe von n Paket-Samples verfügbar ist (liefert der Block 610 z. B. den Wert JA zurück), wird bei der Steuerung zum Block 602 zurückgekehrt. Bestimmt der Modelltrainer 406, dass keine weitere Eingabe von n Paket-Samples verfügbar ist (liefert der Block 610 z. B. den Wert NEIN zurück), generiert der beispielhafte Modelltrainer 406 ein Arbeitslasttypvorhersagemodell (Block 612). Der Modelltrainer 406 gibt das trainierte Modell zum Beispiel an den Modellveröffentlicher 410 (4) aus.
Der beispielhafte Modellveröffentlicher 410 veröffentlicht das Arbeitslasttypvorhersagemodell (Block 614). Der Modellveröffentlicher 410 empfängt zum Beispiel ein Modell vom Modelltrainer 406 und wandelt es in ein verbrauchbares Format für die Veröffentlichung um. Der beispielhafte Modellveröffentlicher 410 stellt das veröffentlichte Modell der beispielhaften Vorhersagesteuereinheit 306 (3) bereit, und der Trainingsablauf 600 endet. In einigen Beispielen wird der Trainingsablauf 600 wiederholt, wenn der Merkmalsextraktor 404 neue Paket-Samples von der Vorverarbeitungssteuereinheit 402 erhält.
7 veranschaulicht einen beispielhaften Inferenzablauf 700 des beispielhaften Modems 208 gemäß 3 zum Klassifizieren von Datenpaketen nach einer Arbeitslastkategorie und zum Generieren dynamischer Latenzwerte basierend auf den Datenpaketen. Am Block 702 liest der beispielhafte Latenzwertgenerator 310 (3) die Beendigungslatenzen aus dem beispielhaften Prozessor 206 (2) aus. Der Latenzwertgenerator 310 fragt zum Beispiel das Stammkomplexbauelement 212 ab, um Beendigungslatenzwerte für die unterschiedlichen Stromsparzustände des Prozessors 206 abzurufen. In einigen Beispielen kann das Stammkomplexbauelement 212 den Speichercontroller 214 nach Beendigungslatenzwerten abfragen.
Die beispielhafte Aktivitätsstatussteuereinheit 308 (3) bestimmt einen Zustand des beispielhaften Modems 208 (2) (Block 704). Die Aktivitätsstatussteuereinheit 308 bestimmt zum Beispiel, ob das Modem 208 in einem Schlaf, Leerlauf- oder aktiven Zustand ist, indem sie das Stammkomplexbauelement 212 (2) nach Informationen über den mit dem Zustand des Modems 208 korrespondierenden und/oder assoziierten Zustand des Prozessors 206 (2) (z. B. an oder aus) abfragt. Die beispielhafte Aktivitätsstatussteuereinheit 308 bestimmt, ob das Modem 208 in einem aktiven Zustand ist (Block 706). Die Aktivitätsstatussteuereinheit 308 bestimmt zum Beispiel, ob das Modem 208 Daten gerade ausführt, verarbeitet, empfängt oder sendet. Bestimmt die beispielhafte Aktivitätsstatussteuereinheit 308, dass das Modem 208 nicht in einem aktiven Zustand ist (liefert Block 706 z. B. den Wert NEIN zurück), endet der beispielhafte Inferenzablauf 700. Ist das Modem 208 zum Beispiel in einem Schlaf- oder Leerlaufzustand, generiert der Latenzwertgenerator 310 Werte für eine maximale Latenz, damit der Prozessor 206 in einen tiefen Stromsparzustand gehen kann, und benötigt die Informationen nicht zum Generieren dynamischer Latenzwerte.
Bestimmt die beispielhafte Aktivitätsstatussteuereinheit 308, dass das Modem 208 in einem aktiven Zustand ist (liefert Block 706 z. B. den Wert JA zurück), erhält die beispielhafte Vorhersagesteuereinheit 306 aktive Pakete, die mit einem oder mehreren Netzflüssen korrespondieren (Block 708). Die Netzpaketsteuereinheit 302 stellt zum Beispiel Netzdatenpakete, die erfasst worden sind, der Vorhersagesteuereinheit 306 zur Analyse und Klassifizierung bereit. In einigen Beispielen löst die Aktivitätsstatussteuereinheit 308 die Netzpaketsteuereinheit 302 aus, damit diese die aktiven Datenpakete an die Vorhersagesteuereinheit 306 sendet. In anderen Beispielen startet die Aktivitätsstatussteuereinheit 308 die Vorhersagesteuereinheit 306, damit diese die Netzpaketsteuereinheit 302 nach den aktiven Datenpaketen abfragt.
Die beispielhafte Vorhersagesteuereinheit 306 extrahiert Merkmale aus den aktiven Paketen (Block 710). Die Vorhersagesteuereinheit 306 identifiziert zum Beispiel statistische Informationen im Header des Datenpakets (in den Headern der Datenpakete) und extrahiert sie in einen Merkmalsvektor. Die beispielhafte Vorhersagesteuereinheit 306 bestimmt einen Arbeitslasttyp des Netzflusses basierend auf einer Eingabe der Merkmale in ein trainiertes Arbeitslasttypvorhersagemodell (Block 712). Die Vorhersagesteuereinheit 306 implementiert zum Beispiel das durch die Trainingssteuereinheit 304 (3) veröffentlichte Modell, um eine Vorhersage über die Klassifikation der aktiven Datenpakete auszugeben. In einigen Beispielen gibt die Vorhersage an, ob die aktiven Datenpakete am wahrscheinlichsten zu einer Echtzeit-Arbeitslast, einer Nicht-Echtzeit-Arbeitslast, einer Videoanrufarbeitslast, einer Spielarbeitslast, einer Dateidownload-Arbeitslast etc. gehören. In einigen Beispielen gibt die Vorhersagesteuereinheit 306 die Vorhersage des Arbeitslasttyps an den Latenzwertgenerator 310 aus.
Der beispielhafte Latenzwertgenerator 310 generiert Latenzwerte basierend auf dem Arbeitslasttyp und Beendigungslatenzen (Block 714). Der Latenzwertgenerator 310 bestimmt zum Beispiel möglicherweise basierend auf den Performanz- und Qualitätsanforderungen des Arbeitslasttyps sowie der Beendigungslatenz des Prozessors 206 einen möglichen akzeptablen Latenzwert. Weitere beispielhafte Befehle, die zum Implementieren von Block 714 genutzt werden können, werden unten in Verbindung mit 8 beschrieben.
Der beispielhafte Latenzwertgenerator 310 kommuniziert Latenzwerte an den Prozessor 206 (Block 716). Der Latenzwertgenerator 310 generiert zum Beispiel LTR-Nachrichten, die den Speichercontroller 214 (2) und/oder den Prozessor 206 darüber informieren, dass der Speichercontroller und/oder der Prozessor in einen Stromsparzustand oder einen Stromausführungszustand eintreten sollen/soll. In einigen Beispielen reduziert der Latenzwertgenerator 310 einen unnötigen Stromverbrauch der Computergerätplattform 100 durch das Senden solcher Latenzwerte an den Prozessor 206.
Das beispielhafte Latenzgenerierungsprogramm 714 beginnt unter jetziger Bezugnahme auf 8, sobald der beispielhafte Latenzwertgenerator 310 durch die beispielhafte Vorhersagesteuereinheit 306 ausgelöst wird, damit er Latenzwerte generiert. Der beispielhafte Latenzwertgenerator 310 bestimmt die Empfindlichkeitsstufe der Arbeitslast (Block 802). Der Latenzwertgenerator 310 bestimmt zum Beispiel, wie latenzempfindlich die Arbeitslast ist. Eine latenzempfindliche Arbeitslast korrespondiert mit einer Arbeitslast, für die während der Ausführung zu Performanzzwecken eine minimale Latenz erforderlich ist. In einigen Beispielen bestimmt der Latenzwertgenerator 310 latenzempfindliche Arbeitslasten basierend auf der vorhergesagten Klassifikation (z. B. der zugewiesenen Beschriftung) der Arbeitslast. Die Arbeitslastklassifikation korrespondiert zum Beispiel möglicherweise mit einer bestimmten Prioritätsstufe (z. B. einer QoS-Markierung), die auf die Empfindlichkeit der Arbeitslast bezogen ist.
Der beispielhafte Latenzwertgenerator 310 bestimmt, ob die Arbeitslast latenzempfindlich ist (Block 804). Der Latenzwertgenerator 310 bestimmt zum Beispiel, ob für die Arbeitslast ein hoher Durchsatz, wenig oder keine Latenz und/oder eine hohe Interaktion erforderlich ist. Bestimmt der beispielhafte Latenzwertgenerator 310, dass die Arbeitslast latenzempfindlich ist (liefert der Block 804 z. B. den Wert JA zurück), bestimmt der beispielhafte Latenzwertgenerator 310, dass der beispielhafte Puffer 312 aktive Pakete nicht puffern soll (Block 806). Der Latenzwertgenerator 310 bestimmt zum Beispiel, dass eine Pufferung der aktiven Datenpakete, die mit einer latenzempfindlichen Arbeitslast korrespondieren, Performanzprobleme bewirkt. Daher sind aktive Datenpakete der latenzempfindlichen Arbeitslast dem beispielhaften Speicher 204 und/oder dem beispielhaften Prozessor 206 sofort zur Verarbeitung bereitzustellen. Zusätzlich oder alternativ bestimmt der beispielhafte Latenzwertgenerator 310, dass der beispielhafte Puffer 108 des beispielhaften Funknetzgeräts 104 aktive Pakete nicht puffern soll.
Der beispielhafte Latenzwertgenerator 310 generiert erste Latenzwerte, die eine minimale Latenz zwischen dem beispielhaften Modem 208 und dem Prozessor 206 angeben (Block 808). Der Latenzwertgenerator 310 generiert zum Beispiel Zeitwerte, die angeben, zu welchen Zeiten der Prozessor 206 die aktiven Datenpakete empfangen und ausführen soll. In einigen Beispielen bewirken die ersten Latenzwerte, dass der Prozessor 206 die Pakete verarbeitet, um in den Stromausführungszustand einzutreten. Der beispielhafte Latenzwertgenerator 310 sendet die ersten Latenzwerte an den beispielhaften Prozessor 206.
Bestimmt der beispielhafte Latenzwertgenerator 310, dass die Arbeitslast nicht latenzempfindlich ist (liefert der Block 804 z. B. den Wert NEIN zurück), bestimmt der beispielhafte Latenzwertgenerator 310, ob die Arbeitslast periodisch ist (Block 810). Der Latenzwertgenerator 310 bestimmt zum Beispiel, ob Datenpakete, die mit der Arbeitslast korrespondieren, ankommen und/oder durch die Netzpaketsteuereinheit 302 in periodischen Abständen, häufig etc. abgerufen werden. Bei Arbeitslasten, die periodisch sein können, handelt es sich etwa um Videoanrufe (z. B. eine Skype- oder Webex-Besprechung) oder Audioanrufe.
Bestimmt der beispielhafte Latenzwertgenerator 310, dass die Arbeitslast periodisch ist (liefert der Block 810 z. B. den Wert JA zurück), bestimmt der beispielhafte Latenzwertgenerator 310 eine zum Puffern von Paketen maximal zulässige Zeit (Block 812). Der Latenzwertgenerator 310 bestimmt zum Beispiel basierend auf den Prioritätsanforderungen der Arbeitslast, wie lange die aktiven Datenpakete im Puffer 312 gepuffert werden können, bis sich dies negativ auf die Performanz auswirkt.
Der beispielhafte Latenzwertgenerator 310 generiert zweite Latenzwerte, die eine Latenz zwischen dem beispielhaften Modem 208 und dem beispielhaften Prozessor 206 angeben (Block 814). Die durch den Latenzwertgenerator 310 bestimmte Latenz korrespondiert mit 1) der zum Puffern der Datenpakete der periodischen Arbeitslast zulässigen maximalen Zeit und 2) den Beendigungslatenzen des Prozessors 206. In einigen Beispielen sind die zweiten Latenzwerte Zeitwerte, die ermöglichen, dass der Prozessor 206 in einen bestimmten Stromsparzustand eintritt. Der beispielhafte Latenzwertgenerator 310 sendet die zweiten Latenzwerte an den beispielhaften Prozessor 206.
Bestimmt der beispielhafte Latenzwertgenerator 310, dass die Arbeitslast nicht periodisch ist (liefert der Block 810 z. B. den Wert NEIN zurück), bestimmt der beispielhafte Latenzwertgenerator 310 eine maximale Zeit zum Puffern von Paketen (Block 816). Ist die Arbeitslast zum Beispiel weder latenzempfindlich noch periodisch, korrespondiert die Arbeitslast möglicherweise mit einer nicht interaktiven Arbeitslast. In einem solchen Beispiel sind die Datenpakete für die maximal mögliche Dauer, in der der Puffer 312 die Daten speichern kann, im Puffer 312 zu speichern (also zu puffern), da sich dies nicht negativ auf die Performanz auswirken wird. Zusätzlich oder alternativ kann der beispielhafte Latenzwertgenerator 310, wenn die Arbeitslast weder latenzempfindlich noch periodisch ist, über die beispielhafte Netzverkehrssteuereinheit 314 anfordern, dass der beispielhafte Puffer 108 des beispielhaften Funknetzgeräts 104 die Datenpakete für die maximal mögliche Dauer puffert.
Der beispielhafte Latenzwertgenerator 310 generiert dritte Latenzwerte, die die maximale Latenz, die zwischen dem beispielhaften Modem 208 und dem beispielhaften Prozessor 206 zulässig ist, angeben (Block 818). Der Latenzwertgenerator 310 generiert zum Beispiel Latenzwerte, die mit der maximalen Pufferzeit korrespondieren, wodurch ermöglicht wird, dass der Prozessor 206 in einen Stromsparzustand eintritt. Der beispielhafte Latenzwertgenerator 310 sendet die Latenzwerte an den beispielhaften Prozessor 206.
In 9, auf die nunmehr eingegangen wird, ist ein Blockschaltbild der beispielhaften Netzverkehrssteuereinheit 314 veranschaulicht. Die beispielhafte Netzverkehrssteuereinheit 314 dient zum Generieren von Zielwartezeitparametern und/oder -übersprungzeitparametern basierend auf Arbeitslasttypen, Benutzeranforderungen und Beacons (z. B. AP-Datenrahmen 110). Die beispielhafte Netzverkehrssteuereinheit 314 enthält einen beispielhaften Rahmenanalysator 902, einen beispielhaften Reaktivierungswähler 904, einen beispielhaften Vergleicher 906 und einen beispielhaften Datenrahmengenerator 908.
Die beispielhafte Netzverkehrssteuereinheit 314 in 9 enthält den beispielhaften Rahmenanalysator 902 zum Analysieren von Beacons (z. B. AP-Datenrahmen 110), um die Fähigkeit des beispielhaften Funknetzgeräts 104, das durch das beispielhafte Funknetzgerät 104 festgelegte Beacon-Intervall und/oder das Traffic-Indication-Map-Element zu bestimmen. Zusätzlich oder alternativ bestimmt der beispielhafte Rahmenanalysator 902 Eigenschaften von noch beliebigen anderen Typen, die mit dem beispielhaften Funknetzgerät 104 korrespondieren. Der beispielhafte Rahmenanalysator 902 identifiziert Informationen im Beacon und stellt die Informationen dem beispielhaften Reaktivierungswähler 904 bereit. Der beispielhafte Rahmenanalysator 902 empfängt die Beacons von der beispielhaften Netzpaketsteuereinheit 302 gemäß 3.
Die beispielhafte Netzverkehrssteuereinheit 314 in 9 enthält den beispielhaften Reaktivierungswähler 904 zum Generieren der Zielwartezeitparameter und/oder -übersprungzeitparameter basierend auf Informationen vom beispielhaften Rahmenanalysator 902, einer Vorhersage von der beispielhaften Vorhersagesteuereinheit 306 gemäß 3 und einem Benutzeranforderungsstatus vom beispielhaften Benutzeranforderungswähler 316 gemäß 3. In einigen Beispielen wird der Reaktivierungswähler 904 (z. B. von einem Entwickler, einem Benutzer oder einem Bediener) so konfiguriert, dass er Zielwartezeitparameter oder -übersprungzeitparameter für das Modem 208 generiert. In anderen Beispielen bestimmt der Reaktivierungswähler 904, ob basierend auf den Informationen vom Rahmenanalysator 902 ein aushandelbarer Zielwartezeitparameter zu generieren ist oder ob ein Übersprungzeitparameter zu generieren ist. Der Reaktivierungswähler 904 bestimmt zum Beispiel, ob das Funknetzgerät 104 einen Stromsparmodus gemäß der Definition im 802.11-Standard unterstützt. Der Stromsparmodus ist eine Funktion, die ermöglicht, dass die Computergerätplattform 100 Batteriestrom über die Zielwartezeitparameter spart. Der Stromsparmodus ermöglicht, dass die Computergerätplattform 100, um Energie zu sparen, basierend auf den Zielwartezeitparametern jeweils zwischen einem aktiven Zustand und einem Schlafzustand umschaltet. Das Funknetzgerät 104 gibt zum Beispiel im TIM-Element eines Beacons (z. B. im TIM-Element 126 des AP-Datenrahmens 110) an, ob gepufferte Unicast-Pakete oder Broadcast/Multicast-Übertragungen darauf warten, abgerufen zu werden (z. B. über einen DTIM-Indikator (DTIM = Delivery Traffic Indication Map) im TIM-Element 126). Das beispielhafte Modem 208 wird pro DTIM reaktiviert, damit es Multicast- und/oder Broadcast-Datenpakete empfängt, und es wird reaktiviert, damit es das TIM-Element 126 des Beacons prüft, um zu bestimmen, ob das Funknetzgerät 104 gerade Datenpakete puffert. Wenn das Modem 208 oder genauer die Netzpaketsteuereinheit 302 in einigen Beispielen bestimmt, dass gepufferte Datenpakete vorhanden sind, ruft das Modem 208 korrespondierende Pakete in einer im 802.11-Standard definierten Prozedur ab. Das Modem 208 überträgt zum Beispiel einen PS-Poll-Rahmen (PS = Power Save) an das Funknetzgerät 104. Der beispielhafte Reaktivierungswähler 904 ermöglicht längere Schlafzyklen des Modems 208 und daher weniger häufige Reaktivierungen des Modems 208 (in einigen Beispielen wird es z. B. nicht pro DTIM reaktiviert), indem effiziente Zielwartezeitparameter und/oder effiziente Übersprungzeitparameter generiert werden. Die Effizienz der Parameter hängt vom Arbeitslasttyp und Benutzerpräferenzen ab, sodass, wenn für den Arbeitslasttyp keine geringe Latenz erforderlich ist (wenn z. B. für die Arbeitslast nicht erforderlich ist, dass der Prozessor 206 Datenpakete mit minimaler Verzögerung verarbeitet) und wenn der Benutzerpräferenzstatus eine Stromsparoptimierung angibt, die Parameterwerte so gesetzt werden, dass sie im Vergleich zum in der 802.11-Spezifikation definierten Übertragungsstandard (z. B. zur Beacon-Intervalldauer) lang sind. Darüber hinaus ist die Effizienz der Parameter vom Arbeitslasttyp und von der Benutzerpräferenz abhängig, sodass, wenn für den Arbeitslasttyp eine geringe Latenz von der Computergerätplattform 100 erforderlich ist und die Benutzerpräferenz eine Stromsparoptimierung angibt, die Parameterwerte so generiert werden, dass ein Ausgleich zwischen den Arbeitslastanforderungen und einem minimalen Stromverbrauch geschaffen wird.
In einigen Beispielen ist der Reaktivierungswähler 904 in Kommunikation mit dem Latenzwertgenerator 310 gemäß 3. Der Reaktivierungswähler 904 kann zum Beispiel Informationen vom Latenzwertgenerator 310 über eine Kabelverbindung und/oder eine drahtlose Verbindung empfangen oder aus ihm abrufen. In einigen Beispielen bestimmt der Reaktivierungswähler 904 eine Zielwartezeit und/oder eine Zielübersprungzeit basierend auf den durch den Latenzwertgenerator 310 generierten Latenzwerten. Die Latenzwerte, die eine Zeit zum Puffern von Netzdatenpaketen und/oder einen Stromsparzustand angeben, informieren den Reaktivierungswähler 904 zum Beispiel darüber, wie lange eine Pufferung der Netzdatenpakete durch das Funknetzgerät 104 gemäß 1 angemessen ist. In einem solchen Beispiel handelt der Reaktivierungswähler 904 die Latenzwertzeiten mit dem Funknetzgerät 104 aus.
Die beispielhafte Netzverkehrssteuereinheit 314 in 9 enthält den beispielhaften Vergleicher 906 zum Vergleichen von Übersprungzeitparametern mit einem Disassoziierungszeitraum des Funknetzgeräts 104. Ein Disassoziierungszeitraum, wie hierin genutzt, korrespondiert mit einem Inaktivitätszeitraum zwischen dem Funknetzgerät 104 und der Computergerätplattform 100, der bewirkt, dass das Funknetzgerät 104 von der Computergerätplattform 100 disassoziiert wird, wodurch die Verbindung zwischen der Computergerätplattform 100 und dem Netz 102 getrennt wird. Der beispielhafte Vergleicher 906 vergleicht einen Zeitwert, der durch den Reaktivierungswähler 904 generiert wird, mit einem Disassoziierungsgrenzwert (z. B. einem Disassoziierungszeitraum), der angibt, wann das Funknetzgerät 104 die Verbindung zwischen dem Computergerätplattform 100 und dem Netz 102 trennt. In einigen Beispielen benachrichtigt der Vergleicher 906 den Reaktivierungswähler 904, wenn der Zeitwert den Disassoziierungsgrenzwert erreicht und/oder überschreitet. In einigen Beispielen generiert der Reaktivierungswähler 904 neue Übersprungzeitwerte, die kleiner als der Disassoziierungsgrenzwert sind.
Die beispielhafte Netzverkehrssteuereinheit 314 in 9 enthält den beispielhaften Datenrahmengenerator 908 zum Generieren eines Modemdatenrahmens. Der beispielhafte Datenrahmengenerator 908 füllt den Datenrahmen mit Informationen auf, die durch den beispielhaften Reaktivierungswähler 904 bereitgestellt werden. Der Datenrahmengenerator 908 weist zum Beispiel dem Listen-Interval-Feld 136 einen Zielwartezeitwert zu. In einigen Beispielen stellt der Datenrahmengenerator 908 den Modemdatenrahmen der Netzpaketsteuereinheit 302 bereit. Die beispielhafte Netzpaketsteuereinheit 302 überträgt den Datenrahmen an das beispielhafte Funknetzgerät 104, um den im Listen-Interval-Feld 136 angegebenen Wert auszuhandeln. Wenn das Funknetzgerät 104 das Listen Interval akzeptiert, sendet das Funknetzgerät 104 in einigen Beispielen eine Bestätigung an das Modem 208 oder genauer die Netzpaketsteuereinheit 302 zurück. Eine solche Bestätigung gibt an, dass die beispielhafte Reaktivierungssteuereinheit 106 Datenpakete für eine mit dem Wert des Listen-Interval-Felds 136 korrespondierende Dauer speichert oder puffert.
Der Reaktivierungswähler 904 konfiguriert und/oder generiert in einem beispielhaften Ablauf der Netzverkehrssteuereinheit 314 Zielwartezeitparameter, wenn der Rahmenanalysator 902 bestimmt, dass das Funknetzgerät 104 einen Stromsparmodus unterstützt. Der beispielhafte Reaktivierungswähler 904 analysiert die Arbeitslasttypvorhersage von der Vorhersagesteuereinheit 306 und den Benutzeranforderungsstatus vom Benutzeranforderungswähler 316 in Verbindung miteinander, um optimierte Zielwartezeitwerte zu bestimmen. Der Reaktivierungswähler 904 wird zum Beispiel so voreingestellt und/oder konfiguriert, dass er analysiert, ob das Sparen von Strom oder die Performanz das Ziel ist und ob der Arbeitslasttyp hohe, mittlere und/oder niedrige Latenzanforderungen enthält. Wenn die Benutzerpräferenz in einigen Beispielen das Sparen von Strom angibt und der Arbeitslasttyp eine nicht interaktive Arbeitslast (z. B. eine hohe Latenz) angibt, generiert der Arbeitslastwähler 904 einen Zielwartezeitwert für eine lange Dauer, der das Funknetzgerät 104 darüber informiert und/oder bewirkt, dass das Funknetzgerät Datenpakete der Arbeitslast für eine maximale Dauer puffern wird, wobei die maximale Dauer von der Länge des Puffers 108 definiert wird.
Wenn die Benutzerpräferenz in einigen Beispielen die Performanz angibt und der Arbeitslasttyp nicht interaktiv angibt, generiert der Arbeitslastwähler 904 einen Zielwartezeitwert, der bewirkt, dass der Puffer 108 die Datenpakete für eine erforderliche minimale Dauer puffern wird, wobei die erforderliche minimale Dauer von den Latenzanforderungen des Arbeitslasttyps definiert wird.
Sobald der beispielhafte Reaktivierungswähler 904 den Zielwartezeitparameter basierend auf den Benutzerpräferenz- und Arbeitslastanforderungen generiert, generiert der beispielhafte Datenrahmengenerator 908 einen Datenrahmen, der die Zielwartezeit enthält. Der beispielhafte Datenrahmengenerator 908 wartet auf eine Bestätigung vom beispielhaften Funknetzgerät 104, die angibt, dass das Funknetzgerät 104 Datenpakete in der Zielwartezeit puffern wird. Sobald der Datenrahmengenerator 908 eine Bestätigung empfängt, tritt das beispielhafte Modem 208 für die Dauer der Zielwartezeit in einen Stromsparzustand ein.
Der beispielhafte Reaktivierungswähler 904 ist so konfiguriert, dass er in einem beispielhaften zweiten Ablauf der Netzverkehrssteuereinheit 314 einen Übersprungzeitparameter generiert, sobald der Rahmenanalysator 902 bestimmt, dass das Funknetzgerät 104 einen Stromsparmodus nicht unterstützt. Der beispielhafte Reaktivierungswähler 904 analysiert die Arbeitslasttypvorhersage von der Vorhersagesteuereinheit 306 und den Benutzeranforderungsstatus vom Benutzeranforderungswähler 316 in Verbindung miteinander, um optimierte Übersprungzeitwerte zu bestimmen. Der Reaktivierungswähler 904 wird zum Beispiel so voreingestellt und/oder konfiguriert, dass er analysiert, ob das Sparen von Strom oder die Performanz das Ziel ist und ob der Arbeitslasttyp hohe, mittlere und/oder niedrige Latenzanforderungen enthält. Wenn die Benutzerpräferenz in einigen Beispielen das Sparen von Strom angibt und der Arbeitslasttyp eine nicht interaktive Arbeitslast angibt, generiert der Reaktivierungswähler 904 Übersprungzeitwerte, die bewirken, dass die Netzpaketsteuereinheit 302 vor dem Abrufen von Datenpaketen aus dem Funknetzgerät 104 eine maximale Anzahl von Beacon-Intervallen überspringt, wobei die maximale Anzahl von Beacon-Intervallen durch den Disassoziierungszeitraum des Funknetzgeräts 104 definiert wird.
Wenn die Benutzerpräferenz in einigen Beispielen die Performanz angibt und der Arbeitslasttyp eine nicht interaktive Arbeitslast angibt, generiert der Reaktivierungswähler 904 einen Übersprungzeitwert, der bewirkt, dass die Netzpaketsteuereinheit 302 Datenpakete aus dem Funknetzgerät 104 in jedem Beacon-Intervall abruft (z. B. beträgt der Übersprungzeitwert in einem solchen Beispiel null).
In einem dritten Beispiel sei angenommen, dass das Modem 208 einen AP-Datenrahmen 110 erhält, der ein DTIM-Bit in dem TIM-Element 126, das auf den Wert 1 gesetzt ist, enthält. In einem solchen Beispiel wird davon ausgegangen, dass das Modem 208 Beacons in jedem Beacon-Intervall (z. B. ungefähr 102 ms) vom Funknetzgerät 104 empfängt. Darüber hinaus führt die Computergerätplattform 100 oder genauer der beispielhafte Prozessor 106 im Hintergrund ohne irgendeine Vordergrundaktivität einen E-Mail-Vorgang aus. Es wird davon ausgegangen, dass das beispielhafte Modem 208 reaktiviert wird, damit es jedes Beacon empfängt. Dahingegen identifiziert der Reaktivierungswähler 904 die Verkehrsklasse (z. B. den Arbeitslasttyp) und die Benutzerpräferenz und generiert einen Übersprungzeitwert, der gleich 500 ms ist, damit das Modem 208 länger in einem Schlafzyklus bleiben kann. In einem solchen Beispiel hat der Reaktivierungswähler 904 bestimmt, dass vier Beacons zu überspringen sind. Nach dem fünften Beacon ruft das Modem 208 seine gepufferten Daten in einer der im 802.11-Standard definierten Prozeduren ab.
In 9 ist veranschaulicht, wie sich die Netzverkehrssteuereinheit 314 gemäß 3 beispielhaft implementieren lässt, jedoch können eines oder mehrere der Elemente, einer oder mehrere der Prozesse und/oder eines oder mehrere der Geräte, die in 9 veranschaulicht sind, auch kombiniert, aufgeteilt, anders angeordnet, weggelassen, entfernt und/oder auf eine beliebige andere Weise implementiert werden. Ferner können der beispielhafte Rahmenanalysator 902, der beispielhafte Reaktivierungswähler 904, der beispielhafte Vergleicher 906, der beispielhafte Datenrahmengenerator 908 und allgemeiner die beispielhafte Netzverkehrssteuereinheit 314 gemäß 3 durch Hardware, Software, Firmware und/oder eine beliebige Kombination aus Hardware, Software oder Firmware implementiert werden. Mithin könnten der beispielhafte Rahmenanalysator 902, der beispielhafte Reaktivierungswähler 904, der beispielhafte Vergleicher 906, der beispielhafte Datenrahmengenerator 908 und allgemeiner die beispielhafte Netzverkehrssteuereinheit 314 durch eine oder mehrere analoge oder digitale Schaltungen, eine oder mehrere logische Schaltungen, einen oder mehrere programmierbare Prozessoren, einen oder mehrere programmierbare Controller, einen oder mehrere Grafikprozessoren (GPU(s)), einen oder mehrere Digitalsignalprozessoren (DSP(s)), eine oder mehrere anwendungsspezifische integrierte Schaltungen (ASIC(s)), einen oder mehrere Logikbausteine (PLD(s)) und/oder einen oder mehrere vom Anwender programmierbare Logikbausteine (FPLD(s)) implementiert werden. Werden Vorrichtungs- oder Systemansprüche dieses Patents derart interpretiert, dass sie eine reine Software- und/oder Firmware-Implementierung abdecken, werden der beispielhafte Rahmenanalysator 902, der beispielhafte Reaktivierungswähler 904, der beispielhafte Vergleicher 906 und der beispielhafte Datenrahmengenerator 908 hiermit ausdrücklich so definiert, dass sie nichttransiente, computerlesbare, die Software und/oder die Firmware enthaltende Speicherelemente oder -platten wie etwa einen Speicher, eine DVD (Digital Versatile Disk), eine CD (Compact Disk), eine Blu-ray Disc etc. einschließen. Außerdem kann die beispielhafte Netzverkehrssteuereinheit 314 gemäß 3 ein oder mehrere Elemente, einen oder mehrere Prozesse und/oder ein oder mehrere Geräte entweder zusätzlich zu denjenigen, die in 9 veranschaulicht sind, oder an ihrer Stelle enthalten und/oder kann mehr als nur eines von beliebigen oder allen der veranschaulichten Elemente, mehr als nur einen von beliebigen oder allen der veranschaulichten Prozesse bzw. mehr als nur eines von beliebigen oder allen der veranschaulichten Geräte enthalten. Der Ausdruck „in Kommunikation“ sowie Varianten davon, wie hierin genutzt, schließt eine direkte oder indirekte Kommunikation durch eine oder mehrere Zwischenkomponenten ein, er setzt jedoch nicht voraus, dass eine direkte physische (z. B. drahtgebundene) und/oder ständige Kommunikation erfolgen muss, und kann darüber hinaus eine selektive Kommunikation in periodischen Intervallen, geplanten Intervallen, aperiodischen Intervallen und/oder durch einmalige Ereignisse enthalten.
In den 11-12 sind Ablaufschemata gezeigt, die repräsentativ für eine beispielhafte Hardwarelogik, beispielhafte maschinenlesbare Befehle, beispielhafte in Hardware implementierte Zustandsmaschinen oder beliebige Kombinationen davon zum Implementieren der Netzverkehrssteuereinheit 314 gemäß den 3 und 9 sind. In 10 ist darüber hinaus ein Ablaufschema gezeigt, das repräsentativ für eine beispielhafte Hardwarelogik, beispielhafte maschinenlesbare Befehle, beispielhafte in Hardware implementierte Zustandsmaschinen oder beliebige Kombinationen davon zum Implementieren des Benutzeranforderungswählers 316 gemäß 3 sind. Bei den maschinenlesbaren Befehlen handelt es sich möglicherweise um ein oder mehrere ausführbare Programme oder einen oder mehrere Teile eines ausführbaren Programms zur Ausführung durch einen Computerprozessor oder eine Prozessorschaltung wie den Prozessor 1312, der in der beispielhaften Prozessorplattform 1300, die in Verbindung mit 13 unten erörtert wird, gezeigt ist. Das Programm kann in Software, die in einem nichttransienten, computerlesbaren Speichermedium, etwa auf einer CD-ROM, einer Diskette, einer Festplatte, einer DVD, einer Blu-ray Disc oder in einem zum Prozessor 1312 gehörenden Speicher gespeichert ist, realisiert sein, jedoch könnten das ganze Programm oder Teile davon statt durch den Prozessor 1312 alternativ auch durch andere Elemente ausgeführt werden und/oder in Firmware oder dedizierter Hardware realisiert sein. Ferner wird das beispielhafte Programm zwar mit Bezug auf die in den 10-12 veranschaulichte Ablaufschemata beschrieben, jedoch kommen alternativ noch viele weitere Verfahren zum Implementieren der beispielhaften Netzverkehrssteuereinheit 314 und des Benutzeranforderungswählers 316 in Frage. Zum Beispiel kann die Reihenfolge der Ausführung der Blöcke geändert werden, und/oder einige der beschriebenen Blöcke können geändert, entfernt oder kombiniert werden. Zusätzlich oder alternativ sind beliebige einzelne oder auch alle der Blöcke durch einen oder mehrere Hardwareschaltkreise (z. B. diskrete und/oder integrierte analoge und/oder digitale Schaltungsbauteile, ein FPGA, einen ASIC, einen Vergleicher, einen Operationsverstärker (OpAmp) oder einen Logikschaltkreis), die so strukturiert sind, dass sie den korrespondierenden Vorgang ohne Ausführung von Software oder Firmware durchführen, implementierbar. Die Prozessorschaltung kann über unterschiedliche Stellen in einem Netz verteilt oder lokal in einem der mehreren Geräten untergebracht sein (z. B. ein Mehrkernprozessor in einer einzigen Maschine oder mehrere über ein Server-Rack verteilte Prozessoren).
Die hierin beschriebenen maschinenlesbaren Befehle können in einem oder mehreren der folgenden Formate gespeichert sein: einem komprimierten Format, einem verschlüsselten Format, einem fragmentierten Format, einem kompilierten Format, einem ausführbaren Format, einem Paketformat etc. Maschinenlesbare Befehle, wie hierin beschrieben, können als Daten oder Datenstruktur (z. B. Abschnitte von Befehlen, Code oder Darstellungen von Code), die zum Erzeugen, Herstellen und/oder Produzieren maschinenlesbarer Befehle verwendet werden können, gespeichert sein. Die maschinenlesbaren Befehle sind zum Beispiel möglicherweise fragmentiert und in einem oder mehreren Speicherelementen und/oder einem oder mehreren Computergeräten (z. B. Servern), die sich an derselben Stelle oder an unterschiedlichen Stellen in einem oder mehreren Netzen (z. B. in der Cloud oder in Edge Devices) befinden, gespeichert. Damit die maschinenlesbaren Befehle von einem Computergerät oder einer anderen Maschine direkt gelesen, interpretiert und/oder ausgeführt werden können, erfordern sie möglicherweise eine oder mehrere der folgenden Aktionen: Installation, Modifizierung, Anpassung, Aktualisieren, Kombinieren, Ergänzen, Konfigurieren, Entschlüsselung, Dekomprimierung, Entpacken, Verteilung, Neuzuweisung, Kompilierung etc. Die maschinenlesbaren Befehle können zum Beispiel in mehreren Teilen, die einzeln komprimiert, verschlüsselt und in separaten Computergeräten gespeichert werden, gespeichert sein, wobei die Teile, wenn sie entschlüsselt, dekomprimiert und kombiniert werden, einen Satz ausführbarer Befehle bilden, die eine oder mehrere Funktionen, welche zusammen ein Programm wie das hierin beschriebene Programm bilden können, implementieren.
In einem weiteren Beispiel sind die maschinenlesbaren Befehle möglicherweise in einem Zustand gespeichert, in dem sie von einer Prozessorschaltung gelesen werden können, in dem jedoch zusätzlich, damit die Befehle in einem bestimmten Computergerät oder sonstigen Gerät ausgeführt werden können, eine Bibliothek (z. B. eine Dynamic Link Library (DLL)), ein Software-Development-Kit (SDK) oder eine Anwendungsprogrammierschnittstelle (API) nötig ist. In einem weiteren Beispiel müssen die maschinenlesbaren Befehle möglicherweise erst konfiguriert werden (z. B. müssen Einstellungen gespeichert, Daten eingegeben oder Netzadressen registriert werden), bevor die maschinenlesbaren Befehle und/oder das korrespondierende Programm (die korrespondierenden Programme) ganz oder teilweise ausgeführt werden können. Maschinenlesbare Medien, wie hierin genutzt, können mithin maschinenlesbare Befehle und/oder Programme unabhängig vom jeweiligen Format oder Zustand der maschinenlesbaren Befehle und/oder Programme, wenn diese gespeichert werden oder ansonst an einer anderen Stelle liegen oder gerade übertragen werden, enthalten.
Die hierin beschriebenen maschinenlesbaren Befehle sind durch eine beliebige frühere, aktuelle oder künftige Befehlssprache, Skriptsprache oder Programmiersprache darstellbar. Die maschinenlesbaren Befehle sind zum Beispiel unter Nutzung einer der folgenden Sprachen darstellbar: C, C++, Java, C#, Perl, Python, JavaScript, HyperText Markup Language (HTML), Structured Query Language (SQL), Swift etc.
Wie oben erwähnt, können die beispielhaften Prozesse gemäß den 10-12 unter Nutzung ausführbarer Befehle (z. B. computer- oder maschinenlesbarer Befehle) implementiert werden, die in einem nichttransienten, computer- oder maschinenlesbaren Medium, etwa auf einer Festplatte, in einem Flashspeicher, einem Festwertspeicher, auf einer CD, einer DVD, in einem Cache, einem Arbeitsspeicher oder einem beliebigen anderen Speicherelement oder einer beliebigen anderen Speicherplatte, in dem/der Informationen beliebig lang (z. B. über längere Zeitabschnitte, dauerhaft, kurz, vorübergehend bei einer Zwischenspeicherung und/oder bei einem Caching der Informationen) liegen können, gespeichert sind. Der Begriff nichttransientes, computerlesbares Medium, wie hierin genutzt, wird ausdrücklich so definiert, dass er computerlesbare Speicherelemente und -platten von einem beliebigen Typ einschließt, die Ausbreitung von Signalen und Übertragungsmedien aber ausschließt.
Die Begriffe „enthalten“ und „umfassen“ (einschließlich aller Formen und Zeiten) sind hierin als offene Begriffe zu verstehen. Es versteht sich also, dass, immer wenn in einem Anspruch einer der Begriffe „enthalten“ oder „umfassen“ in irgendeiner Form (z. B. umfasst, enthält, umfassend, enthaltend oder aufweisend) im Oberbegriff oder innerhalb einer Anspruchsdefinition verwendet wird, weitere Elemente, Begriffe etc. zusätzlich vorhanden sein können, ohne dass hierbei der Schutzbereich des betreffenden Anspruchs oder der betreffenden Definition verlassen wird. Wenn der Ausdruck „mindestens“ hierin dazu genutzt wird, um Wörter zum Beispiel im Oberbegriff eines Anspruchs aneinanderzureihen, ist er ebenso wie die Begriffe „umfassen“ und „enthalten“ als offener Begriff aufzufassen. Wird das Konjunktionspaar „und/oder“ zum Beispiel in der Form A, B und/oder C genutzt, kann eine beliebige Kombination oder Teilmenge aus A, B, C, etwa (1) nur A, (2) nur B, (3) nur C, (4) A mit B, (5) A mit C, (6) B mit C oder (7) A mit B und mit C, gemeint sein. Im Zusammenhang mit der Beschreibung von Strukturen, Komponenten, Einzelteilen, Objekten und/oder Dingen bezieht sich die Formulierung „mindestens eines von A und B“, wie hierin genutzt, auf Implementierungen, die Folgendes einschließen: (1) mindestens ein Element A, (2) mindestens ein Element B und (3) mindestens ein Element A und mindestens ein Element B. Analog bezieht sich die Formulierung „mindestens eines von A oder B“, wie hierin genutzt, im Zusammenhang mit der Beschreibung von Strukturen, Komponenten, Einzelteilen, Objekten und/oder Dingen auf Implementierungen, die Folgendes einschließen: (1) mindestens ein Element A, (2) mindestens ein Element B und (3) mindestens ein Element A und mindestens ein Element B. Im Zusammenhang mit der Beschreibung der Durchführung oder Abarbeitung von Prozessen, Befehlen, Aktionen, Vorgängen oder Schritten bezieht sich die Formulierung „mindestens eines von A und B“, wie hierin genutzt, auf Implementierungen, die Folgendes einschließen: (1) mindestens ein Element A, (2) mindestens ein Element B und (3) mindestens ein Element A und mindestens ein Element B. Analog bezieht sich im Zusammenhang mit der Beschreibung der Durchführung oder Abarbeitung von Prozessen, Befehlen, Aktionen, Vorgängen oder Schritten die Formulierung „mindestens eines von A oder B“, wie hierin genutzt, auf Implementierungen, die Folgendes einschließen: (1) mindestens ein Element A, (2) mindestens ein Element B und (3) mindestens ein Element A und mindestens ein Element B.
Werden hierin Wörter, die die Einzahl ausdrücken, genutzt (z. B. „ein“, „eine“, „erster“ oder „zweiter“), wird hierdurch nicht ausgeschlossen, dass auch die Mehrzahl gemeint sein könnte. Wird hierin auf „eine“ Einheit Bezug genommen, können eine oder mehrere dieser Einheit gemeint sein. Formulierungen mit den Wörtern „ein“ (oder „eine“), „ein oder mehrere“ oder „mindestens eines“ sind hierin untereinander austauschbar. Des Weiteren ist eine Vielzahl von Mitteln, Elementen oder Verfahrensschritten, selbst wenn diese einzeln aufgeführt werden, z. B. durch eine einzige Einheit oder einen einzigen Prozessor implementierbar. Darüber hinaus sind einzelne Merkmale möglicherweise in unterschiedlichen Beispielen oder Ansprüchen enthalten, sind aber trotzdem eventuell kombinierbar, denn dadurch, dass diese in unterschiedlichen Beispielen oder Ansprüchen enthalten sind, wird nicht stillschweigend angedeutet, dass eine Kombination von Merkmalen nicht möglich und/oder vorteilhaft ist.
10 veranschaulicht einen beispielhaften Benutzerpräferenzablauf 1000 des beispielhaften Benutzeranforderungswählers 316 gemäß 3 zum Bestimmen eines Benutzeranforderungsstatus der beispielhaften Computergerätplattform 100. Am Block 1002 erhält der beispielhafte Benutzeranforderungswähler 316 eine Benutzereingabe. Der Benutzeranforderungswähler 316 erhält zum Beispiel mit Eingabedaten von einem Benutzer korrespondierende Informationen vom Prozessor 206 (2) und/oder vom Speicher 204 (2).
Der beispielhafte Benutzeranforderungswähler 316 bestimmt, ob die Benutzereingabe das Sparen von Strom statt der Performanz angibt (Block 1004). Der Benutzeranforderungswähler 316 bestimmt zum Beispiel, ob das Verhältnis zwischen dem Sparen von Strom und der Performanz ein Verhältnis zugunsten des Sparens von Strom statt der Performanz ist. In einigen Beispielen gibt ein solches Verhältnis an, dass der Benutzer eine optimale Batterielebensdauer statt einer optimalen Performanz wünscht.
Bestimmt der beispielhafte Benutzeranforderungswähler 316, dass die Eingabe das Sparen von Strom statt der Performanz angibt (liefert der Block 1004 z. B. den Wert JA zurück), aktualisiert der beispielhafte Benutzeranforderungswähler 316 einen Benutzeranforderungsstatus (Block 1006). Der Benutzeranforderungswähler 316 kann zum Beispiel einen Statuswert, der die Netzverkehrssteuereinheit 314 über eine Benutzerpräferenz informiert, speichern und bereitstellen. In einigen Beispielen ist der Benutzeranforderungsstatus möglicherweise ein Verhältniswert, ein Bitwert oder ein Zahlenwert von einem beliebigen Typ.
Bestimmt der beispielhafte Benutzeranforderungswähler 316, dass die Eingabe nicht das Sparen von Strom statt der Performanz angibt (liefert der Block 1004 z. B. den Wert NEIN zurück), aktualisiert der beispielhafte Benutzeranforderungswähler 316 den Benutzeranforderungsstatus (Block 1006). Der Benutzeranforderungswähler 316 aktualisiert zum Beispiel den Benutzeranforderungsstatus, um anzugeben, dass vom Benutzer eine Performanzoptimierung ausgewählt worden ist. Die Performanzoptimierung wird bestimmt, weil das Verhältnis kein Verhältnis zugunsten des Sparens von Strom war und mithin am wahrscheinlichsten ein Verhältnis zugunsten einer Performanzoptimierung ist.
Der beispielhafte Benutzeranforderungswähler 316 bestimmt, ob der Benutzer den Anforderungsstatus geändert hat (Block 1008). Der Benutzeranforderungswähler 316 empfängt die Benutzereingabedaten zum Beispiel möglicherweise in periodischen Abständen vom Prozessor 206 und bestimmt, ob sich die Benutzereingabe geändert hat. Zusätzlich oder alternativ erhält der Benutzeranforderungswähler 316 jedes Mal, wenn der Benutzer die Präferenzen aktualisiert, eine Benutzereingabe.
Bestimmt der beispielhafte Benutzeranforderungswähler 316, dass der Benutzer den Anforderungsstatus geändert hat (liefert der Block 1008 z. B. den Wert JA zurück), wird bei der Steuerung zum Block 1004 zurückgekehrt. Bestimmt der beispielhafte Benutzeranforderungswähler 316, dass der Benutzer den Anforderungsstatus nicht geändert hat (liefert der Block 1008 z. B. den Wert NEIN zurück), bestimmt der beispielhafte Benutzeranforderungswähler 316, ob in dem Ablauf fortgefahren werden soll (Block 1010). In einigen Beispielen fährt der Benutzeranforderungswähler 316 in dem Ablauf so lange fort, bis der Computergerätplattform 100 kein Strom mehr zugeführt wird, wenn die Benutzerpräferenzeinstellung ausgestellt wird etc. Bestimmt der beispielhafte Benutzeranforderungswähler 316, dass in dem Benutzerpräferenzablauf 1000 fortgefahren werden soll (liefert der Block 1010 z. B. den Wert JA zurück), wird bei der Steuerung zum Block 1002 zurückgekehrt. Bestimmt der beispielhafte Benutzeranforderungswähler 316, dass in dem Benutzerpräferenzablauf 1000 nicht fortgefahren werden soll (liefert der Block 1010 z. B. den Wert NEIN zurück), endet der beispielhafte Benutzerpräferenzablauf 1000.
In 11, auf die nunmehr eingegangen wird, wird ein beispielhafter Übersprungrahmenablauf 1100 der beispielhaften Netzverkehrssteuereinheit 314 gemäß den 3 und 9 zum Generieren eines Übersprungzeitraums veranschaulicht. Am Block 1102 erhält der beispielhafte Rahmenanalysator 902 (9) einen Datenrahmen (Beacon) vom beispielhaften Funknetzgerät 104. Die Netzpaketsteuereinheit 302 (3) stellt zum Beispiel der beispielhaften Netzverkehrssteuereinheit 314 einen beispielhaften AP-Datenrahmen 110 bereit.
Der beispielhafte Rahmenanalysator 902 bestimmt, ob eine Angabe von Datenpaketen zur Ausführung in der Computergerätplattform 100 vorhanden ist (Block 1104). Der Rahmenanalysator 902 analysiert zum Beispiel das TIM-Element 126 des AP-Datenrahmens 110, um zu bestimmen, ob Datenpakete, die für die Computergerätplattform 100 vorgesehen sind, im Funknetzgerät 104 gepuffert werden. Bestimmt der beispielhafte Rahmenanalysator 902, dass im beispielhaften Funknetzgerät 104 keine Datenpakete angegeben werden (liefert der Block 1104 z. B. den Wert NEIN zurück), wartet der beispielhafte Rahmenanalysator 902 auf einen anderen Datenrahmen.
Bestimmt der beispielhafte Rahmenanalysator 902 hingegen, dass im beispielhaften Funknetzgerät 104 Datenpakete angegeben werden (liefert der Block 1104 z. B. den Wert JA zurück), bestimmt der beispielhafte Rahmenanalysator 902 ein Beacon-Intervall für die Datenpakete (Block 1106). Der Rahmenanalysator 902 identifiziert zum Beispiel die Beacon-Intervallzeit im Beacon-Interval-Feld 118 des AP-Datenrahmens 110. In einigen Beispielen stellt der Rahmenanalysator 902 das Beacon-Intervall dem Reaktivierungswähler 904 (9) bereit.
Der beispielhafte Reaktivierungswähler 904 bestimmt eine Prioritätsstufe der Datenpakete basierend auf dem Arbeitslasttyp (Block 1108). Der Reaktivierungswähler 904 bestimmt zum Beispiel die QoS-Anforderungen des Arbeitslasttyps, wobei der Arbeitslasttyp durch die beispielhafte Vorhersagesteuereinheit 306 (3) bestimmt und dem Reaktivierungswähler 904 bereitgestellt wird.
Der beispielhafte Reaktivierungswähler 904 erhält den Benutzeranforderungsstatus (Block 1110). Der Reaktivierungswähler 904 fragt zum Beispiel den Benutzeranforderungswähler 316 (3) nach dem Anforderungsstatus ab.
Der beispielhafte Reaktivierungswähler 904 bestimmt einen Latenzwert basierend auf der Prioritätsstufe und dem Benutzeranforderungsstatus (Block 1112). Der Reaktivierungswähler 904 bestimmt zum Beispiel einen Latenzwert, der einen Ausgleich zwischen den QoS-Anforderungen (z. B. der maximal zulässigen Latenz für den Arbeitslasttyp) und dem Benutzeranforderungsstatus (z. B. Optimierung hinsichtlich der Performanz oder des Sparens von Strom) schafft. In einigen Beispielen ist der Latenzwert ein Zeitwert, der eine gewünschte Zeit, in der das Modem 208 in einem Stromsparzustand bleiben soll, angibt.
Der beispielhafte Reaktivierungswähler 904 generiert basierend auf dem Latenzwert und dem Beacon-Intervall einen Übersprungzeitraum (Block 1114). Der Reaktivierungswähler 904 bestimmt zum Beispiel, wie oft das Modem 208 das Abrufen von Datenrahmen und/oder Datenpaketen aus dem Funknetzgerät 104 überspringen soll. In einigen Beispielen ist der generierte Übersprungzeitraum auf Beacon-Intervalle bezogen.
Der beispielhafte Vergleicher 906 (9) bestimmt, ob der Übersprungzeitraum länger als ein Disassoziierungszeitraum ist (Block 1116). Der Vergleicher 906 erhält den Übersprungzeitraum zum Beispiel vom Reaktivierungswähler 904 und vergleicht den Zeitraum mit einer Zeit, zu der sich das Funknetzgerät 104 von der Computergerätplattform 100 disassoziiert. Bestimmt der beispielhafte Vergleicher 906, dass der Übersprungzeitraum länger als der Disassoziierungszeitraum ist (liefert der Block 1116 z. B. den Wert JA zurück), generiert der beispielhafte Reaktivierungswähler 904 einen anderen Übersprungzeitraum, der kürzer als der Disassoziierungszeitraum ist (Block 1118). Wenn der Übersprungzeitraum mindestens so lang wie der Disassoziierungszeitraum ist, generiert der Reaktivierungswähler 904 einen neuen Übersprungzeitraum, der gleich einem Zeitwert ist, der den Disassoziierungszeitraum unterschreitet.
Der beispielhafte Reaktivierungswähler 904 setzt einen Reaktivierungstimer auf den Übersprungzeitraum (Block 1120). Der Reaktivierungstimer ist zum Beispiel möglicherweise ein Timer des Modems 208, der das Modem 208 darüber informiert, wann Strom zum Abrufen von Netzdaten anzufordern ist. Bestimmt der beispielhafte Vergleicher 906 in einigen Beispielen, dass der Übersprungzeitraum nicht länger als der Disassoziierungszeitraum ist (liefert der Block 1116 z. B. den Wert NEIN zurück), setzt der Reaktivierungswähler 904 den Reaktivierungstimer auf den Übersprungzeitraum (Block 1120).
Das beispielhafte Modem 208 oder genauer der beispielhafte Reaktivierungswähler 904 wartet darauf, dass der Reaktivierungstimer ausgelöst wird (Block 1122). Das Modem 208 wartet zum Beispiel auf einen Ablauf der Uhrzeit ab dem Übersprungzeitraum.
Der beispielhafte Reaktivierungswähler 904 setzt den Reaktivierungstimer zurück (Block 1124). Der Reaktivierungswähler 904 setzt den Reaktivierungstimer zum Beispiel auf den Übersprungzeitraum zurück.
Der beispielhafte Reaktivierungswähler 904 bestimmt, ob eine Angabe anderer Datenpakete vorliegt (Block 1126). Der Reaktivierungswähler 904 bestimmt zum Beispiel, ob in der Computergerätplattform 100 gerade eine neue Arbeitslast läuft. Bestimmt der beispielhafte Reaktivierungswähler 904, dass in dem beispielhaften Funknetzgerät 104 andere Datenpakete vorhanden sind (liefert der Block 1126 z. B. den Wert JA zurück), wird bei der Steuerung zum Block 1106 zurückgekehrt. Sobald der Reaktivierungswähler 904 zum Beispiel eine neue oder andere Vorhersage von der Vorhersagesteuereinheit 306 empfängt, bestimmt der Reaktivierungswähler 904, dass gerade eine neue Arbeitslast ausgeführt wird. Bestimmt der beispielhafte Reaktivierungswähler 904, dass in dem beispielhaften Funknetzgerät 104 keine anderen Datenpakete vorhanden sind (liefert der Block 1126 z. B. den Wert NEIN zurück), wird bei der Steuerung zum Block 1122 zurückgekehrt.
In einigen Beispielen endet der Übersprungrahmenablauf 1100, sobald die beispielhafte Netzverkehrssteuereinheit 314 bestimmt, dass das Funknetzgerät 104 Zielwartezeitaushandlungen unterstützt.
In 12, auf die nunmehr eingegangen wird, wird ein beispielhafter Zielwartezeitablauf 1200 der beispielhaften Netzverkehrssteuereinheit 314 gemäß den 3 und 9 zum Generieren einer Zielwartezeit veranschaulicht. Am Block 1202 erhält der beispielhafte Rahmenanalysator 902 (9) einen Datenrahmen (Beacon) vom beispielhaften Funknetzgerät 104. Die Netzpaketsteuereinheit 302 (3) stellt zum Beispiel der beispielhaften Netzverkehrssteuereinheit 314 einen beispielhaften AP-Datenrahmen 110 bereit.
Der beispielhafte Rahmenanalysator 902 bestimmt, ob eine Angabe von Datenpaketen zur Ausführung in der Computergerätplattform 100 vorliegt (Block 1204). Der Rahmenanalysator 902 analysiert zum Beispiel das TIM-Element 126 des AP-Datenrahmens 110, um zu bestimmen, ob Datenpakete, die für die Computergerätplattform 100 vorgesehen sind, im Funknetzgerät 104 gepuffert werden. Bestimmt der beispielhafte Rahmenanalysator 902, dass keine Datenpakete im beispielhaften Funknetzgerät 104 angegeben werden (liefert der Block 1204 z. B. den Wert NEIN zurück), wartet der beispielhafte Rahmenanalysator 902 auf einen anderen Datenrahmen.
Bestimmt der beispielhafte Rahmenanalysator 902 hingegen, dass Datenpakete im beispielhaften Funknetzgerät 104 angegeben werden (liefert der Block 1204 z. B. den Wert JA zurück), bestimmt der beispielhafte Rahmenanalysator 902 ein Beacon-Intervall für die Datenpakete (Block 1206). Der Rahmenanalysator 902 identifiziert zum Beispiel die Beacon-Intervallzeit im Beacon-Interval-Feld 118 des AP-Datenrahmens 110. In einigen Beispielen stellt der Rahmenanalysator 902 das Beacon-Intervall dem Reaktivierungswähler 904 (9) bereit.
Der beispielhafte Reaktivierungswähler 904 bestimmt eine Prioritätsstufe der Datenpakete basierend auf dem Arbeitslasttyp (Block 1208). Der Reaktivierungswähler 904 bestimmt zum Beispiel die QoS-Anforderungen des Arbeitslasttyps, wobei der Arbeitslasttyp durch die beispielhafte Vorhersagesteuereinheit 306 (3) bestimmt und dem Reaktivierungswähler 904 bereitgestellt wird.
Der beispielhafte Reaktivierungswähler 904 erhält den Benutzeranforderungsstatus (Block 1210). Der Reaktivierungswähler 904 fragt zum Beispiel den Benutzeranforderungswähler 316 (3) nach dem Benutzeranforderungsstatus ab, der eine Benutzerpräferenz angibt.
Der beispielhafte Reaktivierungswähler 904 generiert basierend auf der Prioritätsstufe und dem Benutzeranforderungsstatus einen Zielwartezeitparameter (Block 1212). Der Reaktivierungswähler 904 bestimmt zum Beispiel einen Zeitwert, der eine gewünschte Zeit, in der das Modem 208 in einem Stromsparzustand bleiben soll, und mithin eine gewünschte Zeit, in der der Puffer 108 (1) die Datenpakete für die Computergerätplattform 100 puffern soll, angibt. In einigen Beispielen ist die Zielwartezeit lang, wenn der Benutzeranforderungsstatus das Sparen von Batteriestrom statt der Performanz angibt und/oder wenn der Arbeitslasttyp relativ hohe Latenzanforderungen enthält. In anderen Beispielen ist die Zielwartezeit kurz, wenn der Benutzeranforderungsstatus angibt, dass die Performanz zu erhöhen ist, und/oder wenn der Arbeitslasttyp sehr latenzempfindlich ist.
Der beispielhafte Datenrahmengenerator 908 generiert einen Datenrahmen zum Aushandeln des Zielwartezeitparameters mit dem beispielhaften Funknetzgerät 104 (Block 1214). Der Datenrahmengenerator 908 füllt zum Beispiel einen Modemdatenrahmen 112 mit einem Listen-Interval-Feld 136 auf, das gleich der Zielwartezeit ist.
Der beispielhafte Datenrahmengenerator 908 überträgt den Datenrahmen (Block 1216). Der Datenrahmengenerator 908 sendet den Datenrahmen zum Beispiel über die Netzpaketsteuereinheit 302 an das Funknetzgerät 104.
Der beispielhafte Rahmenanalysator 902 wartet auf eine Bestätigung vom beispielhaften Funknetzgerät 104 (Block 1218). Dem Rahmenanalysator 902 kann ein Beacon bereitgestellt werden, das eine Bestätigung der Annahme der Zielwartezeit enthält. Am Block 1220 bestimmt der Rahmenanalysator 902, ob die Bestätigung empfangen worden ist. In einigen Beispielen wird die Bestätigung nicht empfangen (z. B. liefert der Block 1220 den Wert NEIN zurück), und der Rahmenanalysator 902 wartet weiter (Block 1218).
In anderen Beispielen bestimmt der Rahmenanalysator 902, dass die Bestätigung empfangen worden ist (z. B. liefert der Block 1220 den Wert JA zurück), und der beispielhafte Reaktivierungswähler 904 setzt den Reaktivierungstimer auf den Zielwartezeitparameter (Block 1222). Der Reaktivierungstimer ist zum Beispiel möglicherweise ein Timer des Modems 208, der das Modem 208 darüber informiert, wann Strom zum Abrufen von Netzdaten anzufordern ist.
Das beispielhafte Modem 208 oder genauer der beispielhafte Reaktivierungswähler 904 wartet darauf, dass der Reaktivierungstimer ausgelöst wird (Block 1224). Das Modem 208 wartet zum Beispiel auf einen Ablauf der Uhrzeit ab der Zielwartezeit.
Der beispielhafte Reaktivierungswähler 904 setzt den Reaktivierungstimer zurück (Block 1226). Der Reaktivierungswähler 904 setzt den Reaktivierungstimer zum Beispiel auf die Zielwartezeit zurück.
Der beispielhafte Reaktivierungswähler 904 bestimmt, ob eine Angabe anderer Datenpakete vorliegt (Block 1228). Der Reaktivierungswähler 904 bestimmt zum Beispiel, ob in der Computergerätplattform 100 gerade eine neue Arbeitslast läuft. Bestimmt der beispielhafte Reaktivierungswähler 904, dass in dem beispielhaften Funknetzgerät 104 andere Datenpakete vorhanden sind (liefert der Block 1228 z. B. den Wert JA zurück), wird bei der Steuerung zum Block 1206 zurückgekehrt. Sobald der Reaktivierungswähler 904 zum Beispiel eine neue oder andere Vorhersage von der Vorhersagesteuereinheit 306 empfängt, bestimmt der Reaktivierungswähler 904, dass gerade eine neue Arbeitslast ausgeführt wird. Bestimmt der beispielhafte Reaktivierungswähler 904, dass in dem beispielhaften Funknetzgerät 104 keine anderen Datenpakete vorhanden sind (liefert der Block 1228 z. B. den Wert NEIN zurück), wird bei der Steuerung zum Block 1224 zurückgekehrt.
In einigen Beispielen endet der Zielwartezeitablauf 1200, sobald die beispielhafte Netzverkehrssteuereinheit 314 bestimmt, dass das Funknetzgerät 104 Zielwartezeitaushandlungen nicht mehr unterstützt.
13 ist ein Blockschaltbild einer beispielhaften Prozessorplattform 1300, die so strukturiert ist, dass sie die Befehle gemäß den 5, 6, 7, 8, 10, 11 und 12 zur Implementierung des Modems 208 gemäß den 2, 3, 4 und 9 ausführt. Die Prozessorplattform 1300 kann zum Beispiel ein Server, ein PC, eine Workstation, eine selbstlernende Maschine (z. B. ein neuronales Netz), ein Mobilgerät (z. B. ein Handy, ein Smartphone oder ein Tablet, etwa ein iPad™), ein Personal Digital Assistant (PDA), eine Internet-Appliance, ein DVD-Player, ein CD-Player, ein digitaler Videorecorder, ein Blu-ray-Player, eine Spielkonsole, ein Personal Video Recorder, eine Set-Top-Box, ein Headset, ein Wearable oder ein Computergerät von einem beliebigen anderen Typ sein.
Die Prozessorplattform 1300 in dem veranschaulichten Beispiel enthält einen Prozessor 1312. Der Prozessor 1312 in dem veranschaulichten Beispiel ist eine Hardware. Der Prozessor 1312 kann zum Beispiel durch eine oder mehrere integrierte Schaltungen, eine oder mehrere logische Schaltungen, einen oder mehrere Mikroprozessoren, eine oder mehrere GPUs, einen oder mehrere DSPs oder einen oder mehrere Controller aus einer beliebigen gewünschten Familie oder von einem beliebigen gewünschten Hersteller implementiert werden. Bei dem Hardwareprozessor kann es sich um ein Bauelement auf Halbleiterbasis (z. B. auf Siliciumbasis) handeln. In diesem Beispiel implementiert der Prozessor das beispielhafte Modem 208, die beispielhafte Netzpaketsteuereinheit 302, die beispielhafte Trainingssteuereinheit 304, die beispielhafte Vorhersagesteuereinheit 306, die beispielhafte Aktivitätsstatussteuereinheit 308, den beispielhaften Latenzwertgenerator 310, die beispielhafte Netzverkehrssteuereinheit 314, den beispielhaften Benutzeranforderungswähler 316, den beispielhaften Präprozessor 402, den beispielhaften Merkmalsextraktor 404, den beispielhaften Modelltrainer 406, die beispielhafte Fehler-Verlust-Steuereinheit 408, den beispielhaften Modellveröffentlicher 410, den beispielhaften Rahmenanalysator 902, den beispielhaften Reaktivierungswähler 904, den beispielhaften Vergleicher 906 und den beispielhaften Datenrahmengenerator 908.
Der Prozessor 1312 in dem veranschaulichten Beispiel enthält einen lokalen Speicher 1313 (z. B. einen Cache). In einigen Beispielen implementiert der lokale Speicher 1313 den beispielhaften Puffer 312. Der Prozessor 1312 in dem veranschaulichten Beispiel ist über einen Bus 1318 in Kommunikation mit einem Hauptspeicher, der einen flüchtigen Speicher 1314 und einen nichtflüchtigen Speicher 1316 enthält. Der flüchtige Speicher 1314 kann durch ein Synchronous Dynamic Random Access Memory (SDRAM), ein Dynamic Random Access Memory (DRAM), ein RAMBUS® Dynamic Random Access Memory (RDRAM®) und/oder einen Arbeitsspeicher von einem beliebigen anderen Typ implementiert werden. Der nichtflüchtige Speicher 1316 kann durch einen Flashspeicher und/oder ein Speicherelement von einem beliebigen anderen gewünschten Typ implementiert werden. Der Zugriff auf den Hauptspeicher 1314, 1316 wird durch einen Speichercontroller gesteuert.
Die Prozessorplattform 1300 in dem veranschaulichten Beispiel enthält auch einen Schnittstellenschaltkreis 1320. Der Schnittstellenschaltkreis 1320 kann durch einen beliebigen Schnittstellenstandard implementiert werden, etwa durch eine Ethernet-Schnittstelle, einen universellen seriellen Bus (USB), eine Bluetooth®-Schnittstelle, eine NFC-Schnittstelle (NFC = Near Field Communication) und/oder eine PCI-Express-Schnittstelle.
In dem veranschaulichten Beispiel sind ein oder mehrere Eingabegeräte 1322 mit dem Schnittstellenschaltkreis 1320 verbunden. Ein Benutzer kann über das eine oder die mehreren Eingabegeräte 1322 Daten und/oder Befehle in den Prozessor 1312 eingeben. Das eine oder die mehreren Eingabegeräte können zum Beispiel durch einen akustischen Sensor, ein Mikrofon, eine Kamera (eine Standbildkamera oder eine Videokamera), eine Tastatur, eine Taste, eine Maus, einen Touchscreen, ein Touchpad, einen Trackball, ein Isopoint-Gerät und/oder ein Spracherkennungssystem implementiert sein.
Mit dem Schnittstellenschaltkreis 1324 in dem veranschaulichten Beispiel sind auch ein oder mehrere Ausgabegeräte 1320 verbunden. Das eine oder die mehreren Ausgabegeräte 1324 können zum Beispiel durch Anzeigegeräte (z. B. eine Leuchtdiode (LED), eine organische Leuchtdiode (OLED), eine Flüssigkristallanzeige (LCD), ein CRT-Display (CRT = Cathode Ray Tube), ein IPS-Display (IPS = In-Place-Switching) oder einen Touchscreen), ein Gerät für taktile Ausgaben, einen Drucker und/oder einen Lautsprecher implementiert sein. Der Schnittstellenschaltkreis 1320 in dem veranschaulichten Beispiel enthält mithin typischerweise eine Grafiktreiberkarte, einen Grafiktreiberchip oder einen Grafiktreiberprozessor.
Der Schnittstellenschaltkreis 1320 in dem veranschaulichten Beispiel enthält auch ein Kommunikationsteil wie einen Sender, einen Empfänger, einen Transceiver, ein Modem, ein Residential Gateway, einen Funkzugangspunkt und/oder eine Netzschnittstelle zum Ermöglichen des Datenaustausches mit externen Maschinen (z. B. Computergeräten beliebiger Art) über ein Netz 1326. Die Kommunikation kann zum Beispiel über eine Ethernet-Verbindung, eine DSL-Verbindung (DSL = Digital Subscriber Line), eine Telefonleitungsverbindung, ein Koaxialkabelsystem, ein Satellitensystem, ein drahtloses System mit Sichtverbindung oder ein Mobiltelefonsystem erfolgen.
Die Prozessorplattform 1300 in dem veranschaulichten Beispiel enthält auch einen oder mehrere Massenspeicher 1328 zum Speichern von Software und/oder Daten. Massenspeicher 1328 sind beispielsweise Diskettenlaufwerke, Festplatten, CD-ROM-Laufwerke, Blu-ray-Disc-Laufwerke, RAID-Systeme (RAID = Redundant Array of Independent Disks) oder DVD-Laufwerke (DVD = Digital Versatile Disk).
Die maschinenausführbaren Befehle 1332 gemäß den 5-8 und 10-12 können im Massenspeicher 1328, im flüchtigen Speicher 1314, im nichtflüchtigen Speicher 1316 und/oder auf einem wechselbaren, nichttransienten, computerlesbaren Speichermedium wie einer CD oder DVD gespeichert sein.
Aus der obigen Beschreibung geht hervor, dass beispielhafte Verfahren, Vorrichtungen und Erzeugnisse offenbart worden sind, die Arbeitslasttypen von Netzverkehr und Benutzerpräferenzen eines Computergeräts inferieren, damit ein Reaktivierungswähler Wartezeiten generieren kann, die ermöglichen, dass so viel Strom wie möglich gespart und/oder eine maximale Performanz einer mit Wi-Fi verbundenen Computergerätplattform erzielt wird. In den hierin offenbarten Beispielen wird die Anzahl von Beacon-Intervallen mit einem Funknetzgerät ausgehandelt, damit das Modem in Szenarios mit einer mittleren oder langen Latenz (z. B. wenn der Arbeitslasttyp keine kurze Latenz erfordert) und/oder Stromoptimierungspräferenz-Szenarios weniger oft für Netzverkehrsabrufe reaktiviert werden muss, wodurch mithin tiefe und länger anhaltende Stromsparzustände eines Prozessors und des Modems und infolgedessen eine längere Batterielebensdauer ermöglicht werden. Mit den offenbarten Verfahren, Vorrichtungen und Erzeugnissen lässt sich die Effizienz der Nutzung von Computergeräten verbessern, insofern als das Sparen von Strom und die Performanz von Computergeräten, wenn Wartezeiten generiert werden, unterstützt werden. Mit den offenbarten Verfahren, Vorrichtungen und Erzeugnissen wird demnach auf eine oder mehrere Verbesserungen der Arbeitsweise von Computern abgezielt.
Hierin werden beispielhafte Verfahren, Vorrichtungen, Systeme und Erzeugnisse zum Koordinieren von Netzverkehr zwischen Funknetzgeräten und Computergeräten offenbart. Folgende weitere Beispiele und Kombinationen davon kommen ebenfalls in Betracht:
Beispiel 1 enthält eine Vorrichtung, die einen Reaktivierungswähler zum Generieren eines Zielwartezeitparameters basierend auf einem Arbeitslasttyp einer Anzahl von Paketen, die von einem Netzgerät erhalten werden, und einer Benutzerpräferenz, wobei der Zielwartezeitparameter ein Zeitintervall angibt, das, wenn es eingehalten wird, bewirkt, dass ein Modem die Anzahl von Paketen abruft, einen Datenrahmengenerator zum Generieren eines Datenrahmens, der bewirkt, dass das Netzgerät die Anzahl von Paketen im Zeitintervall puffert, und eine Netzpaketsteuereinheit zum Aushandeln des Zielwartezeitparameters mit einem Netzgerät unter Nutzung des Datenrahmens umfasst.
Beispiel 2 enthält die Vorrichtung nach Beispiel 1, die ferner eine Vorhersagesteuereinheit zum Generieren einer Vorhersage, die eine Wahrscheinlichkeit, dass die Anzahl von Paketen mit dem Arbeitslasttyp korrespondiert, angibt, basierend auf einem trainierten Modell enthält.
Beispiel 3 enthält die Vorrichtung nach Beispiel 2, wobei die Vorhersagesteuereinheit zum Extrahieren einer Anzahl von Merkmalen aus der Anzahl von Paketen, die mit statistischen Eigenschaften von Paketen korrespondieren, um einen Merkmalsvektor zu generieren, dient, wobei die Vorhersage auf dem Merkmalsvektor basiert.
Beispiel 4 enthält die Vorrichtung nach Beispiel 1, die ferner einen Benutzeranforderungswähler zum Bestimmen, dass die Benutzerpräferenz das Optimieren des Sparens von Strom statt der Performanz angibt, enthält.
Beispiel 5 enthält die Vorrichtung nach Beispiel 4, wobei der Reaktivierungswähler zum Generieren des Zielwartezeitparameters, der eine maximal zulässige Zeit für einen Stromsparzustand vor dem Abrufen der Anzahl von Paketen angibt, basierend auf der Benutzerpräferenz für das Optimieren des Sparens von Strom und dem Arbeitslasttyp dient.
Beispiel 6 enthält die Vorrichtung nach Beispiel 1, die ferner einen Benutzeranforderungswähler zum Bestimmen, dass die Benutzerpräferenz das Optimieren der Performanz statt des Sparens von Strom angibt, enthält.
Beispiel 7 enthält die Vorrichtung nach Beispiel 6, wobei der Reaktivierungswähler zum Generieren des Zielwarteparameters, der eine minimal zulässige Zeit für einen Stromsparzustand vor dem Abrufen der Anzahl von Paketen angibt, basierend auf der Benutzerpräferenz für das Optimieren der Performanz und dem Arbeitslasttyp dient.
Beispiel 8 enthält ein nichttransientes, computerlesbares Speichermedium, das Befehle umfasst, die, wenn sie ausgeführt werden, bewirken, dass ein oder mehrere Prozessoren mindestens Folgendes durchführen: Generieren eines Zielwartezeitparameters basierend auf einem Arbeitslasttyp einer Anzahl von Paketen, die von einem Netzgerät erhalten werden, und einer Benutzerpräferenz, wobei der Zielwartezeitparameter ein Zeitintervall angibt, das, wenn es eingehalten wird, bewirkt, dass ein Modem die Anzahl von Paketen abruft, Generieren eines Datenrahmens, der bewirkt, dass das Netzgerät die Anzahl von Paketen im Zeitintervall puffert, und Aushandeln des Zielwartezeitparameters mit einem Netzgerät unter Nutzung des Datenrahmens.
Beispiel 9 enthält das nichttransiente, computerlesbare Speichermedium nach Beispiel 8, wobei die Befehle, wenn sie ausgeführt werden, bewirken, dass der eine oder die mehreren Prozessoren Folgendes durchführen: Generieren einer Vorhersage, die eine Wahrscheinlichkeit, dass die Anzahl von Paketen mit dem Arbeitslasttyp korrespondiert, angibt, basierend auf einem trainierten Modell.
Beispiel 10 enthält das nichttransiente, computerlesbare Speichermedium nach Beispiel 9, wobei die Befehle, wenn sie ausgeführt werden, bewirken, dass der eine oder die mehreren Prozessoren Folgendes durchführen: Extrahieren einer Anzahl von Merkmalen aus der Anzahl von Paketen, die mit statistischen Eigenschaften von Paketen korrespondieren, um einen Merkmalsvektor zu generieren, wobei die Vorhersage auf dem Merkmalsvektor basiert.
Beispiel 11 enthält das nichttransiente, computerlesbare Speichermedium nach Beispiel 8, wobei die Befehle, wenn sie ausgeführt werden, bewirken, dass der eine oder die mehreren Prozessoren Folgendes durchführen: Bestimmen, dass die Benutzerpräferenz das Optimieren des Sparens von Strom statt der Performanz angibt.
Beispiel 12 enthält das nichttransiente, computerlesbare Speichermedium nach Beispiel 11, wobei die Befehle, wenn sie ausgeführt werden, bewirken, dass der eine oder die mehreren Prozessoren Folgendes durchführen: Generieren des Zielwartezeitparameters, der eine maximal zulässige Zeit für einen Stromsparzustand vor dem Abrufen der Anzahl von Paketen angibt, basierend auf der Benutzerpräferenz für das Optimieren des Sparens von Strom und dem Arbeitslasttyp.
Beispiel 13 enthält das nichttransiente, computerlesbare Speichermedium nach Beispiel 8, wobei die Befehle, wenn sie ausgeführt werden, bewirken, dass der eine oder die mehreren Prozessoren Folgendes durchführen: Bestimmen, dass die Benutzerpräferenz das Optimieren der Performanz statt des Sparens von Strom angibt.
Beispiel 14 enthält das nichttransiente, computerlesbare Speichermedium nach Beispiel 13, wobei die Befehle, wenn sie ausgeführt werden, bewirken, dass der eine oder die mehreren Prozessoren Folgendes durchführen: Generieren des Zielwarteparameters, der eine minimal zulässige Zeit für einen Stromsparzustand vor dem Abrufen der Anzahl von Paketen angibt, basierend auf der Benutzerpräferenz für das Optimieren der Performanz und dem Arbeitslasttyp.
Beispiel 15 enthält ein Verfahren, das Folgendes umfasst: Generieren eines Zielwartezeitparameters basierend auf einem Arbeitslasttyp einer Anzahl von Paketen, die von einem Netzgerät erhalten werden, und einer Benutzerpräferenz, wobei der Zielwartezeitparameter ein Zeitintervall angibt, das, wenn es eingehalten wird, bewirkt, dass ein Modem die Anzahl von Paketen abruft, Generieren eines Datenrahmens, der bewirkt, dass das Netzgerät die Anzahl von Paketen im Zeitintervall puffert, und Aushandeln des Zielwartezeitparameters mit einem Netzgerät unter Nutzung des Datenrahmens.
Beispiel 16 enthält das Verfahren nach Beispiel 15, das ferner Folgendes enthält: Generieren einer Vorhersage, die eine Wahrscheinlichkeit, dass die Anzahl von Paketen mit dem Arbeitslasttyp korrespondiert, angibt, basierend auf einem trainierten Modell.
Beispiel 17 enthält das Verfahren nach Beispiel 15, das ferner Folgendes enthält: Bestimmen, dass die Benutzerpräferenz das Optimieren des Sparens von Strom statt der Performanz angibt.
Beispiel 18 enthält das Verfahren nach Beispiel 17, das ferner Folgendes enthält: Generieren des Zielwartezeitparameters, der eine maximal zulässige Zeit für einen Stromsparzustand vor dem Abrufen der Anzahl von Paketen angibt, basierend auf der Benutzerpräferenz für das Optimieren des Sparens von Strom und dem Arbeitslasttyp.
Beispiel 19 enthält das Verfahren nach Beispiel 15, das ferner Folgendes enthält: Bestimmen, dass die Benutzerpräferenz das Optimieren der Performanz statt des Sparens von Strom angibt.
Beispiel 20 enthält das Verfahren nach Beispiel 19, das ferner Folgendes enthält: Generieren des Zielwarteparameters, der eine minimal zulässige Zeit für einen Stromsparzustand vor dem Abrufen der Anzahl von Paketen angibt, basierend auf der Benutzerpräferenz für das Optimieren der Performanz und dem Arbeitslasttyp.
Hierin sind einige beispielhafte Verfahren, Vorrichtungen und Erzeugnisse offenbart worden, jedoch ist der Schutzbereich dieses Patents nicht auf sie begrenzt. Vielmehr deckt dieses Patent sämtliche Verfahren, Vorrichtungen und Erzeugnisse ab, die bei Anlegung angemessener Maßstäbe in den Schutzbereich der Ansprüche dieses Patents fallen.
Die folgenden Ansprüche werden durch diese Bezugnahme hiermit in diese ausführliche Beschreibung aufgenommen, wobei jeder Anspruch als separate Ausführungsform der vorliegenden Offenbarung für sich stehen kann.

Claims

Vorrichtung, die Folgendes umfasst: einen Reaktivierungswähler zum Generieren eines Zielwartezeitparameters basierend auf einem Arbeitslasttyp einer Anzahl von Paketen, die von einem Netzgerät erhalten werden, und einer Benutzerpräferenz, wobei der Zielwartezeitparameter ein Zeitintervall angibt, das, wenn es eingehalten wird, bewirkt, dass ein Modem die Anzahl von Paketen abruft; einen Datenrahmengenerator zum Generieren eines Datenrahmens, der bewirkt, dass das Netzgerät die Anzahl von Paketen im Zeitintervall puffert; und eine Netzpaketsteuereinheit zum Aushandeln des Zielwartezeitparameters mit einem Netzgerät unter Nutzung des Datenrahmens.
Vorrichtung nach Anspruch 1, die ferner eine Vorhersagesteuereinheit zum Generieren einer Vorhersage, die eine Wahrscheinlichkeit, dass die Anzahl von Paketen mit dem Arbeitslasttyp korrespondiert, angibt, basierend auf einem trainierten Modell enthält.
Vorrichtung nach einem der Ansprüche 1 bis 2, wobei die Vorhersagesteuereinheit zum Extrahieren einer Anzahl von Merkmalen aus der Anzahl von Paketen, die mit statistischen Eigenschaften von Paketen korrespondieren, um einen Merkmalsvektor zu generieren, dient, wobei die Vorhersage auf dem Merkmalsvektor basiert.
Vorrichtung nach Anspruch 1, die ferner einen Benutzeranforderungswähler zum Bestimmen, dass die Benutzerpräferenz das Optimieren des Sparens von Strom statt der Performanz angibt, enthält.
Vorrichtung nach Anspruch 4, wobei der Reaktivierungswähler zum Generieren des Zielwartezeitparameters, der eine maximal zulässige Zeit für einen Stromsparzustand vor dem Abrufen der Anzahl von Paketen angibt, basierend auf der Benutzerpräferenz für das Optimieren des Sparens von Strom und dem Arbeitslasttyp dient.
Vorrichtung nach Anspruch 1, die ferner einen Benutzeranforderungswähler zum Bestimmen, dass die Benutzerpräferenz das Optimieren der Performanz statt des Sparens von Strom angibt, enthält.
Vorrichtung nach Anspruch 6, wobei der Reaktivierungswähler zum Generieren des Zielwarteparameters, der eine minimal zulässige Zeit für einen Stromsparzustand vor dem Abrufen der Anzahl von Paketen angibt, basierend auf der Benutzerpräferenz für das Optimieren der Performanz und dem Arbeitslasttyp dient.
Computerlesbares Medium oder computerlesbare Medien, das/die Befehle umfasst/umfassen, die, wenn sie ausgeführt werden, bewirken, dass mindestens ein Prozessor mindestens Folgendes durchführt: Generieren eines Zielwartezeitparameters basierend auf einem Arbeitslasttyp einer Anzahl von Paketen, die von einem Netzgerät erhalten werden, und einer Benutzerpräferenz, wobei der Zielwartezeitparameter ein Zeitintervall angibt, das, wenn es eingehalten wird, bewirkt, dass ein Modem die Anzahl von Paketen abruft; Generieren eines Datenrahmens, der bewirkt, dass das Netzgerät die Anzahl von Paketen im Zeitintervall puffert; und Aushandeln des Zielwartezeitparameters mit einem Netzgerät unter Nutzung des Datenrahmens.
Computerlesbares Medium oder computerlesbare Medien nach Anspruch 8, wobei die Befehle, wenn sie ausgeführt werden, bewirken, dass der eine oder die mehreren Prozessoren Folgendes durchführen: Generieren einer Vorhersage, die eine Wahrscheinlichkeit, dass die Anzahl von Paketen mit dem Arbeitslasttyp korrespondiert, angibt, basierend auf einem trainierten Modell.
Computerlesbares Medium oder computerlesbare Medien nach einem der Ansprüche 8 bis 9, wobei die Befehle, wenn sie ausgeführt werden, bewirken, dass der eine oder die mehreren Prozessoren Folgendes durchführen: Extrahieren einer Anzahl von Merkmalen aus der Anzahl von Paketen, die mit statistischen Eigenschaften von Paketen korrespondieren, um einen Merkmalsvektor zu generieren, wobei die Vorhersage auf dem Merkmalsvektor basiert.
Computerlesbares Medium oder computerlesbare Medien nach Anspruch 8, wobei die Befehle, wenn sie ausgeführt werden, bewirken, dass der eine oder die mehreren Prozessoren Folgendes durchführen: Bestimmen, dass die Benutzerpräferenz das Optimieren des Sparens von Strom statt der Performanz angibt.
Computerlesbares Medium oder computerlesbare Medien nach Anspruch 11, wobei die Befehle, wenn sie ausgeführt werden, bewirken, dass der eine oder die mehreren Prozessoren Folgendes durchführen: Generieren des Zielwartezeitparameters, der eine maximal zulässige Zeit für einen Stromsparzustand vor dem Abrufen der Anzahl von Paketen angibt, basierend auf der Benutzerpräferenz für das Optimieren des Sparens von Strom und dem Arbeitslasttyp.
Computerlesbares Medium oder computerlesbare Medien nach Anspruch 8, wobei die Befehle, wenn sie ausgeführt werden, bewirken, dass der eine oder die mehreren Prozessoren Folgendes durchführen: Bestimmen, dass die Benutzerpräferenz das Optimieren der Performanz statt des Sparens von Strom angibt.
Computerlesbares Medium oder computerlesbare Medien nach Anspruch 13, wobei die Befehle, wenn sie ausgeführt werden, bewirken, dass der eine oder die mehreren Prozessoren Folgendes durchführen: Generieren des Zielwarteparameters, der eine minimal zulässige Zeit für einen Stromsparzustand vor dem Abrufen der Anzahl von Paketen angibt, basierend auf der Benutzerpräferenz für das Optimieren der Performanz und dem Arbeitslasttyp.
Verfahren, das Folgendes umfasst: Generieren eines Zielwartezeitparameters basierend auf einem Arbeitslasttyp einer Anzahl von Paketen, die von einem Netzgerät erhalten werden, und einer Benutzerpräferenz, wobei der Zielwartezeitparameter ein Zeitintervall angibt, das, wenn es eingehalten wird, bewirkt, dass ein Modem die Anzahl von Paketen abruft; Generieren eines Datenrahmens, der bewirkt, dass das Netzgerät die Anzahl von Paketen im Zeitintervall puffert; und Aushandeln des Zielwartezeitparameters mit einem Netzgerät unter Nutzung des Datenrahmens.
Verfahren nach Anspruch 15, das ferner Folgendes enthält: Generieren einer Vorhersage, die eine Wahrscheinlichkeit, dass die Anzahl von Paketen mit dem Arbeitslasttyp korrespondiert, angibt, basierend auf einem trainierten Modell.
Verfahren nach Anspruch 15, das ferner Folgendes enthält: Bestimmen, dass die Benutzerpräferenz das Optimieren des Sparens von Strom statt der Performanz angibt.
Verfahren nach einem der Ansprüche 15 bis 17, das ferner Folgendes enthält: Generieren des Zielwartezeitparameters, der eine maximal zulässige Zeit für einen Stromsparzustand vor dem Abrufen der Anzahl von Paketen angibt, basierend auf der Benutzerpräferenz für das Optimieren des Sparens von Strom und dem Arbeitslasttyp.
Verfahren nach Anspruch 15, das ferner Folgendes enthält: Bestimmen, dass die Benutzerpräferenz das Optimieren der Performanz statt des Sparens von Strom angibt.
Verfahren nach Anspruch 19, das ferner Folgendes enthält: Generieren des Zielwarteparameters, der eine minimal zulässige Zeit für einen Stromsparzustand vor dem Abrufen der Anzahl von Paketen angibt, basierend auf der Benutzerpräferenz für das Optimieren der Performanz und dem Arbeitslasttyp.