Regarding the three classes in LoRaWAN.
In summary, class A transmits the data then listen on RX1 and RX2, class B periodically listen on RX2, Class C always listen to RX2 unless it transmits. I know that upload is the most used and download rarely used unless there is acknowledgement for a message or updating parameters to reconfigure the device, etc.
My question is why Class B and C devices usually listen and class A not listen unless it transmits.
For example, why class A does not listen to RX2 before transmitting? In this case class A mechanism will be as follow: A data ready to send --> listen on RX2 --> transmit --> listen on RX1 --> listen on RX2. While the current mechanism of class A is: transmit --> listen on RX1 --> listen on RX2.
that’s not true.
LBT … Listen Before Talk is not implemented in class A / B / C
Class A
End-devices in Class A support bi-directional communication between a device and a gateway. This operation is the lowest power end-device system, for applications which only require downlink communication from the server shortly after the end-device has sent an uplink transmission. Here Uplink messages can be sent at any time, the device then opens two receive windows at specified times after an uplink transmission. If the server does not respond in either of these receive windows, the next opportunity will be after the next uplink transmission from the device. The server can respond in either the first or second T, the transmission slot scheduled by the end-device is based on its own communication needs with a small variation based on a random time basis (ALOHA-type of protocol).
Class B
The end-devices in class B are bi-directional with scheduled receive slots. This class is similar to Class A, however, Class B devices open extra receive windows at scheduled times in addition to Class A’s random receive windows. In order for the end-device to open its receive window at the scheduled time it receives a time synchronized beacon from the gateway, allowing the server to know when the end-device is listening.
Class C
Class C end-devices are bi-directional with maximal receive slots. This means that Class C end-devices almost have continuously open receive windows, which are only closed when transmitting. This allows for low-latency communication but is many times more energy consuming than devices in Class A. Due to the amount of energy required to keep a node actively awake running the receiver at all times Class C end-devices are used primarily for AC-powered applications.
One reason is because you cannot listen to something that will happen 2 seconds later (by definition) 
. RX1 and RX2 are slots, not frequencies.
Thank you for clarify the mechanism for each class.
Thank you for clarifying this point.
But what I know about the gateway in LoRaWAN it is more than a packet forwarder. It also transmit a beacon frames. What is the role of these beacon frames? Why these beacon frames only transmitted on RX2 channel? Why Class A device do not benefit from these frames like Class B or Class C.
Please clarify for me if I misunderstood certain points on the standard.
Class A is define for lowest power use (battery based deployments) - if node continually has to keep waking up to ‘listen’ that burns extra power - its a system/use case trade off…
let’s put it this way: if Class A nodes had the same features as Class B, there would not be a need for calling them differently. As Jeff told, Class A nodes have the benefit of low consumption, which B and C do not have.
Class A can just receive data exactly 1 (RX1 slot) or 2 (RX2 slot) seconds after transmission. They start receiving only at that time, then they can to to sleep until the next time they need to send something. This is the most frequent use case: nodes send data from time to time, no need to receive.
Class B nodes, in addition, wake up regularly (they negotiate how much) and listen in case the gateway is sending something for them. They sleep less, thus they consume more.
Class C nodes are always awake listening to possible packets unless they are transmitting. To stay awake, they consume a lot of coffee
I think it would be more accurate to say that LBT is not commonly implemented in class A/B/C. It could be used in any class. LBT is just an access mechanism, like duty cycle or dwell time limitations … not part of the protocol.
From what I remember, I think Miromico use LBT in their modules.
I don’t follow … you mean in class B, right?
Based on my understanding for the LoRaWAN standard, Gateway in LoRaWAN transmits beacon frames. Yes only Class B and Class C benefit from this transmitting. My question is that what this beacon frame contain? Do they use only for synchronization? Can these beacons hold more functionality? or the standard obligated their used for certain functions?
It’s not a benefit, it is a need, and as far as I understood is only for Class B because Class C is continuously listening, so no need for synchronization (which is the aim of beacons).
Maybe if you tell what you really need, it is easier to suggest you a solution within LoRaWAN (while if you need something different, you can always build your protocol basing on pure LoRa).