mikrocontroller.net

Forum: HF, Funk und Felder 802.15.4 / ZigBee


Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich hätte mal eine Frage zu dem Standard 802.15.4, und zwar weiß jemand 
wie das mit dem slotted CSMA/CA bzw. mit dem unslotted CSMA/CA (mit oder 
ohne Beacon) funktioniert? Ich meine wie läuft das ab mit dem 
Verbindungsaufbau, und vor allem was ist schneller und wie oft macht ein 
System diese Konfiguration.
Ich weiß man könnte meinen dass man das doch einfach googln kann, jedoch 
gibt es dazu keine exakten Angaben, zumindest nicht auf den Seiten wo 
ich war, und die Bücher darüber sind alle sehr teuer. Vielleicht kann 
mir jemand von Euch weiter helfen!!!

Sebastian

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Slotted CSMA/CA ist ja nur ein Teil des Ganzen; der übergeordnete
Begriff lauted beacon-enabled network, das Gegenstück non beacon-
enabled network.  Vielleicht findest du ja dazu eher was.  (Beim
beacon-enabled network benutzt man slotted CSMA/CA, das andere
arbeitet unslotted.)

Die Idee hinter einem beacon-enabled network ist, dass man einen
Zweirichtungs-Datenverkehr mit geringem Energieverbrauch in den
Knoten dadurch organisieren kann, dass alle Endgeräte synchronisiert
aufwachen.  Dabei hören sie den "beacon" (deutsch: Bake, im Sinne
einer Funkbake), benutzen den Start des beacon als Synchronisations-
zeit fürs nächste Aufwachen, und am Ende des beaoncs folgt eine
Liste mit Geräten, für die der Koordinator (oder Router) Daten
vorliegen hat.  Wenn ein Endgerät sich nicht in dieser Liste wieder
findet, kann es sofort wieder schlafen gehen, andernfalls muss es
die Daten vom Koordinator per data request abholen gehen.  Das Ganze
nennt sich Indirekt-Datentransfer, und das ist die bevorzugte Form,
Daten vom Koordinator zu den Endgeräten zu transportieren.  Daten
vom Endgerät zum Koordinator werden direkt versandt, wobei der
Koordinator während des aktiven Teils des sogenannten Superframes
seinen Empfänger eingeschaltet hält.  (Der Superframe ist die
zeitliche Struktur von einem beacon bis zum nächsten.)

Der Dreh- und Angelpunkt hierbei ist, dass die entsprechenden Geräte
rein durch das Einschalten des Empfängers ziemlich viel Strom
verbrauchen, sodass man die Einschaltzeit minimieren möchte.

Ein Router ist Koordinator für seine Endgeräte und ist selbst wiederum
Endgerät gegenüber seinem Koordinator.  Router müssen ihre beiden
Superframes verschachteln, wobei sie sinnvollerweise den aktiven
Teil ihres eigenen Superframes (zu ihren Endgeräten hin) so legen,
dass er vollständig im inaktiven Teil des übergeordneten Superframes
liegt.

Der aktive Teil des Superframes wird in die CAP (contention access
period) und CFP (contention free period, vorbelegte Zeitschlitze
für "granted time slots" [GTS]) unterteilt, wobei die Gesamtlänge
durch die superframe order angegeben wird.  Der zeitliche Abstand
zwischen zwei beacons wird als beacon order bezeichnet.

Insgesamt ist das Konzept noch nicht sehr stark in Benutzung.  Fast
alle, die IEEE 802.15.4 implementieren, implementieren nur den
non beacon-enabled Modus.

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank Jörg für deine umfangreiche und kompetente Antwort, das 
hilft mir schon sehr weiter!!!!!!

Eine Frage hab ich noch, woher weißt du das alles, hast du dazu 
Literatur die du empfehlen kannst?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sebastian wrote:

> Eine Frage hab ich noch, woher weißt du das alles, hast du dazu
> Literatur die du empfehlen kannst?

Den IEEE-802.15.4-Standard.:-)

