Lora mesh network

Abstract

The present specification provides a repeater (110) that is configured to be connectable to other repeaters, such that the interconnected repeaters operate a Long Range (LoRa) system (100). The repeater comprises two LoRa nodes (215), each configured for transmitting LoRa messages, and at least one LoRa concentrator (310) configured for receiving LoRa messages. The repeater further comprises a processor (305) in communication with the two LoRa nodes and the LoRa concentrator. The processor in conjunction with the two LoRa nodes and the LoRa concentrator are configured for providing cell-based communication having frequency channels for receiving and transmitting LoRa messages, where each frequency channel is assigned to a specific purpose.

Description

LORA MESH NETWORKTechnical Field

[0001] The present invention relates generally to a communication system and, in particular, to an improved LoRa system.Background

[0002] LoRa (stands for “Long Range”) Mesh is a mesh network that typically uses a single frequency band for half-duplex communication between devices connected to the LoRa Mesh. The LoRa Mesh uses LoRa for communication, which is a radio communication technique using spread spectrum modulation.

[0003] The single frequency band and half-duplex communication limit the bandwidth availability, resulting in slow communication between devices.Summary

[0004] It is an object of the present invention to substantially overcome, or at least ameliorate, one or more disadvantages of existing arrangements.

[0005] Disclosed are arrangements which seek to address the above problems by providing a repeater that is configured to connect to other repeaters in an ad-hoc manner, such that the connected repeaters facilitate communication between end devices connected to one of the repeaters and also between a server and an end device. Each repeater provides a cell-based communication with other repeaters and end devices. Each repeater also provides purposespecific frequency channel for different communication purposes with other repeaters and end devices.

[0006] According to a first aspect of the present disclosure, there is provided a repeater that is configured to be connectable to other repeaters, such that the interconnected repeaters operate a Long Range (LoRa) system, the repeater comprising: two LoRa nodes, each configured for transmitting LoRa messages; at least one LoRa concentrator configured for receiving LoRa messages; a processor in communication with the two LoRa nodes and the LoRa concentrator, wherein the processor in conjunction with the two LoRa nodes and the LoRa concentrator areconfigured for providing cell-based communication having frequency channels for receiving and transmitting LoRa messages, where each frequency channel is assigned to a specific purpose.

[0007] According to another aspect of the present disclosure, there is provided a computer program product including a computer readable medium having recorded thereon a computer program for implementing any one of the methods described above.

[0008] Other aspects are also disclosed.Brief Description of the Drawings

[0009] At least one embodiment of the present invention will now be described with reference to the drawings, in which:

[0010] Fig. 1 shows a LoRa system according to the present disclosure;

[0011] Figs. 2A and 2B show block diagrams illustrating connections of end devices of the LoRa system shown in Fig. 1 ;

[0012] Figs. 3A and 3B collectively form a schematic block diagram representation of a repeater of the LoRa system of Fig. 1;

[0013] Fig. 4 shows a data packet of messages transmitted in the LoRa system of Fig. 1;

[0014] Fig. 5 is a flow diagram for processing a system control message from a repeater in the LoRa system of Fig. 1;

[0015] Fig. 6 is a flow diagram for processing a data message from a repeater in the LoRa system of Fig. 1;

[0016] Fig. 7 is a flow diagram for processing a data message from an end device in the LoRa system of Fig. 1;

[0017] Fig. 8 is a flow diagram for processing a remote acknowledgement message from a repeater in the LoRa system of Fig. 1;

[0018] Fig. 9 is a flow diagram for processing a remote acknowledgement message from an end device in the LoRa system of Fig. 1;

[0019] Fig. 10 shows a channel response message frame of the LoRa system of Fig. 1 ;

[0020] Fig. 11 is a flow diagram for processing a channel information request from an end device in the LoRa system of Fig. 1;

[0021] Fig. 12 is a flow diagram for processing a data message from a server in the LoRa system of Fig. 1;

[0022] Fig. 13 shows the status machine of an end device of the LoRa system of Fig. 1 ;

[0023] Fig. 14 shows the interactions between repeaters and an end device when the end device joins the LoRa system of Fig. 1 ;

[0024] Fig. 15 shows the interactions between a repeater and an end device when the end device transmits a channel information request in the LoRa system of Fig. 1;

[0025] Fig. 16 shows the interactions between repeaters and an end device when the end device sends a data message in the LoRa system of Fig. 1; and

[0026] Fig. 17 shows the interactions between a repeater and an end device when a data message is sent from the repeater to the end device in the LoRa system of Fig. 1.Detailed Description

[0027] Where reference is made in any one or more of the accompanying drawings to steps and / or features, which have the same reference numerals, those steps and / or features have for the purposes of this description the same function(s) or operation(s), unless the contrary intention appears.

[0028] It is to be noted that the discussions contained in the "Background" section and that above relating to prior art arrangements relate to discussions of documents or devices which form public knowledge through their respective publication and / or use. Such should not be interpreted as a representation by the present inventor(s) or the patent applicant that such documents or devices in any way form part of the common general knowledge in the art.

[0029] Fig. 1 shows a LoRa system 100 having repeaters 110A to 110D and end devices 120A to 120E. Fig. 1 also shows that the LoRa system 100 is in communication with a server 130 via a communications / computer network 140. Although only one server 130 is shown inFig. 1, the system 100 may connect with two or more servers 130. Hereinafter, reference numeral 110 will be used to refer to all repeaters 110A to 110D or a generic repeater 110A. Hereinafter, reference numeral 120 will be used to refer to all end devices 120A to 120E or a generic end device 120. The LoRa system 100 facilitates communication between the end devices 120 with the server 130 via the repeaters 110 and the computer network 140. The LoRa system 100 also facilitates communication between the end devices 120 via the repeaters 110.

[0030] Fig. 1 only shows an example of possible connections between the repeaters 110, the end devices 120, the computer network 140, and the server 130. In general, a repeater 110 is in communication with one or more other repeaters 110 and one or more of the end devices 120. A repeater 110 can also be in communication with the server 130 via the computer network 140. An end device 120 is only able to communicate with a repeater 110. The server 130 is only able to communicate with a repeater 110 via the computer network 140.

[0031] The repeaters 110 therefore form the backbone of the LoRa system 100, as the repeaters 110 communicate amongst themselves and relay messages from the server 130 to the end devices 120, or from the end devices 120 to the server 130 or other end devices 120. The repeaters 110 can be either installed at fixed locations or dynamically deployed at any desired locations in a given environment. Since all the repeaters 110 are interconnected with each other, if one or more repeaters 110 in the LoRa system 100 is in communication with the computer network 140 (e.g., ethernet, WiFi, 4G, etc.), the remaining repeaters 110 and end devices 120 can communicate with the server 130.

