Both sides previous revisionPrevious revisionNext revision | Previous revision |
en:iot-open:networking2:wireless [2023/11/20 11:57] – pczekalski | en:iot-open:networking2:wireless [2023/11/23 16:11] (current) – pczekalski |
---|
====== Media Layers - Wireless Network Protocols ======= | |
| |
| ====== Media Layers - Wireless Network Protocols ======= |
| {{:en:iot-open:czapka_b.png?50| General audience classification icon }}{{:en:iot-open:czapka_m.png?50| General audience classification icon }}{{:en:iot-open:czapka_e.png?50| General audience classification icon }}\\ |
Wireless connections define core communication for IoT devices. A vast and growing amount of protocols, their variations and the dynamic IoT networking market all present a non-solid situation where old "adult" Internet protocols coexist along with new ideas, and IoT hardware and software platforms are more and more capable with every new generation; thus new concepts appear almost daily. Currently, many IoT networking protocols are defined for various layers of the protocol implementation stack, some compatible while others are concurring. Figure {{ref>iot-protocols}} presents some selected protocols existing for IoT. This covers only the most popular ones and gives a non-exhaustive view. We discuss them in more detail below. | Wireless connections define core communication for IoT devices. A vast and growing amount of protocols, their variations and the dynamic IoT networking market all present a non-solid situation where old "adult" Internet protocols coexist along with new ideas, and IoT hardware and software platforms are more and more capable with every new generation; thus new concepts appear almost daily. Currently, many IoT networking protocols are defined for various layers of the protocol implementation stack, some compatible while others are concurring. Figure {{ref>iot-protocols}} presents some selected protocols existing for IoT. This covers only the most popular ones and gives a non-exhaustive view. We discuss them in more detail below. |
| |
<figure iot-protocols> | <figure iot-protocols> |
{{ :en:iot-open:communications_and_communicating_sut:iot_protocols.png?400 |}} | {{ :en:iot-open:communications_and_communicating_sut:iot_protocols.png?400 | IoT protocols}} |
<caption>IoT protocols</caption> | <caption>IoT protocols</caption> |
</figure> | </figure> |
Moreover, WiFi itself offers only 1-to-1 (figure {{ref>wifionetoone}} or star-like, 1-to-many (figure {{ref>wifistar}} topologies of connections, where the central point is a WiFi Access Point. It does not provide mechanisms, e.g. self-reorganised, failure-tolerant mesh networks.\\ | Moreover, WiFi itself offers only 1-to-1 (figure {{ref>wifionetoone}} or star-like, 1-to-many (figure {{ref>wifistar}} topologies of connections, where the central point is a WiFi Access Point. It does not provide mechanisms, e.g. self-reorganised, failure-tolerant mesh networks.\\ |
<figure wifionetoone> | <figure wifionetoone> |
{{ :en:iot-open:networking2:g16626.png?150 |}} | {{ :en:iot-open:networking2:g16626.png?150 | WiFi 1-to-1}} |
<caption>WiFi 1-to-1</caption> | <caption>WiFi 1-to-1</caption> |
</figure> | </figure> |
| |
<figure wifistar> | <figure wifistar> |
{{ :en:iot-open:networking2:g16625.png?250 |}} | {{ :en:iot-open:networking2:g16625.png?250 | WiFi Star Topology}} |
<caption>WiFi Star Topology</caption> | <caption>WiFi Star Topology</caption> |
</figure> | </figure> |
| |
WiFi has become a more and more popular choice for not-so-constrained IoT devices because they need to implement a full TCP/IP stack, and those devices that are also not so constrained with power resources. A list of WiFi standards and related transmission speeds is present in Table {{ref>Ref.Tab.1.1}}. | WiFi has become a more and more popular choice for not-so-constrained IoT devices because they need to implement a full TCP/IP stack, and those devices that are also not so constrained with power resources. A list of WiFi standards and related transmission speeds is present in table {{ref>Ref.Tab.1.1}}. |
<table Ref.Tab.1.1> | <table Ref.Tab.1.1> |
<caption>WiFi Standards Summary</caption> | <caption>WiFi Standards Summary</caption> |
Bluetooth offers various "profiles" for multimedia, serial ports, packet transmission encapsulation (PAN), etc. The PAN (Personal Area Network) Profile and SPP (Serial Port) are the most useful for IoT devices. | Bluetooth offers various "profiles" for multimedia, serial ports, packet transmission encapsulation (PAN), etc. The PAN (Personal Area Network) Profile and SPP (Serial Port) are the most useful for IoT devices. |
| |
Now Bluetooth covers two branches: BR/EDR (Basic Rate/Enhanced Data Rate) for high-speed audio and file transfer connections and LE (Low Energy) for short burst connections ((https://www.bluetooth.com/what-is-bluetooth-technology/how-it-works)). | Now Bluetooth covers two branches: BR/EDR (Basic Rate/Enhanced Data Rate) for high-speed audio and file transfer connections and LE (Low Energy) for short burst connections ((https://www.bluetooth.com/learn-about-bluetooth/tech-overview/)). |
| |
Classical (before BLE and 4.0) Bluetooth networks can create ad-hoc, so-called WPAN (Wireless Personal Area Networks), sometimes referenced as Piconets. Bluetooth Piconet can handle up to 7 + 1 devices, where 1 device acts as Master and can contact up to 7 Slave devices. Only the Master device can initiate a communication. Fortunately for the IoT approach, much Bluetooth hardware can act as Slave and Master simultaneously, constituting a kind of router; thus, devices can include a tree-like structure named a scatternet. | Classical (before BLE and 4.0) Bluetooth networks can create ad-hoc, so-called WPAN (Wireless Personal Area Networks), sometimes referenced as Piconets. Bluetooth Piconet can handle up to 7 + 1 devices, where 1 device acts as Master and can contact up to 7 Slave devices. Only the Master device can initiate a communication. Fortunately for the IoT approach, much Bluetooth hardware can act as Slave and Master simultaneously, constituting a kind of router; thus, devices can include a tree-like structure named a scatternet as presented in figure {{ref>net_bt_scatternet}}. |
| |
<figure net_bt_scatternet> | <figure net_bt_scatternet> |
{{ :en:iot-open:communications_and_communicating_sut:bt_piconets.png?200 |}} | {{ :en:iot-open:communications_and_communicating_sut:bt_piconets.png?200 | Bluetooth Scatternet}} |
<caption>Bluetooth Scatternet.</caption> | <caption>Bluetooth Scatternet</caption> |
</figure> | </figure> |
| |
Bluetooth Low Energy (BLE) uses a simplified state machine implementation and thus is more constrained-devices friendly. It offers a limited range and is designed to expose the state rather than transmit streamed data. However, it provides a speed reaching up to about 1.4 Mbps (2 Mbps aerial throughput) if needed. It uses a 2.4 GHz band but is designed to avoid interference with WiFi AP and clients. Communication is organised into three advertising channels (located "between" WiFi) and 37 communication channels.\\ | Bluetooth Low Energy (BLE) uses a simplified state machine implementation and thus is more constrained-devices friendly. It offers a limited range and is designed to expose the state rather than transmit streamed data. However, it provides a speed reaching up to about 1.4 Mbps (2 Mbps aerial throughput) if needed. It uses a 2.4 GHz band but is designed to avoid interference with WiFi AP and clients. Communication is organised into three advertising channels (located "between" WiFi) and 37 communication channels.\\ |
| |
Latest Bluetooth implementations (protocol version 5.0 and newer, implemented in mid-2017) offer a Bluetooth mesh network extending ubiquitous connectivity via a many-to-many communication model dedicated to IoT devices, lighting, Industry 4.0, etc. The Bluetooth mesh is layer-organised, and since there is no longer a Master-Slave model used, but messages are relayed through the mesh, it is considered to be no longer the Scatternet because of its flat structure ((https://blog.bluetooth.com/introducing-bluetooth-mesh-networking)). Sample Bluetooth Mesh Network idea is presented in figure {{ref>bt-5-mesh}} and a review of the Bluetooth protocols in table {{ref>Ref.Tab.1.2}}. | Latest Bluetooth implementations (protocol version 5.0 and newer, implemented in mid-2017) offer a Bluetooth mesh network extending ubiquitous connectivity via a many-to-many communication model dedicated to IoT devices, lighting, Industry 4.0, etc. The Bluetooth mesh is layer-organised, and since there is no longer a Master-Slave model used, but messages are relayed through the mesh, it is considered to be no longer the Scatternet because of its flat structure ((https://www.bluetooth.com/learn-about-bluetooth/feature-enhancements/mesh/)). Sample Bluetooth Mesh Network idea is presented in figure {{ref>bt-5-mesh}} and a review of the Bluetooth protocols in table {{ref>Ref.Tab.1.2}}. |
| |
<figure bt-5-mesh> | <figure bt-5-mesh> |
{{ :en:iot-open:communications_and_communicating_sut:g3737.png?400 |}} | {{ :en:iot-open:communications_and_communicating_sut:g3737.png?400 | Example Topology of the Bluetooth 5 Mesh Network}} |
<caption>Example Topology of the Bluetooth 5 Mesh Network</caption> | <caption>Example Topology of the Bluetooth 5 Mesh Network</caption> |
</figure> | </figure> |
| |
<figure gsm_generations> | <figure gsm_generations> |
{{ :en:iot-open:networking2:gsm_evolution.png?560 |}} | {{ :en:iot-open:networking2:gsm_evolution.png?560 | GSM network evolution and generations}} |
<caption>GSM network evolution and generations</caption> | <caption>GSM network evolution and generations</caption> |
</figure> | </figure> |
| |
<figure gsm-net> | <figure gsm-net> |
{{ :en:iot-open:communications_and_communicating_sut:sim800l.jpg?150 |}} | {{ :en:iot-open:communications_and_communicating_sut:sim800l.jpg?150 | Sample GSM hardware for IoT prototyping - image 1}} |
{{ :en:iot-open:communications_and_communicating_sut:a000105_iso.jpg?200 |}} | {{ :en:iot-open:communications_and_communicating_sut:a000105_iso.jpg?200 | Sample GSM hardware for IoT prototyping - image 2}} |
<caption>Sample GSM hardware for IoT prototyping</caption> | <caption>Sample GSM hardware for IoT prototyping</caption> |
</figure> | </figure> |
| |
GSM protocols are proprietary, complex (including advanced ciphering) and require dedicated hardware. Documentation and standards are not publicly available because of security considerations (i.e., voice transmission ciphering details). | GSM protocols are proprietary, complex (including advanced ciphering) and require dedicated hardware. Documentation and standards are not publicly available because of security considerations (e.g., voice transmission ciphering details).\\ |
On the one hand, the GSM network seems to be a good solution for extended distant IoT networks. They have many disadvantages, however: they require operators' infrastructure, as GSM bands are not free, and GSM signalling requires quite decent energy. | On the one hand, the GSM network seems to be a good solution for extended distant IoT networks. They have many disadvantages, however: they require operators' infrastructure, as GSM bands are not free, and GSM signalling requires quite decent energy. |
| |
| |
== Thread == | == Thread == |
Another standard ((Thread Stack Fundamentals, Thread group, 2015)) works using the same 802.15.4 radio and is based on IPv6. There are some differences in the protocol, like address allocation. Like the Z-Wave mentioned above and Zigbee, Thread uses mesh network topology. It incorporates encryption, authentication, and secure key management to protect communication between devices on the network. It is also energy efficient, allowing devices constituting a mesh network to fall asleep and awake when only needed for communication. Those mechanisms cover (among others) asynchronous communication, scheduled sleep, routing concerning the devices' energy resources, adaptive data rates, wake-on-radio, and paging mechanisms (waking up only a selected group of devices). | Another standard ((https://www.threadgroup.org/Portals/0/documents/support/ThreadOverview_633_2.pdf)) works using the same 802.15.4 radio and is based on IPv6. There are some differences in the protocol, like address allocation. Like the Z-Wave mentioned above and Zigbee, Thread uses mesh network topology. It incorporates encryption, authentication, and secure key management to protect communication between devices on the network. It is also energy efficient, allowing devices constituting a mesh network to fall asleep and awake when only needed for communication. Those mechanisms cover (among others) asynchronous communication, scheduled sleep, routing concerning the devices' energy resources, adaptive data rates, wake-on-radio, and paging mechanisms (waking up only a selected group of devices). |
| |
== NFC == | == NFC == |
| |
== LoRa and LoRaWAN == | == LoRa and LoRaWAN == |
<todo @ktokarz>Do dorzucenia info o ograniczeniach w użyciu LoRy</todo> | LoRa (Long Range) is the technology for data transmission with a relatively low speed (20 bps do 41 kbps) and a range of about 2 km (new transceivers can transmit data up to 15 km). It uses CSS (Chirp Spread Spectrum) modulation in the 433 MHz or 868 ISM radio band. |
| |
| A chirp signal is characterized by a continuous frequency sweep over time. This means that the frequency of the transmitted signal starts at some lower frequency and continuously increases throughout the transmission of a single symbol. In LoRa the starting frequency differs depending on the symbol encoded, and while the modulated signal achieves the maximal value of the frequency starts from the minimal one. It means that each chirp uses the whole available bandwidth. Chirp Spread Spectrum modulation makes LoRa signals less susceptible to interference and noise and allows LoRa to achieve long-range communication. LoRa modulation is characterized by two parameters: |
| * **Spreading Factor** determines the speed of the signal frequency change over time. Higher spreading factors result in a longer communication range but lower data rates. It also defines the number of bits encoded by one chirp. |
| * The **Bandwidth** of the LoRa signal determines the amount of spectrum occupied by the transmitted signal. It can be 125, 250 or 500 kHz. It also specifies the sampling frequency of the signal in the receiver. |
| Having these parameters it is possible to calculate the efficient data rate (in bps). |
| Because the range of LoRa communication is long, transmitters can interfere, so some rules for the maximum time of occupation of the channel were introduced. In the European Union, the maximum percentage of transmission time known as the Duty Cycle is 1%. This gives a maximum transmission time of 864 seconds per day. Transmission should be as short as possible, and the delay between following transmissions should last a few minutes. The duty cycle together with bandwidth and spreading factor makes it possible to calculate the maximum payload of the frame and the bitrate. Some online calculators help set LoRa parameters to fulfil the local regulations ((https://www.thethingsnetwork.org/airtime-calculator)). |
| |
LoRa (Long Range) is the technology for data transmission with a relatively low speed (20 bps do 41 kbps) and a range of about 2 km (new transceivers can transmit data up to 15 km). It uses CSS (Chirp Spread Spectrum) modulation in the 433 MHz or 868 ISM radio band. The cell topology is the star, with the gateway at the central point. End devices use one-hop communication with the gateway. A LoRaWAN gateway is usually connected to the standard IP network with a central network server. The LoRa technology is supported as LoRaWAN by LoRa Alliance ((https://www.lora-alliance.org/)) designed as Sigfox for public networks. Still, it can also be used in private networks that do not require a subscription. LoRaWAN uses simplified messaging, where collisions are solved at the server level.\\ The major assumption for the LoRaWAN network is each end-node device is within a range of at least one LoRaWAN gateway.\\ | The cell topology is the star, with the gateway at the central point. End devices use one-hop communication with the gateway. A LoRaWAN gateway is usually connected to the standard IP network with a central network server. The LoRa technology is supported as LoRaWAN by LoRa Alliance ((https://www.lora-alliance.org/)) designed as Sigfox for public networks. Still, it can also be used in private networks that do not require a subscription. LoRaWAN uses simplified messaging, where collisions are solved at the server level.\\ The major assumption for the LoRaWAN network is each end-node device is within a range of at least one LoRaWAN gateway.\\ |
There are 3 classes of devices in LoRa: | There are 3 classes of devices in LoRa: |
* Class A: where downlink is active only after the device uses uplink in a particular time window (twice). It has the greatest energy efficiency among other classes. Downlink opportunity appears asynchronously, so this class is for scenarios where low latency is not a critical requirement. | * Class A: where downlink is active only after the device uses uplink in a particular time window (twice). It has the greatest energy efficiency among other classes. Downlink opportunity appears asynchronously, so this class is for scenarios where low latency is not a critical requirement. |
<figure Sample_6LoWPAN> | <figure Sample_6LoWPAN> |
| |
{{ :en:iot-open:communications_and_communicating_sut:6lowpan2.png?400 |}} | {{ :en:iot-open:communications_and_communicating_sut:6lowpan2.png?400 | Sample 6LoWPAN and Internet Integration}} |
<caption>Sample 6LoWPAN and Internet</caption> | <caption>Sample 6LoWPAN and Internet Integration</caption> |
</figure> | </figure> |
| |
6LoWPAN devices can be just nodes (Hosts) or nodes with routing capability (Routers) as presented in Figure {{ref>Sample_6LoWPAN}}. | 6LoWPAN devices can be just nodes (Hosts) or nodes with routing capability (Routers) as presented in figure {{ref>Sample_6LoWPAN}}. |
| |
The Edge Router implements a gateway between 6LoWPAN and the regular IPv6 (IPv4) network. It aims to translate "compressed" IPv6 addresses to ensure bi-directional communication between the Internet and 6LoWPAN nodes. Note – the network structure of the 6LoWPAN is logically flat (star/mesh with single addressing space), and devices have unique MAC addresses to be recognisable by the Edge Router device. | The Edge Router implements a gateway between 6LoWPAN and the regular IPv6 (IPv4) network. It aims to translate "compressed" IPv6 addresses to ensure bi-directional communication between the Internet and 6LoWPAN nodes. Note – the network structure of the 6LoWPAN is logically flat (star/mesh with single addressing space), and devices have unique MAC addresses to be recognisable by the Edge Router device. |
| |