Naja, ich habe mal vor einiger Zeit einen MAC dafür (mit-)geschrieben.

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bei Elektroniknet.de 
(http://www.stzedn.de/stzedn/files/stz_zigbee_elekt...) 
habe ich folgendes gelesen:

"Der PAN-Koordinator versendet Beacons zur Synchronisation
und gibt damit die Begrenzung eines Superframes
für alle PAN-Stationen verbindlich vor. Die Basiszeit
für den slotted CSMA/CA-Betrieb beträgt 15 ms."

Wie ist das mit den 15ms, braucht die eine Sender - Empfänger 
Konstellation immer, oder ist das eine einmalige Zeit die nur beim 
Ersten Verbindungsaufbau benötigt wird?
Meiner Meinung nach kann das nicht sein, weil von vielen 
Funkmodulherstellern (IEEE 802.15.4) erzählt wird, dass eine Übertragung 
von 128Mbyte innerhalb von 1,5ms geschieht. Ist das dann die Zeit 
nachdem die Verbindung hergestellt worden ist?

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jörg

Vielleicht sollte ich noch erwähnen worum es mir geht, und zwar möchte 
ich gerne in Erfahrung bringen, wie lange 2 oder mehrer Systeme brauchen 
sende bzw. empfangsbereit zu sein, wenn die Funkmodule zum aller ersten 
mal in Reichweite kommen.

Ja der Standard.... 600Seiten +X :-(

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sebastian wrote:

> "Der PAN-Koordinator versendet Beacons zur Synchronisation
> und gibt damit die Begrenzung eines Superframes
> für alle PAN-Stationen verbindlich vor.

Diese Aussage trifft auf jeden Koordinator zu, nicht nur auf den
PAN-Koordinator (der gewissermaßen die Wurzel allen Übels, äh, der
Meister der Meister in einem PAN ist).  Aus Layer-3-Sicht stellen
die Koordinatoren, die nicht PAN-Koordinator sind, einen Router
dar.  (Der MAC als Layer 2 kennt aber kein Routing, daher kennt
er auch den Begriff Router nicht.)

> Die Basiszeit
> für den slotted CSMA/CA-Betrieb beträgt 15 ms."
>
> Wie ist das mit den 15ms,

(Der exakte Wert ist übrigens 15,36 ms (16 · 60 · 16 µs).)

Das ist das kürzeste Superframe-Intervall, für eine beacon order
von 0.  Für größere beacon orders wird das 2^N mal so groß, und
da die beacon order bis 14 gehen kann (15 ist der Wert für ein
non beacon-enabled network), kann man Superframes bis maximal
251 s Länge organisieren.

Das ist der Abstand zwischen den Beacons, und damit auch die
mögliche Latenz (auf MAC-Ebene, also ohne mögliches Routing auf
NWK-Ebene!) in der Richtung Koordinator->Endgerät.

> Funkmodulherstellern (IEEE 802.15.4) erzählt wird, dass eine Übertragung
> von 128Mbyte innerhalb von 1,5ms geschieht.

Das wäre schneller als IEEE 802.11. :-)

Was die 1,5 ms sein sollen, ist mir gar nicht klar.  Ein Rahmen
maximaler Größe hat 127 Octets PHY-Nutzlast (PHY service data unit,
PDU), dazu kommen noch 1 Octet PHY-Header (das Längenbyte) sowie
5 Octets für die Synchronisation (Synchronization header, SHR).
Bei OQPSK 250, mit der IEEE 802.15.4 auf 2,4 GHz moduliert, dauert
die Übertragung eines derartigen Rahmens 4,3 ms.  Hinzu kommt noch
die Zeit für das CSMA/CA, die ja aus einem random backoff einerseits
besteht, andererseits aus zwei CCA-Messungen (bei slotted CSMA/CA,
unslotted ist es nur eine) von je 128 µs Dauer, die an backoff slot
boundaries zu je 20 Symbolen = 320 µs ausgerichtet werden müssen,
genau wie die Datenübertragung selbst.  Selbst bei komplett freiem
Kanal und völlig ohne random backoff brauchst du also vor jeder
Übertragung noch mindestens 640 µs Vorlauf.  Mit random backoff
vergrößert sich das (beim Standardwert von minBE = 2) für den
freien Kanal auf bis zu 2,56 ms.  [Ist alles mehr oder weniger aus
dem Kopf, ich hoffe, ich habe mich nicht verrechnet.]  Weiterhin
brauchst du noch 192 µs (möglicherweise mit einer zusätzlichen
Toleranz von -0 +320 µs, falls jemand partout slotted ACKs machen
will), bis das acknowledgment rein ist.

Von einem belegten Kanal und/oder Retries reden wir da noch gar
nicht.

> Vielleicht sollte ich noch erwähnen worum es mir geht, und zwar möchte
> ich gerne in Erfahrung bringen, wie lange 2 oder mehrer Systeme brauchen
> sende bzw. empfangsbereit zu sein, wenn die Funkmodule zum aller ersten
> mal in Reichweite kommen.

Das dürfte in einem beacon-enabled network wohl in typisch circa
drei Superframe-Intervallen liegen.  Den ersten beacon braucht man,
um überhaupt erst einmal herauszufinden, was ,,alles los ist'', d.h.
einen active oder passive scan.  Danach kennt man die Parameter
seines Koordinators und kann auf den nächsten beacon warten.  Direkt
nach diesem beacon ist der aktive Teil des Superframes des gewünsch-
ten Koordinators, und in diesem kann man ihm einen association
request senden.  Über den muss er befinden, und da er die Antwort
indirekt versenden muss, braucht man eigentlich den nächsten beacon,
um die Antwort zu erhalten.  Falls der Koordinator sich sehr schnell
entscheidet, könnte man innerhalb der CAP noch ,auf Verdacht' (also
ohne eine entsprechende Ankündigung in einem beacon gehört zu haben)
den data request senden, mit dem das association confirm abgeholt
werden soll.  Eine solche Vorgehensweise könnte sich bei einer
sehr großen beacon order lohnen (s. o., ansonsten kann es ja bis
zu 251 s dauern, bevor der nächste beacon übertragen wird).

> Ja der Standard.... 600Seiten +X :-(

Für dich ist ja erstmal nur der MAC-Teil interessant, und dort vor
allem die functional description (Abschnitt 7.5).  Wenn du dich
ernsthaft mit dem Thema befassen willst/sollst/musst, wirst du nicht
umhin kommen, das zu verstehen.

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1000 Dank Jörg. Ich werde jetzt mal versuchen, dass alles so 
nachzurechnen und zu verstehen, wie du mir das wieder einmal sehr sehr 
gut erklärt hast. Ich hoffe ich kann wieder auf deine gute Unterstützung 
hoffen, wenn ich bestimmt bald wieder Fragen haben werde, diese jedoch 
zum jetzigen Zeitpunkt noch nicht ganz verbalisieren kann:-)

Dann werd ich mir wohl wirklich den Standard geben müssen.... hilft 
nichts.
Danke nochmal!!!!!

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt hab ich doch schon wieder eine Frage, und zwar bist du in dem 
vorletzten Absatz, wo du mir erklärt hast, wie lange der 
Verbindungsaufbau dauert, auf ein beacon-enabled - System eingegangen, 
könntest du mir noch kurz sagen, wie das bei einem non beacon enabled - 
System ist. D.h. wie lange dort dieser Erste - Verbindungsaufbau dauern 
würde bzw. wie dieser dort funktioniert?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sebastian wrote:

> könntest du mir noch kurz sagen, wie das bei einem non beacon enabled -
> System ist. D.h. wie lange dort dieser Erste - Verbindungsaufbau dauern
> würde bzw. wie dieser dort funktioniert?

Dort kannst du sofort loslegen, weil der Koordinator ja immer hören
(und daher Strom verbrauchen!) muss.  Damit hast du deine Scanzeit
(die ist einstellbar und richtet sich außerdem noch danach, wie viele
Kanäle du scannen willst), danach kannst du den association request
losschicken.  Früher waren mal ~ 450 ms gefordert, nach denen man
die association response abholen gehen sollte, in der Praxis wird
das aber auch schon eher machbar sein.  Man kann den Algorithmus
ja so implementieren, dass man das ggf. mehrere Male probiert, um
die Latenz herunter zu drücken.