[0032] Each of the end devices 120 includes a LoRa node 215 that is in communication with a sensor 210 (as shown in Fig. 2A) or a host 220 (such as a laptop, a tablet, a mobile telephone, etc.) (as shown in Fig. 2B). A LoRa node 215 in an end device 120 is configured to communicate with a repeater 110 at a single frequency channel. The end devices 120 (via its respective LoRa node 215) is able to communicate with other end devices 120 or servers 130 via the repeaters 110. The end devices 120 must be in communication with a particular repeater 110 before sending any messages to / receiving from other end devices 120 or servers 130.

[0033] Figs. 3A and 3B collectively form a schematic block diagram of a repeater 110 including embedded components, upon which the LoRa communication methods to be described are desirably practiced.

[0034] As seen in Fig. 3A, the repeater 110 comprises an embedded controller 302. Accordingly, the repeater 110 may be referred to as an “embedded device.” In the presentexample, the controller 302 has a processing unit (or processor) 305 which is bi-directionally coupled to an internal storage module 309. The storage module 309 may be formed from nonvolatile semiconductor read only memory (ROM) 360 and semiconductor random access memory (RAM) 370, as seen in Fig. 3B. The RAM 370 may be volatile, non-volatile or a combination of volatile and non-volatile memory.

[0035] As seen in Fig. 3A, the repeater 110 also comprises a portable memory interface 306, which is coupled to the processor 305 via a connection 319. The portable memory interface 306 allows a complementary portable memory device 325 to be coupled to the repeater 110 to act as a source or destination of data or to supplement the internal storage module 309. Examples of such interfaces permit coupling with portable memory devices such as Universal Serial Bus (USB) memory devices, Secure Digital (SD) cards, Personal Computer Memory Card International Association (PCMIA) cards, optical disks and magnetic disks.

[0036] The repeater 110 also has a communications interface 308 to permit coupling of the repeater 110 to a computer or communications network 140 (e.g., ethernet, WiFi, 4G, etc.) via a connection 321. The connection 321 may be wired or wireless. For example, the connection 321 may be radio frequency or optical. An example of a wired connection includes Ethernet. Further, an example of wireless connection includes Bluetooth™ type local interconnection, Wi-Fi (including protocols based on the standards of the IEEE 802.11 family), Infrared Data Association (IrDa) and the like. The communications interface 308 and the computer network 140 therefore enable the repeater 110 to communicate with the server 130.

[0037] The repeater 110 is also configured to communicate with other repeaters 110 and the end devices 120. The embedded controller 302, in conjunction with LoRa concentrator 310 and LoRa nodes 312A and 312B, is provided to faciliate the communication with other repeaters 110 and end devices 120. The LoRa concentrator 310 and LoRa nodes 312A and 312B are connected to the embedded controller 302. Although one LoRa concentrator 310 is shown in Fig. 3A, it is possible to connect more LoRa concentrators 310 to the embedded controller 302. Similarly, although two LoRa nodes 312A and 312B is shown in Fig. 3A, it is possible to connect more LoRa nodes 312 to the embedded controller 302.

[0038] The LoRa concentrator 310 is configured to receive data messages (in LoRa format) in 8 different frequency channels. Therefore, each additional LoRa concentrator 310 provides 8 additional frequency channels.

[0039] Each of the LoRa nodes 312A and 312B is configured to transmit data messages (in LoRa format) in a single frequency channel.

[0040] Therefore, with a combination of one LoRa concentrator 310 and two LoRa nodes 312A and 312B, the repeater 110 is able to receive messages at 8 different frequency channels and to transmit messages at 2 different frequency channels. Accordingly, adding a LoRa concentrator 310 to the repeater 110 adds 8 frequency channels for receiving messages. Similarly, adding a LoRa node 312 to the repeater 110 adds an additional frequency channel for transmitting messages. Utilization of the frequency channels will be described hereinafter.

[0041] The methods described hereinafter may be implemented using the embedded controller 302, where the processes of Figs. 5 to 12 may be implemented as one or more software application programs 333 executable within the embedded controller 302. The repeater 110 of Fig. 3A implements the described methods. In particular, with reference to Fig. 3B, the steps of the described methods are effected by instructions in the software 333 that are carried out within the controller 302. The software instructions may be formed as one or more code modules, each for performing one or more particular tasks.

[0042] The software 333 of the embedded controller 302 is typically stored in the non-volatile ROM 360 of the internal storage module 309. The software 333 stored in the ROM 360 can be updated when required from a computer readable medium. The software 333 can be loaded into and executed by the processor 305. In some instances, the processor 305 may execute software instructions that are located in RAM 370. Software instructions may be loaded into the RAM 370 by the processor 305 initiating a copy of one or more code modules from ROM 360 into RAM 370. Alternatively, the software instructions of one or more code modules may be preinstalled in a non-volatile region of RAM 370 by a manufacturer. After one or more code modules have been located in RAM 370, the processor 305 may execute software instructions of the one or more code modules.

[0043] The application program 333 is typically pre-installed and stored in the ROM 360 by a manufacturer, prior to distribution of the repeater 110. However, in some instances, the application programs 333 may be supplied to the user encoded on one or more CD-ROM (not shown) and read via the portable memory interface 306 of Fig. 3A prior to storage in the internal storage module 309 or in the portable memory 325. In another alternative, the software application program 333 may be read by the processor 305 from the network 140, or loaded into the controller 302 or the portable storage medium 325 from other computer readable media. Computer readable storage media refers to any non-transitory tangible storage medium thatparticipates in providing instructions and / or data to the controller 302 for execution and / or processing. Examples of such storage media include floppy disks, magnetic tape, CD-ROM, a hard disk drive, a ROM or integrated circuit, USB memory, a magneto-optical disk, flash memory, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the repeater 110. Examples of transitory or non-tangible computer readable transmission media that may also participate in the provision of software, application programs, instructions and / or data to the repeater 110 include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like. A computer readable medium having such software or computer program recorded on it is a computer program product.

[0044] Fig. 3B illustrates in detail the embedded controller 302 having the processor 305 for executing the application programs 333 and the internal storage 309. The internal storage 309 comprises read only memory (ROM) 360 and random access memory (RAM) 370. The processor 305 is able to execute the application programs 333 stored in one or both of the connected memories 360 and 370. When the electronic device 110 is initially powered up, a system program resident in the ROM 360 is executed. The application program 333 permanently stored in the ROM 360 is sometimes referred to as “firmware”. Execution of the firmware by the processor 305 may fulfil various functions, including processor management, memory management, device management, storage management and user interface.

