Lpwan tunneling relay

Abstract

The Tunneling Relay provides a tunnel between the end devices and the Gateway for Long-Range Wide Area Network (LoRaWAN) network by encapsulating with its header and repeating not only the uplink and downlink packets but also the join requests and Medium Access Control (MAC) commands coming from end devices and the gateway, respectively. Furthermore, there is no need to meet the tunneling relay with the end device with the use of encapsulation.

Description

DESCRIPTION LPWAN TUNNELING RELAY TECHNICAL FIELD

[0001] The invention relates to a novel hardware design and application and link layer protocol for a Long Range Wide Area Network (LoRaWAN) range extender relay device. BACKGROUND ART

[0002] LoRaWAN is a low-power, wide-area networking protocol designed to control the medium access control (MAC) layer of the devices that are using Long-Range (LoRa) modulation [LR2020]. There are three MAC classes defined in the LoRaWAN specification, Class A, Class B, and Class C.

[0003] Class A devices are the most common devices in the LoRaWAN networks, they are battery-powered and they have a limited energy budget. Class A devices are designed to be energy-efficient, hence they can only transmit data to the gateway in the uplink window, and they can only receive data from the gateway in the downlink window, which is opened by the gateway after the uplink transmission of the device.

[0004] Class B devices are also battery-powered, but they have an additional receive window, which is opened by the device at specific intervals. The receive window can also be controlled by the beacon coming from the gateway.

[0005] Class C devices are always listening for data, hence they are not preferred to be battery-powered, they are usually connected to the power grid.

[0006] The LoRaWAN specification also defines the LoRaWAN gateway, which is the device that receives the uplink packets from the end devices and sends the downlink packets to the end devices. The gateway is connected to the network server, which is responsible for the management of the network, such as the activation of the end devices, the encryption keys, the network addresses, etc.

[0007] The network server is also responsible for the routing of the packets between the end devices and the application server, which is the server that processes the data coming from the end devices and sends the commands to the end devices.

[0008] The LoRaWAN specification also defines the LoRaWAN relay, which is a device that extends the coverage of the network by relaying the packets between the end devices and the gateway. LoRaWAN relays are an essential component in the network architecture, allowing for the extension of network coverage in areas where direct communication between devices and gateways is not possible [LRRELAY2022].

[0009] The recent announcement by the LoRa Alliance regarding the new relay specification is a significant step forward for the technology. The new specification defines a standard for relays, which will enable interoperability between different vendors and ensure that the tunneling relays are compliant with the LoRaWAN protocol.

[0010] The specification defines three types of relays: Class A, Class B, and Class C. Class A relays operate on a time-synchronized schedule and can only transmit during a specific window of time [LRRELAY2022]. Class B relays have an additional receive window, allowing them to receive data from devices at specific intervals. Class C relays are always listening for data, providing continuous coverage for devices.

[0011] One of the key benefits of LoRaWAN relays is their ability to extend network coverage without requiring additional gateways. This is particularly useful in areas where it may be challenging to install new gateways, such as in rural or remote locations. Relays can be installed in strategic locations to extend the range of the network and ensure that devices can communicate with gateways over longer distances.

[0012] Another benefit of LoRaWAN relays is their low power consumption. Relays are typically powered by batteries and can operate for extended periods without requiring maintenance. This is particularly useful in applications where it may not be practical to run power cables to the tunneling relay location.

[0013] LoRaWAN relays play a vital role in extending the coverage of the network and ensuring that devices can communicate with gateways over longer distances. The new relay specification announced by the LoRa Alliance is a significant step forward for the technology, providing a standard for interoperability between different vendors and ensuring that relays are compliant with the LoRaWAN protocol. As the technology continues to evolve, we can expect to see further advancements in the capabilities of LoRaWAN relays, making them an increasingly important component in the Internet of Things (IoT) ecosystem.

[0014] References: [LR2020] LoRaWAN Link Layer Specification v1.0.4, LoRa Alliance, 2020. [LRRELAY2022] LoRaWAN Relay Specification v1.0.0, LoRa Alliance, 2022. SUMMARY OF INVENTION

[0015] The present invention relates to a relay device that enables long-range, low-power communication between a large number of Long-Range Wide Area Network (LoRaWAN) end devices and a LoRaWAN gateway. The tunneling relay device is designed to overcome the range limitations of conventional LoRaWAN networks by providing a wireless bridge between end devices and the gateway. The tunneling relay device operates as a tunneling mechanism, where the uplink packets from the end devices are encapsulated and sent to the gateway, and the downlink packets from the gateway are decapsulated and sent to the respective end device. This way, the coverage of the network is greatly increased without deploying more gateways and increasing the cost.

