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.

This is possible, but there would be a need to convert an existing 802.15.4 or other mesh protocol to use the modulation format. Because of some of LoRa's features such as longer transmission time which increases link budget, single-hop is usually the best choice.

No, you do not need a gateway. You can easily implement simple protocols using LoRa, either with modules or with the chips themselves.

There are two primary reasons why you should use a module:

1. It accelerates development, and you don’t have to write a whole bunch of underlying code to implement the radio system.
2. It’s already fully FCC or ETSI certified, so you don’t have to go through expensive testing.

The open source code available online for LoRaWAN is implementing the LoRaWAN protocol for a chip-down implementation. If you go down this route the RF certification and LoRaWAN Certification will need to be re-done. 

The SX1301 device is the baseband signal processor for LoRa gateways. It takes 32 MHz, 1-bit I/Q digital baseband samples as an input. It is generally paired with two SX1257 front end digitizers, though it can be used with other forms of digital RF. This is often done with the 8 x SX1301 gateway architecture Senet uses in its network deployment.

It is possible to transmit and receive the LoRa modulation at many frequencies between 150 MHz and 1 GHz, such as 169 MHz, 433 MHz, etc. even in the licensed spectrum. However, most of the LoRa devices from Semtech have gaps in the sub-GHz band where they can’t transmit or receive. The Semtech gateway architecture is designed to operate only at 850 MHz to 1 GHz, although it could be easily adapted for other frequencies.

SX1272 has three programmable LoRa bandwidth settings: 500 kHz, 250 kHz and 125 kHz. It covers bands from 850-1 GHz.

SX1276 has bandwidths from 500 kHz to 7.8 kHz, and covers 150 MHz bands, 433 MHz, and 850-1 GHZ.

LoRa is a modulation format and the associated family of chips are from Semtech.

SIGFOX is a company that uses narrowband D-BPSK modulation to do wide area IoT networking.

NWave is a company that does some very similar things to SIGFOX using the Weightless standard.

Other ultra-narrowband companies work with a broader family of transceiver chips, but LoRa is available mostly from Semtech, and more recently from ST Microelectronics.

Semtech’s spread-spectrum modulation is well adapted for mobile applications, being insensitive to Doppler shift, and it also enables GPS-less geo-location, two areas where any narrow-band technology would struggle.

Lora gateways or concentrators are designed to be used in long range star network architectures and are utilized in a LoRaWAN system. They are multi-channel, multi-modem transceivers and can demodulate on multiple channels simultaneously and even demodulate multiple signals on the same channel simultaneously due to the properties of LoRa.

The gateways use different RF components than the end-point to enable high capacity and serve as a transparent bridge relaying messages between end-devices and a central network server via standard IP connections while end-devices use single-hop wireless communication to one or many gateways.

All end-point communication is generally bi-directional, but also supports operations such as multicast enabling, software upgrade, over the air or other mass distribution messages to reduce the on air communication time.

There are different gateway versions depending the desired capacity and installation location (home vs. tower).

The term gateway and concentrator are both used, but they are equivalent components in a LoRa system. In other industries the definition of gateway and concentrator may imply different components.

Accuracy is affected by many parameters, however, with good network planning and coverage, one can expect a mean uncertainty of 120m to 200m in an 8-channel urban LoRaWAN deployment. Packet repetition (time and frequency) diversity has a powerful effect. The sensor will normally randomly select one of the configured channels to transmit any particular packet. This inherently implies frequency diversity with packet repetition.

In field trials conducted in an urban environment configured with eight LoRaWAN uplink channels, the advantage of packet repetition diminishes significantly after 6-8 packets. This suggests that the most significant part of the gain in packet repetition is provided by the frequency diversity effect of transmitting on different channels. Therefore, it is not recommended to configure for packet repetitions beyond the number of channels configured in the LoRaWAN system.

An example is shown below (an 8-channel system in an urban environment): 

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 device's uplink can be received by two networks simultaneously
• The device doesn't even know that it is roaming

• For passive roaming we need to use different network session keys for uplinks and downlinks:
  • LoRa V 1.1 implements a new dual NettSkey key derivation.
  • The scheme reverts back to 1.0 if the server does not support it.

• 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. 

With the early trial data, Semtech is recommending a 3km ISD in most rural cases as a guideline. There is, however, no substitute for detailed network planning and the coverage target should be four gateways. Targeting a configuration giving a four gateway redundancy means that in most cases, the sensor will be in coverage of all four, and in almost all cases will have the required minimum of three. 

Version 1 of Semtech’s solver requires approximately 1.2kB of storage per device.