Alternativ geht in beiden Fällen so eine ,,Assoziierung nach
Absprache'': man geht davon aus, dass der Koordinator einen bereits
kennt und tut so, als wäre man früher mal assoziiert gewesen, hätte
aber die Verbindung zum Koordinator verloren.  Dann schickt man einen
orphan scan, in dessen Ergebnis einem der Koordinator die Kenndaten
(insbesondere die kurze Adresse) neu schickt.  Danach gilt man als
assoziiert.  Der Trick ist nun, dass (wenn sich beide schon vorher
kannten mit ihren langen Adressen) dem Ganzen eigentlich gar nicht
zwingend eine tatsächliche Assoziierung voraus gegangen sein muss:
nach einem erfolgreichen orphan scan gilt man als assoziiert. ;-)
ZigBee nutzt sich dies in ihrem sogenannten `direct join' aus.

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jörg

Woher weißt du eigentlich wie lange die Offset - QPSK für 134 Bytes 
dauert, sind das Erfahrungswerte oder kann man das irgendwie berechnen 
(die selbe Frage habe ich bezüglich der CSMA\CA bzw. CSMA\CCA)?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei O-QPSK wird ein Octet in zwei Symbolen codiert, und bei O-QPSK 250
auf 2,4 GHz ist die Symbolperiode mit 16 µs definiert.  Damit braucht
ein Octet 32 µs.

Auch für alle anderen Werte findest du die Zeitangaben im Standard
(wo sonst), allerdings bauen die Zahlen sehr oft aufeinander auf.
Alle Timing-Werte in der MAC-Schicht werden übrigens in Symbolen
angegeben, d. h. um sie auf eine Echtzeit umzurechnen, musst du sie
mit 16 µs multiplizieren.

Mal ein Beispiel für die Verkettung von Begriffen: die minimale
beacon period, die ich oben mit 15,36 ms benannt habe.  Sie setzt
sich zusammen aus:

. der Symbollänge von 16 µs ergibt sich aus, den Parametern in
  "6.5.2.4 O-QPSK modulation" (2 Mchips/s mit 32 chips per symbol)

. die 16 · 60 ist die Konstante aBaseSuperframeDuration (7.4.1
  MAC constants), die wiederum verweist auf

. die Konstante aBaseSlotDuration von 20

. die Konstante aNumSuperframeSlots von 16

An anderen Stellen stehen in der Kette auch Variablen (sogenannte
PIB attributes) anstelle von Konstanten.

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DANKE nochmal, hast mir wirklich sehr weitergeholfen!!!

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, der Timeout ist gerade abgelaufen, dass ich meinen Beitrag
noch editieren darf:

Jörg Wunsch wrote:

> . die Konstante aBaseSlotDuration von 20

Die ist natürlich gleich 60.  Habe ich auf die Schnelle mit
aUnitBackoffPeriod verwechselt.  Damit enthält letztlich ein "base
slot" drei "unit backoff periods".  Damit das auch richtig konfus
wird: aUnitBackoffPeriod bildet "backoff slots", die man nicht mit
den "superframe slots" verwechseln sollte, deren es ihrererseits
16 Stück in jedem Superframe gibt.  Über diese Zweifachbenutzung
des Begriffs Slot bin ich seinerzeit eine ganze Weile gestolpert.

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jörg Wunsch

Du hast mir gestern erklärt dass bei O-QPSK ein Octet in zwei Symbole 
codiert wird. Jetzt habe ich heute aber schon an mehreren Stellen 
gelesen, dass O-QPSK mit 2 Bit pro Modulationssymbol arbeitet, das 
wiederspricht sich doch oder?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sebastian wrote:

> Du hast mir gestern erklärt dass bei O-QPSK ein Octet in zwei Symbole
> codiert wird. Jetzt habe ich heute aber schon an mehreren Stellen
> gelesen, dass O-QPSK mit 2 Bit pro Modulationssymbol arbeitet, das
> wiederspricht sich doch oder?

Ja, das würde sich widersprechen.  Ich glaube, das sind zwei unter-
schiedliche Symbols hier, das eine beschreibt die Symbols aus der
Sicht der PHY-Schicht, und die enthalten je 4 Bit der Nutzdaten.
Diese 4 Bits werden über ein symbol-to-chip mapping (Tabelle 24)
ins Pseudo-Zufalls-Bitfolgen umgewandelt, die sogenannten Chips.
Aus diesen Chips modulieren jeweils die geradzahligen Bits die
Phase des I-Kanals und die ungeradzahligen Bits die Phase des
Q-Kanals.  Ein echtes `symbol' in dem Sinne gibt es ja bei O-QPSK
(im Gegensatz zur QPSK) nicht, da beide Kanäle jeweils geschachtelt
ihre Phasenumschaltung vornehmen.  (Für diese Schachtelung steht
das Wort `offset' im Namen.)

Diese geradzahligen und ungeradzahligen Bits der Chips sind dann
deine beiden Bits der O-QPSK.

Disclaimer: ich bin alles andere als der große Auskenner in den
tieferen Details dieser Modulationsverfahren.  Das ist nur angelesen
(QPSK ist im englischen Wikipedia ganz gut erklärt) und mit meinen
Worten wiedergegeben, wie ich es verstanden habe.

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke!
Ich hab schon irgendwie vermutet dass es sich hierbei um zwei 
voneinander unhabhängigen Angaben handelt. Aber da ich jetzt die 
Bestätigung von dir erhalten haben bin ich ja beruhigt:-)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Btw., meine Angaben über Kapitel- und Tabellennummern beziehen sich
jeweils auf die 2006er Version des Standards.

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jörg

Ich habe im Internet einen sogenannten MeshDecoder 
(http://www.brandt-data.de/zigbee/zigbee.html) gefunden. Momentan nutze 
ich nämlich nur 2 Funkmodule, dass sollen im Laufe der Zeit aber 
vielleicht auch mal mehr werden. Hast du Erfahrung ob diese Dinger was 
taugen? Ich mein die sind ja schon richtig teuer. Was dieser Decoder 
können sollte, wäre auch von anfang an, also wenn die Funkmodule das 
erste Bit übertragen, alles zu protokollieren, und mir genau sagen was 
da gerade übertragen worden ist.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sebastian wrote:

> Ich habe im Internet einen sogenannten MeshDecoder
> (http://www.brandt-data.de/zigbee/zigbee.html) gefunden. Momentan nutze
> ich nämlich nur 2 Funkmodule, dass sollen im Laufe der Zeit aber
> vielleicht auch mal mehr werden. Hast du Erfahrung ob diese Dinger was
> taugen?

Nö, habe ich nicht.

Solange du nicht ZigBee machen willst, brauchst du das eigentlich
nicht.  Einen einfachen Sniffer für IEEE 802.15.4, der mit Wireshark
zusammen spielt (das seit Version 1.0 das Protokoll IEEE 802.15.4
aus der Dose raus dekodieren kann), findest du auch beim µracoli-
Projekt.

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das hört sich doch sehr gut an.
Könntest du mir das evtl. etwas genauer beschreiben. Das Wireshark - 
Programm gibts ja als freeware, und was hat es mit dem µracoli - Projekt 
auf sich?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
google is your friend...

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
:-)
gut, hast mir eh schon sehr viel geholfen. Und ich bin mir sicher ich 
werde bald wieder Fragen haben:-)

Autor: Andreas F. (andilein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
..weiß jemand wo ich den aktuellen IEEE 802.15.4 Standard downloaden 
kann?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas F. schrieb:
> ..weiß jemand wo ich den aktuellen IEEE 802.15.4 Standard downloaden
> kann?

IEEE 802.15.4-2006 in Gugel eintippen ->
Wikipedia-Link -> ganz unten ->
Link auf das PDF des Standards.

Autor: Andreas F. (andilein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
danke für deinen tipp, aber gibt es keine aktuellere version davon?

Autor: A. W. (uracolix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die 2006er ist die (anno 2009) aktuelle Version. Das ist auch sinnvoll 
so, denn sonst waeren es ja keine Standards sondern Service-Packs.

Es gibt zusaetzliche Erweiterungen, die in der Regel einen 
Schaltkreis-Anwender aber erst interessieren, wenn es den entsprechenden 
Schaltkreis dazu gibt (z.B. 802.15.4c-2009, Chinese WPAN und AT86RF212).

Autor: Christian B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich habe ebenfalls eine Frage bezüglich des IEEE 802.15.4 Standards. Die 
Anzahl der Teilnehmer innerhalb eines Netzwerks, ist durch die 16 Bit 
Kurzadresse auf theoretisch 65535 Teilnehmer begrenzt. Aber in der 
Realität vermutlich kaum zu realisieren.

Wie viele Endgeräte können in einer Stern-Topologie mit einem 
Koordinator verbunden sein, wenn alle im Zyklus von 1 bis 2 Sekunden 4 
Byte an Daten  übertragen? Sind im 868 MHz Frequenzband weniger 
Teilnehmer möglich als im 2,4 GHz Band, da nur ein Kanal genutzt werden 
kann?

Christian

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian B. schrieb:

> Wie viele Endgeräte können in einer Stern-Topologie mit einem
> Koordinator verbunden sein, wenn alle im Zyklus von 1 bis 2 Sekunden 4
> Byte an Daten  übertragen?

Die 4 Byte machen's nicht fett, der Overhead durch die Adressierung
ist schlimmer.  Du hast halt mit dem CSMA-CA den typischen Ethernet-
Effekt: die Stochastik funktioniert bis zu einem bestimmten Punkt
ganz gut, aber dann knickt der Gesamtdurchsatz ab.

> Sind im 868 MHz Frequenzband weniger
> Teilnehmer möglich als im 2,4 GHz Band, da nur ein Kanal genutzt werden
> kann?

Nun, insbesondere hast du, wenn du dich auf BPSK-20 (das war bei
802.15.4-2003 die einzige Modulationsart) beschränken musst eine
deutlich geringere Datenrate.  Wenn du OQPSK-100 (optionale Erweiterung
im 802.15.4-2006) machen kannst, ist der Unterschied nicht mehr so
krass.

Falls du in einem Land mit erweitertem SRD-Band arbeitest, kannst du
ggf. noch weitere Kanäle außer dem standardisierten einen benutzen.
In der BRD beispielsweise könntest du noch 5 Kanäle von 865
bis 868 MHz nutzen, die genauso je 600 kHz breit sind (das wäre im
direkten Anschluss unterhalb des ,offiziellen').  Dort ist allerdings
der duty cycle auf 0,1 % (statt 1 %) limitiert, es sei denn, du
benutzt statt CCA als Zugriffsverfahren LBT (dann bist du aber nicht
strikt 802.15.4-konform).

Normalerweise arbeiten 802.15.4-Netze allerdings ohnehin nur auf
einer einzelnen Frequenz.

Autor: Christian B (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die ausführliche und schnelle Antwort.
Mit der Modulationsart und den daraus resultierenden Unterschieden habe 
ich verstanden. Wie ist das mit dem von dir angesprochenen "bestimmten 
Punkt"?

Jörg Wunsch schrieb:
> die Stochastik funktioniert bis zu einem bestimmten Punkt
> ganz gut, aber dann knickt der Gesamtdurchsatz ab.


Kann man grob abschätzen,wann dieser Punkt erreicht ist?

Wenn z.B. innerhalb einer Sekunde 50 Teilnehmer ihre Daten übertragen 
müssen, und jede Übertragung 10ms dauert, setzt sich die Sekunde aus 500 
ms Datenübertragung und 500 ms Wettbewerb um den freien Kanal (nach dem 
CSMA-CA Verfahren) zusammen.
Das bedeutet 50% der Zykluszeit ist für den Wettbewerb reserviert und 
gewährleistet die Datenübertragung aller Teilnehmer zu x%.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian B schrieb:

> Das bedeutet 50% der Zykluszeit ist für den Wettbewerb reserviert und
> gewährleistet die Datenübertragung aller Teilnehmer zu x%.

Ich denke, damit kommst du einigermaßen um den Ring.  Viel mehr
sollte es aber nicht werden.

Nein, eine konkrete Untersuchung mit zugehörigen Daten habe ich
gerade nicht zur Hand (und ich habe auch nicht so viele Knoten,
dass ich es selbst testen könnte ;-).

Autor: Christian B (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe mich ein wenig in den BitCloud-Stack von Atmel(meshnetics) 
eingelesen. Dort wird beschrieben, dass alle Teilnehmer eines Netzwerks 
sich mit einer 64-Bit "extended PAN ID" beim Koordinator anmelden. Nach 
bzw während der erfolgreichen Anmeldung, weist der Koordinator dem 
Teilnehmer eine 16-Bit PAN ID zu, die für den weiteren Datenaustausch 
verwendet wird.

Ist diese "extended PAN ID" im Zigbee Protokoll vorgesehen? In dem 
Adressfeld des MAC Header (IEEE 802.15.4 Standards, Kapitel 7.2.1) ist 
nur eine 16-Bit PAN ID für Sender und Empfänger beschrieben.

zum Beacon Enable Modus schrieb

Jörg Wunsch (Datum: 30.03.2009 13:25):
> Insgesamt ist das Konzept noch nicht sehr stark in Benutzung.  Fast
> alle, die IEEE 802.15.4 implementieren, implementieren nur den
> non beacon-enabled Modus.

Gibt es einen Zigbee-Stack oder  IEEE802.15.4-Stack, indem der Beacon 
Enable Modus implementiert ist?

Der BitCoud-Stack unterstützt nur den Non-Beacon-Enable Modus.

Autor: A. W. (uracolix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du PAN-ID mit Adresse tauschst, dann ist deine Beschreibung ok.
Es gibt drei Adress-Elemente bei 15.4 & Friends:

 - Der PAN-ID, die Netzwerkkennung oder Netzwerkadresse ist immer
   16 Bit.
 - Die 64-Bit-Adresse ist vergleichbar mit einer MAC-Adresse,
   die jeder Knoten in seinem EEPROM oder anderen
   nichtflüchtigen Speicher hat.
 - Die 16-Bit-Adresse wird vom Koordinator dem sich anmeldenden
   Gerät zugeteilt.

Das andere ist ok, Anmeldung eines Devices mit 64-Bit-Adresse
und Zuteilung einer 16-Bit-Adresse durch den Koordinator.

> Gibt es einen Zigbee-Stack oder  IEEE802.15.4-Stack, indem der Beacon
> Enable Modus implementiert ist?

Ich kenne auch keinen. Wenn ein Software-Entwickler bei diesem Kapitel
des Standards ankommt, klappt er reflexmäßig ganz schnell den Standard 
wieder zu.

Du brauchst ein BEN auch nur, wenn du Daten streamen willst, also
wirklich equidistante zeitliche Abstände für deine Datenpakete
erforderlich sind.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian B schrieb:

> Gibt es einen Zigbee-Stack oder  IEEE802.15.4-Stack, indem der Beacon
> Enable Modus implementiert ist?

Ja: der Atmel-IEEE-802.15.4-MAC kann beacon enabled arbeiten, aber
eben nur Layer 1 + 2 (PHY + MAC), kein NWK.

Autor: Christian B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Axel

Ich meine nicht die 64-Bit Adresse. Beim BitCloud Stack wird zusätzlich 
eine extended PAN ID verwendet, die während oder nach dem anmelden vom 
Koordinator durch ein 16-Bit PAN ID ersetzt wird. (Siehe BitCloud User 
Guide Seite 5-2, letztes Drittel)

www.atmel.com/dyn/resources/prod_documents/doc8199.pdf

Auf Grund deiner Beschreibung nehme ich an, dass die extended PAN ID 
nichts mit dem IEEE 802.15.4 oder Zigbee Standard zu tun hat, sondern 
eine Lösung der BitCloud Stack Entwickler ist. Ist das tatsächlich so?

@ Jörg

Mir wurde geraten als Anfänger besser den BitCloud Stack zu verwenden, 
weil beim IEEE 802.15.4-MAC noch irgend etwas angepasst werden müsste. 
Ich möchte mit den Raven Boards (2,4 GHz) und den ATZB-900-B0 (868 MHz) 
arbeiten, um auch Aussagen über Unterschiede der beiden Frequenzen 
treffen zu können. Kannst du zu dem Anpassungsaufwand was sagen?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian B. schrieb:

> Auf Grund deiner Beschreibung nehme ich an, dass die extended PAN ID
> nichts mit dem IEEE 802.15.4 oder Zigbee Standard zu tun hat, sondern
> eine Lösung der BitCloud Stack Entwickler ist. Ist das tatsächlich so?

Klingt so.  Ich kann mir auch so ungefähr vorstellen, welches Problem
damit gelöst werden soll.  Irgendwie muss man ja als Netzwerkteilnehmer
bei einem Funknetz eine Idee haben, wer seine Partner sind.  Die PAN-ID
gemäß 802.15.4 leidet hierbei aber darunter, dass ihr Adressraum mit
nur 16 bit ziemlich limitiert ist, sodass Konflikte programmiert sind.
Daher beschreibt der Standard zwar die Idee einer `PAN ID conflict
resolution', hält sich dann aber vornehm zurück mit Details, indem
er diese als implementierungsabhängig offen lässt...  Damit weiß ich
aber als device nicht, für welche PAN-ID ich mich denn nach einem
Scan nun überhaupt entscheiden soll.

Nun wird Bitcloud wohl eine 64-bit-PAN-ID dafür benutzen, eine
eindeutige Zuordnung aller Schäfchen zu organisieren, die zu einem
Netz gehören möchten.

> Mir wurde geraten als Anfänger besser den BitCloud Stack zu verwenden,
> weil beim IEEE 802.15.4-MAC noch irgend etwas angepasst werden müsste.

Es ist die Frage, was du denn tun willst.  Bitcloud implementiert
einen eigenen 802.15.4-MAC (also layer 2), darüber dann NWK (layer 3)
und sogenannte Applikationsprofile (layer 4...7) gemäß ZigBee.  Wenn
du layer 3...7 in dieser Form brauchst, dann bleibt dir natürlich
nicht viel anderes übrig, als das zu benutzen.

Außerdem hattest du ja lediglich gefragt, ob es denn überhaupt
jemanden gäbe, der beacon-enabled networks implementiert hat, und
du hast dabei nach "ZigBee-Stack oder IEEE-802.15.4-Stack" gefragt.

> Ich möchte mit den Raven Boards (2,4 GHz) und den ATZB-900-B0 (868 MHz)
> arbeiten, um auch Aussagen über Unterschiede der beiden Frequenzen
> treffen zu können. Kannst du zu dem Anpassungsaufwand was sagen?

Nein, aber du vergleichst Äpfel mit Birnen.  Die Raven-Boards sind
reine Demo-Boards, für Performance-Aussagen sind die weniger geeignet.
Wenn schon, dann vergleiche bitte die jeweiligen Zigbit-Module
miteinander.

Autor: Christian B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Es ist die Frage, was du denn tun willst.

Zunächst geht es mir darum den Markt und die Technik kennen zu lernen 
und abschätzen zu können für welche Anwendung welches Produkt geeignet 
ist.

Habe aber auch eine konkrete Anwendung. Wie oben beschrieben möchte ich 
eine Stern Topologie mit ca. 20 Teilnehmern aufbauen. Dabei sollen die 
Endknoten über Batterie versorgt werden und im Zyklus von 1 bis 2 
Sekunden Daten von bis zu 4 Byte an den Koordinator senden. Diese Daten 
müssen aber nur gesendet werden, wenn vorher vom Koordinator eine 
Freigabe erteilt wurde.
Mit der Freigabe erfolgt auch eine optische Rückmeldung an die 
Endknoten.


Nach meiner bisherigen Einschätzung sind zwei Varianten sinnvoll:

- Beacon Enable Modus, wobei alle Teilnehmer gleichzeitig aus dem Low 
Power Modus aufwachen, Freigabe vom Koordinator empfangen und in den 
zugewiesenen Time Slotts Ihre Daten übertragen.

- Non Beacon Enable Modus, wobei alle Endknoten den polling Mechanismus 
verwenden. Dann muss allerdings der Koordinator sehr häufig senden.
Dies wiederum würde bedeuten, das nur das 2,4 GHz Band genutzt werden 
kann, weil die Datenrate von 20kbps (BPSK) oder 100kbps (OQPSK)bei 868 
MHz nicht ausreichen könnte, den duty cycle von 1% innerhalb von einem 2 
Sekunden Zyklus zu erfüllen.

Das 868 MHz Band wäre aber wahrscheinlich besser, wegen weniger 
Koexistenzproblemen und besseren Funkausbreitungs-Eigenschaften 
innerhalb von Gebäuden.

Deshalb wäre für diese Anwendung der Beacon Enable Modus die sinnvollere 
Variante. Schätze das dann auch der zusätzliche Overhead von Zigbee zu 
verkraften wäre.

Ist meine Einschätzung soweit OK? Gibt es sonst noch Möglichkeiten diese 
Anwendung zu realisieren?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn nur die Endknoten Daten senden wollen, brauchst du keinen
beacon-enabled mode.  Der ist nur interessant, wenn du vom
Koordinator zu den Endknoten etwas senden willst, diese aber den
größten Teil der Zeit schlafen sollen.

Der duty cycle muss nur innerhalb eines Intervalls von einer Stunde
erfüllt sein, und er bezieht sich auf jedes Gerät einzeln.  Da der
Koordinator jeweils vermutlich nur ACKs sendet, sollte das für ihn
kein Problem werden, und die Geräte senden selten genug.  Man könnte
ja außerdem noch LBT benutzen (der benutzte AT86RF212 kann das) statt
CCA, wäre nur eine Frage mit den ACKs, die ja prinzpiell (und sinn-
voller Weise) ohne CCA (und damit auch ohne LBT) gesendet werden.

Christian B. schrieb:
> Das 868 MHz Band wäre aber wahrscheinlich besser, wegen weniger
> Koexistenzproblemen und besseren Funkausbreitungs-Eigenschaften
> innerhalb von Gebäuden.

Du musst nur dran denken, dass du halt größere Antennen brauchst
als bei 2,4 GHz, ansonsten nützen dir die besseren Ausbreitungs-
bedingungen nichts.

Autor: Christian B (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> beacon-enabled mode.  Der ist nur interessant, wenn du vom
> Koordinator zu den Endknoten etwas senden willst, diese aber den
> größten Teil der Zeit schlafen sollen.

Habe die Anwendung nicht genau genug beschrieben. Aber so wie du es 
sagst ist es.
1. Koordinator sendet Freigabe für Endknoten
2. Daten von Endknoten alle 2 Sekunden senden bis
3. Koordinator Freigabe für Endknoten sperrt

Deshalb finde ich den IEEE 802.15.4-MAC interessant.

Christian B. schrieb:
> Mir wurde geraten als Anfänger besser den BitCloud Stack zu verwenden,
> weil beim IEEE 802.15.4-MAC noch irgend etwas angepasst werden müsste.

Damit meine selbst gestellte Frage nicht ganz unbeantwortet stehen 
bleibt,
habe ich jemandem der die ZigBit Module vertreibt gefragt und folgende 
Information bekommen:

"(...)die ZigBit Module (ATZB-900-B0) werden leider im MAC Paket nicht 
direkt unterstützt, aber unsere RCB -boards mit dem RF212. Die Anpassung 
beträfe also die Hardware-Differenzen zwischen diesem RCB212 and dem 
ATZB-900-B0. Wir planten das eigentlich auch noch selber mit anzubieten, 
aber durch viele andere grosse Projekte ist das im Moment von geringerer 
Priorität und somit wird das nicht so bald passieren. BitCloud 
unterstützt die Module bereits direkt, aber im MAC müssten Pinouts etc. 
angepasst werden die bei den unterstützten RCB212 anders sind.(...) "

Somit hat sich der IEEE 802.15.4 MAC für mich wahrscheinlich erledigt, 
weil ich vermute das meine Erfahrungen für so etwas noch nicht 
ausreichend vorhanden sind.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian B schrieb:

> Habe die Anwendung nicht genau genug beschrieben. Aber so wie du es
> sagst ist es.
> 1. Koordinator sendet Freigabe für Endknoten

Ach OK, das hatte ich vermasselt.

> Somit hat sich der IEEE 802.15.4 MAC für mich wahrscheinlich
> erledigt, weil ich vermute das meine Erfahrungen für so etwas noch
> nicht ausreichend vorhanden sind.

Was für Erfahrungen hast du denn?  Ich vermute mal, ein rekursives
Kopieren eines Teilbaumes in einem Verzeichnis und anschließendes
Editieren von ein paar #defines wirst du doch noch schaffen, oder?  Um
viel mehr handelt es sich im Allgemeinen bei solchen Anpassungen ja
nicht.

Autor: Christian B (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was muss den alles Angepasst werden. Vermute mal, dass die Pinouts mit 
den #defines geändert werden können. Was hat es den mit dem Kopieren von 
Teilbäumen auf sich? Warum wird das gemacht und was gehört sonst noch 
alles zum Anpassvorgang dazu.

Habe gelesen, das die Raven-Boards schon an den IEEE 802.15.4-MAC 
angepasst sind. Werde also morgen erst mal versuchen eine Beispiel 
Anwendung des IEEE 802.15.4-MAC auf die Boards zu übertragen.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian B schrieb:
> Was muss den alles Angepasst werden.

Schau dir doch einfach mal an, wie die Software verzeichnismäßig
aufgebaut ist, dann wirst du das besser verstehen.

> Habe gelesen, das die Raven-Boards schon an den IEEE 802.15.4-MAC
> angepasst sind.

Eher andersrum, der MAC enthält bereits Definitionen für die Raven-
Boards.  Nur, wie geschrieben: erwarte HF-mäßig nicht unbedingt
optimale Resultate von den Ravens, die Zigbits könnten sich da
besser schlagen (vor allem mit externer Antenne, die Keramikantennen
sind ja auch nur Stummel, die froh sind, wenn man ihre Energiebilanz
überhaupt noch als ,Gewinn' bezeichnen kann).

Autor: Christian B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK vielen Dank noch mal.
Werde erst mal mit den Raven Boards programmieren und danach beschäftige 
ich mich etwas Intensiver mit der Anpassung der Module. Vielleicht 
klären sich schon einige Fragen während der Programmierung.

Noch eine Frage zum Beacon Enable Modus. Eine bidirektionale 
Kommunikation ist doch nur mit Full Function Devises möglich. Also sind 
auch die Endknoten im Beacon Enable Modus FFDs, oder?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian B. schrieb:

> Noch eine Frage zum Beacon Enable Modus. Eine bidirektionale
> Kommunikation ist doch nur mit Full Function Devises möglich.

Nein, natürlich nicht, das wäre ja sinnlos. ;-)

Im Gegenteil, wenn man Endknoten im non-beacon enabled network
betreiben will, kann man sie nicht als Minimal-RFD implementieren,
weil dann auch der active scan nicht mehr enthalten wäre.  Da ein
passive scan aber für non-beacon keinen Sinn hat, würden derartige
RFDs nie ihren Koordinator finden.  Bei beacon-enabled dagegen ist
der active scan verzichtbar: der Koordinator würde den beacon
request ohnehin nicht auswerten sondern stur seinen nächsten beacon
erst dann senden, wenn die Zeit ran ist.

Autor: Christian B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So wie ich das Attribut "phyTransmitPower" verstehe geben die beiden 
MSBs die Toleranz und die 6 LSBs die eingestellte Sendeleistung an. 6 
Bits entspricht dem maximalen Integer Wert von 32 und der maximalen 
Sendeleistung des Modules. Jeder Integer Wert entspricht minus 1 dBm.

z.B. max. Sendeleistung  0 dBm

Bits 10111111 : Sendeleistung: 0dBm, Toleranz: +- 6dB
Bits 10111110 : Sendeleistung: -1dBm, Toleranz: +- 6dB
Bits 10000000 : Sendeleistung: -32dBm, Toleranz: +- 6dB

Ist mein Beispiel korrekt?

Das Attribut "phyTransmitPower" kann nur ausgelesen werden. Wie können 
die Bits geändert und die Sendeleistungen eingestellt werden?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian B. schrieb:

> Bits 10111111 : Sendeleistung: 0dBm, Toleranz: +- 6dB
> Bits 10111110 : Sendeleistung: -1dBm, Toleranz: +- 6dB
> Bits 10000000 : Sendeleistung: -32dBm, Toleranz: +- 6dB

Die 6-bit-Zahl ist eine gewöhnliche signed integer Zahl, deine
Werte sind also -1 dBm, -2 dBm und 0 dBm, jeweils mit ±6 dB
Toleranz.  Mit diesen 6 Bits lässt sich der Bereich -32 dBm
(0bXX100000) bis +31 dBm (0bXX011111) abdecken.

> Das Attribut "phyTransmitPower" kann nur ausgelesen werden.

Nein, nur die beiden oberen Bits sind read/only (denn sie spiegeln
ja eine Eigenschaft des Geräts bzw. der Firmware wieder), die
unteren 6 Bits sind schreibbar, natürlich in den Grenzen der
jeweiligen Implementierung.  Nicht jeder Modul wird mit +31 dBm
in der Lage sein zu senden. :-)

Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jörg, Christian und alle anderen,

es ist eine wirklich interessante und aufschlussreiche Diskussion die 
ihr hier führt. Ich hoffe es ist jetzt nicht zu spät um hier weiter 
Fragen zu stellen.
Ich arbeite auch an einem MAC Layer für IEEE 802.15.4 und versuche den 
Standard zu verstehen. Diese Woche war ich auf der European ZigBee 
Konferenz in München und hab mir mal angehört was die Fachleute so 
erzählen und verwenden. War für mich ganz interessant und ich konnte 
einen besseren Überblick bekommen.

Jetzt zu meinen Fragen:
Zum "phyTransmitPower". Was ist mit der Toleranz gemeint, ist die vom RF 
chip gegeben? +-6dB ist dann Faktor 4. Wenn ich also 0dBm einstelle kann 
es sein dass das Modul mit 0,25 mW oder 4 mW sendet? Das ist doch sehr 
ungenau.

Ihr habt mal über CCA und LBT geschrieben. Was ist der Unterschied 
zwischen CCA und LBT? CCA ist ein Verfahren bei dem der Kanal überprüft 
ob er frei ist und bei LBT wird erst gesendet wenn er frei ist?

Weiß jemand genau was slotted CSMA/CA ist. Was ist slotted? Bei 16 
Zeitschlitzen in der aktiven Zeit im Superframe kann es vorkommen dass 
ein Frame (Datenrahmen) (PHY Payload max. 127 Byte) länger als ein 
Zeitschlitz ist. Was ist der Vorteil von slottet CSMA/CA und wie streng 
wird das mit den Zeitschlitze eingehalten? Vielleicht kann mir auch 
jemand hier auch ein Buch empfehlen in dem das etwas genauer beschrieben 
ist.

Mario

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mario schrieb:

> Zum "phyTransmitPower". Was ist mit der Toleranz gemeint, ist die
> vom RF chip gegeben? +-6dB ist dann Faktor 4. Wenn ich also 0dBm
> einstelle kann es sein dass das Modul mit 0,25 mW oder 4 mW sendet?

Ja.  Der Hintergrund ist ja einfach, dass die Hardware sinnvoll nur
endlich genau aufgebaut werden kann, und die Werte willst du ja am
Ende über den kompletten Betriebsspannungs- und -temperaturbereich
zusagen können.  Da hängt man sich dann lieber nicht zu weit zum
Fenster raus und klassifiziert das Gerät lieber eine Kategorie
schlechter.  Interessiert ja am Ende sowieso keinen :.), der Anwender
hat ja keine andere Wahl, als dass er einfach einen Wert einstellt und
dann hofft, dass Stack und Hardware das beste draus machen werden.

> Ihr habt mal über CCA und LBT geschrieben. Was ist der Unterschied
> zwischen CCA und LBT?

Im Grunde genommen ist LBT nicht sehr viel anders als CCA/ED (CCA Mode
1, Punkt 6.9.9 im Standard).  Allerdings hat LBT einen anderen
Algorithmus als CCA, mit dem die Belegung des Kanals geprüft wird. Die
Details kannst du in der ETSI EN 300220-1, Kapitel 9.1 und 9.2
nachlesen.  Die besondere Bedeutung von LBT rührt daher, dass die
europäischen Regelungen bei Benutzung einer spread-spektrum-Technik
und Einhaltung der LBT-Regelungen die ansonsten im 868-MHz-SRD-Band
zutreffenden Regelungen über den maximalen duty cycle (relative
Sendedauer) aufheben.  Eigentlich ist es ein Lapsus des IEEE-
Standards, für den Betrieb auf 868 MHz den LBT-Algorithmus nicht als
Alternative zum CCA normiert zu haben.

> Weiß jemand genau was slotted CSMA/CA ist.

Das CSMA/CA-Verfahren, das in einem beacon-enabled network zu benutzen
ist.

> Was ist slotted?

Die CCA-Tests werden auf Zeitschlitze synchronisiert, deren Taktraster
durch den beacon des Koordinators vorgegeben ist.  Damit soll offenbar
erreicht werden, dass jemand, der die Belegung des Kanals testet,
zeitlich korreliert mit denjenigen, die auf dem Kanal gerade zu senden
beginnen, sodass auch bei sehr kurzen Frames der Kanal noch als belegt
erkannt wird.

> Bei 16
> Zeitschlitzen

Den Denkehler hatte ich anfangs auch. ;-)