[0016] The main advantage of the invention is that it requires no change in the end devices and the gateway, they operate as usual, oblivious to the tunneling relaying mechanism. The only adjustment needs to be made at the network server, which should be aware of the tunneling relays so that it can perform the encapsulation / decapsulation procedure for the tunneling relay frames.

[0017] The tunneling relays join the LoRaWAN network sending standard join frames to the gateway. The network server provides the necessary session keys to the tunneling relay as if they are end devices, but it has the list of device Identification Numbers (IDs) that are relays, hence it is aware that this joining device is a relay. Then, the tunneling relay starts to operate, if it receives an uplink frame from an end device, either a join request or an uplink frame, it regards the whole packet as its payload and encapsulates it with its own LoRaWAN header. It also encrypts the packet with its keys. When the gateway receives this frame, it regards it as some regular uplink from an end device, since it is oblivious to the tunneling mechanism, and gives it to the network server. The network server knows this is a relay packet, hence when it decrypts the payload, it knows that it is a whole frame from an end device, hence the end device frame is obtained at the network server. This completes the tunneling relaying mechanism for uplink packets.

[0018] For the downlink packets, the network server knows to which relay the destination end device is connected, since it relayed the join request of the end device before, and it encapsulates the downlink for the device in a frame destined for the tunneling relay. When the tunneling relay receives the frame, it decapsulates it and sends the downlink frame to the destination end device, this completes the tunneling relaying mechanism for downlink packets.

[0019] The main purpose of the invention is to increase the LoRaWAN network coverage, as it is a relay. With that said, using a relay instead of deploying more gateways to increase coverage can only be logical if it costs significantly less. The invention can perform the specified functionality with the standard end device hardware, hence it wouldcost significantly less than a gateway. Some LoRaWAN relays suggested in the literature use gateway hardware, which makes the invention advantageous in the current LoRaWAN market. It should be stated that the use of relays is far from being prevalent as of the writing of this document, and there is no detailed relay specification to dominate the market. The low cost of the invention makes it a significant option for wide adoption in the market.

[0020] Another major advantage of the invention, as hinted in the brief description, is that it requires no changes in the end devices and the gateway, which may already be purchased and deployed by the customer. It only requires calibration in the network server to know the tunneling relay device IDs and act according to the encapsulation / decapsulation scheme already explained. This means the tunneling relay can also be used in the already deployed LoRaWAN networks and maybe some gateways could be used elsewhere, again decreasing the cost significantly. Some other relay suggestions in the market or the literature generally alter the end device and / or the gateway operation, meaning the devicefirmware would need an update. With itsflexibility in this aspect, the invention has a further advantage to be widely adopted in the market.

[0021] The invention increases the LoRaWAN network coverage with a novel relaying mechanism that avoids the disadvantages of a simple listen-and-repeat relay in the following two paragraphs.

[0022] The invention can work with standard end device hardware which significantly decreases the cost.

[0023] The invention uses a tunneling mechanism with encapsulation / decapsulation at the tunneling relay and the network server without imposing any changes on the end devices and the gateway.

[0024] It should be noted that the invention is subject to Industrial, Scientific, and Medical (ISM) band regulations similar to all the other LoRaWAN devices, hence if the traffic load is high on the device the duty cycle limitation of the ISM band may result inpacket drops in the network. With that said, the Internet of Things (IoT) market that LoRaWAN networks dominate does not have such characteristics in general, the sensor data sent by the end devices have periods generally in the order of minutes or even hours, hence the duty cycle limitation is already satisfied without effort.BRIEF DESCRIPTION OF DRAWINGS

[0025] FIG. 1 Encapsulation between the tunneling relay and NS

[0026] FIG. 2 Encapsulated packet format

[0027] FIG. 3 Uplink (blue) and Downlink (red) packetflows for LoRaWAN network (a) without the tunneling relay and (b) with the tunneling relay

[0028] FIG. 4 The Join-Request frame

[0029] FIG. 5 Encapsulated Join-Request frame

[0030] FIG. 6 Encapsulated Join-Accept frame

[0031] FIG. 7 Encapsulated Uplink and Downlink frame structureDETAILED DESCRIPTION

[0032] The main purpose of the tunneling relay is to provide Long-Range Wide Area Network (LoRaWAN) connectivity to the end devices that are suffering poor channel conditions to reach the Gateway. For this purpose, it encapsulates the end device uplink frames before relaying them to the gateway, which is decapsulated by the Network Server (NS), as shown in FIG. 1. The downlink packets to the end devices are handled in the same manner, they are encapsulated in the NS and decapsulated in the tunneling relay. Since the Gateway and the end devices are oblivious to this tunneling mechanism, they operate as they did in a standard LoRaWAN network.