[0045] The processor 305 typically includes a number of functional modules including a control unit (CU) 351, an arithmetic logic unit (ALU) 352, a digital signal processor (DSP) 353 and a local or internal memory comprising a set of registers 354 which typically contain atomic data elements 356, 357, along with internal buffer or cache memory 355. One or more internal buses 359 interconnect these functional modules. The processor 305 typically also has one or more interfaces 358 for communicating with external devices via system bus 381 , using a connection 361.

[0046] The application program 333 includes a sequence of instructions 362 though 363 that may include conditional branch and loop instructions. The program 333 may also include data, which is used in execution of the program 333. This data may be stored as part of the instruction or in a separate location 364 within the ROM 360 or RAM 370.

[0047] In general, the processor 305 is given a set of instructions, which are executed therein. This set of instructions may be organised into blocks, which perform specific tasks or handlespecific events that occur in the repeater 110. Typically, the application program 333 waits for events and subsequently executes the block of code associated with that event. Events may be triggered in response to data messages received from the LoRa concentrator 310 or to data to be sent by the LoRa node 312A or 312B as detected by the processor 305.

[0048] The execution of a set of the instructions may require numeric variables to be read and modified. Such numeric variables are stored in the RAM 370. The disclosed method uses input variables 371 that are stored in known locations 372, 373 in the memory 370. The input variables 371 are processed to produce output variables 377 that are stored in known locations 378, 379 in the memory 370. Intermediate variables 374 may be stored in additional memory locations in locations 375, 376 of the memory 370. Alternatively, some intermediate variables may only exist in the registers 354 of the processor 305.

[0049] The execution of a sequence of instructions is achieved in the processor 305 by repeated application of a fetch-execute cycle. The control unit 351 of the processor 305 maintains a register called the program counter, which contains the address in ROM 360 or RAM 370 of the next instruction to be executed. At the start of the fetch execute cycle, the contents of the memory address indexed by the program counter is loaded into the control unit 351. The instruction thus loaded controls the subsequent operation of the processor 305, causing for example, data to be loaded from ROM memory 360 into processor registers 354, the contents of a register to be arithmetically combined with the contents of another register, the contents of a register to be written to the location stored in another register and so on. At the end of the fetch execute cycle the program counter is updated to point to the next instruction in the system program code. Depending on the instruction just executed this may involve incrementing the address contained in the program counter or loading the program counter with a new address in order to achieve a branch operation.

[0050] Each step or sub-process in the processes of the methods described below is associated with one or more segments of the application program 333, and is performed by repeated execution of a fetch-execute cycle in the processor 305 or similar programmatic operation of other independent processor blocks in the repeater 110.Channel Utilization

[0051] The repeaters 110 and the end devices 120 communicate using a Frequency Division Duplex (FDD) method. Each repeater 110 communicates with other repeaters 110 and end devices 120 using the following channels:

[0052] Repeater-to- Repeater (R2R) channels 112 (see Fig. 1): the frequency channels for a repeater 110 to communicate with other repeaters 110. Each repeater 110 sends messages to other repeaters 110 on a R2R channel 112 (i.e. , at one frequency channel), which is different from the R2R channels 112 (i.e., at other frequency channels) of surrounding repeaters. Each repeater 110 sends messages using the LoRa node 312A or 312B. If one LoRa concentrator 310 is used, then the LoRa concentrator 310 is configured to listen to 7 R2R frequency channels 112. These 7 R2R frequency channels 112 can be referred to as second frequency channels. The R2R channel 112 configured for transmitting messages to other repeaters 110 can be referred to as the fourth frequency channel. Each additional LoRa concentrator 310 allows the repeater 110 to listen to 8 additional R2R channels 112.

[0053] Repeater-to-Node (R2N) channel 124 (see Fig. 1): the channel for a repeater 110 to send messages to end devices 120 that have joined this repeater. Each repeater 110 sends messages to end devices 120 via a unique R2N channel 124 that is different from the R2N frequency channels 124 used by the surrounding repeaters 110. A LoRa node 312A or 312B of the repeater 110 uses that R2N channel 124. The R2N channel 124 can be referred to as third frequency channel.

[0054] Node-to-Repeater (N2R) channel 122 (see Fig. 1): the channel for a repeater 110 to receive messages from end-devices 120 that have joined this repeater. Each repeater 110 receives messages from end devices 120 via a unique N2R channel 122 that is different from the N2R frequency channels 122 used by the surrounding repeaters. As discussed in relation to the R2R channel 112 above, 7 out of the 8 frequency channels of the first LoRa concentrator 310 are used for the R2R channel 112. Accordingly, one of the 8 channels of the LoRa concentrator 310 is used for that N2R channel 122. The N2R channel 122 can be referred to as first frequency channel.

[0055] Every repeater 110 is pre-assigned with a channel group index (which can be either fixed or dynamically assigned), where the channel group index is associated the specific channels 112, 124, and 122 to be used for transmitting messages by that specific repeater 110. Such pre-assignment of frequency channels (where each frequency channel is used for a specific purpose) enables an easy and quick deployment of repeaters 110 to expand a LoRa system 100. Further, as each repeater 110 is pre-assigned with one R2R channel 112 for transmitting messages and at least 7 other R2R channels 112 for receiving messages, the operation of each repeater 110 is cell-based (i.e., the specific area serviced by a repeater 110 has specific frequency channels for transmission and reception of messages). Further, each channel performs a specific function (e.g., transmitting messages from a repeater 110 to an enddevice 120, transmitting messages from a repeater 110 to another repeater 110, etc.). Therefore, the repeaters 110 provide the LoRa system 100 with multi-channel and full-duplex communication between the repeaters 110, the end device 120, and the server 130.

[0056] In one example, the LoRa system 100 uses repeaters 110 with one LoRa concentrator 310 in each repeater 110, meaning 8 frequency channels for receiving messages and 2 frequency channels for transmitting messages (as two LoRa nodes 312A and 312B are used). In such a LoRa system 100, there are 8 possible indices (e.g., indices 0 to 7). When a repeater 110 is assigned with a specific index, the repeater 110 is assigned to receive messages from other repeaters 110 at 7 specific R2R frequency channels 112 (e.g., R2R channels 0 to 7) and receive messages from joined end-devices 120 at 1 specific N2R frequency channel 122 (e.g., any one of N2R channels 0-7). Other repeaters 110 with different indices (i.e. , 1 to 7) are similarly assigned to receive messages at 7 specific R2R frequency channels 112. For example, a repeater 110 with index 1 receives messages at R2R channels 0 and 2 to 7 and N2R channel 1 , while a repeater 110 with index 2 receives messages at R2R channels 0 to 1 and 3 to 7 and N2R channel 2.

