LoRa vs LoRaWAN

[github4f]

Hi- Could you please let me know the gatway is for LoRa or LoRaWAN? tnx

[nullptr0807]

LoRa is a modulation technique, you can understand it as a physical layer implementation.
LoRaWAN is a protocol, a standard. It lies above the physical layer, it's a MAC layer.

[github4f]

Ya I understand that point. It is well-explained for example here: http://www.libelium.com/development/waspmote/documentation/lora-vs-lorawan/
My question is that that layer (MAC) is already supported here (in this gateway) or not?

[nullptr0807]

unfortunately it is not supported, if you see the FAQ in tutorial
here:

10. Is it LoRaWAN compliant?
    No.

Why is it not LoRaWAN compliant?
From the orientation and design choice perspective see 8) and 9) and because we want to provide a level of performance and customization that is not available with LoRaWAN. Technically, it is not LoRaWAN compliant for the following main reason:
With the gateway-centric mode of LoRa LPWAN technology, commercial LoRaWAN gateways for large-scale deployment scenarios are able to listen on several channels and LoRa settings simultaneously. They typically use advanced radio concentrators chips capable of scanning up to 8 different channels: the
4
Author : Congduc Pham, University of Pau, France page Last update : 27.11.2016
SX1301 concentrator is used instead of the SX127x chip serie which is designed for end-devices. They cost several hundredth euros with the cost of the SX1301- capable board alone to be more than a hundred euro. Our gateway uses a different approach in the context of agriculture/micro and small farm/village environments: simpler "single connection/channel" (one combination of BW, CR, SF and one frequency at a time) gateways can be built around an SX1272/76 radio module, much like an end-device would be. This design choice greatly decreases the cost and complexity of the gateway. At the same time, advanced mechanisms to limit interferences can be implemented to compensate for the "single connection/channel" limitation.
Other reasons are: different (simpler) packet format and optional network & application servers for our framework.
Our framework also does not follow the LoRaWAN standard because it wants to propose the possibility to add advanced and ad-hoc mechanisms such as:
• P2P (device-to-device) communications to allow for direct device cooperation schemes;
• LoRa repeaters functionality in end-devices to handle practical deployment issues when some sensing devices are in very remote areas, placed very close to the ground or obstacles;
• Advanced (and ad-hoc) channel access methods to increase transmission reliability;
• Advanced Quality of Service mechanism to handle the duty-cycle limit of sub-GHz transmission, providing some means of guaranteeing transmission latency;

[github4f]

I see your point. but I have a different point of view. I worked with dragino gateway. It also use exactly the same approach as this gateway. Singlechannel with SX127x (supporting only LORA, not LORAWAN). Now the issue is that only 20 nodes can connect to the gateway. Beyond than that, it faces considerable collision. So what counter measures can be used to tackle this issue in this gateway? It is better buy an expensive one (250$) which can handle 1000 nodes, or installing 50 gateways (1000/20=50) which cost 50*30=1500$? I appreciate your comment.

[CongducPham]

I'm a bit surprised by the limit of 20 nodes that you mention. You can handle much more with appropriate device randomization and also channe access method such as CSMA-like mechanism, which is implemented in our lib. regards, Le 17/04/2017 à 10:21, Farshad a écrit :

I see your point. but I have a different point of view. I worked with dragino gateway. It also use exactly the same approach as this gateway. Singlechannel with SX127x (supporting only LORA, not LORAWAN). Now the issue is that only 20 nodes can connect to the gateway. Beyond than that, it faces considerable collision. So what counter measures can be used to tackle this issue in this gateway? It is better buy an expensive one (250$) which can handle 1000 nodes, or installing 50 gateways (1000/20=50) which cost 50*30=1500$? I appreciate your comment. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#90 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABNEN9FYv8gfO8KZdE6mL3NElsxNKI7Aks5rwyEcgaJpZM4M-sg->.

C. Pham.

…

-- |------------ Congduc PHAM - Professor --------------------------| | LIUPPA - Equipe T2I | U.P.P.A. Pau | | http://liuppa.univ-pau.fr/ | http://www.univ-pau.fr | |----------------------------------------------------------------| |UPPA, LIUPPA laboratory, UFR Sciences et Techniques | |Avenue de l'Université - BP 1155 | |64013 PAU CEDEX, FRANCE | | | |phone: [33] (0) 5 59 40 75 94 | |fax: [33] (0) 5 59 40 76 54 | |Congduc.Pham@univ-pau.fr http://www.univ-pau.fr/~cpham | |----------------------------------------------------------------|

[github4f]

In the manual it is mentioned that "if the end nodestrytosend data to the gateway at every 5 minutes, there will be data lost after the network has 20~30nodes due to Channel Collision"! Source: http://www.dragino.com

Do you have any experience to see how many nodes can be connected to the this gateway. Assumption: every 5 minutes we send 32B data. And max distance between nodes and the gateway is around 5km. Thanks and regards.

[CongducPham]

I don't know where the problem is with Dragino. I can tell you that this mentioned limit has not actual reasons. regards, Le 17/04/2017 à 10:36, Farshad a écrit :

In the manual it is mentioned that "if the end nodestrytosend data to the gateway at every 5 minutes, there will be data lost after the network has 20~30nodes due to Channel Collision"! Source: http://www.dragino.com Do you have any experience to see how many nodes can be connected to the this gateway. Assumption: every 5 minutes we send 32B data. And max distance between nodes and the gateway is around 5km. Thanks and regards. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#90 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABNEN_FMhQHajRvCKoVGa_qM0g_A9sCHks5rwySPgaJpZM4M-sg->.

C. Pham.

…

-- |------------ Congduc PHAM - Professor --------------------------| | LIUPPA - Equipe T2I | U.P.P.A. Pau | | http://liuppa.univ-pau.fr/ | http://www.univ-pau.fr | |----------------------------------------------------------------| |UPPA, LIUPPA laboratory, UFR Sciences et Techniques | |Avenue de l'Université - BP 1155 | |64013 PAU CEDEX, FRANCE | | | |phone: [33] (0) 5 59 40 75 94 | |fax: [33] (0) 5 59 40 76 54 | |Congduc.Pham@univ-pau.fr http://www.univ-pau.fr/~cpham | |----------------------------------------------------------------|

[Kevin-Sangeelee]

Dragino are hardware people (which they are good at), and the software is only to show that the hardware is working. The example you referred to uses a crude retry mechanism that is quick to discard data. Where coding/chirp/spreading settings result in long transmissions, it's easy to see how they could hit this limit with 30 units on a 5 minute transmit period when using the example sketch. You would really have to modify it to be of use in production (or use more sophisticated software, such as LowCostLoRaGw!). As an aside, the example uses the ThingSpeak library for Arduino, which offers very little for the amount of microcontroller memory used. It's far more efficient to simply form a URL string. Kevin

…

On 17 April 2017 at 09:36, Farshad ***@***.***> wrote: In the manual it is mentioned that "if the end nodestrytosend data to the gateway at every 5 minutes, there will be data lost after the network has 20~30nodes due to Channel Collision"! Source: http://www.dragino.com Do you have any experience to see how many nodes can be connected to the this gateway. Assumption: every 5 minutes we send 32B data. And max distance between nodes and the gateway is around 5km. Thanks and regards. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#90 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACV12FyfZ6EJ3FXx9Xr2bmp1hHVRAv5iks5rwySPgaJpZM4M-sg-> .