[0033] Long-Range (LoRa) Alliance has recently published Relay Specification. The specification outlines a relay that is energy-constrained and runs on batteries. For this reason, it employs a Wake on Radio (WOR) mechanism that enables the tunneling relay to sleep for most of the time. However, to implement the requirements of the specification, the end devicefirmware must be updated. This introduces an interoperability problem with the already deployed end devices. Moreover, in many relay scenarios, the tunneling relay does not have strict energy constraints, at least not as much as end devices. Hence, we suggest another approach that enables a tunneling mechanism between the tunneling relay and the network server. In this way, the already deployed end devices and the Gateways are oblivious to the change and they operate as usual, without any updates.

[0034] The Tunneling Mechanism is established by an additional encapsulation method, where the tunneling relay regards the LoRaWAN uplink packets of the end devices as its payload and adds its packet header to construct a new packet as seen in FIG. 2. Here, the end device headers are standard uplink frame headers defined in the latest LoRaWAN Link Layer Specification, whosefields arefilled by the end device. The tunneling relay header isagain a standard uplink frame header, itsfields arefilled by the tunneling relay. The end device encrypts its payload with the keys it obtained in the Join process, and the tunneling relay encrypts its payload, which is the whole packet of the end device, with the keys it obtained in its own Join process. This way, the header of the end device, which is now a part of the tunneling relay payload, is encrypted for better security.

[0035] The Gateway is not aware of this whole encapsulation process and the uplink packet of the tunneling relay seems like an ordinary uplink packet to the Gateway, which includes a header and an encrypted payload as usual in the LoRaWAN packet format defined in the latest LoRaWAN Link Layer Specification. This means, the Gateway regards the tunneling relay as just another end device. The decapsulation process will be done in the network server (NS), which knows which devices are end devices and which devices are relays so that it can perform the decapsulation / encapsulation for the tunneling relay uplinks / downlinks. Now, all the parties in the process such as the end device, Gateway, Relay, and network server will be explained in detail.

[0036] The end devices are oblivious to the existence of the tunneling relaying process, they operate as usual like they are connected directly to the Gateway. Theyfirst transmit the Join-Request frame to the network, whosefields are defined in the latest LoRaWAN Link Layer Specification. In the case that the Join-Request frame directly reaches the Gateway, the response of the NS, the Join-Accept frame, is sent back by the Gateway directly to the end device. However, if the Join-Request frame is only detected by the tunneling relay, it encapsulates it with its uplink frame header (it is assumed that the tunneling relay already sent the Join-Request and received the Join-Accept) and sends it to the Gateway. The Join-Accept frame for the end device also comes encapsulated by the NS, which is decapsulated at the tunneling relay and sent to the end device. Then, the end device starts transmitting its standard uplink frames, which are again either received directly by the gateway or encapsulated and relayed by the tunneling relay. Either way, the end device transmits the same uplink frame and receives the same downlink frame. Thisensures that the end devices already deployed have interoperability with the new relay.

[0037] The downlink and uplink packet directions are shown in FIG. 3. In FIG. 3A the standard end device - gateway - network server packet transitions are illustrated. In FIG. 3B the end device - relay - gateway - network server packet transitions are illustrated.

[0038] The activation process of the tunneling relay has no difference from the standard LoRaWAN devices. It can be activated by both Over-the-air activation (OTAA) and activation by personalization (ABP). The tunneling relay device has its session keys.

[0039] For OTAA, the activation is done in the following way. The tunneling relay sends a Join-Request frame to the Gateway. The Gateway forwards the Join-Request frame to the Network Server. The Network Server sends a Join-Accept frame to the Gateway. The Gateway forwards the Join-Accept frame to the tunneling relay. the tunneling relay receives the Join-Accept frame which includes session keys and starts to operate.

[0040] For ABP, the activation is done by the tunneling relay vendor. The tunneling relay vendor sets the session keys and the Network Server address of the tunneling relay. The tunneling relay starts to operate just after it is powered up.

[0041] The session keys are used to encrypt the FRMPayload and calculate the message integrity code (MIC).

