DE102021113263A1 - Extreme-High-Throughput-Fast-Initial-Link-Setup-Unterstützung in einem Mehrfachverbindungsbetrieb in Funkkommunikationen - Google Patents

Abstract

Eine Zugangspunkt-, AP-, Mehrfachverbindungsvorrichtung, MLD, und eine Nicht-AP-Station-, STA-, MLD führt eine Fast-Initial-Link-Setup-, FILS-, Prozedur aus, um Funkkommunikationen über eine Mehrzahl von Verbindungen einzurichten (1210). Die AP-MLD und die Nicht-AP-STA-MLD kommunizieren über eine oder mehrere Verbindungen der Mehrzahl von Verbindungen nach einem Abschluss der FILS-Prozedur (1220) mit einem FILS-Discovery-Rahmen, der in der FILS-Prozedur übertragen wird, der anzeigt, ob eine Dienstsatzkennung (SSID) der AP-MLD zu einer SSID eines APs einer Mehrzahl von APs in der AP-MLD, die den FILS-Discovery-Rahmen sendet, verschieden ist.

Description

• Querverweis auf verwandte Patentanmeldung
• Die vorliegende Offenbarung ist Teil einer nichtvorläufigen Patentanmeldung, die die Priorität der vorläufigen US-Patentanmeldung Nr. 63/028,801 , eingereicht am 22. Mai 2020, beansprucht, deren Inhalte durch Bezugnahme in ihrer Gesamtheit eingeschlossen sind.
• Technisches Gebiet
• Die vorliegende Offenbarung bezieht sich allgemein auf Funkkommunikationen und insbesondere auf eine Extreme-High-Throughput- (EHT-) Fast-Initial-Link-Setup- (FILS-) Unterstützung in einem Mehrfachverbindungsbetrieb (bzw. Multi-Link-Operation) in Funkkommunikationen.
• Hintergrund
• Wenn hier nicht anders angezeigt, sind Ansätze, die in diesem Abschnitt beschrieben sind, nicht Stand der Technik zu den unten angeführten Ansprüchen und werden durch ein Einschließen in diesem Abschnitt nicht als Stand der Technik anerkannt.
• In einem lokalen Funknetzwerk (WLAN) muss eine Station (STA) einen Zugangspunkt (AP) zuerst ermitteln, um Kommunikationen (z.B. Senden und Empfangen von Daten) mit dem AP einzurichten. Innerhalb einer aktuellen Institute of Electrical and Electronics Engineers (IEEE) 802.11 Spezifikation kann ein AP ein FILS-Ermittlungssignal senden, um eine Ermittlung des APs durch (eine) STA(s) innerhalb eines Kommunikationsbereichs zu ermöglichen, um eine Kommunikationsverbindung mit dem AP einzurichten. Eine Verbindungseinrichtung bezieht typischerweise eine Ermittlungsprozedur, eine Authentifikationsprozedur und eine Verknüpfungsprozedur ein. Ein FILS-Discovery-Rahmen wird in der Ermittlungsprozedur verwendet. Einige Modifikationen an dem FILS-Discovery-Rahmen, wie aktuell definiert, sind jedoch notwendig, um einen Mehrfachverbindungsbetrieb zu unterstützen, wenn der AP eine AP-Mehrfachverbindungsvorrichtung (-MLD) ist und/oder die STA eine STA-MLD ist. Zum Beispiel kann für eine AP-MLD, obwohl ein AP in der AP-MLD seine eigene Dienstsatzkennung (SSID) aufweist, die AP-MLD eine MLD-Ebenen-SSID aufweisen, welche zu der SSID des APs verschieden ist. Entsprechend muss der FILS-Discovery-Rahmen, wie aktuell definiert, modifiziert werden, um solche Informationen anzuzeigen. Weiter sind einige Modifikationen an der aktuellen IEEE-Spezifikation notwendig, um eine EHT-FILS in Mehrfachverbindungsbetrieben zu unterstützen.
• Zusammenfassung
• Die nachfolgende Zusammenfassung ist nur darstellend und beabsichtigt nicht, in irgendeiner Weise einschränkend zu sein. Das heißt, die nachfolgende Zusammenfassung wird bereitgestellt, um Konzepte, Höhepunkte, Nutzen und Vorteile der neuen und nicht offensichtlichen Techniken einzuführen, die hierin beschrieben sind. Ausgewählte Implementierungen werden weiter nachfolgend in der detaillierten Beschreibung beschrieben. Somit beabsichtigt die nachfolgende Zusammenfassung nicht, wesentliche Merkmale des beanspruchten Gegenstands zu identifizieren, noch ist sie für ein Verwenden bei einem Bestimmen des Schutzumfangs des beanspruchten Gegenstands gedacht.
• Eine Aufgabe der vorliegenden Offenbarung ist, Schemen, Konzepte, Entwürfe, Techniken, Verfahren und Vorrichtungen bereitzustellen, die eine EHT-FILS-Unterstützung in einem Mehrfachverbindungsbetrieb in Funkkommunikationen betreffen. Bei verschiedenen vorgeschlagenen Schemen gemäß der vorliegenden Offenbarung können Probleme, die hierin beschrieben werden, adressiert werden. Ein Verfahren und eine Vorrichtung gemäß der Erfindung werden in den unabhängigen Ansprüchen definiert. Die abhängigen Ansprüche definieren bevorzugte Ausführungsformen davon.
• In einem Aspekt kann ein Verfahren ein Ausführen einer FILS-Prozedur einbeziehen, um Funkkommunikationen zwischen einer AP-MLD und einer Nicht-AP-STA-MLD über eine Mehrzahl von Verbindungen einzurichten. Das Verfahren kann auch ein Kommunizieren über eine oder mehrere Verbindungen der Mehrzahl von Verbindungen nach einem Abschluss der FILS-Prozedur einbeziehen. Ein FILS-Discovery-Rahmen, der in der FILS-Prozedur übertragen wird, kann anzeigen, ob eine SSID der AP-MLD zu einer SSID eines APs einer Mehrzahl von APs in der AP-MLD, die den FILS-Discovery-Rahmen sendet, verschieden ist.
• In einem anderen Aspekt kann eine Vorrichtung einen Sendeempfänger, der eingerichtet ist, über Funk zu kommunizieren, und einen mit dem Sendeempfänger verbundenen Prozessor aufweisen. Der Prozessor kann über den Sendeempfänger eine FILS-Prozedur ausführen, um Funkkommunikationen zwischen einer AP-MLD und einer Nicht-AP-STA-MLD über eine Mehrzahl von Verbindungen einzurichten. Der Prozessor kann nach einem Abschluss der FILS-Prozedur auch über den Sendeempfänger über eine oder mehrere Verbindungen der Mehrzahl von Verbindungen kommunizieren. Ein FILS-Discovery-Rahmen, der in der FILS-Prozedur übertragen wird, kann anzeigen, ob eine Dienstsatzkennung (SSID) der AP-MLD zu einer SSID eines APs einer Mehrzahl von APs in der AP-MLD, die den FILS-Discovery-Rahmen sendet, verschieden ist.
• Es ist beachtenswert, dass, obwohl die hier bereitgestellte Beschreibung im Kontext bestimmter Funkzugangstechnologien, Netzwerke und Netzwerktopologien wie Wi-Fi steht, die vorgeschlagenen Konzepte, Schemen und jegliche Variation(en)/Weiterentwicklung(en) davon in, für und durch andere Arten von Funkzugangstechnologien, Netzwerken und Netzwerktopologien, wie zum Beispiel und ohne Einschränkung Bluetooth, ZigBee, 5th Generation (5G)/New Radio (NR), Long-Term Evolution (LTE), LTE-Advanced, LTE-Advanced Pro, Internet-of-Things (loT), Industrial loT (IIoT) und Narrowband loT (NB-loT), implementiert werden kann. Somit ist der Schutzumfang der vorliegenden Offenbarung nicht auf die hierin beschriebenen Beispiele beschränkt.
• Figurenliste
• Die begleitenden Zeichnungen sind enthalten, um ein weiteres Verständnis der Offenbarung zu vermitteln, und sind in der vorliegenden Offenbarung eingeschlossen und bilden einen Teil derselben. Die Zeichnungen stellen Implementierungen der Offenbarung dar und dienen zusammen mit der Beschreibung dazu, die Prinzipien der Offenbarung zu erklären. Es ist anzuerkennen, dass die Zeichnungen nicht notwendigerweise maßstabsgetreu sind, da einige Komponenten anders proportioniert gezeigt sein können als die Größe in einer tatsächlichen Implementierung, um das Konzept der vorliegenden Offenbarung klar darzustellen.
• 1 ist ein Diagramm einer Beispielnetzwerkumgebung, in welcher verschiedene Lösungen und Schemen gemäß der vorliegenden Offenbarung implementiert sein können.
• 2 ist ein Diagramm eines Beispielentwurfs gemäß einer Implementierung der vorliegenden Offenbarung.
• 3 ist ein Diagramm eines Beispielentwurfs gemäß einer Implementierung der vorliegenden Offenbarung.
• 4 ist ein Diagramm eines Beispielentwurfs gemäß einer Implementierung der vorliegenden Offenbarung.
• 5 ist ein Diagramm eines Beispielentwurfs gemäß einer Implementierung der vorliegenden Offenbarung.
• 6 ist ein Diagramm eines Beispielentwurfs gemäß einer Implementierung der vorliegenden Offenbarung.
• 7 ist ein Diagramm eines Beispielentwurfs gemäß einer Implementierung der vorliegenden Offenbarung.
• 8 ist ein Diagramm eines Beispielentwurfs gemäß einer Implementierung der vorliegenden Offenbarung.
• 9 ist ein Diagramm eines Beispielentwurfs gemäß einer Implementierung der vorliegenden Offenbarung.
• 10 ist ein Diagramm eines Beispielszenariums gemäß einer Implementierung der vorliegenden Offenbarung.
• 11 ist ein Blockdiagramm eines Beispielkommunikationssystems gemäß einer Implementierung der vorliegenden Offenbarung.
• 12 ist ein Ablaufdiagramm eines Beispielprozesses gemäß einer Implementierung der vorliegenden Offenbarung.
• Detaillierte Beschreibung bevorzugter Ausführungsformen
• Detaillierte Ausführungsformen und Implementierungen der beanspruchten Gegenstände werden hierin offenbart. Es soll jedoch verstanden werden, dass die offenbarten Ausführungsformen und Implementierungen nur darstellend für die beanspruchten Gegenstände sind, welche in verschiedenen Formen ausgeführt werden können. Die vorliegende Offenbarung kann jedoch in vielen unterschiedlichen Formen ausgeführt werden und sollte nicht als auf die beispielhaften Ausführungsformen und Implementierungen beschränkt angesehen werden, die hier dargelegt sind. Diese beispielhaften Ausführungsformen und Implementierungen sind eher so vorgesehen, dass eine Beschreibung der vorliegenden Offenbarung genau und vollständig ist und den Schutzumfang der vorliegenden Offenbarung für diejenigen mit Kenntnissen auf dem Gebiet vollständig vermittelt. In der nachfolgenden Beschreibung können Details von bekannten Merkmalen und Techniken weggelassen sein, um zu verhindern, dass die präsentierten Ausführungsformen und Implementierungen unnötig verschleiert werden.
• Überblick
• Implementierungen gemäß der vorliegenden Offenbarung beziehen sich auf verschiedene Techniken, Verfahren, Schemen und/oder Lösungen, die eine EHT-FILS-Unterstützung in einem Mehrfachverbindungsbetrieb in Funkkommunikationen betreffen. Gemäß der vorliegenden Offenbarung kann eine Anzahl möglicher Lösungen getrennt oder zusammen implementiert werden. Das heißt, obwohl diese möglichen Lösungen nachfolgend getrennt beschrieben sein können, können zwei oder mehr dieser möglichen Lösungen in einer oder einer anderen Kombination implementiert werden.
• 1 stellt eine Beispielnetzwerkumgebung 100 dar, in welcher verschiedene Lösungen und Schemen gemäß der vorliegenden Offenbarung implementiert sein können. 2 ~ 12 stellen Beispiele von Implementierungen verschiedener vorgeschlagener Schemen in der Netzwerkumgebung 100 gemäß der vorliegenden Offenbarung dar. Die nachfolgende Beschreibung verschiedener vorgeschlagener Schemen wird mit Bezug auf 1 ~ 12 bereitgestellt.
• Bezüglich 1 kann die Netzwerkumgebung 100 eine STA 110 und eine STA 120 einbeziehen, die über Funk über mehrere Verbindungen (z.B. Verbindung 1, Verbindung 2 und Verbindung 3) gemäß einem oder mehreren Institute of Electrical and Electronics Engineers (IEEE) 802.11 Standards, wie IEEE 802.11be und darüber hinaus, kommunizieren. Jede der STA 110 und der STA 120 kann als eine MLD fungieren. Zum Beispiel kann die STA 110 als eine Nicht-AP-MLD mit mehreren virtuellen STAs (z.B. STA 1, STA 2 und STA 3), die innerhalb der STA 110 arbeiten, fungieren. Korrespondierend kann die STA 120 als eine AP-MLD mit mehreren virtuellen APs (z.B. AP 1, AP 2 und AP 3), die innerhalb der STA 120 arbeiten, fungieren. Bei verschiedenen vorgeschlagenen Schemen gemäß der vorliegenden Offenbarung können die STA 110 und die STA 120 eingerichtet sein, eine EHT-FILS-Unterstützung in einem Mehrfachverbindungsbetrieb in Funkkommunikationen gemäß verschiedenen vorgeschlagenen Schemen auszuführen, die hierin beschrieben werden.
• 2 stellt einen Beispielentwurf 200 eines FILS-Discovery-Rahmens bei einem vorgeschlagenen Schema gemäß der vorliegenden Offenbarung dar. Bezüglich Teil (A) von 2 kann ein FILS-Discovery-Rahmen verschiedene Informationsfelder aufweisen, die ein FILS-Discovery-Information-Feld umfassen. Bezüglich Teil (B) von 2 kann es unter den verschiedenen Informationsfeldern in dem FILS-Discovery-Information-Feld ein FILS-Discovery- (FD-) Capability-Unterfeld geben. Das FD-Capability-Unterfeld kann mehrere Unterfelder aufweisen, die ein Multiple-Links-Presence-Indicator-Unterfeld umfassen, welches anzeigen kann, ob ein AP (z.B. die STA 120), die den FILS-Discovery-Rahmen sendet, einen Mehrfachverbindungsbetrieb als ein Teil einer AP-MLD unterstützt. Zum Beispiel kann das Multiple-Links-Presence-Indicator-Unterfeld auf 1 festgelegt sein, um anzuzeigen, dass ein Multiple-Links-Element in den Signal- (bzw. Beacon-) und Sondierungsantwortrahmen vorhanden ist. Andererseits kann das Multiple-Links-Presence-Indicator-Unterfeld auf 0 festgelegt sein, um anzuzeigen, dass das Multiple-Links-Element in den Signal- und Sondierungsantwortrahmen nicht vorhanden ist.
• 3 stellt einen Beispielentwurf 300 eines FD-Capability-Unterfelds bei einem vorgeschlagenen Schema gemäß der vorliegenden Offenbarung dar. Bezüglich 3 kann das FD-Capability-Unterfeld verschiedene Unterfelder aufweisen, die ein Multiple-Links-Presence-Indicator-Unterfeld umfassen. Bei dem vorgeschlagenen Schema, wenn das Multiple-Links-Presence-Indicator-Unterfeld in dem FD-Capability-Unterfeld in dem FILS-Discovery-Information-Feld auf 1 festgelegt ist, und die AP-MLD eine AP-MLD-SSID aufweist, welche zu einer SSID eines APs (z.B. AP1, AP2 oder AP3 der STA 120) verschieden ist, der den FILS-Discovery-Rahmen sendet, dann kann das FILS-Discovery-Information-Feld auch ein Short-MLD-SSID-Unterfeld aufweisen, wie in Teil (B) von 2 gezeigt. Das Short-MLD-SSID-Unterfeld kann eine 4-Oktette kurze SSID der AP-MLD (z.B. wie in Abschnitt 9.4.2.170 (Reduced Neighbor Report element) der IEEE-Spezifikation definiert) aufweisen.
• Bei einem vorgeschlagenen Schema gemäß der vorliegenden Offenbarung kann hinsichtlich einer höhere-Schicht-Protokoll- (HLP-) Kapselung, ein FILS-HLP-Container-Element für ein Kapseln von HLP-Paketen verwendet werden. Bei dem vorgeschlagenen Schema kann in einem Fall, dass eine Nicht-AP-STA-MLD (z.B. die STA 110) eine HLP-Kapselung verwendet, die Nicht-AP-STA-MLD ein FILS-HLP-Container-Element für jedes HLP-Paket konstruieren. Die Nicht-AP-STA-MLD kann dann mehrere FILS-HLP-Container-Elemente in einen Verknüpfungs- (oder Wiederverknüpfungs-) Anforderungsrahmen anordnen, solange sie in die Größenbeschränkung einer Medium-Access-Control- (MAC-) Management-Protokolldateneinheit (MMPDU) passen. Das HLP-Paket in dem FILS-HLP-Container-Element kann ein beliebiges MAC-Dienstdateneinheit- (MSDU-) Format aufweisen (z.B. wie im Abschnitt 5.1.4 (MSDU format) der IEEE-Spezifikation definiert). Bei dem vorgeschlagenen Schema kann eine Kapselungsprozedur einbeziehen, dass die Nicht-AP-STA-MLD ein oder mehrere FILS-HLP-Container-Elemente mit einer Ziel-MAC-Adresse, einer Quellen-MAC-Adresse des HLP-Pakets und dem HLP-Paket in einem MSDU-Format füllt. Die Quellen-MAC-Adresse kann die MLD-MAC-Adresse der Nicht-AP-STA-MLD sein. Die Kapselungsprozedur kann auch einbeziehen, dass die Nicht-AP-STA-MLD das (die) FILS-HLP-Container-Element(e) in einen Verknüpfungs- (oder Wiederverknüpfungs-) Anforderungsrahmen einbindet.
• Bei dem vorgeschlagenen Schema kann, in einem Fall, dass eine AP-MLD (z.B. die STA 120) einen Verknüpfungs- (oder Wiederverknüpfungs-) Anforderungsrahmen empfängt, welcher (ein) FILS-HLP-Container-Element(e) aufweist, die AP-MLD das (die) HLP-Paket(e) entkapseln aber braucht das (die) HLP-Paket(e) nicht zu senden, bis eine Schlüsselbestätigung (z.B. wie im Abschnitt 12.12.2.6 (Key confirmation with FILS authentication) der IEEE-Spezifikation definiert) erfolgreich abgeschlossen ist. Nach einer erfolgreichen Schlüsselbestätigung kann die AP-MLD das (die) HLP-Paket(e) an ein Upstream-Netzwerk oder einen Basisdienstsatz (BSS) gemäß der Ziel-MAC-Adresse des HLP-Pakets (der HLP-Pakete) weiterleiten. Die Reihenfolge eines Weiterleitens der HLP-Pakete kann die gleiche sein wie die Reihenfolge der FILS-HLP-Container-Elemente in dem Verknüpfungs- (oder Wiederverknüpfungs-) Anforderungsrahmen. Falls die Schlüsselbestätigung fehlschlägt, kann die AP-MLD das (die) HLP-Paket(e) verwerfen, und die AP-MLD kann auch das (die) HLP-Paket(e) basierend auf bestimmten Regeln filtern.
• Bei dem vorgeschlagenen Schema kann eine Paketkapselungsprozedur für jedes FILS-HLP-Container-Element einbeziehen, dass die AP-MLD die Ziel-MAC-Adresse, die Quellen-MAC-Adresse und das HLP-Paket von einem gegebenen FILS-HLP-Container-Element extrahiert. Dann kann die Prozedur einbeziehen, dass der AP verifiziert, dass die extrahierte Quellen-MAC-Adresse gleich der MLD-MAC-Adresse einer Nicht-AP-STA-MLD (z.B. der STA 110) ist, die mit der Quellen-MAC-Adresse des Verknüpfungs- (oder Wiederverknüpfungs-) Anforderungsrahmens verknüpft ist. Falls diese Adressen verschieden sind, kann der AP das FILS-HLP-Container-Element verwerfen. Als Nächstes kann die Prozedur einbeziehen, dass der AP einen Rahmen in einem geeigneten Format konstruiert, um das HLP-Paket unter Verwendung der extrahierten Ziel-MAC-Adresse, der extrahierten Quellen-MAC-Adresse und des HLP-Pakets zu dem Upstream-Netzwerk oder BSS zuzustellen.
• Bei dem vorgeschlagenen Schema kann die AP-MLD, um einen Verknüpfungs- (oder Wiederverknüpfungs-) Antwortrahmen zu senden, warten, bis eine vordefinierte Dauer, wie eine dot11HLPWaitTime, nach dem Empfangen des Verknüpfungs- (oder Wiederverknüpfungs-) Anforderungsrahmens abgelaufen ist. In einem Fall, dass vor dem Senden des Verknüpfungs- (oder Wiederverknüpfungs-) Antwortrahmens die AP-MLD ein oder mehrere HLP-Pakete von dem Upstream-Netzwerk oder BSS empfängt, welches/welche die MLD-MAC-Adresse der Nicht-AP-STA-MLD oder eine Gruppenadresse als die Zieladresse aufweist/aufweisen, kann die AP-MLD jedes HLP-Paket in einem unterschiedlichen FILS-HLP-Container-Element in dem Verknüpfungs- (oder Wiederverknüpfungs-) Antwortrahmen senden. Die Reihenfolge der FILS-HLP-Container-Elemente in dem Verknüpfungs- (oder Wiederverknüpfungs-) Antwortrahmen kann die gleiche sein wie die Reihenfolge des Empfangs der HLP-Pakete. Falls die AP-MLD HLP-Pakete für die Nicht-AP-STA-MLD nach dem Senden des Verknüpfungs- (oder Wiederverknüpfungs-) Antwortrahmens empfängt, kann die AP-MLD die HLP-Pakete als Datenrahmen senden. In einem Fall, dass der AP vor dem Senden des Verknüpfungs- (oder Wiederverknüpfungs-) Antwortrahmens kein HLP-Paket von dem Upstream-Netzwerk oder BSS empfängt, welches die MLD-MAC-Adresse der Nicht-AP-STA-MLD oder eine Gruppenadresse als die Zieladresse aufweist, braucht die AP-MLD kein FILS-HLP-Container-Element in dem Verknüpfungs- (oder Wiederverknüpfungs-) Antwortrahmen zu senden. Bei dem vorgeschlagenen Schema braucht der Statuscode in dem Verknüpfungs- (oder Wiederverknüpfungs-) Antwortrahmen nicht durch das Vorhandensein oder Fehlen eines FILS-HLP-Container-Elements betroffen zu sein.
• Bei einem vorgeschlagenen Schema gemäß der vorliegenden Offenbarung kann hinsichtlich einer HLP-Kapselung eine Paketkapselungsprozedur für jedes FILS-HLP-Container-Element durch eine AP-MLD (z.B. die STA 120) bestimmte Operationen einbeziehen. Zuerst kann die AP-MLD die Felder des HLP-Container-Elements auf eine bestimmte Weise festlegen. Zum Beispiel kann die AP-MLD das Ziel-MAC-Adressenfeld auf die Ziel-MAC-Adresse des empfangenen HLP-Pakets festlegen, welche die MLD-MAC-Adresse einer Nicht-AP-STA-MLD (z.B. der STA 110) oder eine Gruppenadresse sein kann. Falls die Ziel-MAC-Adresse des empfangenen HLP-Pakets zu der MLD-MAC-Adresse der Nicht-AP-STA-MLD verschieden ist, aber gleich einer der Funkmedium- (WM-) MAC-Adressen der Nicht-AP-STA-MLD ist, kann das Ziel-MAC-Adressenfeld auf die MLD-MAC-Adresse der Nicht-AP-STA-MLD festgelegt werden. Weiter kann die AP-MLD das Quellen-MAC-Adressenfeld auf die Quellen-MAC-Adresse des empfangenen HLP-Pakets festlegen. Weiterhin kann die AP-MLD das HLP-Paketfeld auf das HLP-Paket in dem MSDU-Format festlegen. Dann kann die AP-MLD das erste FILS-HLP-Container-Element (die ersten FILS-HLP-Container-Elemente) in einem Verknüpfungs- (oder Wiederverknüpfungs-) Antwortrahmen einbinden. Als Nächstes kann die AP-MLD den Verknüpfungs- (oder Wiederverknüpfungs-) Antwortrahmen senden.
• Bei einem vorgeschlagenen Schema gemäß der vorliegenden Offenbarung kann hinsichtlich einer HLP-Kapselung, falls eine Nicht-AP-STA-MLD (z.B. die STA 110) einen Verknüpfungs- (oder Wiederverknüpfungs-) Antwortrahmen mit einem oder mehreren FILS-HLP-Container-Elementen empfängt, die Nicht-AP-STA-MLD eine Schlüsselbestätigung zuerst ausführen. Nach einer erfolgreichen Schlüsselbestätigung kann die Nicht-AP-STA-MLD eine MA-UNITDATA.indication-Primitive für jedes HLP-Paket generieren. Die Reihenfolge des Generierens der MA-UNITDATA.indication-Primitive der HLP-Pakete kann die gleiche sein wie die Reihenfolge der FILS-HLP-Container-Elemente in dem Verknüpfungs- (oder Wiederverknüpfungs-) Antwortrahmen. Falls die Schlüsselbestätigung fehlschlägt, kann die Nicht-AP-STA-MLD das HLP-Paket (die HLP-Pakete) verwerfen.
• Bei einem vorgeschlagenen Schema gemäß der vorliegenden Offenbarung kann hinsichtlich einer HLP-Kapselung eine Paketkapselungsprozedur für jedes FILS-HLP-Container-Element durch eine Nicht-AP-STA-MLD (z.B. die STA 110) bestimmte Operationen einbeziehen. Zuerst kann die Nicht-AP-STA-MLD die Ziel-MAC-Adresse, die Quellen-MAC-Adresse und das HLP-Paket extrahieren. Dann kann die Nicht-AP-STA-MLD verifizieren, dass die extrahierte Ziel-MAC-Adresse gleich der MLD-MAC-Adresse der Nicht-AP-STA-MLD oder einer Gruppenadresse ist. Falls die Ziel-MAC-Adresse nicht für die Nicht-AP-STA-MLD ist, kann die Nicht-AP-STA-MLD das FILS-HLP-Container-Element verwerfen. Als Nächstes kann die Nicht-AP-STA-MLD eine MA-UNITDATA.indication-Primitive mit einer Anzahl von Parametern generieren, die zum Beispiel und ohne Einschränkung umfassen: eine Quellenadresse (die extrahierte Quellen-MAC-Adresse), eine Zieladresse (die extrahierte Ziel-MAC-Adresse), Routing-Informationen (alle), Daten (das extrahierte HLP-Paket), einen Empfangsstatus (Erfolg), eine Priorität (Zugangswettbewerb) und eine Dienstklasse (welche eine Quality-of-Service-Bestätigung (QoSAck), wenn die Zieladresse eine individuelle Adresse ist, oder eine Quality-of-Service-Negativbestätigung (QoSNoAck), wenn die Zieladresse keine individuelle Adresse ist, sein kann).
• Bei einem vorgeschlagenen Schema gemäß der vorliegenden Offenbarung können hinsichtlich eines FILS-Public-Key-Elements alle APs (z.B. der AP1, der AP2 und der AP3 in der STA 120) in der AP-MLD einen öffentlichen Schlüssel über mehrere Verbindungen (z.B. die Verbindung 1, die Verbindung 2 und die Verbindung 3) verwenden, und können alle Nicht-AP-STAs (z.B. die STA1, die STA2 und die STA3 in der STA 110) in der Nicht-AP-STA-MLD einen öffentlichen Schlüssel über die mehreren Verbindungen verwenden. Bei dem vorgeschlagenen Schema können Diffie-Hellman-Werte in allen APs in der AP-MLD über die mehreren Verbindungen allgemein / gleich / gemeinsam sein. Ähnlich können die Diffie-Hellman-Werte in allen Nicht-AP-STAs in der Nicht-AP-STA-MLD über die mehreren Verbindungen allgemein / gleich / gemeinsam sein.
• Bei dem vorgeschlagenen Schema kann ein FILS-Public-Key-Element verwendet werden, um den (zertifizierten) öffentlichen Schlüssel einer Vorrichtung für eine Verwendung mit einem FILS-Authentifikationsaustausch zu kommunizieren. 4 stellt einen Beispielentwurf 400 eines FILS-Public-Key-Elements bei dem vorgeschlagenen Schema dar. Bezüglich 4 kann das FILS-Public-Key-Element ein Element-ID-Feld, ein Längenfeld und ein Element-ID-Erweiterungsfeld (z.B. wie im Abschnitt 9.4.2.1 (General) der IEEE-Spezifikation definiert) aufweisen. Das FILS-Public-Key-Element kann auch ein Schlüsseltyp-Feld aufweisen, welches unterschiedliche Werte aufweisen kann. Zum Beispiel kann das Schlüsseltyp-Feld auf 1 festgelegt sein, um anzuzeigen, dass das FILS-Public-Key-Feld ein X.509v3 Zertifikat aufweist, das gemäß einem Internet Engineering Task Force (IETF) Request for Comments (RFC) 5280 codiert ist. Das Schlüsseltyp-Feld kann auf 2 festgelegt sein, um anzuzeigen, dass das FILS-Public-Key-Feld einen unzertifizierten öffentlichen Schlüssel aufweist, der gemäß IETF RFC 5480 codiert ist. Das Schlüsseltyp-Feld kann auf 3 festgelegt sein, um anzuzeigen, dass das FILS-Public-Key-Feld einen unzertifizierten öffentlichen Schlüssel aufweist, der gemäß IETF RFC 3279 codiert ist. Werte 0 und 4 ~ 255 für das Schlüsseltyp-Feld können reserviert sein.
• Bei einem vorgeschlagenen Schema gemäß der vorliegenden Offenbarung können hinsichtlich einer Schlüsseleinrichtung mit einer FILS-Shared-Key-Authentifikation die Nicht-AP-STA-MLD und die AP-MLD eine Schlüsseleinrichtung unter Verwendung von Authentifikationsrahmen ausführen und eine Schlüsselbestätigung unter Verwendung von Verknüpfungs- (oder Wiederverknüpfungs-) Anforderungs- und Verknüpfungs- (oder Wiederverknüpfungs-) Antwortrahmen ausführen. Falls die Nicht-AP-STA-MLD entscheidet, eine FILS-Shared-Key-Authentifikation zu initiieren, kann die Nicht-AP-STA-MLD zuerst einen zufälligen 16-Oktett-Einmalschlüssel auswählen und dann bestimmen, ob ein Pairwise-Master-Key-Securing-Association- (PMKSA-) Caching zu versuchen ist. Falls ein PMKSA-Caching versucht wird, kann die Nicht-AP-STA-MLD eine Liste von PMKSA-Kennungen generieren. Falls die Nicht-AP-STA-MLD versucht, eine Extensible-Authentication-Protocol (EAP-) Registrierungsprozedur (EAP-RP) zu initiieren, kann die Nicht-AP-STA-MLD ein EAP-Initiate/Re-auth-Paket nach IETF RFC 6696 mit bestimmten Klärungen konstruieren. Zum Beispiel kann hinsichtlich EAP-RP-Flags das B-Flag auf 0 festgelegt werden, um anzuzeigen, dass dies keine EAP-RP-Bootstrap-Nachricht ist, kann das L-Flag auf 1 festgelegt werden, um anzuzeigen, dass die Trusted-Third-Party (TTP), mit welcher die STA den rRK gemeinsam nutzt, die Lebensdauern des rRK und rMSK in dem EAP-Finish/Re-auth-Paket bereitstellen muss. Weiter kann die EAP-Kennung auf 0 festgelegt werden und das Cryptosuite-Feld braucht nicht auf 1 festgelegt zu werden. Bei dem vorgeschlagenen Schema kann, falls eine Perfect-Forward-Secrecy (PFS) gewünscht wird, die Nicht-AP-STA-MLD einen Finite-Zyklische-Gruppe-Rahmen dot11RSNAConfigDLCGroupTable auswählen. Dies kann ein Identifizieren einer Zahl von einer durch die Internet Assigned Numbers Authority (IANA) gewarteten Sammlung als „Gruppenbeschreibung“ („Group Description“) -Attribute für IETF RFC 2409 (IKE) einbeziehen. Die STA-MLD kann dann einen kurzlebigen (ephemeral) privaten Schlüssel generieren und die Scalar-Op der Gruppe (z.B. nach Abschnitt 12.4.4.1 (General) der IEEE-Spezifikation) mit ihrem zufälligen kurzlebigen privaten Schlüssel und dem Generator von der ausgewählten finiten zyklischen Gruppe ausführen, um einen kurzlebigen öffentlichen Schlüssel zu berechnen.
• Bei dem vorgeschlagenen Schema kann die Nicht-AP-STA-MLD einen Authentifikationsrahmen auf eine bestimmte Weise konstruieren. Zum Beispiel kann die Nicht-AP-STA-MLD die Authentifikationsalgorithmuszahl auf 4 (für eine FILS-Shared-Key-Authentifikation ohne PFS) oder 5 (für eine FILS-Shared-Key-Authentifikation mit PFS) festlegen (z.B. wie im Abschnitt 9.4.1.1 (Authentication Algorithm Number field) der IEEE-Spezifikation definiert), abhängig davon, ob eine PFS verwendet wird. Die Nicht-AP-STA-MLD kann auch die Authentifikations-Transaktionssequenzzahl auf 1 festlegen. Der zufällige Einmalschlüssel kann in dem FILS-Nonce-Element codiert werden (z.B. wie im Abschnitt 9.4.2.189 (FILS Nonce element (11ai)) der IEEE-Spezifikation definiert). Falls eine Liste von PMKSA-Kennungen generiert worden ist, kann die Nicht-AP-STA-MLD die Liste verwenden, um ein PMKID-Listenfeld in einem Robust-Security-Network-Element zu konstruieren. Die zufällige FILS-Session kann in dem FILS-Session-Element codiert werden (z.B. wie im Abschnitt 9.4.2.179 (FILS Session element (11ai)) der IEEE-Spezifikation definiert). Das EAP-Initiate/Re-authentication-Paket, falls generiert, kann in das FILS-Wrapped-Data-Feld kopiert werden (z.B. wie im Abschnitt 9.4.2.187 (FILS Wrapped Data element (11ai)) der IEEE-Spezifikation definiert). Falls eine PFS gewünscht ist, kann die ausgewählte finite zyklische Gruppe in dem Finite-Cyclic-Group-Feld codiert werden (z.B. wie im Abschnitt 9.4.1.42 (Finite Cyclic Group field) der IEEE-Spezifikation definiert) und der EPHEMERAL öffentliche Schlüssel kann in dem FFE-Feld codiert werden (z.B. wie im Abschnitt 9.4.1.40 (FFE field) der IEEE-Spezifikation definiert) gemäß der Element-zu-Oktettzeichenfolge-Konvertierung im Abschnitt 12.4.7.2.4 (Element to octet string conversion) der IEEE-Spezifikation. Weiter können die Funkmedium- (WM-) MAC-Adressen (einschließlich der STA-MLD-Adresse) für jede Verbindung der unterstützten mehreren Verbindungen und die MLD-MAC-Adresse in dem Multiple-Link-Address-Element codiert werden. Nach dem Konstruieren des Authentifikationsrahmens kann die Nicht-AP-STA-MLD den Authentifikationsrahmen an die AP-MLD senden.
• Bei dem vorgeschlagenen Schema, falls ein PMKSA-Caching nicht verwendet wird und die AP-MLD nicht mit dem Authentifikations-Server, der durch die Nicht-AP-STA-MLD unter Verwendung des Bereichs in dem KEY-Name-NAI-Feld des EAP-Initiate/Re-auth-Pakets identifiziert wird, verbunden ist oder ihn nicht erkennt, dann kann die AP-MLD einen Authentifikationsrahmen mit einem Status-Code-Feld, das auf 113 festgelegt ist, um eine „Authentifikation zurückgewiesen aufgrund von unbekanntem Authentifikations-Server“ anzuzeigen, an die Nicht-AP-STA-MLD senden. Andernfalls kann die AP-MLD ihren eigenen Einmalschlüssel generieren und einen Authentifikationsrahmen für die Nicht-AP-STA-MLD konstruieren. Die AP-MLD kann das FILS-Session-Element von dem Authentifikationsrahmen, der durch die Nicht-AP-STA-MLD gesendet wird, zu diesem Antwortauthentifikationsrahmen kopieren. Falls ein PMKSA-Caching nicht verwendet wird, kann dieser Rahmen die FILS-Wrapped-Daten aufweisen, welche das EAP-Finish/Re-auth-Paket kapseln, das von dem Authentifikations-Server empfangen wird. Zusätzlich kann, falls eine PFS verwendet wird, das FFE-Feld des Authentifikationsrahmens, der durch die AP-MLD gesendet wird, den kurzlebigen öffentlichen Schlüssel der AP-MLD aufweisen. In diesem Rahmen kann die AP-MLD die Authentifikationsalgorithmuszahl auf 4 oder 5 festlegen, abhängig davon, ob eine PFS verwendet wird, und die AP-MLD kann die Authentifikationssequenzzahl auf 2 festlegen. Falls ein PMKSA-Caching verwendet wird, kann der AP die ausgewählte PMKID in der PMKID-Liste anzeigen. Falls eine PFS für den Austausch verwendet wird, kann die AP-MLD die Scalar-Op der Gruppe (z.B. wie im Abschnitt 12.4.4.1 (General) der IEEE-Spezifikation definiert) mit dem kurzlebigen öffentlichen Schlüssel der STA-MLD und ihrem eigenen kurzlebigen privaten Schlüssel ausführen, um ein kurzlebiges Diffie-Herman-shared-secret, DHss, zu erzeugen. Bei dem vorgeschlagenen Schema kann die AP-MLD die WM-MAC-Adressen (einschließlich der AP-MLD-Adresse) für jede Verbindung der unterstützten mehreren Verbindungen und die MLD-MAC-Adresse der AP-MLD in dem Multiple-Link-Address-Element codieren, und die AP-MLD kann das Multiple-Link-Address-Element in dem Authentifikationsrahmen einbinden. Weiter kann die AP-MLD den Authentifikationsrahmen an die Nicht-AP-STA-MLD senden. Nach der Übertragung des FILS-Authentifikationsrahmens kann der AP zu einer Schlüsseleinrichtung nach Abschnitt 12.12.2.5 (Key establishment with FILS authentication) der IEEE-Spezifikation fortfahren.
• Bei dem vorgeschlagenen Schema kann der Pairwise-Master-Key (PMK) unter Verwendung der zwei Einmalschlüssel und des Geheimnisses (der Geheimnisse) von einer FILS-Schlüsseleinrichtung hergeleitet werden. Eine PMK-Kennung (PMKID), die verwendet wird, um die PMKSA zu identifizieren, kann unter Verwendung eines Hash-Algorithmus von einem verhandelten Authentifikations- und Schlüsselmanagement (AKM) auf Eingangsdaten, die für die FILS-Schlüsseleinrichtung spezifisch sind, generiert werden. Die Länge des PMKs kann entweder 256 Bits oder 384 Bits sein, abhängig von dem verhandelten AKM, und die Länge der PKMID kann 128 Bits sein. Falls eine FILS-Shared-Key-Authentifikation verwendet wird, um das Eingangs-Schlüsselmaterial zu generieren, können der PMK und die PMKID wie folgt hergeleitet werden: $$\text{PMK}=\text{HMAC}-\text{Hash}\left(\text{SNonce}\Vert \text{ANonce}\text{, rMSK}\left[\Vert \text{DHss}\right]\right)$$

  

  $$\text{PMKID}=\text{Truncate}-\text{128}\left(\text{Hash}\left(\text{EAP}-\text{Initiate/Reauth}\right)\right)$$

  
