Building day 2 upload Building the Internet of Things with Thingsquare and Contiki - day 2 part 3
•
32 gefällt mir•13,687 views
The third slide set from the second day of the Thingsquare IoT Contiki course. http://thingsquare.com/training/
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Building day 2 upload Building the Internet of Things with Thingsquare and Contiki - day 2 part 3
Ähnlich wie Building day 2 upload Building the Internet of Things with Thingsquare and Contiki - day 2 part 3 (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Building day 2 upload Building the Internet of Things with Thingsquare and Contiki - day 2 part 3
- 1. Application Transport The IoT/IP Protocols Network, routing Adaptation The network layer MAC Duty cycling Radio
- 2. The problem • The general problem – Getting data from node A to node C, through node B • The solutions – Addressing, routing • The wireless problem – Intermediate nodes may move – Wireless medium is brittle – Wireless medium may change over time • The resource problem – Bandwidth-constrained – Memory-constrained
- 3. Routing
- 4. Routing: IETF RPL • ”Ripple” • Proactive any-to-any routing protocol – But optimized for the many-to-one case • RPL forms routing graph from root node • Packet forwarding along graph, routing metric dynamically updated – Short-lived routing loops are tolerated
- 5. The problems that RPL solves • Resource constraints – Memory constraints – Power constraints – Bandwidth constraints • Wireless is unpredictable – Pick good routes
- 6. RPL network formation • Build acyclic graph from root node – DODAG – Destination Oriented Directed Acyclic Graph • DIO messages are broadcast by all nodes, starting from the root node – DIO – DODAG Information Object
- 8. RPL Network Formation N1 DIO (DODAG Information Object) Version: 240 Rank: 256 MinHopRankInc: 256 N2 N3 N5 N4
- 9. RPL Network Formation N1 N2 DIO Version: 240 Rank: 512 DIO Version: 240 Rank: 512 N3 N5 N4
- 10. RPL Network Formation N1 DIO Version: 240 Rank: 768 N2 N3 N5 DIO Version: 240 Rank: 768 N4
- 11. RPL Network Formation Rank: 256 N1 Rank: 512 N2 Rank: 768 N3 N5 Rank: 768 Rank: 1024 N4
- 12. RPL packet forwarding • Given multiple choices, what route should a packet take? – Hop count – shortest amount of hops to the root? – Some other dynamic metric? • RPL leaves this to its Objective Function • Two Objective Functions specified – of0: hop count – of1: ETX
- 13. ETX – Expected Transmissions • For every packet transmission, measure how many tries it takes until an ACK is received – Use as a measure of how many transmissions to expect • Keep a moving average, for every neighbor • To build routes, simply compute the sum of all ETXes
- 14. ETX – illustration 3.5 1.5 4 hops, ETX 4.7 1.0 1.0 2.7 1.2 2 hops, ETX 6.2
- 15. RPL downward routes • Storing mode vs non-storing mode – Storing mode: all nodes store the addresses of their child nodes • Drawback: needs routing tables • This is how Thingsquare/Contiki does this – Non-storing mode: the root node knows the full route to all nodes, sends full route in every packet • Drawback: increases header overhead • This technique is known as source routing
- 16. RPL downward routes N1 N2 DAO (Destination Address Object) Target: N4 N3 N5 N4
- 17. Node IPv6 RPL Network Formation N1 N2 DAO Target: N4 N3 N5 N4
- 18. Node IPv6 RPL Network Formation N1 DAO Target: N4 N2 N3 N5 N4
- 19. RPL Routing: Down • Packets within network routed through common parent node N1 N2 N3 To: N4 N5 N4
- 20. RPL network join • New nodes that appear in the network broadcast Destination Information Solicitation (DIS) packets • Connected nodes that hear DIS packets respond with a DIO
- 21. RPL control traffic suppression • Once the RPL network is established, it reduces the rate of control messages – Expontential increase • To avoid control message explosion, nodes suppress transmissions if it hears too many messages from others – Called the Trickle algorithm (Phil Levis et al)
- 22. RPL repair • Loop detection: packets carry backward path information in header • When a loop is detected, the first few packets are allowed through the loop • If the same packet is seen once again, a local repair is initiated – Node sets rank to infinity, sends DIS • RPL global repair – Increase version number, rebuild DODAG
- 23. RPL Global Repair DIO Version: 241 N1 N2 N3 N5 N4
- 24. RPL Global Repair N1 DIO Version: 241 N2 DIO Version: 241 N3 N5 N4
- 25. RPL Global Repair N1 DIO Version: 241 N2 N3 N5 N4
- 26. RPL any-to-any routing • RPL is optimized for many-to-one routing – All report packets to the sink • Any-to-any routing must go through closest common ancestor – The root, in the worst case • RPL P2P mode a suggested solution – AODV-like reactive route discovery with source routing – Contiki implementation exists: http://contiki-p2p-rpl.gforge.inria.fr/
- 27. RPL pitfalls • Rebooting the root node – Must listen for a while to obtain network version • Global repair may take a while
- 28. In Contiki • ContikiRPL code is difficult to use – Integrated with the uIPv6 stack – Complex API • Thingsquare provides a simple-rpl module – Gracefully handles root node reboots – Provides global repair / local repair API
- 29. In Contiki • RPL node types • Mesh nodes: RPL routers, can be routed to • Leaf nodes: does not route RPL traffic, can be routed to • Feather nodes: routes RPL traffic, cannot be routed to
- 30. Addressing: IPv6
- 31. IPv6 addresses • 128 bits – Much more than the 32 bits of IPv4 • Examples: – 2001:0db8:85a3:0000:0000:8a2e:0370:7334 – fe80::12:7400:1:100 • An IPv6 host has multiple addresses • An IPv6 network interface has multiple addresses • IPv6 addresses are typically automatically generated – From a given prefix
- 32. IPv6 duplicate address detection 1. Pick a tentative address – Usually from your EUI-64 address • Or timestamp 2. Send a neighbor discovery message for the tentative address – Send a Neighbor Solicitation (NS), wait for a Neighbor Advertisement (NA) 3. If there is a reply, go back to step 1 4. If nobody replies, claim the tentative address – The tentative address is now preferred address
- 33. IPv6 address generation Unique local unicast IPv6 address (RFC 4193) Bits: 7 1 40 Prefix L Global ID 16 64 Subnet ID Interface ID subnet within a site globally unique prefix FC00::/7
- 34. IPv6 address generation Link-local unicast IPv6 address (RFC 4291) Bits: 10 54 Prefix 64 0 Interface ID FE80::/10
- 35. IPv6 address generation Global unicast IPv6 address (RFC 3587) Bits: n Global Routing Prefix 64 - n 64 Subnet ID Interface ID From site admins 2000::/3 & RIR/ISP ID
- 36. IPv6 address generation Multicast IPv6 addresses (RFC 3513) Bits: 8 4 4 128 Prefix flgs scop Group ID FF::/8
- 37. IPv6 shortening • Replace any number of zeroes with :: – But only once • Replace any leading zeroes in 16-bit field omitted – 01ff -> 1ff • Hex as lower-case letters • Eg – fe80::1db:9
- 38. IPv6 Good-to-know • /n is CIDR notation: first n bits are fixed • Multicast ff::/8 – but ff0x:: reserved (where x = 0..f) • all nodes multicast – ff01::1 (interface-local) – ff02::1 (link-local) • all routers multicast – ff01::2 (interface-local) – ff02::2 (link-local) – ff05::2 (site-local) • fe80::/10 – link local addresses • fc00::/7 – unique local addresses • Global addresses 2000:: – 3ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
- 39. In Contiki • Contiki provides a full IPv6 stack – With support for IPv6 address management, multiple addresses, duplicate address detection, neighbor tables, routing tables
- 40. Takeaway network layer • The network layer addresses devices and routes packets • The IoT/IP stack uses IPv6 and RPL
- 41. Application Transport The IoT/IP Protocols Network, routing Adaptation The adaptation layer MAC Duty cycling Radio
- 42. The problem • How do we transmit IP packets over a medium like 802.15.4? – 802.15.4 frames are tiny – 802.15.4 bit rates are slow – IP headers are large – IPv6 headers are even larger – IPv6 packets may be huge • The solutions – Header compression – Fragmentation
- 43. IPv6 over 802.15.4 • IP headers are large – IPv6 headers are 40 bytes – minimum – UDP headers are 8 bytes, TCP headers 20 bytes – minimum • IP packets may be huge – 1280 bytes must be supported • 802.15.4 frames are 127 bytes – maximum
- 44. 6lowpan • standard defined by the 6lowpan working group – 6lowpan = IPv6 for Low-power Wireless Personal Area Networks – Because of the name of the standard, many people refer to IPv6 over 802.15.4 as ”6lowpan networks” or ”6lowpan stacks” • We don’t
- 45. 6lowpan header compression • Don’t send what the receiver(s) already know/can compute • IPv6 addresses often automatically constructed from the MAC address – if so, just set a bit • Transport layer may contain a length field – Can be computed from link-layer header – set a bit • Some port numbers are more common than others – Set a bit • And so on
- 47. 6lowpan fragmentation • Split large IPv6 packets across multiple link-layer frames – Reassemble at every hop • Set fragmentation bit in first packet – Fragmentation header in subsequent packets – When all packets have been received, send packet upwards to network layer
- 49. Further issues • IPv6 neighbor management defined for transitive links – Transitive: if A hears B, B will also hear A – Wireless multi-hop links are non-transitive • This impacts duplicate address detection – If node A and B happen to pick the same address, they may not know about it • Multicast is expensive for wireless • Optimizations for 802.15.4 links: RFC 6775
- 50. In Contiki • The 6lowpan layer does header compression, fragmentation • Informs the upper layers about the number of retransmissions needed by the MAC layer • Shields the IPv6 stack from radio-level details – Such as signal strength
- 51. Takeway from adaptation layer • Specifies how to transmit IP packets over the radio link layer – Header compression – Fragmentation – Called 6lowpan for IEEE 802.15.4
- 52. Application Transport The IoT/IP Protocols Network, routing Adaptation The MAC layer MAC Duty cycling Radio
- 53. The MAC layer • The simplest layer in the IoT/IP stack • CSMA/CA: Carrier Sense Multiple Access with Collision Avoidance – Sense the medium before sending – Back off if someone else is sending • May result in hidden terminal problem – But the capture effect mitigates this to some degree [c.f. Österlind et al, IPSN 2012]
- 54. In Contiki • Two MAC layers – CSMA/CA • Regular CSMA/CA layer • Timing depends on RDC layer • Network layer decides number of transmissions – nullmac • A MAC layer that doesn’t do anything
- 55. Takeaway from MAC layer • Avoid collisions, back-off if there is too much other traffic
- 56. Application Transport The IoT/IP Protocols Network, routing Adaptation The radio duty cycling layer MAC Duty cycling Radio
- 57. The duty cycling problem • Radio transceivers consume (significant) power when just listening – Often as much as or more as when transmitting • Need to duty cycle the radio transceiver – Keep it off as much as possible – Coordination needed
- 58. Simple duty cycling methods • Star network duty cycling (ZigBee) – Routers and coordinators are always on • Must be plugged into power source – Leaf nodes may be off
- 59. Sleepy mesh duty cycling • Allow arbitrary mesh communication between nodes – ContikiMAC • Highly optimized for 802.15.4 – Drowsie (Thingsquare firmware) • Portable across radios – 802.15.4 CSL • Standardized radio duty cycling
- 60. ContikiMAC ~2 * 200 microseconds 0.125 – 1 seconds
- 61. Thingsquare 802.15.4e CSL ~2 * 200 microseconds 0.125 – 10.5 seconds
- 62. Drowsie
- 64. Implications of duty cycling • Slight increase in response time – Must wait until receiver is awake • Throughput reduced • But we save power! – Thingsquare CSL idle ca 0.5% DC
- 65. In Contiki • The RDC layer also does encryption, duplicate frame filtering, address filtering – AES decryption / encryption – For sub-GHz radios, support for 802.15.4-like behavior • ContikiMAC – Highly optimized, for 802.15.4 • Drowsie – More relaxed, works on more platforms • Less power-efficient • 802.15.4e CSL – Standardized power-saving! – Similar to ContikiMAC • nullrdc – An RDC layer that always keeps the radio on
- 66. Takeways from radio duty cycling layer • Duty cycling allows sleepy meshing – Unlike many other technologies (e.g. ZigBee, Bluetooth Low-Energy)
- 67. Application Transport The IoT/IP Protocols Network, routing Adaptation The radio layer MAC Duty cycling Radio
- 68. The radio layer (PHY) • Getting 1s and 0s across the air • Modulation and encoding – How the 1s and 0s are represented • Modulation examples – On off keying (OOK), amplitude shift keying (ASK), frequency shift keying (FSK), phase shift keying (PSK) – Direct sequence spread spectrum (DSSS), offset quadrature phase-shift keying (O-QPSK) • Resilience and EMC – Forward Error Correction (FEC) – Whitening
- 69. IEEE 802.15.4 PHY • 27 logical channels – 0-10: sub GHz bands – 11-26: 2.4 GHz band • Other various modulations, freq bands etc • Low-power mechanisms 2012
- 70. IEEE 802.15.4 channels 868-868.8 MHz Channel 0 902 - 928 MHz Channel 1-10
- 72. IEEE 802.11 (Wi-Fi) • Channels 1, 6, 11 are not overlapping cisco.com
- 73. 802.15.4 and Wi-Fi overlap 15 20 25, 26
- 74. IEEE 802.15.4 is more • IEEE 802.15.4 does not only specify a PHY layer – – – – – – Node addressing Network addressing MAC layer framing MAC layer mechanisms Encryption Node types: Full Function Devices (FFDs) and Reduced Function Devices (RFDs) • IEEE 802.15.4e, IEEE 802.15.4g: even more
- 75. IEEE 802.15.4 addressing • Node addresses – Three address types: simple, short and long – Short addresses • 2 bytes • Dynamically assigned at run-time – Long addresses • 8 bytes – EUI 64™ • Statically assigned by manufacturer • Network addresses – PAN ID – Dynamically assigned
- 76. 802.15.4 MAC layer framing • Data frames • ACK frames – Like data frames, but no addressing, data, security
- 77. 802.15.4e MAC layer frame
- 78. 802.15.4 framing • Frames are protected by CRC-16 • 127 bytes maximum data frame size • ACK frames must be sent within a specific time – Usually handled automatically by hardware
- 79. 802.15.4 security • AES 128 encryption • Message Integrity Check (MIC) – Protects against the message being altered – Sequence number protects against replay attacks – Timestamp may be used to protect against delay attacks • Uses AES CBC-MAC mode – Authentication and confidentiality
- 80. IEEE 802.15.4 node types • Not used (much) with low-power IP, but good to know about • FFDs – – – – Always on PAN coordinators Assigns short addresses Use so-called Beacon-mode • RFDs – May be off a lot – Cannot be mesh nodes
- 81. IEEE 802.15.4e • Standardized duty cycling – Coordinated Sampled Listening (CSL) • Very similar to ContikiMAC – Time Synchronized Channel Hopping (TSCH) • Duty cycling and channel hopping • Based on TSMP / WirelessHART – Receiver Initiated Transmission (RIT) • Similar to Contiki’s LPP
- 82. IEEE 802.15.4g • Smart metering • Better support for sub-GHz modes • Possible to run with some existing subGHz chips – TI CC1101, TI CC1120
- 83. In Contiki • The radio layer is about low-level drivers • Complexity such as encryption is put into the RDC layer
- 84. Wireless connectivity • Counter-intuitive • Not a simple replacement to cables
- 85. Takeways from the radio layer • Different radios have different properties, benefits, drawbacks • IEEE 802.15.4 is currently a popular standard – But don’t worry too much about the details
- 86. Hands-on: UDP sockets, light sensors, LEDs, timers
- 87. Challenge! • Scenario: Old art in museum. • Color ages/deteriorates from sunlight / UV exposure • Hypothetical application: Light alarm © Leonardo
- 88. Challenge: Light alarm © www.timeslive.co.za • Too bright? Notify us! • Logged on the backend • Warn by blinking LEDs on the device
- 89. Challenge: Light alarm © www.timeslive.co.za • Bonus points for taking into consideration: – Periodic logging of ambient light – Reducing alarm latency (read often) – Be a responsible network citizen, don’t spam/flood – Manually be able to remotely enable/disable the application
- 90. Light alarm • Use udp-broadcast.c, light-sensor.c, cookbook.c
- 91. Conclusions • What we have done – Built an IoT cloud service – Built an IoT cloud-connected device • What we have seen – The protocols underneath it all • What we can do next – Develop our own connected product
Hinweis der Redaktion
- IETF ROLL (routing over low-power lossy links) WGAgnostic of under-laying link layer technology (PLC, 15.4 etc)
- DIO, DIS, DAO, DAO-ACK are ICMPv6-messages
- The root node transmits a DIO, adv the DODAG net version, what rank the root node has, and the minimum rank increase.
- At the next hop, the node N2 receives the DIO, and as it is not currently in a RPL net, it joins the net, having the same version and rank 256+256 = 512. It then starts to broadcast DIO messages so other nodes, further from the root, can hear them and join the RPL DODAG.
- When N3 gets the DIO, it also joins the net and gets rank 256+256+256=768 and starts broadcasting DIOs.
- Now the entire DODAG has been formed with the ranks as shown. As you can see, N5 has two possible parents and will later use routing metrics to chose the better one. Now it just takes the first one it heard to be parent.
- The difference is in downward routing, upward routing is same: send to default route (parent).Non-storing mode: any frame needs to go via root as no-one except root has any route.Storing mode: packets travel up to common ancestor.
- Now that we have a RPL DODAG, the children must inform the parents higher up that they have joined, so they send DAOs up the tree. N4 tells its parent N3 that ”here I am”.
- N3 in turn tells N2 that he knows N4.
- When N5 wants to send a message to another node, here N4, N5 checks the routing table, finds that he doesn’t know N4 so N5 sends it to its parent, N2. N2 checks the routing table, sees that N3 knows N4 so he sends it to N3, who sends it to N4.Mesh node = route on behalf of others, can be routed toLeaf node = cannot route on behalf of others, but can be routed to (ie does not keep a neighbor table but sends DAO) – saves RAM on local deviceFeather node = can route on behalf of others, but cannot be routed to (keeps neighbor table, does not send DAO) – saves neighbor table space on parents and rootSleepy leaf node = cannot route, cannot be routed to (no neighbor table, no DAO)
- Control traffic sent as ICMPv6 link-local multicasts and unicasts
- To do a global repair, the root node sends a DIO with an increased version number. It was previously 240, now it is 241.
- N2 receives the increased version number, being higher than what it knew, so it discards the routing tables and transmits DIO
- ... Which is propagated just like when the network was initially formed.RPL local repair happens on any mesh node. It drops the parent, sets it’s routing metric to infinity and transmits DIS’s.
- If the root node reboots and doesn’t listen for a while to get the current network version, it would start broadcasting DIOs with a lower version number than currently
- Version == 4/6Traffic class, Flow label for QoS and ...Payload length field 2B – max payload 65535 BNext header: IPv6 is specified to be very flexible and extendable, so this field tells what follows after the IPv6 header, typically the transport layer protocol like UDP, TCP or extension headers like fragmentation information or routing options.
- 128 bits -> more than 100 addresses per atom on the face of the earth
- Unique Local Address (ULA) Unique Local Unicast, [RFC4193]An IPv6 unicast address, globally unique and intended for local communications (Unique Local IPv6 Unicast Addresses).Not expected to be routable on the global Internet but inside of a more limited area, such as a site. Well-known prefix to allow for easy filtering at site boundaries. If accidentally leaked outside of a site via routing or DNS, there is no conflict with any other addresses.Global ID = 40 bits least significant of SHA-1 (timeofday + EUI-64 (or from 48b MAC if no EUI)) | 7 bits |1| 40 bits | 16 bits | 64 bits | +--------+-+------------+-----------+----------------------------+ | Prefix |L| Global ID | Subnet ID | Interface ID | +--------+-+------------+-----------+----------------------------+ Prefix FC00::/7 prefix to identify Local IPv6 unicast addresses. L 1 if the prefix is locally assigned following this algo. 0 may be defined in the future (another algo). Global ID 40-bit global identifier used to create a globally unique prefix. Global ID = 40 bits least significant of SHA-1 (timeofday + EUI-64 (or from 48b MAC if no EUI)) Subnet ID 16-bit Subnet ID is an identifier of a subnet within the site. Interface ID 64-bit Interface ID. Global IDs: The allocation of Global IDs is pseudo-random. They MUST NOT be assigned sequentially or with well-known numbers. This is to ensure that there is not any relationship between allocations and to help clarify that these prefixes are not intended to be routed globally.
- Link-Local addresses are for use on a single link for purposes such as automatic address configuration, neighbor discovery, or when no routers are present. Routers must not forward any packets with Link-Local source or destination addresses to other links.
- * global routing prefix is a (typically hierarchically-structured) value assigned to a site (a cluster of subnets/links), designed to be structured hierarchically by the RIRs and ISPs* subnet ID is an identifier of a subnet within the site, designed to be structured hierarchically by site administrators* interface IDcurrently only 2000::/3 is being delegated by the IANA, implementations should not make any assumptions about 2000::/3 being special2000::/3 2000:: to 3fff:ffff:ffff:ffff are available now
- Flags = rrrT, where r is reserved and T = 1 indicates ad hoc/tranisent multicast groupScope = 0..0xF indicating scope and 1 is interface-local to 0xE is global
- IPv6 does not implement broadcast addressing. Broadcast's traditional role is subsumed by multicast addressing to the all-nodes link-local multicast group ff02::1. However, the use of the all-nodes group is not recommended, and most IPv6 protocols use a dedicated link-local multicast group to avoid disturbing every interface in the network.
- IPv6 does not implement broadcast addressing. Broadcast's traditional role is subsumed by multicast addressing to the all-nodes link-local multicast group ff02::1. However, the use of the all-nodes group is not recommended, and most IPv6 protocols use a dedicated link-local multicast group to avoid disturbing every interface in the network.
- 6lowpan was the name of the IETF working group
- Version == 4/6Traffic class, Flow label for QoS and ...Payload length field 2B – max payload 65535 BNext header: IPv6 is specified to be very flexible and extendable, so this field tells what follows after the IPv6 header, typically the transport layer protocol like UDP, TCP or extension headers like fragmentation information or routing options.
- RFC 6775: IPv6 Neighbor Discovery not designed for non-transitive wireless links - heavy use of multicast make it inefficient for LLNs simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low- power Wireless Personal Area Networks and similar
- Leaf nodes wake up to transmit the message, then go back to sleep, they assume the receiving coordinator or router is on.
- BTLE, Ant+ are only low-power on the sender side; it sleeps until time to send something, typically a periodic sample of a sensor. Then wakes up and transmits, and goes back to sleep. The receiver must be always on. In TS, we call their equivalent fringe nodes.
- The radio layer, most often called the PHY or physical layer, is getting the 0’s and 1’s through the air, doing modulation, perhaps shaping the signal to have better analog characteristics in order to comply with regulations or have better performance.There are three basic properties in a sine wave: amplitude, freq and phase. Some modulation examples are... OOK, ASK, PSK, GFSK etc.In 15.4, one of several modulations is DSSS/O-QPSK, which is used in 2.4 GHz.FEC adds resilience to bit-errors by introducing redundancy, so that corrupt bits can be computed from the othersWhitening spreads the signal to not contain long strings of ones or zeroes so that the resulting signal is more like white noise, ie better for filters, spreads the energy more evenly etc...
- 802.15.4e-2012 low-power802.15.4g-2013 PHY for smart metering, 2048 byte frames
- 2400—2483 MHz, overlapping channelsUS 11 channels, Europe 14(?)best option is for everyone to use channels 1,6,11 as otherwise overlap makes the channels back off due to CSMA
- We see that there are only a few channels that go free of overlap with 802.11b, ie channels 15, 20, 25, and 26. This overlap can be a cause of grief as 802.11 is 1000 times stronger, but also faster so if not heavily utilized, a .11 and a 15.4 may very well co-exist in peace.Actually, what has been noticed is that 802.15.4 disturbs 802.11 more than the other way around, as .11 does CSMA/CA before tx, backing off when hearing the rather lengthy 15.4
- FFDs are always on-devices that are mains-powered, while RFD devices can be battery operated.The 802.15.4g update added freq bands and –e adds mechanisms for conserving power, esp CSL which is similar to ContikiMAC.
- 802.15.4 specifies two addresses: a short 16-bit and a long EUI-64 bit. Networks have a PANID, personal area network ID, set by the network coordinator aka the router but in practice it is common to statically assign this ID.PANID 0xFFFF is a broadcast PAN address, meaning all PANs will accept the packet.
- 802.15.4 frames are at a maximum 127 Bytes long. The PHY header is a preamble, just 0101010101, for 4 bytes, a start of frame delimiter magic number (0xE5) and 7 bits for length (+1 bit reserved).On MAC layer, the frame header contains a Control field with flags such as ACK req, frame pending flag, sec enabled, addressing mode etc.A sequence number, used for eg ACKs, Addressing fields, optional security, then data and a Frame Check seq footer
- Gerneral MAC frame format in the 802.15.4e-2012 addition
- 15.4 frames are encrypted with AES 128AES CBC-MAC creates a message authenticity code so the receiver can be confident that the message is from the right sender and has not been tampered with.
- The graph shows the measured packet reception ratio measured over x*1000 packets from a sender in the middle to a number of devices in a 15*15 m2 area.Shows not a circle, showing pockets of bad and good ratios, and this changes over time.