Es gibt zwei Sorten "slots" im beacon-enabled network.  Die 16 slots,
die du nennst, sind die möglichen Unterteilungen des Superframes in
Zeitschlitze.  Die Grenzen dieser Zeitschlitze bestimmen, an welchen
Stellen bspw. der aktive Teil des Superframes aufhört, sich die Geräte
also bis zum nächsten beacon schlafen legen dürfen, sie sind
gleichzeitig auch die potenziellen Grenzen für zugwiesene Zeitschlitze
(granted time slots, GTS), in denen ein Gerät ohne CSMA/CA senden
darf.

Der "slot" beim "slotted CSMA/CA" jedoch ist ein anderer, das ist der
"backoff slot", und der ist immer 20 Symbole lang.  In diesem Raster,
synchronisiert mit dem SFD des beacons vom Koordinator, sollen in
einem beacon-enabled network sämtliche Aussendungen beginnen, und
entsprechend auch sämtliche CCA-Messungen erfolgen.  In der 2003er
Version des Standard sollten auf diese slot boundaries sogar noch die
ACKs synchronisiert werden, aber diese Forderung hat man in der 2006er
Version des Standards optional gemacht.  (Bei einer beacon order von 0
hat jeder der 16 Superframe-slots dann übrigens genau 3 backoff slots,
bei größeren beacon orders entsprechen 2^N mehr.)