[0057] Repeaters 110 with different index transmit messages on different R2N channel 124 and R2R channel 112 and their joined end-devices 120 also transmit signals on different N2R channels 122. The assigned frequency channels 112, 122, 124 do not interfere each other at all and their deployed locations are flexible and movable. If there are repeaters 110 with the same index, they must be installed far enough so that these repeaters 110 do not interfere with each other. There are two repeater index assignment methods: the fixed index and dynamic index. All the repeaters in the same system 100 need to apply the same index assignment method.

[0058] The fixed index enables the repeaters 110 be connected to a LoRa system 100 without having to determine neighbouring repeaters 110. When a repeater 110 is deployed, the repeater 110 immediately performs its function as a repeater without having to sense neighbouring devices 110 or 120 or determining routing map (as the receiving and transmitting channels are already set). This functionality enables repeaters 110 to be moved to different locations in a given environment while still operating. Accordingly, if all the repeaters 110 have fixed indexes, the repeaters 110 immediately transmit system control messages on the assigned R2R channels 112 with no risk of signal collision because their channels 112, 122, 124 are exclusive. When the amount of repeaters 110 is equal to or less than the allowed repeater index number, each repeater 110 has a fixed and unique index and there is no limitation to their location. However, if the amount of repeaters 110 outnumbers the availableindex, some repeaters 110 need to share the same index and extra rules need to be applied to ensure that the repeaters 110 are separated by sufficient distance interval.

[0059] Alternatively, the index may be dynamically assigned when a repeater 110 joins a particular LoRa system 100. When a dynamic index is applied, a repeater 110 receives all communication via the 8 R2R channels 112 to detect any nearby repeaters 110. Since a repeater 110 periodically broadcasts System Control Message on its R2R channel 112, the new repeater 110 then determines one or more R2R channels 112 that are already assigned to neighbouring repeaters 110 (i.e., 1 hop neighbouring repeater). Additionally, the system control message of a repeater 110 also contains the information of other repeaters 110 that detected by that repeater 110. For example, a repeater 110A joins a LoRa system 100. The repeater 110A then detects system control messages from repeater 110B which contains the information of other repeaters (e.g., 110C, 110D) detected by the repeater 110B. A new repeater 110 then determines the 2 hop neighbouring repeaters 110 as well. Therefore, by checking the existence of any signals on all R2R channels 112 and the messages’ payload of any detected signals, a new repeater 110 can determine any neighbouring repeaters in 2 hops (and their indexes).Then the new repeater 110 determines and selects an R2R channel 112 (with its corresponding index) that is not occupied. If the R2R channels 112 are all occupied, the new repeater 110 continues receiving communication from all R2R channels 112 until one of the R2R channels is empty (which means the corresponding N2R channel 122 and R2N channel 124 are also available).LoRa Message Format

[0060] Both repeaters 110 and end-devices 120 have unique device identifications (IDs). Every message contains a source address and a destination address which are the ID of the source and destination devices, respectively.

[0061] All the devices 110 and 120 in the same network share the same PAN_ID which is the ID of the LoRa network 100, devices 110 and 120 ignore all messages with different PAN_ID.

[0062] All the messages transmitted in the LoRa system 100 are in the format shown in Fig. 4.

[0063] Each message has a header and a payload. The payload includes the message that needs to be transmitted.

[0064] The header includes the following:Identifier- PANJDSource addressSource repeater addressDestination addressQuality of Service (QOS); andSession ID.

[0065] The identifier includes a fixed byte to indicate that a message is a LoRa message.

[0066] PANJD includes two bytes identification to indicate the LoRa system 100 to which the message belong. All devices 110 and 120 in the same system 100 share the same PANJD.

[0067] Source address indicates an identification of the device 110 or 120 sending the message.

[0068] Source repeater address indicates an identification of the repeater 110 that first repeats the message.

[0069] Destination address indicates an identification of the device 110, 120, or 130 to which the message should be sent.

[0070] QOS indicates the priority level of the message. Messages with higher QoS value has priority to be repeated first.

[0071] The current message types are system control message, data traffic message, channel information request, channel information response, repeater acknowledgement, and remote acknowledgement.

[0072] System control messages are transmitted by repeaters 110, which are used to manage the system 100.

[0073] Data traffic messages carry a payload.

[0074] Channel info request / response messages are transmitted between an end-device 120 and its joined repeater 110 so that end devices 120 can get measured channel characteristics such as the signal strength and signal to noise ratio of repeaters 110 that are connected to the joined repeater 110.

[0075] Repeater acknowledgement message is a message from a repeater 110 to its enddevices 120 to indicate a specific data traffic message that is received by this repeater 110.

[0076] Remote acknowledgement message is a message sent by a destination device 110, 120, or 130 indicating that a data traffic message is received by the destination device 110, 120, or 130.

[0077] QoS indicates the priority of a message. The QoS may indicate the following priority: a. Low priority with no ACK required. b. Low priority with repeater ACK required. c. Medium priority with repeater ACK required. d. Medium priority with both repeater and remote ACK required. e. High priority with both repeater and remote ACK required.

[0078] Session identification is a two-byte sequence number which, together with the source ID, serve as a unique identifier for a message, preventing the information from being redundantly transmitted in the system 100 and causing echoes.Functionalities of a Repeater 110

[0079] As described hereinbefore, a repeater 110 may either have a fixed index or a dynamically assigned index. If the repeater 110 has a fixed index, the repeater 110 can join a system 100 at any time and commence transmitting and receiving messages at the assigned frequency channels.

[0080] The repeater 110 has 6 functions, as follows:a. Prepare and send system control messages to R2R and R2N transmission (TX) queue. b. Transmit the messages in the R2R TX queue. c. Transmit the messages in the R2N TX queue. d. Schedule message transmission for applications running on the repeater 110. e. Forward messages from the server 130. f. Receive messages from other repeaters 110 at R2R channels 112 and from end devices 120 at N2R channel 122 and respond accordingly.

[0081] The six functions described above are executed in parallel.

[0082] The first function of the repeater 110 is to transmit system control messages at a predetermined interval (e.g., 1 second) at both its R2R channel 112 and R2N channel 124. System control messages are sent at the scheduled intervals. System control messages are not in the R2R or R2N TX queues. When dynamic indexing is used, system control messages also include information on other repeaters (e.g., 110B, 110C, etc.) connected to the repeater (e.g., 110A) transmitting the system control message.

