otRadioFrame

ACK-Sicherheitsframe-Zähler (gilt, wenn mAckedWithSecEnhAck festgelegt ist)

Index des ACK-Sicherheitsschlüssels (anwendbar, wenn mAckedWithSecEnhAck festgelegt ist).

Gibt an, ob dieser Frame mit der Einstellung „Frame ausstehend“ bestätigt wurde.

Gibt an, ob dieser Frame mit gesichertem Enhancement ACK bestätigt wurde.

Das für die AES-CCM-Framesicherheit verwendete Schlüsselmaterial.

Kanal, der zum Übertragen/Empfangen des Frames verwendet wird.

Geben Sie "true" an, wenn der CSL-Header IE vorhanden ist.

Setzen Sie den Wert auf „true“, um CSMA-CA für dieses Paket zu aktivieren, andernfalls auf „false“.

Der Zeiger auf die Header-IE(s)-Informationen.

Die Zusammenführung von Sende- und Empfangsinformationen für einen Funkrahmen.

Gibt an, ob der Frame erneut übertragen wurde oder nicht.

Gibt an, ob der Frame-Zähler und CSL-IEs im Header ordnungsgemäß aktualisiert werden.

Wenn die Plattformebene keine OT_RADIO_CAPS_TRANSMIT_SEC-Funktionen bietet, kann dieses Flag ignoriert werden.

Wenn die Plattform OT_RADIO_CAPS_TRANSMIT_SEC-Funktionen bietet, wird erwartet, dass sie die TX-Sicherheitsverarbeitung und die Zuweisung des Frame-Zählers abwickelt. In diesem Fall ist das folgende Verhalten zu erwarten:

Wenn mIsHeaderUpdated festgelegt ist, bedeutet dies, dass OpenThread Core bereits den Frame-Zähler und CSL-IEs (bei aktivierter Sicherheit) im vorbereiteten Frame festgelegt hat. Es wird sichergestellt, dass der Zähler mit dem Zählerwert der vorherigen Versuche desselben Frames übereinstimmt. Die Plattform sollte den Frame-Zähler weder zuweisen noch ändern, aber möglicherweise muss, abhängig vom mIsSecurityProcessed-Flag, dennoch eine Sicherheitsverarbeitung durchgeführt werden.

Wenn mIsHeaderUpdated nicht festgelegt ist, werden der Frame-Zähler und der Schlüssel-CSL IE nicht im Frame vom OpenThread-Core festgelegt, und es liegt in der Verantwortung der Funkplattform, sie zuzuweisen. Die Plattform muss den Frame-Header aktualisieren (Zähler- und CSL IE-Werte zuweisen), bevor der Frame over-the-air gesendet wird. Wenn die Übertragung jedoch abgebrochen wird und der Frame nie over-the-air gesendet wird (z. B. ein Fehler beim Kanalzugriff), kann die Plattform den Header möglicherweise nicht aktualisieren. Wenn die Plattform den Header aktualisiert, muss auch dieses Flag festgelegt werden, bevor der Frame vom otPlatRadioTxDone()-Callback zurückgegeben wird.

True, wenn der SubMac die AES-Verarbeitung dieses Frames überspringen soll.

Länge der PSDU.

Linkqualitätsanzeige für empfangene Frames.

Maximale Anzahl von Backoff-Versuchen, bevor der CCA-Fehler deklariert wird.

Maximal zulässige Anzahl von Wiederholungen nach einem Übertragungsfehler.

Die PSDU.

Funklinktyp – sollte vom Radiotreiber ignoriert werden.

Anzeige der empfangenen Signalstärke in dBm für empfangene Frames.

Der RX-Kanal nach Frame TX ist abgeschlossen (nach allen Frame-Wiederholungen – Bestätigung empfangen, Zeitüberschreitung oder Abbruch).

Radioplattformen können dies ignorieren. Der OT-Stack sorgt dafür, dass otPlatRadioReceive() mit dem gewünschten RX-Kanal aufgerufen wird, nachdem ein Frame TX abgeschlossen und im otPlatRadioTxDone()-Callback signalisiert wurde. Radioplattformen, die OT_RADIO_CAPS_TRANSMIT_RETRIES nicht bereitstellen, müssen dies immer ignorieren.

Dies ist für Situationen gedacht, in denen es zu Verzögerungen bei Interaktionen zwischen dem OT-Stack und der Funkschnittstelle kommen kann. Ein Beispiel hierfür wird in der RCP-/Host-Architektur verwendet, damit RCP schneller zum PAN-Kanal wechselt. Dies kann insbesondere bei der CSL für ein schläfriges Kind hilfreich sein, wenn es einen anderen Kanal als den PAN-Kanal für CSL verwendet. Nach Frame tx soll der Funk-/RCP-Kanal schnell zum PAN-Kanal zurückwechseln, um sicherzustellen, dass das übergeordnete Element tx des untergeordneten Elements anschließend nicht verpasst, z.B. wenn das Kind auf den zuvor übertragenen CSL-Frame vom übergeordneten CSL-Kanal antwortet, der den PAN-Kanal verwendet, während der Funk noch auf dem CSL-Kanal bleibt.

Der Wechsel zum RX-Kanal MUSS geschehen, nachdem der Frame TX vollständig abgeschlossen ist, d.h. nach allen Wiederholungen und wenn die Bestätigung empfangen wurde (wenn das Flag „Ack Request“ auf den TX-Frame gesetzt ist) oder das Bestätigungs-Timeout. Die Bestätigung wird auf dem Kanal erwartet, über den der Frame gesendet wird.

Struktur, die Funkframe-Empfangsinformationen darstellt.

Die Zeit der lokalen Radiouhr in Mikrosekunden, als das SFD-Ende bei der lokalen Antenne vorhanden war.

Die Verzögerungszeit in Mikrosekunden für diese Übertragung, auf die mTxDelayBaseTime verweist.

Hinweis: mTxDelayBaseTime + mTxDelay MÜSSEN auf den Zeitpunkt verweisen, an dem das Ende von SFD bei der lokalen Antenne in Bezug auf die lokale Funkuhr vorhanden ist.

Die Basiszeit in Mikrosekunden für geplante Übertragungen bezogen auf die lokale Radiouhr, siehe otPlatRadioGetNow und mTxDelay.

Struktur, die Funkframe-Übertragungsinformationen darstellt.