> in der aktiven Zeit im Superframe kann es vorkommen dass
> ein Frame (Datenrahmen) (PHY Payload max. 127 Byte) länger als ein
> Zeitschlitz ist.

Diese Kollision hast du nur bei sehr geringen Werten für die beacon
order, die ich persönlich für kaum noch praktikabel halte.

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann jemand nachfolgendes validieren.

Im 802.15.4-Artikel in Wikipedia[1] steht, dass die die maximale 
BackOffPeriod = (2^BE-1)  aUnitBackoffPeriode  SymbolPeriod = (2^5 - 
1)  20  60µs = 9920µs sei.

Im 2006er-Standard steht aber auf Seite 163f, Table86-MAC PIB 
attributes, dass sich der macMaxBE ein Wert von 3 bis 8 annehmen kann 
(default=5) und macMinBE ein Wert von 0 bis macMaxBE.
Somit variert BE zwischen 0 und 8.

Und damit ändert sich die maximal BackOffPeriode zu
BackOffPeriod = (2^8 - 1)  20  60µs = 306ms

Kann das jemand bestätigen? Ist das eine Änderung im Standard von 
Version 2003 zu 2006?




[1] http://de.wikipedia.org/wiki/IEEE_802.15.4

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tom schrieb:
> Ist das eine Änderung im Standard von
> Version 2003 zu 2006?