[0042] The tunneling relay starts its operation by sending a Join-Request to the Network Server via the Gateway. The NS recognizes the tunneling relay by checking its Device Address (DevAddr). The NS responds to the tunneling relay with a Join-Accept frame and from that point on, the NS will be aware that the uplinks from the tunneling relay are encapsulated end-device packets. Furthermore, when the NS wants to send a downlink frame to the end devices, it will encapsulate the packet with the header of the tunneling relay. After the Join procedure is done between the tunneling relay and the NS, the tunneling relay encapsulates the uplink packets that are coming from end devices and decapsulates the downlink packets that are coming from the NS. In this way, a logical link is established between the NS and the end devices, which corresponds to the functionalityof the Gateway. the tunneling relay gets the identification numbers (IDs) of active Relays from NS and stores them. The active Relays list is updated in specific periods via predefined medium access control (MAC) commands.

[0043] In this new relay scenario, the functionality of the Gateway remains the same as the already specified version in the technical specifications latest LoRaWAN Link Layer Specification. It receives the uplink packets from the end devices and the tunneling relays, all of which are regarded by the Gateway as end devices. This is because in both cases what it receives is a header and an encrypted payload. In addition, the downlink packets that are sent from the NS to the Gateway are transmitted to their respective destinations according to the headers, since the NS encapsulates the downlinks to be delivered to the end device by the tunneling relay. This ensures that the already deployed Gateways can continue to operate as usual when the new relay is used in the network.

[0044] The Network Server (NS) keeps a table of all connected devices to the Gateway and it distinguishes the tunneling relays from the end devices. The packets that belong to the end devices which are directly coming from the Gateway are handled by the NS as usual. The packets that belong to the end devices which are suffering to reach the Gateway, will be encapsulated by the tunneling relay so, they will reach the NS as the tunneling relay uplink packets. Hence, the behavior of the NS will not be as usual in this case, it willfirst decrypt the payload of the tunneling relay uplink frame by using the keys that belong to the tunneling relay, which will give the uplink frame of the end device, again with its payload encrypted. The NS decrypts also the end device packet payload using the keys that belong to the end device. This is the essence of the tunneling mechanism since only the tunneling relay and the NS are aware of this encapsulation process, and the tunneling relaying process as well.

[0045] The frame formats to be used in the suggested LoRaWAN network are the same as the ones defined in the specifications latest LoRaWAN Link Layer Specification, as stated before. Nevertheless, let us briefly mention the types of frames and their distinctiveproperties.

[0046] The Join-Request frame is transmitted by the end devices and the tunneling relays so that the NS can recognize their existence in the network and it can assign encryption keys and network addresses to them. Itsfields vary between OTAA and ABP, where in the former the specified information is asked from the NS whereas in the latter it is stored on the device. The response of the NS to the Join-Request frame is the Join-Accept frame, which is discussed next. The Join-Request Frame format for the tunneling relay to the NS is the same as the end device join-request frame from the standardization. However, if the end device will be sending a join-request frame via the tunneling relay to the NS, the Join-Request Frame will be encapsulated in the uplink packet of the tunneling relay as shown in FIG. 4.

[0047] The PHYPAYLOAD structure of the tunneling relay uplink packet is shown in FIG. 5. The packet is a generic LoRaWAN frame and its name is PHYPayload. The PHYPayload consists of the MAC header (MHDR) and MACPayload. The MHDR is a 1-bytefield that contains the frame type and the frame options. The MACPayload is a variable-lengthfield that contains the MAC commands and the FRMPayload. The MAC commands are optionalfields that are used for the management of the LoRaWAN network. The FRMPayload is a variable-lengthfield that contains the application data.

[0048] The Join-Accept frame is sent from the NS to the end device, and in our new setting also to the tunneling relay when it joins the network. It contains the information necessary for the device to participate in the network, such as channel information, data rate information, etc. In addition, as stated in the previous part the keys and addresses to be used by the device are also in the Join-Accept frame. The Join-Accept frame packet structure is shown in FIG. 6. After the device gets the Join-Accept frame, it can start transmitting uplink frames and / or receive downlink frames.

[0049] When an end device wants to transmit an uplink frame, it gets the payload information and encrypts it with the keys it got in the join procedure. Then, it constructsthe uplink frame header, which contains the address of the sending end device, or relay, and some other control information about the transmission, such as the LoRaWAN Class used, the data rate, etc. In addition, the MAC commands are sent and received using the optionalfields in the header of the uplink frame. The PHYPAYLOAD of the uplink frame going from the tunneling relay to the gateway is shown in FIG. 7.

[0050] The downlink frames have the samefields and syntax as the uplinkfields and it has the same structure as FIG. 7, the only difference is that the sender is the NS and the receiver is the end device or the tunneling relay. In downlink frames, the NS can send data or MAC commands, and itfills the headerfields as detailed in the latest LoRaWAN Link Layer Specification so that the destination device can parse and process the frame when it receives it.