[0083] The second function of the repeater 110 is to transmit the messages in the R2R TX queue. The R2R TX queue is a queue of messages to be transmitted by the repeater 110 to other repeaters 110 via the R2R channel 112. The queue is stored in the internal storage 309. The enqueued messages are sorted based on the respective QoS values and arrival time. The messages in the R2R TX queue are then transmitted one by one via the LoRa node 312A or 312B at the R2R channel 112. When a system control message is to be sent at its scheduled interval, the R2R TX queue is paused and the system control message is sent first.Additionally, Remote Acknowledgement messages have relatively high QoS value while the data traffic messages have variable QoS values. In one arrangement, if a message with low QoS value stays in the R2R TX queue over a predetermined period of time (e.g., 5 seconds), the message is deleted.

[0084] The third function of the repeater 110 is to transmit the messages in the R2N TX queue. The R2N TX queue is a queue of messages to be transmitted by the repeater 110 tothe end devices 120 via the R2N channel 124. The queue is stored in the internal storage 309. The enqueued messages are sorted based on the respective QoS values and arrival time. The messages in the R2N TX queue are then transmitted one by one via the LoRa node 312A or 312B at the R2N channel 124. When a system control message is to be sent at its scheduled interval, the R2N TX queue is paused and the system control message is sent first.Additionally, Channel Information Request / Response, Remote Acknowledgement, and Repeater Acknowledgement have relatively high QoS value while the data traffic messages have variable QoS values. In one arrangement, if a message with low QoS value stays in the R2N TX queue over a predetermined period of time (e.g., 5 seconds), the message is deleted.

[0085] The fourth function of the repeater 110 is to schedule message transmission for applications running on the repeater 110. Third party applications running on the repeater 110 can send messages to the end devices 120 or the server 130. The repeater 110 receives the messages from the applications via an API. In turn, the repeater 110 generates data traffic messages and enqueue the messages to either the R2N or R2R TX queues.

[0086] The fifth function of the repeater 110 is to forward messages received from the server 130. Certain repeaters 110 may be connected to the computer network 140 in order to receive messages from the server 130. Such repeaters 110 receive messages from the server 130 and enqueue the received messages in either the R2R or R2N TX queues.

[0087] The sixth function of the repeater 110 is to receive the different messages on its R2R channel 112 or the N2R channel 122 and to respond accordingly. The responses of the repeater 110 based on the received messages will be described hereinafter in relation to Figs. 5 to 12.

[0088] Fig. 5 shows a method 500 for a repeater 110 to process a system control message. The method 500 is a software application program 333 that is executable within the embedded controller 302. The method 500 commences when a repeater 110 receives a system control message. The method 500 proceeds to step 510 after receiving the system control message. At step 510, the method 500 records the source address of the received system control message. The method 500 also records the signal strength and the signal to noise ratio of the received system control message. The method 500 then proceeds from step 510 to step 520.

[0089] In step 520, the method 500 adjust a schedule for sending system control messages contingent on the received system control message. The repeaters 110 are synchronized based on the system control messages sent by adjoining repeaters 110. A repeater 110 with achannel group index of 0 transmits a system control message at time to. A repeater 110 with a channel group index of 1 then transmit a system control message at time to + a predetermined time interval (e.g., 50ms). Therefore, when a repeater 110 first joins a system 100 and receives a system control message from another repeater 110, the repeater 110 determines the channel group index of the repeater 110 sending the system control message. The repeater 110 then determines when the repeater 110 must send its system control message. For example, a repeater 110 with a channel group index of 5 receives a system control message from another repeater 110 with a channel group index of 3. The repeater 110 with the channel group index of 5 determines that its next system control message must be sent 100ms (if the predetermined time interval is 50ms) after this particular system control message.

[0090] The method 500 concludes at the conclusion of step 520.

[0091] Fig. 6 shows a method 600 for a repeater 110 to process a data traffic message from the R2R channel 112. The method 600 is a software application program 333 that is executable within the embedded controller 302. The method 600 commences when a repeater 110 receives a data traffic message from the R2R channel 112. The method 600 proceeds to step 605 after receiving the data traffic message. At step 605, the method 600 determines a destination of the data traffic message based on the destination address of the received data traffic message. The method 600 then proceeds from step 605 to step 610 if the destination address is the present repeater 110. Otherwise, if the destination address is another repeater 110, an end device 120, or a server 130, then the method 600 proceeds to step 630. Step 610 onward will be described first before turning to step 630

[0092] In step 610, the method 600 determines the QoS of the received data traffic message based on the QoS of the received message. The method 600 then proceeds from step 610 to step 615.

[0093] In step 615, the method 600 determines whether an acknowledgement of the received data traffic message is required. As described hereinbefore when discussing QoS, the QoS value indicates whether a receipt acknowledgement of the data traffic message is required. If no acknowledgement is required (NO), the method 600 proceeds to step 625. Otherwise (YES), the method 600 proceeds to step 620. In step 620, the method 600 adds a remote acknowledgement message to the R2R TX queue of the repeater 110. The method 600 proceeds from step 620 to step 625.

[0094] In step 625, the method 600 transmits the received data traffic message to an application running on the repeater 110. The method 600 concludes at the conclusion of step 625.

[0095] Turning to step 630, the method 600 determines at step 630 the source identification and the session identification (discussed hereinbefore in relation to Fig. 4) of the received data traffic message. The method 600 then proceeds from step 630 to step 635.

[0096] In step 635, the method 600 determines whether the data traffic message is received previously based on the identified source and session identifications. If the identified source and session identifications (determined at step 630) are determined to be the same as a previously received data traffic message (YES), then the method 600 concludes. Otherwise (NO), the method 600 proceeds from step 635 to step 640.

[0097] In step 640, the method 600 determines whether the destination address of the data traffic message is a server 130. If YES, the method 600 proceeds from step 640 to step 645. In step 645, the method 600 adds the data traffic message to the R2N and R2R TX queues. If NO, the method 600 proceeds from step 640 to step 650.

[0098] In step 650, the method 600 determines whether there is Internet access. In other words, whether the repeater 110 is connected to the computer network 140. If YES, the method 600 proceeds from step 650 to step 660. Otherwise (NO), the method 600 proceeds from step 650 to step 655.

[0099] In step 655, the method 600 adds the data traffic message to the R2R TX queue. The method 600 then concludes.

[0100] In step 660, the method 600 transmits the data traffic message to the server 130. The method 600 then concludes.

[0101] Fig. 7 shows a method 700 for a repeater 110 to process a data traffic message from the N2R channel 122. The method 700 is a software application program 333 that is executable within the embedded controller 302. The method 700 commences when a repeater 110 receives a data traffic message from the N2R channel 122. The method 700 proceeds to step 705 after receiving the data traffic message. At step 705, the method 700 determines a destination of the data traffic message based on the destination address of the received data traffic message. The method 700 then proceeds from step 705 to step 710 if the destinationaddress is the present repeater 110. Otherwise, if the destination address is another repeater 110, an end device 120, or a server 130, then the method 700 proceeds to step 730. Step 710 onward will be described first before turning to step 730