• Wenn eine FILS-Public-Key-Authentifikation verwendet wird, um das Eingangs-Schlüsselmaterial zu generieren, können der PMK und die PMKID wie folgt hergeleitet werden: $$\text{PMK}=\text{HMAC}-\text{Hash}\left(\text{SNonce }\Vert \text{ ANonce}\text{, }\text{DHss}]\right)\left(\text{MLD}-\text{level}\right)$$

  

  $$\text{PMKID}=\text{Truncate}-\text{128}\left(\text{Hash}\left(\text{gSTA }\Vert \text{ gAP}\right)\right)\left(\text{MLD}-\text{level}\right)$$

  
• Hier kennzeichnet SNonce den STA-MLD-Einmalschlüssel und ANonce kennzeichnet den AP-MLD-Einmalschlüssel. Zusätzlich kennzeichnet rMSK das Shared-Secret von dem EAP-RP-Austausch und DHss kennzeichnet das Shared-Secret, das von dem Diffie-Hellman-Austausch hergeleitet wird, wenn er ausgeführt wird, da, wenn eine Elliptic-Curve-Cryptographie (ECC) verwendet wird, nur die x-Koordinate von der Elliptic-Curve-Diffie-Hellman (ECDH) eingeschlossen ist. Die Klammern zeigen das Einschließen des Shared-Secrets an, wenn ein Diffie-Hellman-Austausch ausgeführt wird, oder andernfalls gibt es kein einzuschließendes Shared-Secret. EAP-Initiate/Reauth kennzeichnet das EAP-RP-Paket, das durch die STA unter Verwendung einer Schlüsseleinrichtung mit einer FILS-Shared-Key-Authentifikation gesendet wird. Weiter kennzeichnet gSTA den Diffie-Hellman-Wert der STA-MLD, und gAP kennzeichnet den Diffie-Hellman-Wert der AP-MLD. Hash kennzeichnet den Hash-Algorithmus, der spezifisch für das verhandelte AKM ist (siehe Tabelle 9-151 (AKM suite selectors) der IEEE-Spezifikation).
• Für eine Pairwise-Transient-Key-Security-Association- (PTKSA-) Schlüsselgenerierung können die Eingaben zu der Pseudo-Zufallsfunktion (PRF) der PMK der PMKSA, ein konstantes Kennzeichen und eine Aneinanderreihung der STA-MLD-MAC-Adresse, der AP-MLD-MAC-Adresse, des Einmalschlüssels der STA-MLD und des Einmalschlüssels der AP-MLD sein. Wenn das verhandelte AKM 00-OF-AC:14 oder 00-OF-AC:16 ist, kann die Länge des Key-Encryption-Keys (KEK) 256 Bits sein und die Länge des Integrity-Check-Value-Keys (ICK) soll 256 Bits sein. Wenn das verhandelte AKM 00-0F-AC:15 oder 00-0F-AC: 17 ist, soll die Länge des KEKs 512 Bits sein und die Länge des ICKs kann 384 Bits sein. Wenn das verhandelte AKM 00-0FAC:16 ist, kann eine FILS-FT 256 Bits sein. Wenn das verhandelte AKM 00-0F-AC:17 ist, kann eine FILS-FT 384 Bits sein, andernfalls wird eine FILS-FT nicht hergeleitet. Die Gesamtzahl an Bits, die von der Schlüsselherleitungsfunktion (KDF) extrahiert werden, kann deshalb 512+TK Bits, 896+TK Bits oder 1280+TK Bits sein, abhängig von dem verhandelten AKM, wobei TK Bits wie folgt bestimmt werden: $$\begin{array}{l}\text{FILS}-\text{Key}-\text{Data}=\text{PRF}-\text{X}(\text{PMK},\text{ ‶FILS PTK KDerivation″}\text{, SPR }\Vert \text{ AA }\Vert \text{ SNonce }\Vert \hfill \\ \text{ Anonce}\left[\Vert \text{ DHss}\right])\hfill \end{array}$$

  

  $$\text{ICK}=\text{L}\left(\text{FILS-Key-Data}\text{, 0}\text{, ICK\_bits}\right)$$

  

  $$\text{KEK}=\text{L}\left(\text{FILS-Key-Data}\text{, ICK\_bits}\text{, KEK\_bits}\right)$$

  

  $$\text{TK}=\text{L}\left(\text{FILS-Key-Data}\text{, ICK\_bits}+\text{KEK\_bits}\right)$$

  