Claims

AMENDED CLAIMS received by the International Bureau on 26 January 2025 (26.01 .2025)1. A tunneling relay, comprising: an antenna, a radio frequency (RF) transceiver that supports Long-Range (LoRa) modulation, coupled to the antenna, a microcontroller unit (MCU) coupled to the radio-frequency (RF) transceiver, an optional memory coupled to the MCU, a power supply coupled to the MCU, a box that covers all the materials above, wherein the MCU is configured to: send a Join Request frame to a gateway, receive a Join Accept frame from the gateway, send an uplink frame to the gateway, receive a downlink frame from the gateway; wherein the MCU is further configured to: encapsulate the Join Request frame coming from the end device with a relay header and send it to the gateway, decapsulate the Join Accept frame coming from the gateway and send it to the end device, encapsulates the uplink frame coming from the end device with a relay header and send it to the gateway, decapsulate the downlink frame coming from the gateway and send it to the end device; wherein the MCU is further configured to:AMENDED SHEET (ARTICLE 19)encrypt the Join Request frame coming from the end device with a relay session keys which are NwkSKey and AppSKey, encrypt the uplink frame coming from the end device with relay session keys which are NwkSKey and AppSKey, decrypt the Join Accept frame coming from the gateway with relay session keys which are NwkSKey and AppSKey and forward the FRMPayload of the packet to the end device, decrypt the downlink frame coming from the gateway with relay session keys which are NwkSKey and AppSKey and forward the FRMPayload of the packet to the end device; wherein the MCU is further configured to: store the device identification numbers (IDs) of the end devices that are connected to the tunneling relay characterized in that, wherein the MCU is further configured to: send a Join Request frame to the gateway if the tunneling relay is activated with connected to the tunneling relay over-the-air activation (OTAA), sends an uplink frame to the gateway if the tunneling relay is activated with activation by personalization (ABP); wherein the MCU is further configured to: receiving the uplink packet coming from an end device without listening a wake-on radio (WOR) frame, by adjusting its receive windows to find the end devices packet transmission function to make the relay device still backward compatible, and making the end device does not need to know it is sending its data to the relay device.

2. The tunneling relay of claim 1, wherein the MCU is further configured to:AMENDED SHEET (ARTICLE 19)send a Join Request frame to the gateway if the tunneling relay is activated byOTAA, send an uplink frame to the gateway if the tunneling relay is activated by ABP.

3. A network server stores a table that includes: the tunneling relay IDs, relay status (active or passive), relay activation type, relay key performance indicators (KPIs): the number of end devices connected to the tunneling relay and it is also modified for decapsulation of received relay packets.

4. A tunneling relay includes different stages comprising: idle stage, that is for listening to Long-Range Wide Area Network (LoRaWAN) channels until detecting a frame;End device Join-Request stage, the tunneling relay regards the whole frame as its payload, encrypts it with its key encapsulates it with its header, and transmits it to the gateway, in addition, it adds the device ID to its list of connected end devices; the network server will know this is an encapsulated frame since it knows this is a relay uplink, and thus it will have the means to obtain the Join Request of the end device and to construct the corresponding Join Accept, it encapsulates this frame in a relay downlink and sends it to the tunneling relay, the tunneling relay decapsulates the Join Accept frame of the end device and sends it to the device;End device uplink stage, the tunneling relay checks if this device is added to its list of connected end devices i.e. whether this end device sent its Join Request through it before, if it is on the list it encapsulates the frame in the aforementioned way and sends it to the gatewayAMENDED SHEET (ARTICLE 19)otherwise, it discards it;Relay downlink stage, a tunneling relay observes frame contents if the frame is an encapsulated frame destined for an end device in the list of this relay, it decapsulates the frame and sends the downlink frame of the end device to it, if the downlink is destined for the tunneling relay, for example, some medium access control (MAC) command, then it processes it in the regular LoRaWAN methodology;Unidentified packet stage, if the received frame is a downlink frame destined for some other device, discards it; Multi-hop stage,If the received frame is an uplink frame coming from another relay, the tunneling relay encapsulates the frame again and then transmits it.

5. The end devices operate as they do in a regular LoRaWAN network, they transmit a Join Request, wait for a Join Accept with necessary parameters, and then transmit uplinks and receive downlinks as defined in LoRaWAN specification.

6. The Gateway operates as defined in LoRaWAN specification without any modification.

7. The Network Server is modified for decapsulation of received relay packets.

8. The Application Server is also modified for key performance indicators (KPIs) and statistics of the tunneling relay.AMENDED SHEET (ARTICLE 19)

Images