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
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.
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?
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.
bei Elektroniknet.de (http://www.stzedn.de/stzedn/files/stz_zigbee_elektronik_wireless_0401.pdf) 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?
@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 :-(
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.
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!!!!!
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?
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.
@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)?
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.
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.
@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?
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.
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:-)
Btw., meine Angaben über Kapitel- und Tabellennummern beziehen sich jeweils auf die 2006er Version des Standards.
@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.
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.
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?
:-) gut, hast mir eh schon sehr viel geholfen. Und ich bin mir sicher ich werde bald wieder Fragen haben:-)
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.
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).
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
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.
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%.
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 ;-).
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.
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.
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.
@ 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?
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.
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?
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.
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.
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.
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.
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).
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?
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.
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?
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. :-)
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
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.
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
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).
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.
@ 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)
@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 ;-)
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).
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.