There is no such concept as a LoRa gateway or LoRaWAN gateway. A LoRa gateway can be connected to a LoRaWAN network server, in other words a server running LoRaWAN protocol, or to another server running another protocol. In fact, only gateways with eight channels or more are considered LoRaWAN-capable.

No, LoRa devices can be used like any other RF transceiver in existing applications with custom proprietary protocols. However, using LoRaWAN will significantly improve time to market. The stack, having similarities to 802.15.4,  is FCC and ETSI compliant and offers all the security needed by a modern RF protocols (network key, unique Id for each end point, AES128 encryption... ). LoRaWAN also offers the possibility to be used in private AND public networks.

The "JoinAccept" message is decrypted by the Application Server (AS) and  not the Network Server (NS). 

The AS is allowed to see the end-device application data but the NS is not. 

The AS exchanges key information with the end-device through the NS (the NS forwards the messages but doesn’t understand them). 

At the end of the exchange, when the session keys have been calculated, the AS gives the network session key to the NS.   

LoRaWAN data rates range for LoRa between 0.3 kbps to 11 kbps, and one GFSK data rate at 50 kbps for Europe. In North America, the minimum data rate is 0.9 kpbs due to FCC rules. To maximize both battery life of the end-devices and overall network capacity, the LoRaWAN network server is managing the data rate and RF output power for each end-device individually by means of an adaptive data rate (ADR) algorithm. The ADR is critical for a high performance network and it enables scalability. A network can be deployed with a minimal investment in infrastructure, and as capacity is needed, more gateways can be deployed and the ADR will shift the data rates higher which will scale the network capacity. 

No, LoRaWAN as a protocol is strictly for wide area networks, but LoRa as a lower-level physical layer technology (PHY) can be used in all sorts of applications outside of wide area.

The LoRaWAN certification process with Espotel is as follows:

1. Contact Espotel for a quote. We can guide you through the whole process.
2.  Prepare your product(s) for certification. We can guide you through these requirements.
   • Must fulfill 2015-LoRaWAN_Specification_1R0_611_1. The specification is available from the LoRa Alliance.
   • Must fulfill LoRa Alliance End Device Certification Requirements for EU. The specification is available from the LoRa Alliance.
3. Fill in the certification questionnaire. The questionnaire is available from the LoRa Alliance.
4. Send your product to us. It should be ready for Over the Air activation or already personalized.
5. We run the certification tests and send you the results.
6.  If test passed, either we or you can provide the results to LoRa Alliance.
7.  If test failed we will give you the diagnostics and help you to fix the problem. Then follows a retest (step 4 again).
8.  Alliance reviews the passed test result and produces the LoRaWAN certificate.

Results and basic product information are released on LoRa Alliance web page. This can be delayed if a certain product launch date is requested.

Full guidance through the LoRaWAN certification process. The certification testing includes test diagnostics and instructions for corrections in case your node fails.

Also a single retest round is included in the price if the node fails.

No, regulatory testing can take place before, after or at the same time as the LoRaWAN certification testing.

Espotel can also help you with the regulatory approvals, so that you get a full turnkey solution for your testing, certification and regulatory approval needs.

Every network operator agrees that they can only connect 10-15% of the predicted volume of IoT devices with cellular. WiFi and BTLE serve some applications well, but clearly are not going to connect moisture sensors for agriculture with WiFi. LPWAN, with the inherent long range and low power characteristics will be the ‘goto’ technology for IoT applications where remote locations, easy deployment, thousands of connections per gateway and long battery life are required.

Most analysts predict that 45-55% of predicted IoT volumes will be in the LPWAN space, see also the comparative volumes below as per SNS Research.

The main IoT applications for LPWA technology need a long battery life to enable 'fit and forget' or disposable end-devices, a low cost sensor or end-device BOM, and long range connectivity.

The applications where LPWAN's are applicable are endless, but if you look at the main applications driving the current network deployments they are intelligent building, supply chain, Smart City and agriculture. In intelligent building the main value driver is in insurance premiums and servicing.

In cold regions a broken water pipe has an approximate insurance claim of $50K, so insurance companies offer a premium discount if a building management solution is utilized. Having sensors know if the building or room was used can have significant reductions in service management and related expenses.

In supply chain any application that has a delivery or pick-up with associated inventory can have huge savings in inventory management and delivery route optimization. A smart trash monitoring solution reduces pick-ups by 40%.

In agriculture the needs are driven by growing food demands. Agricultures accounts for 80% percent of water usage, and the value of crops is extremely high, so having sensors to determine water usage, health of soil/crop, etc. is extremely important. Accurate irrigation and soil monitoring translates into significant cost savings in resource usage and improved profit with improved yields.  

The 64 bit Extended Unique Identifier (EUI) is comprised of two parts, the 24 bit Organisationally Unique Identifier (OUI) and a 40 bit serial number. The OUI is allocated  by the IEEE, and the serial number by anyone that owns an OUI, together they form the EUI. AppEUI and DevEUI are both special cases of EUI.

FPort values 1..223 are application specific with their meaning being defined by the application provider. The LoRa Alliance has not specified an assignment for any port in this range to a particular application.

The network server will pass the FCnt (specifically the FCntUp) to the application layer as part of the MACPayload Frame header (FHDR) as specified in 4.3.1 of 1.0.3 of the LoRaWAN Specification. The Application Session Key (AppSKey) along with the FCntUp and DevAddr are used in the decryption of the payload data (FRMPayload) as described in 4.3.3 of the LoRaWAN Specification.

If a time is booked for certification and an end node provided,  the test report will be delivered within one weeks’ time from the booked date.

The LoRaWAN certification testing tests for end node functionality, in other words it tests that node’s LoRaWAN protocol stack and application are compliant with the LoRaWAN specification.

The certification does not cover radio performance. Radio performance includes things such as the radiated power, radio sensitivity etc. These are key parameters for good performance when signal strength is poorer. This is also something where Espotel can help you.

For a network operator it would be useful to set minimum acceptable performance requirements for nodes. This would ensure that end customers get the best possible network coverage. If you are a LoRaWAN network operator, Espotel could help you to setup end node requirements. If you are an end node manufacturer Espotel may perform performance testing for your nodes.

Two kinds of complimentary roaming processes for mobile devices have been defined in LoRaWAN R1.1

• Passive roaming
• Hand over roaming

Together with:

• Class B
• Temporary class A/C mode switching

• The mobile device is handed over to another network operator
• Data is still routed through the home network

• For handover roaming the device must periodically broadcast a special"rejoin request" frame.
• The rejoin request frame has been defined in LoRaWAN Rev 1.1

• LoRaWAN Rev 1.1 is required for mobile roaming between networks without interruption.
• Service provided over multiple public partner networks with non-nomadic devices.

• NetID is a 24 bit network identifier which gives the possibility of 16 million networks.
• NetID is part of the Rejoin frame broadcast by roaming end devices used to find the home network of a device.
• NetID is allocated by the LoRa alliance.
• NwkID consists of the 7 LSBs of NetID.
• All DevAddr of a network start with NwkID

• A lot more than 2^25 = 33 million
• Actual device identifier is DevAddr+NetSKey so the same DevAddr can be reused many times.

The answer is many billions. Once you reach a billion a new NetID will be allocated by the Alliance.