• Wenn eine Fast-Transition- (FT-) Initial-Mobility-Domain-Association unter Verwendung einer FILS-Authentifikation ausgeführt wird, kann die FILS-FT wie folgt bestimmt werden: $$\text{FILS-FT}=\text{L}\left(\text{FILS-Key-Data}\text{, ICK\_bits}+\text{KEK\_bits}+\text{TK\_bits}\text{, FILS-FT\_bits}\right)$$

  
• Hier kennzeichnet ICK_bits die Länge eines ICKs in Bits, kennzeichnet KEK_bits die Länge eines KEKs in Bits, kennzeichnet FILS-FT_bits die Länge einer FILS-FT in Bits, wenn eine FT-Initial-Mobility-Domain-Association unter Verwendung einer FILS-Authentifikation ausgeführt wird. X kann 512+TK Bits, 768+TK Bits, 896+TK Bits oder 1280+TK Bits von Tabelle 12-7 (Cipher suite key lengths) der IEEE-Spezifikation sein, abhängig von dem verhandelten AKM. PMK kennzeichnet den PMK von der PMKSA, der entweder von einer anfänglichen FILS-Verbindung oder von einer gespeicherten PMKSA, wenn ein PMKSA-Caching verwendet wird, erzeugt wird. Wenn eine FT-Initial-Mobility-Domain-Association unter Verwendung einer FILS-Authentifikation ausgeführt wird, ist dieses gleich dem Master-PMK (MPMK) (z.B. wie im Abschnitt 12.7.1.6.3 (PMKR0) der IEEE-Spezifikation definiert). SPA kennzeichnet die STA-MLD-MAC-Adresse, AA kennzeichnet die AP-MLD-MAC-Adresse, ANonce kennzeichnet den Einmalschlüssel der STA-MLD, ANonce kennzeichnet den Einmalschlüssel der AP-MLD, DHss kennzeichnet das Shared-Secret, das von dem Diffie-Hellman-Austausch hergeleitet wird, wenn er ausgeführt wird und ein PMKSA-Caching verwendet wird. Weiter zeigen die Klammern das Einschließen des Shared-Secret an, wenn ein Diffie-Hellman-Austausch ausgeführt wird, während ein PMKSA-Caching verwendet wird, und es gibt andernfalls kein anzuzeigendes Shared-Secret. Nach einem Abschließen einer FILS-Key-Datengenerierung kann das Shared-Secret, DHss, unwiederbringlich gelöscht werden, falls ein Diffie-Hellman-Austausch ausgeführt wurde.
• Bei einem vorgeschlagenen Schema gemäß der vorliegenden Offenbarung kann hinsichtlich einer Verknüpfungs- (oder Wiederverknüpfungs-) Anforderung für eine FILS-Schlüsselbestätigung eine Schlüsselbestätigung für eine FILS-Authentifikation ein (Wieder-) Verknüpfungsanforderungsrahmen gefolgt von einem (Wieder-) Verknüpfungsantwortrahmen sein. Komponenten der (Wieder-) Verknüpfungsanforderungs- und (Wieder-) Verknüpfungsantwortrahmen können unter Verwendung eines KEKs geschützt werden. Die STA-MLD kann einen (Wieder-) Verknüpfungsanforderungsrahmen für eine FILS-Authentifikation konstruieren (z.B. gemäß Abschnitt 9.3.3.5 (Association Request frame format) und Abschnitt 9.3.3.7 (Reassociation Request frame format) der IEEE-Spezifikation). Hash-Algorithmen können verwendet werden, um das FILS-Key-Confirmation-Element zu generieren, und der spezifische Hash-Algorithmus kann von dem verhandelten AKM abhängen (z.B. gemäß Abschnitt 9.4.2.24.3 (AKM suites) der IEEE-Spezifikation).
• Bei dem vorgeschlagenen Schema kann für eine FILS-Shared-Key-Authentifikation und eine FILS-Public-Key-Authentifikation, wenn ein PMKSA-Caching verwendet wird, das KeyAuth-Feld des FILS-Key-Confirmation-Elements durch ein Verwenden des Hash-Based-Message-Authentication-Code- (HMAC-) Modus des verhandelten Hash-Algorithmus mit einem Schlüssel eines ICK auf einer Aneinanderreihung des Einmalschlüssels der STA-MLD, des Eimalschlüssels der AP-MLD, der STA-MLD-MAC-Adresse, der AP-MLD-MAC-Adresse und bedingt dem öffentlichen Diffie-Hellman-Wert der STA-MLD und dem öffentlichen Diffie-Hellman-Wert der AP-MLD in dieser Reihenfolge, wie folgt konstruiert werden: $$\begin{array}{l}\text{Key}-\text{Auth}=\text{HMAC}-\text{Hash}(\text{ICK}\text{, SNonce }\Vert \text{ ANonce }\Vert \text{ STA}-\text{MLD}-\text{MAC }\Vert \text{ AP}-\text{MLD}-\text{MAC}\hfill \\ \left[\Vert \text{ gSTA }\Vert \text{ gAP}\right])\hfill \end{array}$$

  
• Hier kennzeichnet Hash den Hash-Algorithmus, der für das verhandelte AKM spezifisch ist (siehe Tabelle 9-151 (AKM suite selectors) der IEEE-Spezifikation), SNonce kennzeichnet den Einmalschlüssel der STA-MLD, ANonce kennzeichnet den Einmalschlüssel der AP-MLD, STA-MLD-MAC kennzeichnet die MLD-MAC-Adresse der STA-MLD, AP-MLD-MAC kennzeichnet die MLD-MAC-Adresse der AP-MLD, gSTA kennzeichnet den öffentlichen Diffie-Hellman-Wert der STA-MLD, gAP kennzeichnet den öffentlichen Diffie-Hellman-Wert der AP-MLD und die Klammern zeigen das Einschließen der öffentlichen Diffie-Hellman-Werte an, wenn eine PFS mit einer FILS-Shared-Key-Authentifikation oder ein PMKSA-Caching mit einer FILS-Public-Key-Authentifikation ausgeführt wird. Andernfalls gibt es keine öffentlichen Diffie-Hellman-Werte einzuschließen.
• Für eine FILS-Public-Key-Authentifikation, wenn ein PMKSA-Caching nicht verwendet wird, kann das KeyAuth-Feld des FILS-Key-Confirmation-Elements eine digitale Signatur sein, die den privaten Schlüssel der STA-MLD des verhandelten Hash-Algorithmus auf einer Aneinanderreihung des öffentlichen Diffie-Hellman-Werts der STA-MLD, des öffentlichen Diffie-Hellman-Werts der AP-MLD, des Einmalschlüssels der STA-MLD, des Einmalschlüssels der AP-MLD, der STA-MLD-MAC-Adresse und der AP-MLD-MAC-Adresse in der Reihenfolge wie folgt verwendet: $$\begin{array}{c}\text{Key-Auth}=\text{Sig-STA }(\text{gSTA}\Vert \text{gAP}\Vert \text{ SNonce }\Vert \text{ ANonce }\Vert \text{ STA-MLD-MAC }\Vert \text{ AP-}\\ \text{MLD-MAC})\end{array}$$

  
• Hier zeigt Sig-STA() eine digitale Signatur an, die den privaten Schlüssel der STA-MLD analog zu dem gesicherten (trusted) öffentlichen Schlüssel der STA-MLD verwendet. Die Form der Signatur kann von der Art des öffentlichen Schlüssels abhängen, der von der STA-MLD verwendet wird (IETF RFC 3447 für RSA, FIPS 186-4 für DSA und ISO/IEC 14888-3 für ECDSA). Die zu signierenden Daten können zuerst verschlüsselt (hashed) werden, und der Hash-Algorithmus, der mit dem geeigneten Digitalsignaturalgorithmus verwendet wird, kann spezifisch für das verhandelte AKM sein.
• Bei dem vorgeschlagenen Schema kann der (Wieder-) Verknüpfungsanforderungsrahmen unter Verwendung des Authenticated-Encryption-with-Associated-Data- (AEAD-) Algorithmus (z.B. wie im Abschnitt 12.12.2.7 (AEAD cipher mode for FILS) der IEEE-Spezifikation definiert) mit dem KEK als dem Schlüssel verschlüsselt werden. Die Additional-Authentication-Data (AAD), die mit dem AEAD-Algorithmus für den Verknüpfungsanforderungsrahmen verwendet werden, können die nachfolgenden Daten aufweisen, die als getrennte Komponenten in der nachfolgenden Reihenfolge weitergeleitet werden: (i) die MAC-Adresse der STA, (ii) die Basisdienstsatzkennung (BSSID) des APs, (iii) den Einmalschlüssel der STA, (iv) den Einmalschlüssel des APs und (v) die Inhalte des (Wieder-) Verknüpfungsanforderungsrahmens von dem Capability-Information-Feld (einschließlich) zu dem FILS-Session-Element (einschließlich). Zusätzlich können die Additional-Authentication-Data (AAD), die mit dem AEAD-Algorithmus für den Verknüpfungsanforderungsrahmen verwendet werden, (vi) die STA-MLD-MAC-Adresse und (vii) die AP-MLD-MAC-Adresse aufweisen. Der Klartext, der an den AEAD-Algorithmus gegeben wird, können die Daten sein, welche dem FILS-Session-Element in einem unverschlüsselten Rahmenhauptteil folgen würden. Die Ausgabe des AEAD-Algorithmus können die Daten werden, welche dem FILS-Session-Element in dem verschlüsselten und authentifizierten (Wieder-) Verknüpfungsanforderungsrahmen folgen. Die Ausgabe des Algorithmus kann so sein, wie in IETF RFC 5116 spezifiziert. Der resultierende (Wieder-) Verknüpfungsanforderungsrahmen kann an die AP-MLD gesendet werden. Die AP-MLD kann die FILS-Session des empfangenen (Wieder-) Verknüpfungsanforderungsrahmens mit der FILS-Session vergleichen, welche verwendet wurde, um die FILS-Session in den Authentifikationsrahmen zu identifizieren. Wenn sie sich unterscheiden, schlägt der Authentifikationsaustausch fehl.
• Bei dem vorgeschlagenen Schema kann die AP-MLD den empfangenen (Wieder-) Verknüpfungsanforderungsrahmen mit dem AEAD-Algorithmus (z.B. wie im Abschnitt 12.12.2.7 (AEAD cipher mode for FILS) der IEEE-Spezifikation definiert) mit dem KEK als dem Schlüssel entschlüsseln und verifizieren. Die AAD können rekonstruiert werden, wie vorstehend definiert, und können zusammen mit dem Chiffre-Text des empfangenen Rahmens an die AEAD-Entschlüsselungsoperation geleitet werden. Falls die Ausgabe von der AEAD-Entschlüsselungsoperation einen Fehler zurückgibt, schlägt der Authentifikationsaustausch fehl. Falls die Ausgabe keinen Fehler zurückgibt, kann der ausgegebene Klartext den Chiffre-Text als einen Teil des Rahmenhauptteils ersetzen, welcher dem FILS-Session-Element folgt, und ein Verarbeiten des empfangenen Rahmens kann durch ein Prüfen des Werts des FILS-Key-Confirmation-Elements fortfahren. Die AP-MLD kann verifizieren, dass das in dem (Wieder-) Verknüpfungsanforderungsrahmen empfangene RSNE eine identische AKM-Folge (AKM suite) und Chiffre-Folgen (cipher suites) und RSN-Fähigkeiten, wie sie in dem RSNE in dem Authentifikationsrahmen von der STA-MLD enthalten waren, aufweist. Wenn sich diese Felder unterscheiden, schlägt der Authentifikationsaustausch fehl. Für eine FILS-Shared-Key-Authentifikation kann die AP-MLD einen Verifizierer, Key-Auth', auf eine identische Weise konstruieren, wie die STA-MLD ihren Key-Auth vorstehend konstruiert hat. Die AP-MLD kann Key-Auth' mit dem KeyAuth-Feld in dem FILS-Key-Confirmation-Element des empfangenen Rahmens vergleichen. Wenn sie sich unterscheiden, schlägt die Authentifikation fehl.
• Für eine FILS-Public-Key-Authentifikation kann die AP-MLD den (zertifizierten) öffentlichen Schlüssel der STA-MLD von dem FILS-Public-Key-Element verwenden, um zu verifizieren, dass die Signatur, die in dem KeyAuth-Feld enthalten ist, zu der durch die STA-MLD vorgegebenen Signatur korrespondiert, über die Aneinanderreihung des Folgenden: der öffentliche Diffie-Hellman-Wert der STA (gSTA), der öffentliche Diffie-Hellman-Wert des APs (gAP), der Einmalschlüssel der STA (SNonce), der Einmalschlüssel des APs (ANonce), die MAC-Adresse der STA (STA-MAC) und die BSSID des APs (AP-BSSID) in dieser Reihenfolge gemäß dem verwendeten Signatur-Schema. Weiter kann die AP-MLD alle Zertifikate in der Zertifikatreihe prüfen, sowohl cryptographisch als auch aus der Sicht einer Sicherheitsbestimmung, gemäß den Prozeduren zum Prüfen von Zertifikaten und Zertifikatreihen in IETF RFC 5280. Wenn eine dieser Verifikationen fehlschlägt, schlägt die Authentifikation fehl.
• Bei dem vorgeschlagenen Schema können, falls die Authentifikation als Fehlschlag angesehen wird, der ICK, der KEK, der TK und die PTKSA unwiederbringlich gelöscht werden, und die AP-MLD kann einen Authentifikationsrahmen mit einem auf 112 festgelegten Statuscode zurückgeben, um „Authentifikation abgelehnt aufgrund eines FILS-Authentifikationsfehlers“ anzuzeigen. Falls ein PMKSA-Caching für diesen fehlgeschlagenen Authentifikationsversuch nicht eingesetzt wurde, kann die PMKSA auch gelöscht werden. Falls ein PMKSA-Caching eingesetzt wurde, kann der Grund für den Fehlschlag ein Identitätsdiebstahl sein. Deshalb kann, wenn ein PMKSA-Caching fehlerhaft ist, die AP-MLD entscheiden, die gespeicherte PMKSA zu behalten.
• Bei einem vorgeschlagenen Schema gemäß der vorliegenden Offenbarung kann hinsichtlich einer (Wieder-) Verknüpfungsantwort für eine FILS-Schlüsselbestätigung die AP-MLD einen (Wieder-) Verknüpfungsantwortrahmen für eine FILS-Authentifikation konstruieren (z.B. gemäß Abschnitt 9.3.3.6 (Association Response frame format) und Abschnitt 9.3.3.8 (Reassociation Response frame format) der IEEE-Spezifikation). Wie mit dem (Wieder-) Verknüpfungsanforderungsrahmen können Hash-Algorithmen verwendet werden, um das FILS-Key-Confirmation-Element zu generieren, und der spezifische Hash-Algorithmus kann von dem verhandelten AKM abhängen (siehe 9.4.2.24.3 (AKM suites)). Zusätzlich kann die AP-MLD ein Key-Delivery-Element konstruieren, das den aktuellen Group-Temporal-Key (GTK) und den Key-Receive-Sequence-Counter (RSC) für jede Verbindung der mehreren Verbindungen, den aktuellen Integrity-Group-Temporal-Key (IGTK) und die IGTK-Paketnummer (IPN) für jede Verbindung der mehreren Verbindungen, falls ein Managementrahmenschutz aktiviert ist, und den aktuellen Beacon-Integrity-Group-Temporal-Key (BIGTK) und die BIGTK-Paketnummer (BIPN) für jede Verbindung der mehreren Verbindungen, falls ein Signalschutz (beacon protection) aktiviert ist, anzeigt. Die AP-MLD kann das Key-Delivery-Element in den (Wieder-) Verknüpfungsantwortrahmen platzieren.
• 5 stellt einen Beispielentwurf 500 eines Key-Delivery-Elements bei einem vorgeschlagenen Schema gemäß der vorliegenden Offenbarung dar. Bezüglich 5 kann das Key-Delivery-Element eine Anzahl von Feldern aufweisen, die zum Beispiel ein Element-ID-Feld, ein Längenfeld, ein Element-ID-Erweiterungsfeld, ein Key-RSC-Feld und ein Key-Data-Encapsulation- (KDE-) Listenfeld umfassen. Das Key-RSC-Feld kann den Empfangssequenzzähler für den GTK umfassen, der zu der gleichen Verbindung installiert ist, auf welcher das Key-Delivery-Element übertragen wird. Das KDE-Listenfeld kann ein oder mehrere KDEs aufweisen, die unter Verwendung eines vordefinierten Formats gekapselt sind. Zum Beispiel kann das KDE-Listenfeld eine GTK-KDE, eine IGTK-KDE und eine BIGTK-KDE für die gleiche Verbindung aufweisen, auf welcher das Key-Delivery-Element übertragen wird. Weiter kann das KDE-Listenfeld eine Mehrfachverbindungs-GTK-KDE, eine Mehrfachverbindungs-IGTK-KDE und eine Mehrfachverbindungs-BIGTK-KDE für (eine) unterschiedliche Verbindung(en) aufweisen, auf welcher (welchen) das Key-Delivery-Element übertragen wird.
• 6 stellt einen Beispielentwurf 600 eines Mehrfachverbindungs-GTK-KDE-Elements bei einem vorgeschlagenen Schema gemäß der vorliegenden Offenbarung dar. Bezüglich 6 kann das Mehrfachverbindungs-GTK-KDE-Element eine Anzahl von Feldern aufweisen, die zum Beispiel ein Key-ID-Feld, ein Transmit- (Tx-) Feld, ein Reserviert-Feld, ein Link-ID-Feld, ein Key-RSC-Feld und ein GTK-Feld umfassen. Das Key-ID-Feld kann den Wert der GTK-Schlüsselkennung anzeigen. Das Tx-Feld kann die Verbindung anzeigen, auf welcher der GTK übertragen wird. Falls der Wert des Tx-Felds 1 ist, kann die IEEE-802.1X-Komponente den temporären Schlüssel, der von der KDE hergeleitet wird, in seine IEEE-802.11-MAC(#2507) sowohl für eine Sendung als auch für einen Empfang konfigurieren. Falls der Wert des Tx-Felds 0 ist, kann die IEEE-802-1X-Komponente den temporären Schlüssel, der von der KDE hergeleitet wird, in seine IEEE-802.11-MAC(#2507) nur für einen Empfang konfigurieren. Das Link-ID-Feld kann die Verbindung (z.B. die Betriebsklasse und die Primärkanalnummer) für den GTK, der installiert wird, anzeigen. Das Key-RSC-Feld kann den Empfangssequenzzähler für den GTK aufweisen, der auf der durch das Link-ID-Feld angezeigten Verbindung installiert wird. Eine Übergabe des RSC-Feldwerts kann einer STA ermöglichen, wiederholte MAC-Protokolldateneinheiten (MPDUs) auf der durch das Link-ID-Feld angezeigten Verbindung zu identifizieren. Falls der RSC-Feldwert kleiner als 8 Oktette in einer Länge ist, können die übrigen Oktette auf 0 festgelegt werden. Das niederwertigste Oktett des Sendesequenzzählers (TSC) oder die Paketnummer (PN) können sich in dem ersten Oktett des RSC-Felds befinden.
• 7 stellt einen Beispielentwurf 700 eines Mehrfachverbindungs-IGTK-KDE-Elements bei einem vorgeschlagenen Schema gemäß der vorliegenden Offenbarung dar. Bezüglich 7 kann das Mehrfachverbindungs-IGTK-KDE-Element eine Anzahl von Feldern aufweisen, die zum Beispiel ein Key-ID-Feld, ein IPN-Feld, ein Link-ID-Feld und ein IGTK-Feld umfassen. Das Key-ID-Feld kann den Wert der IGTK-Schlüsselkennung anzeigen. Das Link-ID-Feld kann die Verbindung (z.B. die Betriebsklasse und die Primärkanalnummer) für den IGTK, der installiert wird, anzeigen. Das IPN-Feld kann zu der letzten Paketnummer korrespondieren, die von einem Broadcast-/Multicast-Sender auf der durch das Link-ID-Feld angezeigten Verbindung verwendet wird, und es kann von einem Empfänger als ein Anfangswert für einen Broadcast-Integrity-Protocol- (BIP-) Wiederholungszähler für den IGTK verwendet werden.
• 8 stellt einen Beispielentwurf 800 eines Mehrfachverbindungs-BIGTK-KDE-Elements bei einem vorgeschlagenen Schema gemäß der vorliegenden Offenbarung dar. Bezüglich 8 kann das Mehrfachverbindungs-BIGTK-KDE-Element eine Anzahl von Feldern aufweisen, die zum Beispiel ein Key-ID-Feld, ein BIPN-Feld, ein Link-ID-Feld und ein BIGTK-Feld umfassen. Das Key-ID-Feld kann den Wert der BIGTK-Schlüsselkennung anzeigen. Das Link-ID-Feld kann die Verbindung (z.B. die Betriebsklasse und die Primärkanalnummer) für den BIGTK, der installiert wird, anzeigen. Das BIPN-Feld kann zu dem BIPN-Wert korrespondieren, welcher in dem Management-Message-Integrity-Check-(MIC-) Element (MME) des letzten geschützten Signalrahmens (Beacon frame) auf der durch das Link-ID-Feld angezeigten Verbindung übertragen wurde, und es kann von dem Empfänger als der Anfangswert für den BIP-Wiederholungszähler für den BIGTK verwendet werden.
• Bei einem vorgeschlagenen Schema gemäß der vorliegenden Offenbarung kann für eine FILS-Shared-Key-Authentifikation und eine FILS-Public-Key-Authentifikation, wenn ein PMKSA-Caching verwendet wird, das KeyAuth-Feld des FILS-Key-Confirmation-Elements durch ein Verwenden des HMAC-Modus des verhandelten Hash-Algorithmus mit einem Schlüssel von ICK auf einer Aneinanderreihung des Einmalschlüssels der AP-MLD, des Einmalschlüssels der STA-MLD, der AP-MLD-MAC-Adresse, der STA-MLD-MAC-Adresse und bedingt des öffentlichen Diffie-Hellman-Werts der AP-MLD und des öffentlichen Diffie-Hellman-Werts der STA-MLD in dieser Reihenfolgen und wie folgt konstruiert werden: $$\begin{array}{c}\text{Key}-\text{Auth}=\text{HMAC}-\text{Hash}(\text{ICK}\text{, ANonce }\Vert \text{ SNonce }\Vert \text{ AP}-\text{MLD}-\text{MAC }\Vert \text{ STA}-\text{MLD}-\text{MAC}\\ \left[\Vert \text{ gAP }\Vert \text{ gSTA}\right])\end{array}$$

  
• Hier kennzeichnet Hash den für das verhandelte AKM spezifischen Hash-Algorithmus, ANonce kennzeichnet den Einmalschlüssel der AP-MLD, SNonce kennzeichnet den Einmalschlüssel der STA-MLD, AP-MLD-MAC kennzeichnet die MLD-MAC-Adresse der AP-MLD, STA-MLD-MAC kennzeichnet die MLD-MAC-Adresse der STA-MLD, gAP kennzeichnet den öffentlichen Diffie-Hellman-Wert der AP-MLD, gSTA kennzeichnet den öffentlichen Diffie-Hellman-Wert der STA-MLD und die Klammern zeigen das Einschließen der öffentlichen Diffie-Hellman-Werte an, wenn eine PFS mit einer FILS-Shared-Key-Authentifikation ausgeführt wird. Andernfalls braucht es keine einzuschließenden öffentlichen Diffie-Hellman-Werte zu geben.
• Bei dem vorgeschlagenen Schema kann für eine FILS-Public-Key-Authentifikation, wenn ein PMKSA-Caching nicht verwendet wird, das KeyAuth-Feld des FILS-Key-Confirmation-Elements eine digitale Signatur sein, die den privaten Schlüssel der AP-MLD der Ausgabe von dem verhandelten Hash-Algorithmus auf eine Aneinanderreihung des öffentlichen Diffie-Hellman-Werts der AP-MLD, des öffentlichen Diffie-Hellman-Werts der STA-MLD, des Einmalschlüssels der AP-MLD, des Einmalschlüssels der STA-MLD, der AP-MLD-MAC-Adresse und der STA-MLD-MAC-Adresse in dieser Reihenfolge verwendet. Die spezifische Konstruktion der digitalen Signatur kann von dem Cryptographiesystem des öffentlichen/privaten Schlüsselpaars wie folgt abhängen: $$\begin{array}{c}\text{Key}-\text{Auth}=\text{Sig}-\text{AP }(\text{gAP}\Vert \text{gSTA}\Vert \text{ ANonce }\Vert \text{ SNonce }\Vert \text{ AP}-\text{MLD}-\text{MAC }\Vert \text{ STA}-\text{MLD}-\\ \text{MAC})\end{array}$$

  
• Hier kann Sig-AP() eine digitale Signatur anzeigen, die den privaten Schlüssel der AP-MLD analog zu dem gesicherten öffentlichen Schlüssel der AP-MLD verwendet. Die Form der Signatur kann von der Art des öffentlichen Schlüssels abhängen, der von der AP-MLD verwendet wird (IETF RFC 3447 für RSA, FIPS 186-4 für DAS und ISO/IEC 14883-3 für ECDSA). Die zu signierenden Daten können zuerst verschlüsselt (hashed) werden und der Hash-Algorithmus, der mit dem geeigneten digitalen Signaturalgorithmus verwendet wird, kann spezifisch für das verhandelte AKM sein.
• Bei einem vorgeschlagenen Schema gemäß der vorliegenden Offenbarung kann der (Wieder-) Verknüpfungsantwortrahmen unter Verwendung des AEAD-Algorithmus (z.B. wie im Abschnitt 12.12.2.7 (AEAD cipher mode for FILS) der IEEE-Spezifikation) mit dem KEK als dem Schlüssel verschlüsselt werden. Die AAD, die mit dem AEAD-Algorithmus für den (Wieder-) Verknüpfungsantwortrahmen verwendet werden, können die nachfolgenden Daten aufweisen, die als getrennte Komponenten in der nachfolgenden Reihenfolge weitergeleitet werden: die BSSID des APs, die MAC-Adresse der STA, der Einmalschlüssel des APs, der Einmalschlüssel der STA und die Inhalte des (Wieder-) Verknüpfungsantwortrahmens von dem Capability-Information-Feld (einschließlich) zu dem FILS-Session-Element (einschließlich). Zusätzlich können die AAD, die mit dem AEAD-Algorithmus für den Verknüpfungsantwortrahmen verwendet werden, die STA-MLD-MAC-Adresse und die AP-MLD-MAC-Adresse aufweisen. Der Klartext, der an den AEAD-Algorithmus geleitet wird, können die Daten sein, welche dem FILS-Session-Element in einem unverschlüsselten Rahmenhauptteil folgen würden. Die Ausgabe des AEAD-Algorithmus können die Daten werden, welche dem FILS-Session-Element in dem verschlüsselten und authentifizierten (Wieder-) Verknüpfungsantwortrahmen folgen. Die Ausgabe des Algorithmus kann sein, wie in IETF RFC 5116 spezifiziert. Der resultierende (Wieder-) Verknüpfungsantwortrahmen kann an die STA-MLD übertragen werden.
• Bei dem vorgeschlagenen Schema kann die STA-MLD den empfangenen (Wieder-) Verknüpfungsantwortrahmen mit dem AEAD-Algorithmus (z.B. wie im Abschnitt 12.12.2.5 (Key establishment with FILS authentication) der IEEE-Spezifikation definiert) mit dem KEK als dem Schlüssel entschlüsseln und verifizieren. Die AAD können, wie in dem vorstehenden Unterabschnitt definiert, rekonstruiert werden und können mit dem Chiffre-Text des empfangenen Rahmens an die AEAD-Entschlüsselungsoperation gegeben werden. Die STA-MLD kann die FILS-Session des empfangenen Rahmens mit der FILS-Session, die die STA-MLD ausgewählt hat, vergleichen, um die FILS-Session zu identifizieren. Falls sie sich unterscheiden, schlägt die Authentifikation fehl. Falls die Ausgabe der AEAD-Entschlüsselungsoperation einen Fehler zurückgibt, schlägt der Authentifikationsaustausch fehl. Falls die Ausgabe keinen Fehler zurückgibt, kann der ausgegebene Klartext den Chiffre-Text als einen Teil des Rahmenhauptteils ersetzen, welcher dem FILS-Session-Element folgt, und das Verarbeiten des empfangenen Rahmens kann mit einem Prüfen des Werts des FILS-Key-Confirmation-Elements fortfahren. Die STA-MLD kann verifizieren, dass das RSNE, das in dem (Wieder-) Verknüpfungsantwortrahmen empfangen wird, identische AKM-Folgen und Chiffre-Folgen und RSN-Fähigkeiten aufweist, wie in dem RSNE in den Signal-, Sondierungsantwort- und Authentifikationsrahmen von der AP-MLD enthalten sind. Falls sich diese unterscheiden, schlägt die Authentifikation fehl.
• Bei dem vorgeschlagenen Schema kann für eine FILS-Shared-Key-Authentifikation die STA-MLD einen Verifizierer, Key-Auth', auf eine identische Weise generieren, wie der AP seinen Key-Auth vorstehend konstruiert hat. Die STA-MLD kann Key-Auth' mit dem KeyAuth-Feld in dem FILS-Key-Confirmation-Element des empfangenen Rahmens vergleichen. Falls sie sich unterscheiden, schlägt die Authentifikation fehl. Für eine FILS-Public-Key-Authentifikation kann die STA-MLD den (zertifizierten) öffentlichen Schlüssel der AP-MLD von dem FILS-Public-Key-Element verwenden, um zu verifizieren, dass die in dem KeyAuth-Feld enthaltene Signatur zu der durch den AP vorgegebenen Signatur korrespondiert, über die Aneinanderreihung des nachfolgenden in dieser Reihenfolge und gemäß dem verwendeten Signaturschema: der öffentliche Diffie-Hellman-Wert des APs (gAP), der öffentliche Diffie-Hellman-Wert der STA (gSTA), der Einmalschlüssel des APs (ANonce), der Einmalschlüssel der STA (SNonce), die BSSID des APs (AP-BSSID) und die MAC-Adresse der STA (STA-MAC). Weiterhin kann die AP-MLD alle Zertifikate in der Zertifikatreihe sowohl cryptographisch als auch hinsichtlich einer Sicherheitsbestimmung gemäß den Prozeduren für ein Prüfen von Zertifikaten und Zertifikatreihen in IEFT RFC 5280 prüfen. Falls eine dieser Verifikationen fehlschlägt, schlägt die Authentifikation fehl.
• Bei dem vorgeschlagenen Schema können, falls die Authentifikation als ein Fehlschlag angesehen wird, der ICK, der KEK, der PMK und der TK unwiederbringlich gelöscht werden, und die STA-MLD soll den Austausch abbrechen. Andernfalls ist die Authentifikation erfolgreich und die STA-MLD und die AP-MLD können das nichtbeständige geheime Schlüsselmaterial unwiederbringlich löschen, welches durch das Ausführen der Schlüsseleinrichtung mit dem FILS-Shared-Key-Authentifikationsschema (z.B. gemäß Abschnitt 12.12.2.3 (Key establishment with FILS Shared Key authentication) der IEEE-Spezifikation) oder der Schlüsseleinrichtung mit dem FILS-Public-Key-Authentifikationsschema (z.B. gemäß Abschnitt 12.12.2.4 (Key establishment with FILS Public Key authentication) der IEEE-Spezifikation) erzeugt wurde. Der KEK und PMK können für ein anschließendes Schlüsselmanagement verwendet werden (z.B. wie im Abschnitt 12.6 (RSNA security association management) der IEEE-Spezifikation spezifiziert). Falls die Lebensdauer des rMSK bekannt ist, können die STA-MLD und die AP-MLD die Lebensdauer der PMKSA auf die Lebensdauer des rMSK festlegen. Andernfalls können die STA-MLD und die AP-MLD die Lebensdauer der PMKSA auf den Wert dot11RSNAConfigPMKLifetime festlegen. Nach einem erfolgreichen Abschluss der FILS-Authentifikationsprozedur kann die STA-MLD das Key-Delivery-Element in dem (Wieder-) Verknüpfungsantwortrahmen verarbeiten. Die STA-MLD kann den GTK und den Schlüssel-RSC und den IGTK und die IPN für jede Verbindung der mehreren Verbindungen, falls ein Managementrahmenschutz aktiviert ist, und den BIGTK und die BIPN für jede Verbindung der mehreren Verbindungen, falls sie in dem Key-Delivery-Element vorhanden sind und dot11BeaconProtectionEnabled wahr ist, installieren.
• 9 stellt einen Beispielentwurf 900 eines Robust-Security-Network- (RSN-) Capabilities-Felds bei einem vorgeschlagenen Schema gemäß der vorliegenden Offenbarung dar. Bezüglich 9 kann das RSN-Capabilities-Feld eine Anzahl von Unterfeldern aufweisen, die ein Extended-Key-ID-for-Individually-Addressed-Frames-Unterfeld umfassen. Das Extended-Key-ID-for-Individually-Addressed-Frames-Unterfeld (angeordnet bei Bit 13 oder B13 des RSN-Capabilities-Felds) kann auf 1 festgelegt sein, um anzuzeigen, dass die STA Key-ID-Werte in dem Bereich 0 ~ 1 für eine PTKSA unterstützt, wenn die Chiffre-Folge ein Chipher-Block-Chaining-Message-Authentication-Code-Protocol (CCMP) oder ein Galois/Counter-Mode-Protocol (GCMP) ist. Bit 13 kann auf 0 festgelegt sein, um anzuzeigen, dass die STA nur eine Key-ID 0 für eine PTKSA unterstützt.
• Bei einem vorgeschlagenen Schema gemäß der vorliegenden Offenbarung kann hinsichtlich einer Robust-Security-Network-Association- (RSNA-) Schlüsselerneuerung, wenn beide Enden einer Verbindung erweiterte Key-IDs für individuell adressierte Rahmen unterstützen, eine neue PTKSA ohne einen Datenverlust installiert werden, vorausgesetzt, dass die neue PTKSA eine zu der alten PTKSA verschiedene Key-ID verwendet. Es ist bemerkenswert, dass ein Datenverlust auftreten kann, wenn die gleiche Key-ID verwendet wird, weil es nicht möglich ist, (aufgrund von Software-Verarbeitungsverzögerungen) präzise zu koordinieren, wann der neue Schlüssel für eine Übertragung an einem Ende verwendet wird, und wann er angewendet wird, um an dem anderen Ende zu empfangen. Falls eine unterschiedliche Key-ID für die neue PTKSA verwendet wird, vorausgesetzt, dass der neue Schlüssel vor seiner ersten Verwendung an der Sendeseite auf der Empfangsseite installiert ist, braucht keine Notwendigkeit für eine präzise Koordination zu bestehen. Während des Übergangs können empfangene Pakete unter Verwendung der Key-ID eindeutig als zu entweder der alten oder der neuen PTKSA gehörend identifiziert werden.
• Bei dem vorgeschlagenen Schema kann, falls das Extended-Key-ID-for-Individually-Addressed-Frames-Unterfeld des RSN-Capabilities-Felds sowohl für den Authentifikator als auch für den Bittsteller 1 ist, der Authentifikator eine neue Key-ID für die PTKSA in dem Bereich von 0 ~ 1 zuweisen, welche zu der Key-ID verschieden ist, die in dem vorhergehenden Handshake zugewiesen war, und zusätzlich kann der Authentifikator die MLMESETKEYS.request-Primitive verwenden, um den neuen Schlüssel zu installieren, um individuell adressierte MPDUs, die durch den PTK mit der zugewiesenen Key-ID geschützt sind, zu empfangen. Andernfalls kann eine Key-ID 0 verwendet werden, und eine Installation des Schlüssels kann verschoben werden, bis nachdem eine Nachricht 4 empfangen worden ist. Der Authentifikator kann eine Nachricht 3 an den Bittsteller senden. Es ist bemerkenswert, dass, falls ein existierender PTK noch gültig ist, die Authentifikator-IEEE-802.11-MAC fortfahren kann, geschützte, individuell adressierte MPDUs (wenn vorhanden) unter Verwendung des existierenden Schlüssels zu senden. Mit der Installation des neuen Schlüssels für den Empfang kann der Authentifikator in der Lage sein, geschützte, individuell adressierte MPDUs unter Verwendung entweder des alten Schlüssels (wenn vorhanden) oder des neuen Schlüssels zu empfangen.
• 10 stellt ein Beispielszenarium 1000 einer RSNA-Schlüsselerneuerung bei dem vorgeschlagenen Schema dar. Bezüglich 10 kann eine RSNA-Schlüsselerneuerungsprozedur zwei Schlüssel verwenden. In dem Szenarium 1000 können Schlüssel (für eine Empfangsverarbeitung) für zwei Handshake-Perioden bestehen bleiben. Eine PTKSA-Lebensdauer kann zwei Handshake-Perioden betragen. Eine Installation eines neuen Schlüssels kann einen alten Schlüssel mit der gleichen Key-ID ersetzen. Entsprechend kann ein Aufweisen/Verwenden von zwei aktiven Schlüsseln einen reibungslosen, zeitunkritischen Übergang von einer PTKSA zu der nächsten ermöglichen.
• Bei einem vorgeschlagenen Schema gemäß der vorliegenden Offenbarung können hinsichtlich einer CCMP-Kapselung die PN-Werte sequentiell jede MPDU nummerieren. Jeder Sender kann eine einzelne PN (z.B. einen 48-Bit-Zähler) für jede PTKSA und Group-Temporal-Key-Security-Association (GTKSA) unterhalten. Die PN kann als ein strikt ganzzahlig steigender 48-Bit-Wert implementiert werden, der auf 1 initialisiert wird, wenn der korrespondierende zeitliche Schlüssel initialisiert oder aktualisiert wird.
• Bei einem vorgeschlagenen Schema gemäß der vorliegenden Offenbarung können hinsichtlich einer GCMP-Kapselung die PN-Werte sequentiell jede MPDU nummerieren. Jeder Sender kann eine einzelne PN (z.B. einen 48-Bit-Zähler) für jede PTKSA und GTKSA unterhalten. Die PN kann als ein strikt ganzzahlig steigender 48-Bit-Wert implementiert sein, der auf 1 initialisiert wird, wenn der korrespondierende zeitliche Schlüssel initialisiert oder aktualisiert wird.
• Bei einem vorgeschlagenen Schema gemäß der vorliegenden Offenbarung kann hinsichtlich einer RSNA-Schlüsselerneuerung in einem Mehrfachverbindungsbetrieb, wenn eine STA (z.B. die STA 110) einen Rahmen für eine erneute Übertragung auf der gleichen Verbindung oder einer anderen Verbindung erneut verschlüsselt, die STA das Key-ID-Feld in der CCMP- oder GCMP-Kopfzeile auf einen Wert festlegen, welcher der gleiche ist wie der Wert des Key-ID-Felds einer ersten übertragenen MPDU. Andernfalls kann, weil die PN-Abstände der verschiedenen Key-IDs verschieden sind, die Wiederholungserfassung auf Schwierigkeiten stoßen.
• Erläuternde Implementierungen
• 11 stellt ein Beispielsystem 1100, das mindestens eine Beispielvorrichtung 1110 und eine Beispielvorrichtung 1120 aufweist, gemäß einer Implementierung der vorliegenden Offenbarung dar. Jede der Vorrichtung 1110 und der Vorrichtung 1120 kann verschiedene Funktionen ausführen, um hier beschriebene Schemen, Techniken, Prozesse und Verfahren zu implementieren, die eine EHT-FILS-Unterstützung in einem Mehrfachverbindungsbetrieb in Funkkommunikationen betreffen, einschließlich sowohl der verschiedenen vorstehend mit Bezug auf verschiedene vorgeschlagene Entwürfe, Konzepte, Schemen, Systeme und Verfahren beschriebenen Schemen als auch der nachfolgend beschriebenen Prozesse. Zum Beispiel kann die Vorrichtung 1110 eine Beispielimplementierung der STA 110 sein und die Vorrichtung 1120 kann eine Beispielimplementierung der STA 120 sein.
• Jede der Vorrichtung 1110 und der Vorrichtung 1120 kann ein Teil einer Elektronikvorrichtung sein, welche eine STA oder ein AP sein kann, wie eine transportable oder mobile Vorrichtung, eine tragbare Vorrichtung, eine Funkkommunikationsvorrichtung oder eine Computer-Vorrichtung. Zum Beispiel kann jede der Vorrichtung 1110 und der Vorrichtung 1120 in einem Smartphone, einer Smartwatch, einem Personal-Digital-Assistant, einer Digitalkamera oder einer Computer-Ausrüstung, wie einem Tablet-Computer, einem Laptop-Computer oder einem Notebook-Computer implementiert sein. Jede der Vorrichtung 1110 und der Vorrichtung 1120 kann auch ein Teil einer maschinenartigen Vorrichtung sein, welche eine loT-Vorrichtung sein kann, wie eine unbewegliche oder stationäre Vorrichtung, eine Heimvorrichtung, eine drahtgebundene Kommunikationsvorrichtung oder eine Computer-Vorrichtung. Zum Beispiel kann jede der Vorrichtung 1110 und der Vorrichtung 1120 in einem Smart-Thermostat, einem Smart-Kühlschrank, einem Smart-Türschloss, einem Funklautsprecher oder einem Heimsteuerungszentrum implementiert sein. Wenn in einer oder als eine Netzwerkvorrichtung implementiert, kann die Vorrichtung 1110 und/oder die Vorrichtung 1120 in einem Netzwerkknoten, wie einem AP in einem WLAN implementiert sein.
• In einigen Implementierungen kann jede der Vorrichtung 1110 und der Vorrichtung 1120 in der Form eines oder mehrerer Integrierte-Schaltung- (IC-) Chips implementiert sein, wie zum Beispiel und ohne Einschränkung ein oder mehrere Einkernprozessoren, ein oder mehrere Mehrkernprozessoren, ein oder mehrere Reduced-Instruction-Set-Computing-(RISC-) Prozessoren oder ein oder mehrere Complex-Instruction-Set-Computing- (CISC-) Prozessoren. In den verschiedenen vorstehend beschriebenen Schemen kann jede der Vorrichtung 1110 und der Vorrichtung 1120 in einer oder als eine STA oder in einem oder als ein AP implementiert sein. Jede der Vorrichtung 1110 und der Vorrichtung 1120 kann jeweils zumindest einige der in 11 gezeigten Komponenten aufweisen, wie zum Beispiel einen Prozessor 1112 und einen Prozessor 1122. Jede der Vorrichtung 1110 und der Vorrichtung 1120 kann weiter eine oder mehrere andere Komponenten aufweisen, die für das vorgeschlagene Schema der vorliegenden Offenbarung nicht relevant sind (z.B. eine interne Energieversorgung, eine Anzeigevorrichtung und/oder eine Benutzerschnittstellenvorrichtung), und somit wird (werden) (eine) solche Komponente(n) der Vorrichtung 1110 und der Vorrichtung 1120 im Interesse einer Einfachheit und Kürze weder in 11 gezeigt noch nachfolgend beschrieben.
• In einem Aspekt kann jeder des Prozessors 1212 und des Prozessors 1222 in der Form eines oder mehrerer Einkernprozessoren, eines oder mehrerer Mehrkernprozessoren, eines oder mehrerer RISC-Prozessoren oder eines oder mehrerer CISC-Prozessoren implementiert sein. Das heißt, obwohl ein Einzahlbegriff „ein Prozessor“ hier verwendet wird, um auf den Prozessor 1112 und den Prozessor 1122 zu verweisen, kann jeder des Prozessors 1112 und des Prozessors 1122 gemäß der vorliegenden Offenbarung in einigen Implementierungen mehrere Prozessoren und in anderen Implementierungen einen einzelnen Prozessor aufweisen. In einem anderen Aspekt kann jeder des Prozessors 1112 und des Prozessors 1122 in der Form einer Hardware (und optional Firmware) mit Elektronikkomponenten implementiert sein, die zum Beispiel und ohne Einschränkung einen oder mehrere Transistoren, eine oder mehrere Dioden, einen oder mehrere Kondensatoren, einen oder mehrere Widerstände, eine oder mehrere Induktionsspulen, einen oder mehrere Memristoren und/oder einen oder mehrere Varaktoren aufweisen, die ausgelegt und angeordnet sind, bestimmte Zwecke gemäß der vorliegenden Offenbarung zu erfüllen. Mit anderen Worten ist zumindest in einigen Implementierungen jeder des Prozessors 1112 und des Prozessors 1122 eine Spezialmaschine, die spezifisch dafür entworfen, angeordnet und ausgelegt ist, bestimmte Aufgaben auszuführen, die diejenigen einschließen, die eine EHT-FILS-Unterstützung in einem Mehrfachverbindungsbetrieb in Funkkommunikationen gemäß verschiedener Implementierungen der vorliegenden Offenbarung betreffen.
• In einigen Implementierungen kann die Vorrichtung 1110 auch einen Sendeempfänger 1116 aufweisen, der mit dem Prozessor 1112 verbunden ist. Der Sendeempfänger 1116 kann in der Lage sein, Daten drahtlos zu senden und zu empfangen. In einigen Implementierungen kann die Vorrichtung 1120 auch einen Sendeempfänger 1126 aufweisen, der mit dem Prozessor 1122 verbunden ist. Der Sendeempfänger 1126 kann einen Sendeempfänger aufweisen, der in der Lage ist, Daten drahtlos zu senden und zu empfangen. Der Sendeempfänger 1116 der Vorrichtung 1110 und der Sendeempfänger 1126 der Vorrichtung 1120 können miteinander über eine oder mehrere von Mehrfachverbindungen Verbindung 1 ~ Verbindung N kommunizieren, mit N > 1, wie eine erste Verbindung und eine zweite Verbindung.
• In einigen Implementierungen kann die Vorrichtung 1110 weiter einen Speicher 1114 aufweisen, der mit dem Prozessor 1112 verbunden und geeignet ist, dass der Prozessor 1112 darauf zugreift und Daten darin abspeichert. In einigen Implementierungen kann die Vorrichtung 1120 weiter einen Speicher 1124 aufweisen, der mit dem Prozessor 1122 verbunden und geeignet ist, dass der Prozessor 1122 darauf zugreift und Daten darin abspeichert. Jeder des Speichers 1114 und des Speichers 1124 kann eine Art von Zufallszugriffsspeicher (RAM), wie dynamisches RAM (DRAM), statisches RAM (SRAM), Thyristor-RAM (T-RAM) und/oder Zero-Capacitor-RAM (Z-RAM), aufweisen. Alternativ oder zusätzlich kann jeder des Speichers 1114 und des Speichers 1124 eine Art von Nurlesespeicher (ROM), wie Mask-ROM, programmierbares ROM (PROM), löschbares programmierbares ROM (EPROM) und/oder elektrisch löschbares programmierbares ROM (EEPROM) aufweisen. Alternativ oder zusätzlich kann jeder des Speichers 1114 und des Speichers 1124 eine Art von nicht-flüchtigem Zufallszugriffsspeicher (NVRAM), wie Flash-Memory, Solid-State-Memory, ferroelektrisches RAM (FeRAM), magnetoresistives RAM (MRAM) und/oder Phase-Change-Memory aufweisen.
• Jede der Vorrichtung 1110 und der Vorrichtung 1120 kann eine Kommunikationseinheit sein, die geeignet ist, unter Verwendung verschiedener vorgeschlagener Schemen gemäß der vorliegenden Offenbarung miteinander zu kommunizieren. Zu darstellenden Zwecken und ohne Einschränkung wird nachfolgend eine Beschreibung von Fähigkeiten der Vorrichtung 1110 als eine STA 110, welche eine eingeschränkte Nicht-AP-MLD sein kann, und der Vorrichtung 1120 als eine STA 120, welche eine eingeschränkte AP-MLD sein kann, bereitgestellt. Es ist nennenswert, dass, obwohl die nachfolgend beschriebenen Beispielimplementierungen in dem Kontext eines WLANs vermittelt werden, die gleichen in anderen Arten von Netzwerken implementiert werden können.
• Bei einem vorgeschlagenen Schema kann hinsichtlich einer EHT-FILS-Unterstützung in einem Mehrfachverbindungsbetrieb in Funkkommunikationen gemäß der vorliegenden Offenbarung jeder des Prozessors 1112 der Vorrichtung 1110 und des Prozessors 1122 der Vorrichtung 1120, die jeweils in einer Nicht-AP-STA-MLD und einer AP-MLD implementiert sind, eine FILS-Prozedur ausführen, um Funkkommunikationen zwischen der AP-MLD und der Nicht-AP-STA-MLD über eine Mehrzahl von Verbindungen einzurichten. Weiter kann jeder des Prozessors 1112 der Vorrichtung 1110 und des Prozessors 1122 der Vorrichtung 1120 nach einem Abschluss der FILS-Prozedur über eine oder mehrere Verbindungen der Mehrzahl von Verbindungen kommunizieren.
• In einigen Implementierungen kann ein in der FILS-Prozedur übertragener FILS-Discovery-Rahmen anzeigen, ob eine SSID der AP-MLD zu einer SSID eines APs einer Mehrzahl von APs in der AP-MLD, die den FILS-Discovery-Rahmen sendet, verschieden ist.
• In einigen Implementierungen kann ein Multiple-Links-Presence-Indicator-Unterfeld in einem FD-Capability-Unterfeld in einem FILS-Discovery-Information-Feld des FILS-Discovery-Rahmens auf 1 festgelegt sein, um anzuzeigen, dass die SSID der AP-MLD zu der SSID des APs der Mehrzahl von APs in der AP-MLD, die den FILS-Discovery-Rahmen sendet, verschieden ist. In einigen Implementierungen kann in einem Fall, dass das Multiple-Links-Presence-Indicator-Unterfeld auf 1 festgelegt ist, das FILS-Discovery-Information-Feld auch ein Short-MLD-SSID-Unterfeld aufweisen, das eine 4-Oktette kurze SSID der AP-MLD aufweist.
• In einigen Implementierungen kann bei dem Ausführen der FILS-Prozedur der Prozessor 1112, der in der Nicht-AP-STA-MLD implementiert ist, eine Verknüpfungs- oder Wiederverknüpfungsprozedur mit einer HLP-Kapselung ausführen durch: (a) Konstruieren eines FILS-HLP-Container-Elements, um ein HLP-Paket zu bilden; und (b) Senden des FILS-HLP-Container-Elements in einem Verknüpfungs- oder Wiederverknüpfungsanforderungsrahmen an die AP-MLD. In einigen Implementierungen kann das FILS-HLP-Container-Element eine Ziel-MAC-Adresse, eine Quellen-MAC-Adresse und das HLP-Paket in einem MSDU-Format aufweisen. Weiter kann die Quellen-MAC-Adresse eine MLD-MAC-Adresse der Nicht-AP-STA-MLD enthalten oder sein.
• In einigen Implementierungen kann bei dem Ausführen der FILS-Prozedur der Prozessor 1122, der in der AP-MLD implementiert ist, das HLP-Paket empfangen und entkapseln durch: (a) Extrahieren der Ziel-MAC-Adresse, der Quellen-MAC-Adresse und des HLP-Pakets von dem FILS-HLP-Container-Element; (b) Feststellen, ob die extrahierte Quellen-MAC-Adresse mit der MLD-MAC-Adresse der Nicht-AP-STA-MLD übereinstimmt, die mit der Quellen-MAC-Adresse des Verknüpfungs- oder Wiederverknüpfungsanforderungsrahmens verknüpft ist; und (c) als Reaktion auf das Feststellen, dass die extrahierte Quellen-MAC-Adresse mit der MLD-MAC-Adresse der Nicht-AP-STA-MLD übereinstimmt: (i) Konstruieren eines Rahmens, der das HLP-Paket aufweist; und (ii) Zustellen des Rahmens an ein Upstream-Netzwerk oder einen BSS. Weiter kann der Prozessor 1122 das FILS-HLP-Container-Element als Reaktion auf ein Feststellen, dass die extrahierte Quellen-MAC-Adresse nicht mit der MLD-MAC-Adresse der Nicht-AP-STA-MLD übereinstimmt, verwerfen.
• In einigen Implementierungen kann bei dem Ausführen der FILS-Prozedurjeder des Prozessors 1112 und des Prozessors 1122, die jeweils in der Nicht-AP-STA-MLD und der AP-MLD implementiert sind, eine Authentifikationsprozedur mit einem öffentlichen Schlüssel über die Mehrzahl von Verbindungen durch die Mehrzahl von APs in der AP-MLD und durch eine Mehrzahl von STAs in der Nicht-AP-STA-MLD über die Mehrzahl von Verbindungen ausführen. In einigen Implementierungen können Diffie-Hellman-Werte in der Mehrzahl von APs in der AP-MLD über die Mehrzahl von Verbindungen allgemein/gleich/gemeinsam sein. Ähnlich können Diffie-Hellman-Werte in der Mehrzahl von STAs in der Nicht-AP-STA-MLD über die Mehrzahl von Verbindungen allgemein/gleich/gemeinsam sein.
• In einigen Implementierungen kann bei dem Ausführen der FILS-Prozedurjeder des Prozessors 1112 und des Prozessors 1122, die jeweils in der Nicht-AP-STA-MLD und der AP-MLD implementiert sind, eine Authentifikationsprozedur unter Verwendung eines PMK und einer PMKID ausführen. In einigen Implementierungen kann jedes des PMK und der PMKID unter Verwendung von MLD-Ebene-Informationen generiert werden, die sich auf die AP-MLD und die Nicht-AP-STA-MLD beziehen.
• In einigen Implementierungen kann bei dem Ausführen der FILS-Prozedur der Prozessor 1112, der in der Nicht-AP-STA-MLD implementiert ist, eine Authentifikationsprozedur ausführen durch: (a) Generieren eines Authentifikationsrahmens durch: (i) Codieren einer MLD-MAC-Adresse der Nicht-AP-STA-MLD, welche eine WM-MAC-Adresse ist, für jede Verbindung einer oder mehrerer unterstützter Verbindungen aus der Mehrzahl von Verbindungen; und (ii) Einbinden der codierten MAC-Adresse in einem Multiple-Link-Address-Element des Authentifikationsrahmens; und (b) Senden des Authentifikationsrahmens an die AP-MLD.
• In einigen Implementierungen kann bei dem Ausführen der FILS-Prozedur der Prozessor 1122, der in der AP-MLD implementiert ist, eine Authentifikationsprozedur ausführen durch: (a) Generieren eines Authentifikationsrahmens durch: (i) Codieren einer MLD-MAC-Adresse der AP-MLD, welche eine WM-MAC-Adresse ist, für jede Verbindung einer oder mehrerer unterstützter Verbindungen aus der Mehrzahl von Verbindungen; und (ii) Einbinden der codierten MAC-Adresse in einem Multiple-Link-Address-Element des Authentifikationsrahmens; und (b) Senden des Authentifikationsrahmens an die Nicht-AP-STA-MLD.
• In einigen Implementierungen kann bei dem Ausführen der FILS-Prozedur der Prozessor 1122, der in der AP-MLD implementiert ist, eine Verknüpfungs- oder Wiederverknüpfungsprozedur ausführen durch: (a) Generieren eines Verknüpfungs- oder Wiederverknüpfungsantwortrahmens durch ein Konstruieren eines Key-Delivery-Elements, das anzeigt: (i) einen aktuellen GTK und einen Schlüssel-RSC, die mit jeder Verbindung der Mehrzahl von Verbindungen verknüpft sind, (ii) einen aktuelle IGTK und eine IPN, die mit jeder Verbindung der Mehrzahl von Verbindungen verknüpft sind, in einem Fall, dass ein Managementrahmenschutz aktiviert ist, und (iii) einen aktuellen BIGKT und eine BIPN, die mit jeder Verbindung der Mehrzahl von Verbindungen verknüpft sind, in einem Fall, dass ein Signalschutz aktiviert ist; und (b) Senden des Verknüpfungs- oder Wiederverknüpfungsantwortrahmens an die Nicht-AP-STA-MLD. In einigen Implementierungen kann das Key-Delivery-Element ein KDE-Listenfeld aufweisen, das eine Mehrfachverbindungs-GTK-KDE, eine Mehrfachverbindungs-IGTK-KDE und eine Mehrfachverbindungs-BIGTK-KDE aufweist, die mit jeder Verbindung einer oder mehrerer Verbindungen aus der Mehrzahl von Verbindungen verknüpft sind, auf welcher das Key-Delivery-Element übertragen wird.
• In einigen Implementierungen kann die Mehrfachverbindungs-GTK-KDE aufweisen: (i) ein Key-ID-Feld, das einen Wert einer GTK-Schlüsselkennung anzeigt, (ii) ein Transmit-Feld, das eine Verbindung anzeigt, auf welcher der GTK übertragen wird, (iii) ein Link-ID-Feld, das eine Verbindung anzeigt, auf welcher der GTK installiert wird, und (iv) ein Key-RSC-Feld, das einen RSC für den GTK aufweist, der auf der Verbindung installiert wird, die durch das Link-ID-Feld angezeigt wird. In einigen Implementierungen kann die GTK-Schlüsselkennung eine MLD-Ebene für die AP-MLD und die Nicht-AP-STA-MLD sein, die eine gleiche Schlüsselkennung unterstützt.
• In einigen Implementierungen kann die Mehrfachverbindungs-IGTK-KDE aufweisen: (i) ein Key-ID-Feld, das einen Wert einer IGTK-Schlüsselkennung anzeigt, (ii) ein Link-ID-Feld, das eine Verbindung anzeigt, auf welcher der IGTK installiert wird, und (iii) ein IPN-Feld, das zu einer letzten Paketnummer korrespondiert, die von einem Sender auf der durch das Link-ID-Feld angezeigten Verbindung verwendet wird und von einem Empfänger als ein Anfangswert für einen BIP-Wiederholungszähler für den IGTK verwendet wird. In einigen Implementierungen kann die IGTK-Schlüsselkennung eine MLD-Ebene für die AP-MLD und die Nicht-AP-STA-MLD sein, die eine gleiche Schlüsselkennung unterstützt.
• In einigen Implementierungen kann die Mehrfachverbindungs-BIGTK-KDE aufweisen: (i) ein Key-ID-Feld, das einen Wert einer BIGTK-Schlüsselkennung anzeigt, (ii) ein Link-ID-Feld, das eine Verbindung anzeigt, auf welcher der BIGTK installiert wird, und (iii) ein BIPN-Feld, das zu einem BIPN-Wert korrespondiert, der in einem MME eines letzten geschützten Signalrahmens auf der durch das Link-ID-Feld angezeigten Verbindung übertragen wird und von einem Empfänger als ein Anfangswert für einen BIP-Wiederholungszähler für den BIGTK verwendet wird. In einigen Implementierungen kann die BIGTK-Schlüsselkennung eine MLD-Ebene für die AP-MLD und die Nicht-AP-STA-MLD sein, die eine gleiche Schlüsselkennung unterstützt.
• In einigen Implementierungen sendet oder empfängt bei dem Kommunizieren jeder des Prozessors 1112 und des Prozessors 1122 jeweils über den Sendeempfänger 1116 oder den Sendeempfänger 1126 einen erneut übertragenen Rahmen mit einem Key-ID-Feld in einer CCMP- oder GCMP-Kopfzeile des Rahmens, das gleich einem Key-ID-Feld einer ersten übertragenen MPDU ist.
• Erläuternde Prozesse
• 12 stellt einen Beispielprozess 1200 gemäß einer Implementierung der vorliegenden Offenbarung dar. Der Prozess 1200 kann einen Aspekt eines Implementierens verschiedener vorgeschlagener Entwürfe, Konzepte, Schemen, Systeme und Verfahren repräsentieren, die vorstehend beschrieben sind. Genauer kann der Prozess 1200 einen Aspekt der vorgeschlagenen Konzepte und Schemen repräsentieren, die EHT-FILS-Unterstützung in einem Mehrfachverbindungsbetrieb in Funkkommunikationen gemäß der vorliegenden Offenbarung betreffen. Der Prozess 1200 kann eine oder mehrere Operationen, Aktionen oder Funktionen umfassen, wie durch einen oder mehrere von Blöcken 1210 und 1220 dargestellt. Obwohl sie als diskrete Blöcke dargestellt sind, können verschiedene Blöcke des Prozesses 1200 abhängig von der gewünschten Implementierung in zusätzliche Blöcke unterteilt, in weniger Blöcke zusammengefasst oder eliminiert werden. Weiter können die Blöcke/Unterblöcke des Prozesses 1200 in der in 12 gezeigten Reihenfolge oder alternativ in einer anderen Reihenfolge ausgeführt werden. Weiterhin können einer oder mehrere der Blöcke/Unterblöcke des Prozesses 1200 wiederholt oder iterativ ausgeführt werden. Der Prozess 1200 kann sowohl durch die oder in der Vorrichtung 1110 und Vorrichtung 1120 als auch Variationen davon implementiert sein. Nur zu darstellenden Zwecken und ohne den Schutzumfang einzuschränken, wird der Prozess 1200 nachfolgend in dem Kontext der Vorrichtung 1110 als die STA 110 (z.B. eine STA oder ein AP) und der Vorrichtung 1120 als die STA 120 (z.B. eine Partner-STA oder ein Partner-AP) eines Funknetzwerks, wie eines WLANs gemäß einem oder mehreren IEEE 802.11 Standards, beschrieben. Der Prozess 1200 kann bei Block 1210 beginnen.
• Bei 1210 kann der Prozess 1200 einbeziehen, dass jede der Vorrichtung 1110 und der Vorrichtung 1120, die jeweils in einer Nicht-AP-STA-MLD und einer AP-MLD implementiert sind, eine FILS-Prozedur ausführt, um Funkkommunikationen zwischen der AP-MLD und der Nicht-AP-STA-MLD über eine Mehrzahl von Verbindungen einzurichten. Der Prozess 1200 kann von 1210 nach 1220 fortfahren.
• Bei 1220 kann der Prozess 1200 einbeziehen, dass jede der Vorrichtung 1110 und der Vorrichtung 1120 nach einem Abschluss der FILS-Prozedur über eine oder mehrere Verbindungen der Mehrzahl von Verbindungen kommuniziert.
• In einigen Implementierungen kann ein FILS-Discovery-Rahmen, der in der FILS-Prozedur gesendet wird, anzeigen, ob eine SSID der AP-MLD zu einer SSID eines APs einer Mehrzahl von APs in der AP-MLD, die den FILS-Discovery-Rahmen sendet, verschieden ist.
• In einigen Implementierungen kann ein Multiple-Links-Presence-Indicator-Unterfeld in einem FD-Capability-Unterfeld in einem FILS-Discovery-Information-Feld des FILS-Discovery-Rahmens auf 1 festgelegt sein, um anzuzeigen, dass die SSID der AP-MLD zu der SSID des APs der Mehrzahl von APs in der AP-MLD, die den FILS-Discovery-Rahmen sendet, verschieden ist. In einigen Implementierungen kann in einem Fall, dass das Multiple-Links-Presence-Indicator-Unterfeld auf 1 festgelegt ist, das FILS-Discovery-Information-Feld auch ein Short-MLD-SSID-Unterfeld aufweisen, das eine 4-Oktette kurze SSID der AP-MLD aufweist.
• In einigen Implementierungen kann bei dem Ausführen der FILS-Prozedur der Prozess 1200 einbeziehen, dass die Nicht-AP-STA-MLD eine Verknüpfungs- oder Wiederverknüpfungsprozedur mit einer HLP-Kapselung ausführt durch: (a) Konstruieren eines FILS-HLP-Container-Elements, um ein HLP-Paket zu bilden; und (b) Senden des FILS-HLP-Container-Elements in einem Verknüpfungs- oder Wiederverknüpfungsanforderungsrahmen an die AP-MLD. In einigen Implementierungen kann das FILS-HLP-Container-Element eine Ziel-MAC-Adresse, eine Quellen-MAC-Adresse und das HLP-Paket in einem MSDU-Format aufweisen. Weiter kann die Quellen-MAC-Adresse eine MLD-MAC-Adresse der Nicht-AP-STA-MLD enthalten oder sein.
• In einigen Implementierungen kann bei dem Ausführen der FILS-Prozedur der Prozess 1200 weiter einbeziehen, dass die AP-MLD das HLP-Paket empfängt und entkapselt durch: (a) Extrahieren der Ziel-MAC-Adresse, der Quellen-MAC-Adresse und des HLP-Pakets von dem FILS-HLP-Container-Element; (b) Feststellen, ob die extrahierte Quellen-MAC-Adresse mit der MLD-MAC-Adresse der Nicht-AP-STA-MLD übereinstimmt, die mit der Quellen-MAC-Adresse des Verknüpfungs- oder Wiederverknüpfungsanforderungsrahmens verknüpft ist; und (c) als Reaktion auf ein Feststellen, dass die extrahierte Quellen-MAC-Adresse mit der MLD-MAC-Adresse der Nicht-AP-STA-MLD übereinstimmt: (i) Konstruieren eines Rahmens, der das HLP-Paket aufweist; und (ii) Zustellen des Rahmens an ein Upstream-Netzwerk oder einen BSS. Weiter kann der Prozessor 1200 einbeziehen, dass die AP-MLD das FILS-HLP-Container-Element als Reaktion auf ein Feststellen, dass die extrahierte Quellen-MAC-Adresse nicht mit der MLD-MAC-Adresse der Nicht-AP-STA-MLD übereinstimmt, verwirft.
• In einigen Implementierungen kann bei dem Ausführen der FILS-Prozedur der Prozess 1200 einbeziehen, dass jede der Vorrichtung 1110 und der Vorrichtung 1120 eine Authentifikationsprozedur mit einem öffentlichen Schlüssel über die Mehrzahl von Verbindungen durch die Mehrzahl von APs in der AP-MLD und durch eine Mehrzahl von STAs in der Nicht-AP-STA-MLD über die Mehrzahl von Verbindungen ausführt. In einigen Implementierungen können Diffie-Hellman-Werte in der Mehrzahl von APs in der AP-MLD über die Mehrzahl von Verbindungen allgemein/gleich/gemeinsam sein. Ähnlich können Diffie-Hellman-Werte in der Mehrzahl von STAs in der Nicht-AP-STA-MLD über die Mehrzahl von Verbindungen allgemein/gleich/gemeinsam sein.
• In einigen Implementierungen kann bei dem Ausführen der FILS-Prozedur der Prozess 1200 einbeziehen, dass jede der Vorrichtung 1110 und der Vorrichtung 1120 eine Authentifikationsprozedur unter Verwendung eines PMK und einer PMKID ausführt. In einigen Implementierungen kann jedes des PMK und der PMKID unter Verwendung von MLD-Ebene-Informationen generiert werden, die sich auf die AP-MLD und die Nicht-AP-STA-MLD beziehen.
• In einigen Implementierungen kann bei dem Ausführen der FILS-Prozedur der Prozess 1200 einbeziehen, dass die Vorrichtung 1110, die in der Nicht-AP-STA-MLD implementiert ist, eine Authentifikationsprozedur ausführt durch: (a) Generieren eines Authentifikationsrahmens durch: (i) Codieren einer MLD-MAC-Adresse der Nicht-AP-STA-MLD, welche eine WM-MAC-Adresse ist, für jede Verbindung einer oder mehrerer unterstützter Verbindungen aus der Mehrzahl von Verbindungen; und (ii) Einbinden der codierten MAC-Adresse in einem Multiple-Link-Address-Element des Authentifikationsrahmens; und (b) Senden des Authentifikationsrahmens an die AP-MLD.
• In einigen Implementierungen kann bei dem Ausführen der FILS-Prozedur der Prozess 1200 einbeziehen, dass die Vorrichtung 1120, die in der AP-MLD implementiert ist, eine Authentifikationsprozedur ausführt durch: (a) Generieren eines Authentifikationsrahmens durch: (i) Codieren einer MLD-MAC-Adresse der AP-MLD, welche eine WM-MAC-Adresse ist, für jede Verbindung einer oder mehrerer unterstützter Verbindungen aus der Mehrzahl von Verbindungen; und (ii) Einbinden der codierten MAC-Adresse in einem Multiple-Link-Address-Element des Authentifikationsrahmens; und (b) Senden des Authentifikationsrahmens an die Nicht-AP-STA-MLD.
• In einigen Implementierungen kann bei dem Ausführen der FILS-Prozedur der Prozess 1200 einbeziehen, dass die Vorrichtung 1120, die in der AP-MLD implementiert ist, eine Verknüpfungs- oder Wiederverknüpfungsprozedur ausführt durch: (a) Generieren eines Verknüpfungs- oder Wiederverknüpfungsantwortrahmens durch ein Konstruieren eines Key-Delivery-Elements, das anzeigt: (i) einen aktuellen GTK und Schlüssel-RSC, die mit jeder Verbindung der Mehrzahl von Verbindungen verknüpft sind, (ii) einen aktuellen IGTK und eine IPN, die mit jeder Verbindung der Mehrzahl von Verbindungen verknüpft sind, in einem Fall, dass ein Managementrahmenschutz aktiviert ist, und (iii) einen aktuellen BIGTK und eine BIPN, die mit jeder Verbindung der Mehrzahl von Verbindungen verknüpft sind, in einem Fall, dass ein Signalschutz aktiviert ist; und (b) Senden des Verknüpfungs- oder Wiederverknüpfungsantwortrahmens an die Nicht-AP-STA-MLD. In einigen Implementierungen kann das Key-Delivery-Element ein KDE-Liste-Feld aufweisen, das eine Mehrfachverbindungs-GTK-KDE, eine Mehrfachverbindungs-IGTK-KDE und eine Mehrfachverbindungs-BIGTK-KDE aufweist, die mit jeder Verbindung einer oder mehrerer Verbindungen aus der Mehrzahl von Verbindungen verknüpft sind, auf welcher das Key-Delivery-Element gesendet wird.
• In einigen Implementierungen kann die Mehrfachverbindungs-GTK-KDE aufweisen:
• (i) ein Key-ID-Feld, das einen Wert einer GTK-Schlüsselkennung anzeigt, (ii) ein Transmit-Feld, das eine Verbindung anzeigt, auf welcher der GTK gesendet wird, (iii) ein Link-ID-Feld, das eine Verbindung anzeigt, auf welcher der GTK installiert wird, und (iv) ein Key-RSC-Feld, das einen RSC für den GTK aufweist, der auf der durch das Link-ID-Feld angezeigten Verbindung installiert wird. In einigen Implementierungen kann die GTK-Schlüsselkennung eine MLD-Ebene für die AP-MLD und die Nicht-AP-STA-MLD sein, die eine gleiche Schlüsselkennung unterstützt.
• In einigen Implementierungen kann die Mehrfachverbindungs-IGTK-KDE aufweisen:
• (i) ein Key-ID-Feld, das einen Wert einer IGTK-Schlüsselkennung anzeigt, (ii) ein Link-ID-Feld, das eine Verbindung anzeigt, auf welcher der IGTK installiert wird, (iii) ein IPN-Feld, das zu einer letzten Paketnummer korrespondiert, die von einem Sender auf der durch das Link-ID-Feld angezeigten Verbindung verwendet wird und von einem Empfänger als ein Anfangswert für einen BIP-Wiederholungszähler für den IGTK verwendet wird. In einigen Implementierungen kann die IGTK-Schlüsselkennung eine MLD-Ebene für die AP-MLD und die Nicht-AP-STA-MLD sein, die eine gleiche Schlüsselkennung unterstützt.
• In einigen Implementierungen kann die Mehrfachverbindungs-BIGTK-KDE aufweisen: (i) ein Key-ID-Feld, das einen Wert einer BIGTK-Schlüsselkennung anzeigt, (ii) ein Link-ID-Feld, das eine Verbindung anzeigt, auf welcher der BIGTK installiert wird, und (iii) ein BIPN-Feld, das zu einem BIPN-Wert korrespondiert, der in einem MME eines letzten geschützten Signalrahmens auf der durch das Link-ID-Feld angezeigten Verbindung übertragen wird und von einem Empfänger als ein Anfangswert für einen BIP-Wiederholungszähler für den BIGTK verwendet wird. In einigen Implementierungen kann die BIGTK-Schlüsselkennung eine MLD-Ebene für die AP-MLD und die Nicht-AP-STA-MLD sein, die eine gleiche Schlüsselkennung unterstützt.
• In einigen Implementierungen kann bei dem Kommunizieren der Prozess 1200 einbeziehen, dass jede der Vorrichtung 1110 und der Vorrichtung 1120 einen erneut übertragenen Rahmen mit einem Key-ID-Feld in einer CCMP- oder GCMP-Kopfzeile des Rahmens, das gleich einem Key-ID-Feld einer ersten übertragenen MPDU ist, sendet oder empfängt.
• Zusätzliche Anmerkungen
• Der hier beschriebene Gegenstand stellt manchmal unterschiedliche Komponenten, die in verschiedenen anderen Komponenten enthalten oder damit verbunden sind, dar. Es soll verstanden werden, dass solche veranschaulichten Architekturen nur Beispiele sind, und dass tatsächlich viele andere Architekturen implementiert werden können, welche die gleiche Funktionalität erzielen. In einem konzeptionellen Sinn ist jegliche Anordnung von Komponenten, um die gleiche Funktionalität zu erzielen, effektiv „verbunden“, sodass die gewünschte Funktionalität erzielt wird. Daher können zwei Komponenten, die hier kombiniert sind, um eine bestimmte Funktionalität zu erzielen, als „miteinander verknüpft“ angesehen werden, sodass die gewünschte Funktionalität erzielt wird, unabhängig von Architekturen oder Zwischenkomponenten. Ähnlich können zwei so verknüpfte Komponenten auch als „betriebsfähig verbunden“ oder „betriebsfähig gekoppelt“ miteinander angesehen werden, um die gewünschte Funktionalität zu erzielen, und zwei Komponenten, die geeignet sind, so verknüpft zu werden, können auch als „betriebsfähig koppelbar“ miteinander angesehen werden, sodass sie die gewünschte Funktionalität erzielen. Bestimmte Beispiele von betriebsfähig koppelbar umfassen aber sind nicht beschränkt auf physikalisch verbindbare und/oder physikalisch zusammenwirkende Komponenten und/oder drahtlos zusammen betreibbare und/oder drahtlos zusammenwirkende Komponenten und/oder logisch zusammenwirkende und/oder logisch zusammen betreibbare Komponenten.
• Weiter können jene mit Kenntnissen auf dem Gebiet hinsichtlich der Verwendung im Wesentlichen jeder Mehrzahl- und/oder Einzahlbegriffe hier von der Mehrzahl zu der Einzahl und/oder von der Einzahl zu der Mehrzahl übertragen, wie es für den Kontext und/oder die Anwendung angemessen ist. Die verschiedenen Einzahl-/Mehrzahl-Permutationen können im Sinne einer Klarheit hier ausdrücklich dargelegt werden.
• Weiter wird von denjenigen mit Kenntnissen auf dem Gebiet verstanden, dass allgemein Begriffe, die hier und speziell in den angehängten Ansprüchen, z.B. den Merkmalen der angehängten Ansprüche, verwendet werden, generell als „offene“ Begriffe gedacht sind, z.B. sollte der Begriff „einschließend“ interpretiert werden als „einschließend aber nicht beschränkt auf“, sollte der Begriff „aufweisen“ interpretiert werden als „mindestens aufweisend“, sollte der Begriff „umfasst“ interpretiert werden als „umfasst aber ist nicht beschränkt auf“, usw. Es wird weiter von denjenigen mit Kenntnissen auf dem Gebiet verstanden, dass, wenn eine bestimmte Zahl einer eingeführten Anspruchsrezitation beabsichtigt ist, eine solche Absicht in dem Anspruch explizit rezitiert wird, und bei der Abwesenheit einer solchen Rezitation eine solche Absicht nicht vorhanden ist. Zum Beispiel können als eine Verständnishilfe die nachfolgenden angehängten Ansprüche eine Verwendung der einführenden Formulierungen „mindestens ein“ und „ein oder mehrere“ aufweisen, um Anspruchsrezitationen einzuführen. Die Verwendung solcher Formulierungen sollte jedoch nicht als derart implizierend angesehen werden, dass die Einführung einer Anspruchsrezitation durch den unbestimmten Artikel „ein“ einen bestimmten Anspruch einschränkt, der eine so eingeführte Anspruchsrezitation auf Implementierungen aufweist, die nur eine solche Rezitation aufweisen, selbst wenn der gleiche Anspruch die einführenden Formulierungen „ein oder mehrere“ oder „mindestens ein“ und unbestimmte Artikel wie „ein“ aufweist, z.B. sollte „ein“ so interpretiert werden, dass es „mindestens ein“ oder „ein oder mehrere“ bedeutet; das Gleiche gilt für die Verwendung von bestimmten Artikeln, die verwendet werden, um Anspruchsrezitationen einzuführen. Zusätzlich werden, selbst wenn eine bestimmte Zahl einer eingeführten Anspruchsrezitation explizit rezitiert wird, diejenigen mit Kenntnissen auf dem Gebiet erkennen, dass eine solche Rezitation so interpretiert werden sollte, dass sie mindestens die rezitierte Zahl bedeutet, z.B. bedeutet die reine Rezitation von „zwei Rezitationen“ ohne andere Attribute mindestens zwei Rezitationen oder zwei oder mehr Rezitationen. Weiter ist in denjenigen Fällen, in welchen eine Aussage analog zu „mindestens eins von A, B und C, usw.“ verwendet wird, ein solches Konstrukt allgemein in dem Sinn gedacht, wie jemand mit Kenntnissen auf dem Gebiet die Aussage verstehen würde, z.B. „ein System weist mindestens eins von A, B und C auf“ würde umfassen aber nicht beschränkt sein auf Systeme, die nur A, nur B, nur C, A und B zusammen, A und C zusammen, B und C zusammen und/oder A, B und C zusammen aufweisen, usw. In denjenigen Fällen, in welchen eine Aussage analog zu „mindestens eins von A, B oder C, usw.“ verwendet wird, ist ein solches Konstrukt allgemein in dem Sinn gedacht, wie jemand mit Kenntnissen auf dem Gebiet die Aussage verstehen würde, z.B. würde „ein System, das mindestens eins von A, B oder C aufweist“, umfassen aber nicht beschränkt sein auf Systeme, welche nur A, nur B, nur C, A und B zusammen, A und C zusammen, B und C zusammen und/oder A, B und C zusammen aufweisen, usw. Es wird weiter von denjenigen mit Kenntnissen auf dem Gebiet verstanden, dass nahezu jedes trennende Wort und/oder Formulierung, das/die zwei oder mehr alternative Begriffe präsentiert, sei es in der Beschreibung, den Ansprüchen oder den Zeichnungen, so verstanden werden sollte, dass es die Möglichkeiten eines Einschließens eines der Begriffe, eines anderen der Begriffe, oder beider Begriffe in Betracht zieht. Zum Beispiel wird die Formulierung „A oder B“ so verstanden, dass sie die Möglichkeiten „A“ oder „B“ oder „A und B“ umfasst.
• Aus dem Vorstehenden wird anerkannt, dass verschiedene Implementierungen der vorliegenden Offenbarung hier für Zwecke einer Darstellung beschrieben worden sind, und dass verschiedene Modifikationen vorgenommen werden können, ohne von dem Schutzumfang der vorliegenden Offenbarung abzuweichen. Entsprechend sind die verschiedenen hier offenbarten Implementierungen nicht gedacht, einschränkend zu sein, wobei der wahre Schutzumfang durch die nachfolgenden Ansprüche angezeigt wird.
• ZITATE ENTHALTEN IN DER BESCHREIBUNG
• Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
• Zitierte Patentliteratur
• US 63/028801 [0001]

Claims (14)

1. Verfahren, umfassend: Ausführen einer Fast-Initial-Link-Setup-, im Folgenden auch als FILS bezeichnet, Prozedur, um Funkkommunikationen zwischen einer Zugangspunkt-, im Folgenden auch als AP bezeichnet, Mehrfachverbindungsvorrichtung, im Folgenden auch als MLD bezeichnet, und einer Nicht-AP-Station-, im Folgenden auch als STA bezeichnet, MLD über eine Mehrzahl von Verbindungen einzurichten (1210); und Kommunizieren über eine oder mehrere Verbindungen der Mehrzahl von Verbindungen nach einem Abschluss der FILS-Prozedur (1220), wobei ein FILS-Discovery-Rahmen, der in der FILS-Prozedur gesendet wird, anzeigt, ob eine Dienstsatzkennung, im Folgenden auch als SSID bezeichnet, der AP-MLD zu einer SSID eines APs einer Mehrzahl von APs in der AP-MLD, die den FILS-Discovery-Rahmen sendet, verschieden ist.
2. Verfahren gemäß Anspruch 1, wobei ein Multiple-Links-Presence-Indicator-Unterfeld in einem FILS-Discovery-, im Folgenden auch als FD bezeichnet, Capability-Unterfeld in einem FILS-Discovery-Information-Feld des FILS-Discovery-Rahmens auf 1 festgelegt ist, um anzuzeigen, dass die SSID der AP-MLD zu der SSID des APs der Mehrzahl von APs in der AP-MLD, die den FILS-Discovery-Rahmen sendet, verschieden ist; wobei vorzugsweise in einem Fall, dass das Multiple-Links-Presence-Indicator-Unterfeld auf 1 festgelegt ist, das FILS-Discovery-Information-Feld weiter ein Short-MLD-SSID-Unterfeld aufweist, das eine 4-Oktette kurze SSID der AP-MLD aufweist.
3. Verfahren gemäß Anspruch 1 oder 2, wobei das Ausführen der FILS-Prozedur umfasst, dass die Nicht-AP-STA-MLD eine Verknüpfungs- oder Wiederverknüpfungsprozedur mit einer höhere-Schicht-Protokoll-, im Folgenden auch als HLP bezeichnet, Kapselung ausführt durch: Konstruieren eines FILS-HLP-Container-Elements, um ein HLP-Paket zu bilden; und Senden des FILS-HLP-Container-Elements in einem Verknüpfungs- oder Wiederverknüpfungsanforderungsrahmen an die AP-MLD, wobei das FILS-HLP-Container-Element eine Ziel-Medium-Access-Control-, im Folgenden auch als MAC bezeichnet, Adresse, eine Quellen-MAC-Adresse und das HLP-Paket in einem MAC-Dienstdateneinheit-, im Folgenden auch als MSDU bezeichnet, Format aufweist, und wobei die Quellen-MAC-Adresse eine MLD-MAC-Adresse der Nicht-AP-STA-MLD aufweist; und/oder wobei das Ausführen der FILS-Prozedur weiter umfasst, dass die AP-MLD das HLP-Paket empfängt und entkapselt durch: Extrahieren der Ziel-MAC-Adresse, der Quellen-MAC-Adresse und des HLP-Pakets von dem FILS-HLP-Container-Element, Feststellen, ob die extrahierte Quellen-MAC-Adresse mit der MLD-MAC-Adresse der Nicht-AP-STA-MLD übereinstimmt, die mit der Quellen-MAC-Adresse des Verknüpfungs- oder Wiederverknüpfungsanforderungsrahmens verknüpft ist, und als Reaktion auf ein Feststellen, dass die extrahierte Quellen-MAC-Adresse mit der MLD-MAC-Adresse der Nicht-AP-STA-MLD übereinstimmt: Konstruieren eines Rahmens, der das HLP-Paket aufweist, und Zustellen des Rahmens an ein Upstream-Netzwerk oder einen Basisdienstsatz, im Folgenden auch als BSS bezeichnet, wobei als Reaktion auf ein Feststellen, dass die extrahierte Quellen-MAC-Adresse nicht mit der MLD-MAC-Adresse der Nicht-AP-STA-MLD übereinstimmt, das FILS-HLP-Container-Element durch die AP-MLD verworfen wird.
4. Verfahren gemäß einem der Ansprüche 1 bis 3, wobei das Ausführen der FILS-Prozedur ein Ausführen einer Authentifikationsprozedur mit einem öffentlichen Schlüssel über die Mehrzahl von Verbindungen durch die Mehrzahl von APs in der AP-MLD und durch eine Mehrzahl von STAs in der Nicht-AP-STA-MLD über die Mehrzahl von Verbindungen umfasst; wobei vorzugsweise Diffie-Hellman-Werte in der Mehrzahl von APs in der AP-MLD über die Mehrzahl von Verbindungen gemeinsam sind, und wobei Diffie-Hellman-Werte in der Mehrzahl von STAs in der Nicht-AP-STA-MLD über die Mehrzahl von Verbindungen gemeinsam sind.
5. Verfahren gemäß einem der Ansprüche 1 bis 4, wobei das Ausführen der FILS-Prozedur ein Ausführen einer Authentifikationsprozedur unter Verwendung eines Pairwise-Master-Key, im Folgenden auch als PMK bezeichnet, und einer PMK-Kennung, im Folgenden auch als PMKID bezeichnet, umfasst, und wobei jedes des PMKs und der PMKID unter Verwendung von MLD-Ebene-Informationen, die sich auf die AP-MLD und die Nicht-AP-STA-MLD beziehen, generiert wird.
6. Verfahren gemäß einem der Ansprüche 1 bis 5, wobei das Ausführen der FILS-Prozedur umfasst, dass die Nicht-AP-STA-MLD eine Authentifikationsprozedur ausführt durch: Generieren eines Authentifikationsrahmens durch: Codieren einer MLD-MAC-Adresse der Nicht-AP-STA-MLD, welche eine Funkmedium-, im Folgenden auch als WM bezeichnet, MAC-Adresse ist, für jede Verbindung einer oder mehrerer unterstützter Verbindungen aus der Mehrzahl von Verbindungen, und Einbinden der codierten MAC-Adresse in einem Multiple-Link-Address-Element des Authentifikationsrahmens, und Senden des Authentifikationsrahmens an die AP-MLD; und/oder wobei das Ausführen der FILS-Prozedur umfasst, dass die AP-MLD eine Authentifikationsprozedur ausführt durch: Generieren eines Authentifikationsrahmens durch: Codieren einer MLD-MAC-Adresse der AP-MLD, welche eine WM-MAC-Adresse ist, für jede Verbindung einer oder mehrerer unterstützter Verbindungen aus der Mehrzahl von Verbindungen; und Einbinden der codierten MAC-Adresse in einem Multiple-Link-Address-Element des Authentifikationsrahmens; und Senden des Authentifikationsrahmens an die Nicht-AP-STA-MLD.
7. Verfahren gemäß einem der Ansprüche 1 bis 6, wobei das Ausführen der FILS-Prozedur umfasst, dass die AP-MLD eine Verknüpfungs- oder Wiederverknüpfungsprozedur ausführt durch: Generieren eines Verknüpfungs- oder Wiederverknüpfungsantwortrahmens durch ein Konstruieren eines Key-Delivery-Elements, das anzeigt: einen aktuellen Group-Temporal-Key, im Folgenden auch als GTK bezeichnet, und einen Key-Receive-Sequence-Counter, im Folgenden auch als RSC bezeichnet, die mit jeder Verbindung der Mehrzahl von Verbindungen verknüpft sind, einen aktuellen Integrity-Group-Temporal-Key, im Folgenden auch als IGTK bezeichnet, und eine IGTK-Paketnummer, im Folgenden auch als IPN bezeichnet, die mit jeder Verbindung der Mehrzahl von Verbindungen verknüpft sind, in einem Fall, dass ein Managementrahmenschutz aktiviert ist, und einen aktuellen Beacon-Integrity-Group-Temporal-Key, im Folgenden auch als BIGTK bezeichnet, und eine BIGTK-Paketnummer, im Folgenden auch als BIPN bezeichnet, die mit jeder Verbindung der Mehrzahl von Verbindungen verknüpft sind, in einem Fall, dass ein Signalschutz aktiviert ist; und Senden des Verknüpfungs- oder Wiederverknüpfungsantwortrahmens an die Nicht-AP-STA-MLD, wobei das Key-Delivery-Element ein Key-Data-Encapsulation-, im Folgenden auch als KDE bezeichnet, Listenfeld aufweist, das eine Mehrfachverbindungs-GTK-KDE, eine Mehrfachverbindungs-IGTK-KDE und eine Mehrfachverbindungs-BIGTK-KDE aufweist, die mit jeder Verbindung einer oder mehrerer Verbindungen aus der Mehrzahl von Verbindungen verknüpft sind, auf welchen das Key-Delivery-Element gesendet wird.
8. Verfahren gemäß Anspruch 7, wobei die Mehrfachverbindungs-GTK-KDE aufweist: ein Key-Identifier-, im Folgenden auch als ID bezeichnet, Feld, das einen Wert einer GTK-Schlüsselkennung anzeigt, ein Transmit-Feld, das eine Verbindung anzeigt, auf welcher der GTK gesendet wird, ein Link-ID-Feld, das eine Verbindung anzeigt, auf welcher der GTK installiert wird, und ein Key-RSC-Feld, das einen RSC für den GTK, der auf der durch das Link-ID-Feld angezeigten Verbindung installiert wird, aufweist, wobei die GTK-Schlüsselkennung eine MLD-Ebene für die AP-MLD und die Nicht-AP-STA-MLD ist, die eine gleiche Schlüsselkennung unterstützt; und/oder wobei die Mehrfachverbindungs-IGTK-KDE aufweist: ein Key-ID-Feld, das einen Wert einer IGTK-Schlüsselkennung anzeigt, ein Link-ID-Feld, das eine Verbindung anzeigt, auf welcher der IGTK installiert wird, und ein IPN-Feld, das zu einer letzten Paketnummer korrespondiert, die von einem Sender auf der durch das Link-ID-Feld angezeigten Verbindung verwendet wird und die von einem Empfänger als ein Anfangswert für einen Broadcast-Integrity-Protocol-, im Folgenden auch als BIP bezeichnet, Wiederholungszähler für den IGTK verwendet wird, wobei die IGTK-Schlüsselkennung eine MLD-Ebene für die AP-MLD und die Nicht-AP-STA-MLD ist, die eine gleiche Schlüsselkennung unterstützt; und/oder wobei die Mehrfachverbindungs-BIGTK-KDE aufweist: ein Key-ID-Feld, das einen Wert einer BIGTK-Schlüsselkennung anzeigt, ein Link-ID-Feld, das eine Verbindung anzeigt, auf welcher der BIGTK installiert wird, und ein BIPN-Feld, das zu einem BIPN-Wert korrespondiert, der in einem Management-Message-Integrity-Check-, im Folgenden auch als MIC bezeichnet, Element, im Folgenden auch als MME bezeichnet, eines letzten geschützten Signalrahmens auf der durch das Link-ID-Feld angezeigten Verbindung übertragen wird und von einem Empfänger als ein Anfangswert für einen BIP-Wiederholungszähler für den BIGTK verwendet wird, wobei die BIGTK-Schlüsselkennung eine MLD-Ebene für die AP-MLD und die Nicht-AP-STA-MLD ist, die eine gleiche Schlüsselkennung unterstützt.
9. Verfahren gemäß einem der Ansprüche 1 bis 8, wobei das Kommunizieren ein Senden oder Empfangen eines erneut übertragenen Rahmens mit einem Key-ID-Feld in einer Cipher-Block-Chaining-Message-Authentication-Code-Protocol-, im Folgenden auch als CCMP bezeichnet, oder einer Galois/Counter-Mode-Protocol-, im Folgenden auch als GCMP bezeichnet, Kopfzeile des Rahmens umfasst, die einem Key-ID-Feld einer ersten übertragenen MAC-Protokolldateneinheit, im Folgenden auch als MPDU bezeichnet, gleicht.
10. Vorrichtung, aufweisend: einen Sendeempfänger, der eingerichtet ist, über Funk zu kommunizieren; und einen Prozessor, der mit dem Sendeempfänger verbunden und eingerichtet ist, Operationen auszuführen, die umfassen: Ausführen, über den Sendeempfänger, einer Fast-Initial-Link-Setup-, im Folgenden auch als FILS bezeichnet, Prozedur, um Funkkommunikationen zwischen einer Zugangspunkt-, im Folgenden auch als AP bezeichnet, Mehrfachverbindungsvorrichtung, im Folgenden auch als MLD bezeichnet, und einer Nicht-AP-Station-, im Folgenden auch als STA bezeichnet, MLD über eine Mehrzahl von Verbindungen einzurichten; und Kommunizieren, über den Sendeempfänger, über eine oder mehrere Verbindungen der Mehrzahl von Verbindungen nach einem Abschluss der FILS-Prozedur, wobei ein FILS-Discovery-Rahmen, der in der FILS-Prozedur gesendet wird, anzeigt, ob eine Dienstsatzkennung, im Folgenden auch als SSID bezeichnet, der AP-MLD zu einer SSID eines APs einer Mehrzahl von APs in der AP-MLD, die den FILS-Discovery-Rahmen sendet, verschieden ist.
11. Vorrichtung gemäß Anspruch 10, wobei ein Multiple-Links-Presence-Indicator-Unterfeld in einem FILS-Discovery-, im Folgenden auch als FD bezeichnet, Capability-Unterfeld in einem FILS-Discovery-Information-Feld des FILS-Discovery-Rahmens auf 1 festgelegt ist, um anzuzeigen, dass die SSID der AP-MLD zu der SSID des APs der Mehrzahl von APs in der AP-MLD, die den FILS-Discovery-Rahmen sendet, verschieden ist, und wobei in einem Fall, dass das Multiple-Links-Presence-Indicator-Unterfeld auf 1 festgelegt ist, das FILS-Discovery-Information-Feld weiter ein Short-MLD-SSID-Unterfeld aufweist, das eine 4-Oktette kurze SSID der AP-MLD aufweist.
12. Vorrichtung gemäß Anspruch 10 oder 11, wobei der Prozessor in der AP-MLD oder der Nicht-AP-STA-MLD implementiert ist, wobei: wenn in der Nicht-AP-STA-MLD implementiert, bei dem Ausführen der FILS-Prozedur der Prozessor eine Verknüpfungs- oder Wiederverknüpfungsprozedur mit einer höhere-Schicht-Protokoll-, im Folgenden auch als HLP bezeichnet, Kapselung ausführt durch: Konstruieren eines FILS-HLP-Container-Elements, um ein HLP-Paket zu bilden, wobei das FILS-HLP-Container-Element eine Ziel-Medium-Access-Control-, im Folgenden auch als MAC bezeichnet, Adresse, eine Quellen-MAC-Adresse und das HLP-Paket in einem MAC-Dienstdateneinheit, im Folgenden auch als MSDU bezeichnet, Format aufweist, mit der Quellen-MAC-Adresse, die eine MLD-MAC-Adresse der Nicht-AP-STA-MLD aufweist; und Senden des FILS-HLP-Container-Elements in einem Verknüpfungs- oder Wiederverknüpfungsanforderungsrahmen an die AP-MLD, und wenn in der AP-MLD implementiert, bei dem Ausführen der FILS-Prozedur der Prozessor das HLP-Paket empfängt und entkapselt durch: Extrahieren der Ziel-MAC-Adresse, der Quellen-MAC-Adresse und des HLP-Pakets von dem FILS-HLP-Container-Element; Feststellen, ob die extrahierte Quellen-MAC-Adresse mit der MLD-MAC-Adresse der Nicht-AP-STA-MLD übereinstimmt, die mit der Quellen-MAC-Adresse des Verknüpfungs- oder Wiederverknüpfungsanforderungsrahmens verknüpft ist, und als Reaktion auf ein Feststellen, dass die extrahierte Quellen-MAC-Adresse mit der MLD-MAC-Adresse der Nicht-AP-STA-MLD übereinstimmt: Konstruieren eines Rahmens, der das HLP-Paket aufweist; und Zustellen des Rahmens an ein Upstream-Netzwerk oder einen Basisdienstsatz, im Folgenden auch als BSS bezeichnet, oder als Reaktion auf ein Feststellen, dass die extrahierte Quellen-MAC-Adresse nicht mit der MLD-MAC-Adresse der Nicht-AP-STA-MLD übereinstimmt, Verwerfen des FILS-HLP-Container-Elements.
13. Vorrichtung gemäß einem der Ansprüche 10 bis 12, wobei bei dem Ausführen der FILS-Prozedur der Prozessor eine Authentifikationsprozedur mit einem öffentlichen Schlüssel über die Mehrzahl von Verbindungen durch die Mehrzahl von APs in der AP-MLD und durch eine Mehrzahl von STAs in der Nicht-AP-STA-MLD über die Mehrzahl von Verbindungen ausführt, wobei Diffie-Hellman-Werte in der Mehrzahl von APs in der AP-MLD über die Mehrzahl von Verbindungen gemeinsam sind, und wobei Diffie-Hellman-Werte in der Mehrzahl von STAs in der Nicht-AP-STA-MLD über die Mehrzahl von Verbindungen gemeinsam sind.
14. Vorrichtung gemäß einem der Ansprüche 10 bis 13, wobei, wenn in der AP-MLD implementiert, bei dem Ausführen der FILS-Prozedur der Prozessor eine Verknüpfungs- oder Wiederverknüpfungsprozedur ausführt durch: Generieren eines Verknüpfungs- oder Wiederverknüpfungsantwortrahmens durch ein Konstruieren eines Key-Delivery-Elements, das anzeigt: einen aktuellen Group-Temporal-Key, im Folgenden auch als GTK bezeichnet, und einen Key-Receive-Sequence-Counter, im Folgenden auch als RSC bezeichnet, die mit jeder Verbindung der Mehrzahl von Verbindungen verknüpft sind, einen aktuellen Integrity-Group-Temporal-Key, im Folgenden auch als IGTK bezeichnet, und eine IGTK-Paketnummer, im Folgenden auch als IPN bezeichnet, die mit jeder Verbindung der Mehrzahl von Verbindungen verknüpft sind, in einem Fall, dass ein Managementrahmenschutz aktiviert ist, und einen aktuellen Beacon-Integrity-Group-Temporal-Key, im Folgenden auch als BIGTK bezeichnet, und eine BIGTK-Paketnummer, im Folgenden auch als BIPN bezeichnet, die mit jeder Verbindung der Mehrzahl von Verbindungen verknüpft sind, in einem Fall, dass ein Signalschutz aktiviert ist; und Senden des Verknüpfungs- oder Wiederverknüpfungsantwortrahmens an die Nicht-AP-STA-MLD, wobei das Key-Delivery-Element ein Key-Data-Encapsulation-, im Folgenden auch als KDE bezeichnet, Liste-Feld aufweist, das eine Mehrfachverbindungs-GTK-KDE, eine Mehrfachverbindungs-IGTK-KDE und eine Mehrfachverbindungs-BIGTK-KDE aufweist, die mit jeder Verbindung einer oder mehrerer Verbindungen aus der Mehrzahl von Verbindungen verknüpft sind, auf welchen das Key-Delivery-Element gesendet wird.

Images