[0102] In step 710, the method 700 determines the QoS of the received data traffic message based on the QoS of the received message. The method 700 then proceeds from step 710 to step 715.

[0103] In step 715, the method 700 determines whether an acknowledgement of the received data traffic message is required. As described hereinbefore when discussing QoS, the QoS value indicates whether a receipt acknowledgement of the data traffic message is required. If no acknowledgement is required (NO), the method 700 proceeds from step 715 to step 725. Otherwise (YES), the method 700 proceeds to step 720. In step 720, the method 700 adds a remote acknowledgement message to the R2N TX queue of the repeater 110. The method 700 proceeds from step 720 to step 725.

[0104] In step 725, the method 700 transmits the received data traffic message to an application running on the repeater 110. The method 700 concludes at the conclusion of step 725.

[0105] Turning to step 730, the method 700 adds an identification of the repeater to the data traffic message if the repeater 110 is the first repeater receiving the data traffic message. In one arrangement, the repeater 110 adds its identification to the data traffic message if the data traffic message does not have a source repeater address (which is described hereinbefore in the LoRa message format section). The method 700 then proceeds from step 730 to steps 735 and 750. Although Fig. 7 shows two separate processes of step 735 and 750, the two processes may be placed within the same process.

[0106] In step 735, the method 700 determines the QoS of the data traffic message. The method 700 then proceeds from step 735 to step 740. In step 740, the method 700 determines whether an acknowledgement of the received data traffic message is required. As described hereinbefore when discussing QoS, the QoS value indicates whether a receipt acknowledgement of the data traffic message is required. If no acknowledgement is required (NO), the method 700 does not add an acknowledgement message to the R2N TX queue. Otherwise (YES), the method 700 proceeds to step 745. In step 745, the method 700 adds a repeater acknowledgement message to the R2N TX queue of the repeater 110. This path ofwhether to send an acknowledgement message concludes and the method 700 continues with step 750.

[0107] In step 750, the method 700 determines the source identification and the session identification (discussed hereinbefore in relation to Fig. 4) of the received data traffic message. The method 700 then proceeds from step 750 to step 755.

[0108] In step 755, the method 700 determines whether the data traffic message is received previously based on the identified source and session identifications. If the identified source and session identifications (determined at step 750) are determined to be the same as a previously received data traffic message (YES), then the method 700 concludes. Otherwise (NO), the method 700 proceeds from step 755 to step 760.

[0109] In step 760, the method 700 determines whether the destination address of the data traffic message is a server 130. If YES, the method 700 proceeds from step 760 to step 770. If NO, the method 700 proceeds from step 760 to step 765. In step 765, the method 700 adds the data traffic message to the R2N and R2R TX queues.

[0110] In step 770, the method 700 determines whether there is Internet access. In other words, whether the repeater 110 is connected to the computer network 140. If YES, the method 700 proceeds from step 770 to step 780. Otherwise (NO), the method 700 proceeds from step 770 to step 775.

[0111] In step 775, the method 700 adds the data traffic message to the R2R TX queue. The method 700 then concludes.

[0112] In step 780, the method 700 transmits the data traffic message to the server 130. The method 700 then concludes.

[0113] Fig. 8 shows a method 800 for a repeater 110 to process a remote acknowledgement message from the R2R channel 112. The method 800 is a software application program 333 that is executable within the embedded controller 302. The method 800 commences when a repeater 110 receives a remote acknowledgement message from the R2R channel 112. The method 800 proceeds to step 805 after receiving the remote acknowledgement message. At step 805, the method 800 determines a destination of the remote acknowledgement message based on the destination address of the received remote acknowledgement message. The method 800 then proceeds from step 805 to step 810 if the destination address is the presentrepeater 110. Otherwise, if the destination address is another repeater 110, an end device 120, or a server 130, then the method 800 proceeds to step 815.

[0114] In step 815, the method 800 determines the source identification and the session identification (discussed hereinbefore in relation to Fig. 4) of the received remote acknowledgement message. The method 800 then proceeds from step 815 to step 820.

[0115] In step 820, the method 800 determines whether the remote acknowledgement message is received previously based on the identified source and session identifications. If the identified source and session identifications (determined at step 815) are determined to be the same as a previously received remote acknowledgement message (YES), then the method 800 concludes. Otherwise (NO), the method 800 proceeds from step 820 to step 825.

[0116] In step 825, the method 800 determines whether the destination address of the remote acknowledgement message is a server 130. If YES, the method 800 proceeds from step 825 to step 835. If NO, the method 800 proceeds from step 825 to step 830. In step 830, the method 800 adds the remote acknowledgement message to the R2N and R2R TX queues.

[0117] In step 835, the method 800 determines whether there is Internet access. In other words, whether the repeater 110 is connected to the computer network 140. If YES, the method 800 proceeds from step 835 to step 845. Otherwise (NO), the method 800 proceeds from step 835 to step 840.

[0118] In step 840, the method 800 adds the remote acknowledgement message to the R2R TX queue. The method 800 then concludes.

[0119] In step 845, the method 800 transmits the remote acknowledgement message to the server 130. The method 800 then concludes.

[0120] Fig. 9 shows a method 900 for a repeater 110 to process a remote acknowledgement message from the N2R channel 122. The method 900 is a software application program 333 that is executable within the embedded controller 302. The method 900 commences when a repeater 110 receives a remote acknowledgement message from the N2R channel 122. The method 900 proceeds to step 905 after receiving the remote acknowledgement message. At step 905, the method 900 determines a destination of the remote acknowledgement message based on the destination address of the received remote acknowledgement message. The method 900 then proceeds from step 905 to step 910 if the destination address is the presentrepeater 110. Otherwise, if the destination address is another repeater 110, an end device 120, or a server 130, then the method 900 proceeds to step 915.

[0121] In step 915, the method 900 adds an identification of the repeater 110 to the remote acknowledgement message if the repeater 110 is the first repeater receiving the remote acknowledgement message. In one arrangement, the repeater 110 adds its identification to the remote acknowledgement message if the remote acknowledgement message does not have a source repeater address (which is described hereinbefore in the LoRa message format section). The method 900 then proceeds from step 915 to step 920.

[0122] In step 920, the method 900 determines the source identification and the session identification (discussed hereinbefore in relation to Fig. 4) of the received remote acknowledgement message. The method 900 then proceeds from step 920 to step 925.

[0123] In step 925, the method 900 determines whether the remote acknowledgement message is received previously based on the identified source and session identifications. If the identified source and session identifications (determined at step 920) are determined to be the same as a previously received remote acknowledgement message (YES), then the method 900 concludes. Otherwise (NO), the method 900 proceeds from step 925 to step 930.

