doc: Revised device classes (#539)

doc/content/lorawan/classes/_index.md

@@ -6,77 +6,71 @@ images:
 - class-a.png
 ---
 
-The LoRaWAN specification defines three device types: **Class A**, **Class B**, and **Class C**. All LoRaWAN devices must implement Class A, whereas Class B and Class C are extensions to the specification of Class A devices. All device classes support bi-directional communication (uplink and downlink)
+The LoRaWAN specification defines three device types: **Class A**, **Class B**, and **Class C**. All LoRaWAN devices must implement Class A, whereas Class B and Class C are extensions to the specification of Class A devices. All device classes support bi-directional communication (uplink and downlink). During firmware upgrades over-the-air (FUOTA), a device must be switched to Class B or Class C.
 
 {{< note "End devices can’t send uplink messages while they receive downlink messages." />}}
 
 ## Class A
 
-All LoRaWAN end-devices must support **Class A** implementation. Class A communication is always initiated by the end-device. A device can send an uplink message at any time. Once the uplink transmission is completed the device opens two short receive (downlink) windows. There is a delay between the end of the uplink transmission and the start of the receive windows (RX1 and RX2 respectively. If the network server does not respond during these two receive windows, the next downlink will be after the next uplink transmission.
+All LoRaWAN end-devices must support Class A implementation. A Class A device can send an uplink message at any time. Once the uplink transmission is completed, the device opens two short receive windows for receiving downlink messages from the network. There is a delay between the end of the uplink transmission and the start of each receive window, known as RX1 Delay and RX2 Delay, respectively. If the network server does not respond during these two receive windows, the next downlink will be scheduled immediately after the next uplink transmission.
 
 ![Class A Receive Windows](class-a.png)
 
-_Figure: Class A receive windows_
-
-The server can respond during the first receive window (RX1), or during  the second receive window (RX2), but does not use both windows.  Let’s consider three situations for downlink messages as illustrated below.
+The network server can respond during the first receive window (RX1) or the second receive window (RX2), but does not use both windows. Let's consider three situations for downlink messages as illustrated below.
 
 ![Class A Receive Windows](class-a-alt.png)
 
-_Figure: Behaviour of Class A receive windows_
+1. The end device opens both receive windows but it doesn’t receive an downlink message during either receive window.
+2. The end device receives a downlink during the first receive window and therefore it does not open the second receive window.
+3. The end device opens the first receive window but it does not receive a downlink. Therefore it opens the second receive window and it receives a downlink during  the second receive window.
 
-* **Case 1:** The end device opens both receive windows but it doesn’t receive an downlink message during either receive window.
-* **Case 2:**  The end device receives a downlink during the first receive window and therefore it does not open the second receive window.
-* **Case 3:** The end device opens the first receive window but it does not receive a downlink. Therefore it opens the second receive window and it receives a downlink during  the second receive window.
+Class A end devices have very low power consumption. Therefore, they can operate with battery power. They spend most of their time in sleep mode and usually have long intervals between uplinks. Additionally, Class A devices have high downlink latency, as they require sending an uplink to receive a downlink.
 
-Class A end devices:
+The following are some of the use cases for Class A end devices:
 
-*   are often battery-powered
-*   have the lowest energy consumption
-*   spend most of the time in sleep mode
-*   usually keep long intervals between uplinks
-*   have high downlink latency (to receive a downlink, the end device must send an uplink)
+- Environmental monitoring
+- Animal tracking
+- Forest fire detection
+- Water leakage detection
+- Smart parking
+- Asset tracking
+- Waste management
 
-Some common use cases for Class A end-devices:
+## Class B
 
-*   Environmental monitoring
-*   Animal tracking
-*   Fire detection
-*   Water leakage detection
-*   Earthquake early detection
-*   Location tracking
+Class B devices extend Class A capabilities by periodically opening receive windows called **ping slots** to receive downlink messages. The network broadcasts a time-synchronized beacon (unicast and multicast) periodically through the gateways, which is received by the end devices. These beacons provide a timing reference for the end devices, allowing them to align their internal clocks with the network. This allows the network server to know when to send a downlink to a specific device or a group of devices. The time between two beacons is known as the **beacon period**.
 
-## Class B
+After an uplink, the two short receive windows, RX1 and RX2 will open similar to Class A devices.
 
-In addition to the class A initiated receive windows, **Class B** devices open  scheduled receive windows for receiving downlink messages from the network server. Using time-synchronized beacons transmitted by the gateway, the devices periodically open receive windows. The time between two beacons is known as the beacon period. 
-The device opens downlink ‘ping slots’ at scheduled times for receiving downlink messages from the network server.
-Class B devices also open receive windows after sending an uplink, as you can see below:
 
 ![Class B Receive Windows](class-b.png)
 
-_Figure: Class B receive windows_
-
-Class B end devices have lower latency than the Class A end devices, because they are reachable at preconfigured times and do not need to send an uplink to receive a downlink. The battery life is shorter in Class B than Class A, because the device spends more time in active mode, during beacons and ping slots. 
+Class B end devices have low latency for downlinks compared to Class A end devices because they periodically open ping slots. However, they have much higher latency than the Class C end devices. Class B devices are often battery powered. The battery life is shorter in Class B compared to Class A because the devices spend more time in active mode due to receiving beacons and having open ping slots. Because of the low latency for downlinks, Class B mode can be used in devices that require medium-level critical actuation, such as utility meters.
 
-Some common use cases for Class B end-devices:
+The following are some of the use cases for Class B end devices:
+- Utility meters (electrical meters, water meters, etc)
+- Street lights
 
-*   Utility meters
-*   Temperature reporting
+Class B devices can also operate in Class A mode.
 
 ## Class C
 
-**Class C** devices extend Class A by keeping the receive windows open unless they are transmitting, as shown in the figure below. This allows for low-latency communication but is many times more energy consuming than Class A devices.
+Class C devices extend Class A capabilities by keeping the receive windows open unless transmitting an uplink, as shown in the figure below. Therefore, Class C devices can receive downlink messages at almost any time, thus having very low latency for downlinks. These downlink messages can be used to activate certain functions of a device, such as reducing the brightness of a street light or turning on the cut-off valve of a water meter.
+
+Class C devices open two receive windows, RX1 and RX2, similar to Class A. However, the RX2 receive window remains open until the next uplink transmission. After the device sends an uplink, a short RX2 receive window opens, followed by a short RX1 receive window, and then the continuous RX2 receive window opens. This RX2 receive window remains open until the next uplink is scheduled. Uplinks are sent when there is no downlink in progress.
 
-![Class C Receive Windows](class-c.png)
 
-Class C end devices:
+![Class C Receive Windows](class-c.png)
 
-*   are often mains powered
-*   have no downlink latency - continuous receive window
+Compared to Class A and Class B devices, Class C devices have the lowest latency. However, they consume more power due to the need for opening continuous receive slots. As a result, these devices cannot be operated with batteries for long time therefore they are often mains powered.
 
-The following are some common **Class C** end device **applications**, but there are more:
+The following are some of the use cases for Class C end devices:
+- Utility meters (electrical meters, water meters, etc)
+- Street lights
+- Beacon lights
+- Alarms
 
-*   Utility meters with cut-off valves/switches
-*   Streetlights
+Class C devices can also operate in Class A mode.
 
 ##  Questions