Ja, ist es.

Bedenke bei zeitlichen Berechnungen noch, dass die Dauer eines Symbols
abhängig von Frequenzband und Modulationsart ist.  Derzeit haben wir
16 µs (O-QPSK 250 auf 2,4 GHz sowie 910 MHz), 25 µs (BPSK 40 auf 910
MHz), 40 µs (O-QPSK 100 auf 868 MHz) und 50 µs (BPSK 20 auf 868 MHz).
Im Prinzip gibt's noch den ASK-PHY für 868/910 MHz, aber wenn man
von dem Joke hier

Beitrag "[V] Datenblatt"

mal absieht, hat der (noch) keine praktische Relevanz.  Bei dem ist
alles völlig anders (und noch viel schräger).

Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dazu hab ich gleich noch ne Frage. Gibt es zu der maximalen 
BackOffPeriod auch ein PIB Attribut (exakte Bezeichnung) die ich im 
Standard finden kann?  Auf Seite 160 (2006) wird mit Formel 14 die 
macMaxFrameTotalWaitTime berechnet, da ist (2^BE-1)* 
aUnitBackoffPeriode enthalten aber auch noch eine Summe über 2^(macMinBE 
+ k). Was ist macMaxFrameTotalWaitTime und was ist der Unterschied zur 
maximalen BackOffPeriod?