[0124] In step 930, the method 900 determines whether the destination address of the remote acknowledgement message is a server 130. If YES, the method 900 proceeds from step 930 to step 940. If NO, the method 900 proceeds from step 925 to step 930. In step 930, the method 900 adds the remote acknowledgement message to the R2N and R2R TX queues.

[0125] In step 940, the method 900 determines whether there is Internet access. In other words, whether the repeater 110 is connected to the computer network 140. If YES, the method 900 proceeds from step 940 to step 950. Otherwise (NO), the method 900 proceeds from step 940 to step 945.

[0126] In step 945, the method 900 adds the remote acknowledgement message to the R2R TX queue. The method 900 then concludes.

[0127] In step 950, the method 900 transmits the remote acknowledgement message to the server 130. The method 900 then concludes.

[0128] Fig. 11 shows a method 1100 for a repeater 110 to process a channel information request message from the N2R channel 122. The method 1100 is a software application program 333 that is executable within the embedded controller 302. The method 1100 commences when a repeater 110 receives a channel information request message from the N2R channel 122. The method 1100 proceeds to step 1110 after receiving the channel information request message. At step 1110, the method 1100 transmits a channel information response to the end device 120 transmitting the channel information request message. The channel response message is transmitted via the R2N channel 124.

[0129] The content of the channel response message is shown in Fig. 10. The channel response message includes information relating to the repeater 110 which receives the channel information request message. The information is the information of other repeaters 110 recorded at step 510, which includes the identifications of other repeaters 110 connected to this repeater 110, the signal strength received from other repeaters 110, and the signal to noise ratio of the received system control message from other repeaters 110.

[0130] The method 1100 then concludes at the conclusion of step 1110.

[0131] Fig. 12 shows a method 1200 for a repeater 110 to process a data traffic message from the server 130. The method 1200 is a software application program 333 that is executable within the embedded controller 302. The method 1200 commences when a repeater 110 receives a data traffic message from the server 130. The method 1200 proceeds to step 1205 after receiving the data traffic message. At step 1205, the method 1200 determines a destination of the data traffic message based on the destination address of the received data traffic message. The method 1200 then proceeds from step 1205 to step 1210 if the destination address is the present repeater 110. Otherwise, if the destination address is another repeater 110, an end device 120, or a server 130, then the method 1200 proceeds to step 1225.

[0132] In step 1210, the method 1200 determines the QoS of the received data traffic message based on the QoS of the received message. The method 1200 then proceeds from step 1210 to step 1215.

[0133] In step 1215, the method 1200 determines whether an acknowledgement of the received data traffic message is required. As described hereinbefore when discussing QoS, the QoS value indicates whether a receipt acknowledgement of the data traffic message is required. If no acknowledgement is required (NO), the method 1200 proceeds from step 1215 to step 1222. Otherwise (YES), the method 1200 proceeds to step 1220. In step 1220, the method1200 adds a remote acknowledgement message to the server 130. The method 1200 proceeds from step 1220 to step 1222.

[0134] In step 1222, the method 1200 transmits the received data traffic message to an application running on the repeater 110. The method 1200 concludes at the conclusion of step 1222.

[0135] In step 1225, the method 1200 determines the source identification and the session identification (discussed hereinbefore in relation to Fig. 4) of the received data traffic message. The method 1200 then proceeds from step 1225 to step 1230.

[0136] In step 1230, the method 1200 determines whether the data traffic message is received previously based on the identified source and session identifications. If the identified source and session identifications (determined at step 1225) are determined to be the same as a previously received data traffic message (YES), then the method 1200 concludes. Otherwise (NO), the method 1200 proceeds from step 1230 to step 1235.

[0137] In step 1235, the method 1200 adds the data traffic message to the R2N and R2R TX queue. The method 1200 then concludes.

[0138] The discussion now turns to the operation of an end device 120. As shown in Figs. 2A and 2B, an end device 120 may be connected to a sensor 210 or a host 220. If the end device 120 is connected to a sensor 210, the end device 120 is typically preprogrammed to forward a data traffic message relating to the data collected by the sensor 210. However, if the end device 120 is connected to a host 220, then the host 220 (e.g., a laptop) can command the end device 120 to perform one or more of the following actions: a. Start and join the LoRa system 100. b. Quit the LoRa system 100. c. send a message to the server 130 or other devices 110 or 120 when the enddevice 120 has joined the LoRa system 100. d. Query the status of the neighbouring repeaters 110 by sending a channel information request message.

[0139] Fig. 13 illustrates the internal status machine of the end device 120. When the end device 120 is powered up, the end device 120 is in idle status 1305 and the host 220 can command the end device 120 to start. When receiving the start command, the end device 120 moves from idle status 1305 to searching status 1310 and controls the end-device 120 to listen to the R2N channels 124 from the various repeaters 110.

[0140] If there is no message received, the end-device 120 stays in searching status 1310 to receive messages from the R2R channels 124.

[0141] If system control messages are received by the end device 120, the end device 120 selects the R2N channel 124 on which the strongest signal is received and go to TXRX status 1315.

[0142] The end device 120 has a hot start option if the end device 120 is in communication with a specific repeater 110. In such a circumstance, the end-device 120 moves from the idle status 1305 to TXRX status 1315 without having to go to the searching status 1310.

[0143] In TXRX status 1315, the end device 120 listens to the selected R2N channel 124. In case a message whose destination address is equal to its own device identification, the end device 120 reports this message to the host 220. The end device 120 could receive different types of messages including a channel information response message, repeater acknowledgement message, remote acknowledgement message, and data traffic message. These messages are involved in different interactions between the joined repeater 110 and other repeaters 110, the server 130, and other end devices 120 in the same LoRa system 100. These interactions will be described hereinafter in relation to Figs. 14 to 17.

[0144] In TXRX status 1315, the end device 120 can send messages via the LoRa system 100. The message could be a channel information request message or a data traffic message. Either the end-device’s host 220 or an application program within the end device 120 collecting sensor data provides the message type, destination address and QoS, so the end device 120 can prepare the message accordingly. The end device 120 needs to generate a unique session identification which is different from previous messages in a certain period of time. Then, the end device 120 stops listening and go to busy status 1320.

[0145] In Busy status 1320, the end device 120 sends the message to the N2R channel 122 which is in the same channel group with the selected R2N channel 124. Then the end device 120 goes back to TXRX status 1315.

[0146] In TXRX status 1315, the end device 120 continues monitoring the received system control messages. If the message is missing or too weak for a certain period of time (which can be defined by end-devices 120 based on their own duty cycle), the end device 120 goes to Searching status 1310 and listens to the R2N channels 124 again.

[0147] In TXRX status 1315, the host 120 can command the end-device 120 to stop. The end device 120 then stops listening and go to IDLE status 1305.

[0148] As discussed hereinbefore, there are different interactions between repeaters 110, the server 130, and end devices 120 in the same LoRa system 100. The first interaction is when an end device 120 joins a repeater 110. Fig. 14 shows the first interaction. A repeater 110 typically transmits system control messages at a predetermined interval at the R2N channel 124. Different repeaters 110 transmit the respective control messages at different times in a short period of time. An end device 120 then receives the system control messages by listening to the R2N channel 124. The end device 120, in turn, determines the system control message with the strongest signal and selects the repeater 110 to join based on the determined strongest signal. The end device 120 then listens to only the system control messages from the selected repeater 110. No handshake protocol is required between the repeater 110 and the end device 120.

[0149] Fig. 15 shows the second interaction of an end device 120 requesting channel information from a repeater 110. The second interaction can only occur once the end device 120 joins the repeater 110. To request channel information, the end device 120 sends (via the N2R channel 122) a channel information request message to the repeater 110, which in turn transmits (via the R2N channel 124) a channel information response message back to the end device 120. As described hereinbefore in relation to Fig. 11, the channel information response message contains information relating to other repeaters 110 that are connected to the repeater 110 that receives the channel information request message.

[0150] Fig. 16 shows the third interaction of an end device 120 sending a data traffic message to other devices 110, 120, and 130. The third interaction can only occur once the end device 120 joins the repeater 110. The end device 120 sends a data traffic message via the N2R channel 122 when there is a message to be transmitted to other devices 110, 120, and 130. Each data traffic message is assigned with a session identification generated by the end device 120. When the data traffic message is received by the repeater 110, the repeater 110 does not amend the session identification so that the LoRa system 100 recognizes the same messageand does not repeatedly send the data traffic message (described in step 755 of the method 700 above). This interaction is described hereinabove in relation to Fig. 7.

[0151] Fig. 17 shows the fourth interaction of an end device 120 receiving a data traffic message from its joined repeater 110. The fourth interaction can only occur once the end device 120 joins the repeater 110. The end device 120 receives such a data traffic message from the R2N channel 124. The end device 120 in turn determines whether a remote acknowledgement message is required contingent on the QoS value in the received data traffic message.

[0152] The above described LoRa system 100 is able to provide native support to both sensor data transmission and audio transmission at the same time. A conventional LoRa system is typically too slow for audio transmission. However, the LoRa system 100 is capable of transmitting audio due to is use of multiple channels and cell-based feature (i.e. , each repeater 110 operates at predetermined frequency channels that are different to the frequency channels of adjoining repeaters 110).

[0153] In one example application, an end device 120 receives an audio message. The host 220 of the end device 120 first processes the received audio message with one or more applications (e.g., Lyra SDK, audio compressing tool, etc.) residing in the host 220. The host 220 then segments the processed / compressed audio message into multiple LoRa payload. The host 220 then controls the LoRa node 215 to package the payload according to the format shown in Fig. 4 and send the packages sequentially.

[0154] The destination device (e.g., another end device 120, a server 130, a repeater 110) may fail to receive one or more of the segmented packages, but the applications (e.g., Lyra SDK) residing in the destination device can still recover the audio message imperfectly.

[0155] In another example, when sensor data needs to be sent by an end device 120, the LoRa node 215 in an end device 120 can be programmed to collect sensor data (e.g., via I2C, UART port, etc.), the LoRa node 215 then packages the sensor data and sends the sensor data to the assigned destination device (e.g., another end device 120, a server 130, a repeater 110). The QoS can be adjusted based on how important the message is and the end-device 120 can determine whether resending the sensor data is required after determining whether an acknowledgement is received.Industrial Applicability

[0156] The arrangements described are applicable to the communication industries and particularly for the LoRa communication system.

[0157] The foregoing describes only some embodiments of the present invention, and modifications and / or changes can be made thereto without departing from the scope and spirit of the invention, the embodiments being illustrative and not restrictive.

[0158] In the context of this specification, the word “comprising” means “including principally but not necessarily solely” or “having” or “including”, and not “consisting only of”. Variations of the word "comprising", such as “comprise” and “comprises” have correspondingly varied meanings.

Claims

CLAIMS:

1. A repeater that is configured to be connectable to other repeaters, such that the interconnected repeaters operate a Long Range (LoRa) system, the repeater comprising: two LoRa nodes, each configured for transmitting LoRa messages; at least one LoRa concentrator configured for receiving LoRa messages; a processor in communication with the two LoRa nodes and the LoRa concentrator, wherein the processor in conjunction with the two LoRa nodes and the LoRa concentrator are configured for providing cell-based communication having frequency channels for receiving and transmitting LoRa messages, where each frequency channel is assigned to a specific purpose.

2. The repeater of claim 1, wherein the LoRa concentrator is configured for receiving LoRa messages from an end device at a first frequency channel and LoRa messages from other repeaters at second frequency channels.

3. The repeater of claim 1 or 2, wherein one of the LoRa nodes is configured for transmitting LoRa messages from the repeater to an end device at a third frequency channel.

4. The repeater of any one of claims 1 to 3, wherein one of the LoRa nodes is configured for transmitting LoRa messages from the repeater to another repeater at a fourth frequency channel.

5. The repeater of any one of claims 1 to 4, wherein the repeater is assigned with a channel group index indicating the receiving and transmitting frequency channels used by the repeater.

6. The repeater of claim 5, wherein the channel group index is fixed or dynamically assigned when the repeater joins a LoRa system.

7. The repeater of any one of claims 1 to 6, wherein the repeater is configured to connect to a server.

8. The repeater of any one of claims 1 to 7, wherein the LoRa messages include any one of the following: a system control message, a data traffic message, a channel information request, a channel information response, a repeater acknowledgment, and a remote acknowledgement.

9. The repeater of claim 8, wherein the repeater is configured to transmit the system control messages periodically at the first and the third frequency channels.

10. The repeater of claim 8 or 9, wherein the dynamic assignment of the channel group index is based on the system control messages.11 . The repeater of any one of claims 1 to 10, wherein the repeater includes a first message queue for transmitting messages to other repeaters and a second message queue for transmitting messages to end devices connected to the repeater, wherein the messages in the queues are sent based on a priority level and an arrival time of the messages.

12. A LoRa system comprising repeaters according to any one of claims 1 to 11.

13. The LoRa system of claim 12 further comprising: end devices configured to connect to one or more of the repeaters, such that the end devices send messages to other end devices or repeaters via the connected repeater.

14. The LoRa system of claim 12 or 13, wherein one of the repeaters is connected to a server, such that the end devices and the servers communicate via the repeaters.

Images