Ist die maximale BackoffPeriod die max. Zeit in der der Algorithmus das 
CCA durchführt, bzw. ein Ergebnis Kanal belegt oder Kanal frei liefert?

Für eine Abschätzung bräuchte ich die maximale Dauer eines Backoff-CCA 
für slotted CSMA/CA und 2,4 GHz O-QPSK.

Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Tom: mir ist das mit der SymbolPeriod unklar. Warum sind das 60 µs? 
Handelt es sich hier um die Zeiten aus Jörgs Beitrag? Also für 2,4 GHz 
16 µs?

> 16 µs (O-QPSK 250 auf 2,4 GHz sowie 910 MHz), 25 µs (BPSK 40 auf 910
> MHz), 40 µs (O-QPSK 100 auf 868 MHz) und 50 µs (BPSK 20 auf 868 MHz)

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Mario: Ja, die 60µs sind ein Abschreibfehler von Wikipedia, es müsste 
16µs heißen. Danke für den Hinweis, ist mir bisher gar nicht 
aufgefallen.

Und die Multiplikations-Sterne die ich auch eingetippt hatte, hat das 
Forum gefressen ;-)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mario schrieb:
> Gibt es zu der maximalen
> BackOffPeriod auch ein PIB Attribut (exakte Bezeichnung) die ich im
> Standard finden kann?

Es gibt macMinBE und macMaxBE.  Letzteres war im 2003er Standard noch
eine Konstante (aMaxBE, Wert 5).

> Was ist macMaxFrameTotalWaitTime

Warum es dafür ein eigenes Attribut gibt, ist mir nicht ganz klar,
aber vielleicht wollte man dem MAC ja die Berechnung der komplizierten
Formel ersparen. ;-)  Der "next higher layer" weiß ja im Allgemeinen
schon, welchen Wert er für macMaxBE vorgibt und welchen PHY er
benutzt, sodass er diese Zeit auch gleich als Konstante in den MAC
programmieren kann.

> und was ist der Unterschied zur
> maximalen BackOffPeriod?

Hat mit einer BackOffPeriod nichts zu tun.  Hier geht es um die
Antwort auf einen data request oder auf ein im beacon angekündigte
broadcast.

> Ist die maximale BackoffPeriod die max. Zeit in der der Algorithmus das
> CCA durchführt, bzw. ein Ergebnis Kanal belegt oder Kanal frei liefert?

Nein, es ist der backoff, also die Zeit, die vor einer CCA-Messung
gewartet wird.  Dabei wird sowohl vor der allerersten Messung eine
zufällige Zeit lang gewartet als auch nach jeder Messung, die einen
belegten Kanal erkannt hat.  Damit soll verhindert werden, dass alle
"zugleich losquatschen" (ähnliches wird auch bei CSMA/CD bei Ethernet
gemacht).  Die beiden Pflichtmessungen beim slotted CSMA/CA werden
jedoch stets an aufeinanderfolgenden backoff slot boundaries
durchgeführt (allerdings geht's sofort zurück zur nächsten Runde und
damit zum random backoff, wenn bereits die erste der beiden Messungen
einen belegten Kanal ergab).

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.