KR20180102383A - LoRa SERVER AND METHOD FOR NETWORK COMMUNICATION RECOVERY THEREOF - Google Patents

Abstract

The present invention relates to a method for recovering a network communication of a LoRa server, which comprises the steps of: receiving a first LoRa message including session information with a LoRa terminal from the LoRa terminal; generating a second LoRa message to be transmitted to the LoRa terminal when information corresponding to the session information is not present in a database in reference to the database; and transmitting the second LoRa message to the LoRa terminal. When recovery information is set in a specific region of the second LoRa message, the LoRa terminal deletes the session information with the LoRa server, and transmits a new session connection request to the LoRa server after releasing the session connection with the LoRa server, wherein the second LoRa message has recovery information to be set in the specific region, and bit information of a region other than the specific region is the same as the bit information of a region corresponding to the first LoRa message.

Description

BACKGROUND OF THE INVENTION 1. Field of the Invention [0001] The present invention relates to a LoRa server,

A method for restoring network communication between a LoRa terminal and a LoRa server using a LoRa message is disclosed.

LoRa (LongRange) network is difficult to recover when session information is lost for terminal due to server failure.

When the gateway processing the LoRa message transmitted by the LoRa terminal is changed, it is difficult to communicate with the network server when the gateway before and after the change is connected to the different LoRa network server.

Disclosed is a method for performing session connection and release through message transmission between a LoRa server and a LoRa terminal, and automatically recovering network communication.

A method of restoring a network communication of a LoRa server includes receiving a first LoRa message including session information from the LoRa terminal with the LoRa terminal, referring to the database, determining whether the information corresponding to the session information does not exist in the database , Generating a second LoRa message in which recovery information is set in a specific area, and transmitting the second LoRa message to the LoRa terminal, wherein the LoRa terminal transmits the second LoRa message, When the restoration information is set in a specific area, disconnects the session with the LoRa server, and then transmits a new session connection request to the LoRa server, and the second LoRa message includes bits of other areas excluding the specific area Information is the same as the bit information of the corresponding area of the first LoRa message.

The specific area may be an MHDR (Mac Header), and the recovery information may be a specific bit included in the MHDR.

The recovery information may be the fourth bit of the MHDR, and the recovery information may be set by setting the bit to 1.

The session information may include the LoRa terminal information.

The LoRa server may transmit the first LoRa message to the IoT app server when information corresponding to the session information exists in the database.

The LoRa server includes a memory for storing a control program, a central processing unit operating in accordance with the control program, a database including session information with the LoRa terminal, and a communication interface for transmitting and receiving information to and from the LoRa terminal and the IoT app server, Wherein the control program comprises the steps of: receiving a first LoRa message including session information from the LoRa terminal with the LoRa terminal; if the information corresponding to the session information does not exist in the database, Generating a second LoRa message in which recovery information is set in a specific area, and transmitting the second LoRa message to the LoRa terminal, wherein the LoRa terminal transmits the second LoRa message to the specific area of the second LoRa message, When the recovery information included in the LoRa server is set, the LoRa server deletes the session connection with the LoRa server, And to transmit a new session connection request, the first message is 2 LoRa, the bit information of the other region except for the specific region is equal to the bit information of the corresponding area of the first 1 LoRa message.

The specific area may be an MHDR (Mac Header), and the recovery information may be a specific bit included in the MHDR.

The recovery information may be the fourth of the MHDR, and the recovery information may be set by setting the bit to 1.

The session information may include the LoRa terminal information.

The LoRa server may transmit the first LoRa message to the IoT app server when information corresponding to the session information exists in the database.

Through the signal transmission between the server and the terminal, the session information about the terminal lost due to the server failure can be recovered.

When the gateway processing the first LoRa message transmitted by the LoRa terminal is changed, communication between the network servers can be performed even if the before and after gateways are connected to different LoRa network servers.

1 is a block diagram of a LoRa server.
2 is a flowchart of a network connection recovery method between a LoRa terminal and a LoRa server.
3 is a block diagram of the LoRa message.
Figures 4A and 4B show one embodiment of a first LoRa message and a second LoRa message.
5 shows an embodiment of a method for restoring a network connection between a LoRa terminal and a LoRa server.

In the following, embodiments will be described in detail with reference to the accompanying drawings. Like reference symbols in the drawings denote like elements.

Various modifications may be made to the embodiments described below. It is to be understood that the embodiments described below are not intended to limit the embodiments, but include all modifications, equivalents, and alternatives to them.

The terms used in the examples are used only to illustrate specific embodiments and are not intended to limit the embodiments. The singular expressions include plural expressions unless the context clearly dictates otherwise. In this specification, the terms "comprises" or "having" and the like refer to the presence of stated features, integers, steps, operations, elements, components, or combinations thereof, But do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or combinations thereof.

Unless defined otherwise, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which this embodiment belongs. Terms such as those defined in commonly used dictionaries are to be interpreted as having a meaning consistent with the contextual meaning of the related art and are to be interpreted as either ideal or overly formal in the sense of the present application Do not.

In the following description of the present invention with reference to the accompanying drawings, the same components are denoted by the same reference numerals regardless of the reference numerals, and redundant explanations thereof will be omitted. In the following description of the embodiments, a detailed description of related arts will be omitted if it is determined that the gist of the embodiments may be unnecessarily blurred.

1 is a block diagram of a LoRa server.

The LoRa (LongRange) network is one of the large, low-power, low power wide area (LPWA), which means a communication technology capable of transmitting small amounts of data and enabling long distance communication. The LoRa network transmits a small amount of data, so it does not require a large amount of power, usually guarantees a radio wave range of 20 Km, uses a frequency band of 900 MHz, uses low-speed / low-power objects (Internet, Small Things] are used in Internet technology. The LoRa network can provide seamless interoperability between smart devices.

The LoRa network is typically built with a star-of-stars topology and can link messages between the backend of the terminal and the server. The gateway may be connected to a network server while the terminal is using single-hop wireless communication for at least one or more gateways. End-point communication is basically bidirectional, but it can also support jobs such as queuing to reduce queued communication time, multicast that can upgrade software through other mass-distributed messages.

Communication between the terminal and the gateway may affect other channels and data rates. The selection of the data rate is in a trade-off relationship between the communication range and the message duration. By spread spectrum techniques, communicating at different data rates can create a virtual channel set that increases the capacity of the gateway without causing interference to other devices. The range of the LoRa network data rate may be between 0.3 Kbps and 50 Kbps. To maximize the battery life of the terminal and all network capacity, the LoRa server manages the data rate and RF (Resonance Frequency) output for each terminal separately through an Adaptive Data Rate (ADR) scheme.

The LoRa network uses a nationwide network targeted at the Internet of Things (IoT), such as critical infrastructure, confidential personal information, or important social functions for communication security. Communication security is based on multiple layers of encryption (for example, end-to-end at the application level with unique network key (EUI 64) and network level security assurance, unique application key (EUI 64) ) And device-specific keys, etc.).

The LoRa network has different classes at end-points to address the different requirements reflected in a wide range of applications:

The bidirectional terminal (Class A) permits bi-directional communication when the uplink transmission of each terminal is followed by two short downlinks by a plurality of windows. The transmission slots scheduled for the terminal are based on communications involving a small variation based on random time basis (ALOHA-a protocol of some sort). Class A is the lowest power terminal system for applications that require downlink communications from the server immediately after the terminal sends an uplink transmission. Downlink communications from the server may have to wait until the next scheduled uplink.

The bidirectional terminal (Class B) scheduled for slot reception will further open in Class A, which receives the window at random, with extra reception windows at a scheduled time. In order for the terminal to open the receive window at a predetermined time, the class B receives a beacon synchronized in time from the gateway. Through this, the server can know whether or not the terminal is receiving information.

In most cases, the bidirectional terminal (Class C) with the maximum slot reception is closed only when the reception window is continuously opened and the class C is transmitted.

The LoRa server 100 means a device connected to the LoRa terminal 200 via a gateway. The LoRa server 100 includes a memory 110 for storing a control program, a central processing unit 120 operating in accordance with a control program, a database 130 including session information with the LoRa terminal 200, 200 and a communication interface 140 for transmitting and receiving information to and from the IoT app server. The LoRa terminal 200 means a device connected to the LoRa server 100 via a gateway.

2 is a flowchart of a network connection restoration method between a LoRa terminal and a LoRa server.

The LoRa terminal 200 transmits a first LoRa message including session information between the LoRa terminal 200 and the LoRa server 100 to the LoRa server 100 (S100).

The session information includes the eigenvalue information of the LoRa terminal 200, the connection location, the access frequency, and the data or signal transmitted from the LoRa server 100 to the LoRa server 100 (or received from the LoRa server 100) can do. Unlike cookies, session information is used to store information in a web container that is embedded in a server, rather than to store information in a web browser. The session information is created, maintained and managed by the server. Typically, one web browser creates one session. Since sessions are stored on the server, they are more secure than cookies.

An example of the first LoRa message is shown in FIG.

Referring to FIG. 3, the first LoRa message may include a preamble, a physical header (PHDR), a cyclic redundancy check (PHDR_CRC), a physical payload (PHY), and a cyclic redundancy check (CRC). The PHY Payload may include an MHDR (Mac Header), a MAC (Message Authentication Code) payload, and a MIC (Message Integrity Check). The MHDR and the MAC Payload may be areas where integrity is protected. The MHDR may include one byte, and the eight bits constituting one byte of the MHDR may be composed of MType (3 bits), Reserved (3 bits), and Major Version (2 bits). At least one of the bits constituting the MHDR may be used for setting recovery information. The MAC Payload may include an FHDR (Frame Header), a FPort (Frame Port), and a FRMPayload. The FHDR may include a device address (DevAddr), a frame control (FCtrl), a frame count (FCnt), and a frame option (FOpts). The FRMPayload may be an encrypted area. The first LoRa message may follow the configuration of the LoRa WAN standard message as shown in FIG.

Referring back to FIG. 2, the LoRa server 100 refers to the database 130 and determines whether information corresponding to the session information included in the first LoRa message exists in the database 130 (S110).

The LoRa server 100 can determine whether a failure or a problem has occurred in the LoRa network based on whether or not the session information exists in the database 130. [ Specifically, when the session information is present in the database 130, the LoRa server 100 can determine that the LoRa network is normally operating. If the session information does not exist in the database 130, It can be determined that a failure or a problem has occurred. When the LoRa server 100 determines that a failure or a problem has occurred in the LoRa network, it generates a second LoRa message for solving the LoRa network problem.

As a result of the determination, if the information corresponding to the session information included in the first LoRa message is not present in the database 130, the LoRa server 100 transmits a second LoRa message in which recovery information is set in a specific area (S120).

The second LoRa message is distinguished from the first LoRa message, and the bit information of the other region except the specific region is the same as the bit information of the corresponding region of the first LoRa message.

In one embodiment, the specific area of the first LoRa message may be an MHDR (Mac Header). In this case, the recovery information of the second LoRa message may be a specific bit included in the MHDR. That is, since the MHDR includes one byte, the recovery information may be one bit of one byte constituting the MHDR.

In another embodiment, the recovery information of the second LoRa message may be more than one bit included in the second LoRa message. That is, the recovery information may be determined by a value of at least two bits of an arbitrary position of the second LoRa message.

If it is determined in step S110 that the information corresponding to the session information included in the first LoRa message exists in the database 130, the LoRa server 100 may transmit the first LoRa message to the IoT app server (Not shown). When receiving the first LoRa message from the LoRa server 100, the IoT app server can determine that the session between the LoRa terminal 200 and the LoRa server 100 is normally connected and that the network operates normally.

The LoRa server 100 transmits the generated second LoRa message to the LoRa terminal 200 (S130).

In one embodiment, the LoRa server 100 may send a second LoRa message with recovery information set to the LoRa terminal 200. [

In another embodiment, the LoRa server 100 may transmit a second LoRa message, which is the same as the bit information of the corresponding area of the first LoRa message, with a specific bit included in the MHDR set to the LoRa terminal 200. [

In another embodiment, the LoRa server 100 is the same as the bit information of the corresponding region of the first LoRa message, but the value of certain bits is set to a predetermined value (e.g., three bits of an arbitrary position The third bit is set to 1, the fifth bit is set to 0, and the seventh bit is set to 1) to the LoRa terminal 200. In this case,

The LoRa terminal 200 determines whether recovery information is set in a specific area of the second LoRa message (S140).

In one embodiment, the LoRa terminal 200 may determine whether recovery information is set in a specific area of the second LoRa message.

In another embodiment, the LoRa terminal 200 may determine whether recovery information is set in a specific bit included in the MHDR of the second LoRa message.

In another embodiment, the LoRa terminal 200 may determine whether the value of the specific bits included in the second LoRa message is set to a predetermined value.

As a result of the determination, if the recovery information is set in the specific area of the second LoRa message, the LoRa terminal 200 cancels the session connection with the LoRa server 100 (S150).

In another embodiment, when a specific bit included in the MHDR of the second LoRa message is set, the LoRa terminal 200 can release the session connection with the LoRa server 100. [

The LoRa server 100 can delete the released session information when the session connection with the LoRa terminal 200 is released.

After the session connection with the LoRa server 100 is released, the LoRa terminal 200 can transmit a new session connection request to the LoRa server 100 (S160).

The LoRa terminal 200 and the LoRa server 100 can repeat steps S100 to S160 for solving a network problem between the LoRa terminal 200 and the LoRa server 100 when a new session connection is established have.

5 shows an embodiment of a method for restoring a network connection between a LoRa terminal and a LoRa server.

The LoRa server 100 receives the first LoRa message including the session information between the LoRa terminal 200 and the LoRa server 100 from the LoRa terminal 200 (S200).

Referring to FIG. 3, the first LoRa message may include a preamble, a physical header (PHDR), a cyclic redundancy check (PHDR_CRC), a physical payload (PHY), and a cyclic redundancy check (CRC). The PHY Payload may include an MHDR (Mac Header), a MAC (Message Authentication Code) payload, and a MIC (Message Integrity Check). The MHDR and the MAC Payload may be areas where integrity is protected. The MHDR may include one byte, and the eight bits constituting one byte of the MHDR may be composed of MType (3 bits), Reserved (3 bits), and Major Version (2 bits). At least one of the bits constituting the MHDR may be used for setting recovery information. The MAC Payload may include an FHDR (Frame Header), a FPort (Frame Port), and a FRMPayload. The FHDR may include a device address (DevAddr), a frame control (FCtrl), a frame count (FCnt), and a frame option (FOpts). The FRMPayload may be an encrypted area. The first LoRa message may follow the configuration of the LoRa WAN standard message as shown in FIG.

5, the LoRa server 100 may refer to the database 130 to determine whether information corresponding to the session information included in the first LoRa message exists in the database 130 (S210) .

The LoRa server 100 can determine whether a problem has occurred in the LoRa network based on whether or not the session information exists in the database 130. [ Specifically, when the session information is present in the database 130, the LoRa server 100 can determine that the LoRa network is normally operating. If the session information does not exist in the database 130, It can be judged that a problem has occurred. When it is determined that a problem has occurred in the LoRa network, the LoRa server 100 generates a second LoRa message in which recovery information is set in a specific area for solving the LoRa network problem.

As a result of the determination, if the information corresponding to the session information included in the first LoRa message is not present in the database 130, the LoRa server 100 transmits a second LoRa message in which recovery information is set in a specific area (S220).

In one embodiment, the second LoRa message is a message distinguished from the first LoRa message, and the fourth bit of the MHDR may be set as recovery information.

Referring to FIG. 4A, when the MHDR includes one byte and 8 bits constituting one byte are Mtype 3 bits, Reserved 3 bits, and Major Version 2 bits, the fourth bit is the first bit of Reserved have. The LoRa server 100 may generate a second LoRa message in which the fourth bit of the MHDR, i.e., the first bit of the Reserved, is set, as shown in FIG. 4B.

FIG. 4A shows an example of this first LoRa message.

Referring to FIG. 4A, the MHDR of the first LoRa message may include MType (3 bits), Reserved (3 bits), and Major Version (2 bits).

In one embodiment, the bits with arbitrary values may be denoted as "X ", such as MType, Major Version in FIG. 4A. That is, the bits configuring the MType and Major Version may have any value (0 or 1). The first LoRa message may be the fourth bit of the MHDR (i.e., the first bit of the Reserved) and the fourth bit of the MHDR may be 0, as shown in FIG. 4A.

In one embodiment, the LoRa server 100 determines if the particular region of the first LoRa message is the fourth bit of the MHDR and if the session information of the first LoRa message is not present in the database 130, A second LoRa message with the fourth bit of the MHDR set to one can be generated.

FIG. 4B shows an example of the second LoRa message generated by the LoRa server 100. FIG. Referring to FIG. 4B, the fourth bit of the MHDR among the generated second LoRa message may be set to '1'.

In one embodiment, the LoRa server 100 may generate a second LoRa message in which a bit of MType or Major Version is set in addition to the Reserved field. In another embodiment, the LoRa server 100 may generate a second LoRa message in which more than one bit contained in the MHDR is set.

In another embodiment, the LoRa server 100 may generate a second LoRa message by setting the value of certain bits to a predetermined value (e.g., if the specific 3 bits are 010).

If it is determined in step S210 that the information corresponding to the session information included in the first LoRa message exists in the database 130, the LoRa server 100 receives the next LoRa message from the LoRa terminal 200 The session connection with the LoRa terminal 200 can be maintained (not shown).

The LoRa server 100 may transmit the generated second LoRa message to the LoRa terminal 200 (S230).

In one embodiment, the LoRa server 100 may generate and transmit a second LoRa message with the fourth bit of the MHDR set to 1 to the LoRa terminal 200.

In another embodiment, the LoRa server 100 may transmit a second LoRa message generated by setting at least two bits to the LoRa terminal 200.

The LoRa terminal 200 may determine whether the fourth bit of the MHDR of the second LoRa message is set to 1 (S240).

In one embodiment, the LoRa terminal 200 may determine whether the fourth bit of the MHDR of the second LoRa message is set to '1'.

In another embodiment, the LoRa terminal 200 can determine whether two or more specific bits among the bits included in the second LoRa message are set to 1 (not shown).

If it is determined that the fourth bit of the MHDR of the second LoRa message is set to 1, the LoRa terminal 200 can release the session connection with the LoRa server 100 (S250).

In one embodiment, when the fourth bit of the MHDR of the second LoRa message is set to 1, the LoRa terminal 200 can release the session connection with the LoRa server 100. [

In another embodiment, the LoRa terminal 200 can determine whether two or more specific bits among the bits included in the second LoRa message are set to 1 (not shown).

The LoRa terminal 200 can release the session connection with the LoRa server 100 when the fourth bit of the MHDR of the second LoRa message is set to 1. [

The LoRa server 100 may delete the released session information after the session connection with the LoRa terminal 200 is released.

After the session connection with the LoRa server 100 is released, the LoRa terminal 200 may transmit a new session connection request to the LoRa server 100 (S260).

The LoRa terminal 200 and the LoRa server 100 repeat steps S200 to S260 to solve the network problem between the LoRa terminal 200 and the LoRa server 100 when a new session connection is established .

The apparatus described above may be implemented as a hardware component, a software component, and / or a combination of hardware components and software components. For example, the apparatus and components described in the embodiments may be implemented within a computer system, such as, for example, a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable array (FPA) A programmable logic unit (PLU), a microprocessor, or any other device capable of executing and responding to instructions. The processing device may execute an operating system (OS) and one or more software applications running on the operating system. The processing device may also access, store, manipulate, process, and generate data in response to execution of the software. For ease of understanding, the processing apparatus may be described as being used singly, but those skilled in the art will recognize that the processing apparatus may have a plurality of processing elements and / As shown in FIG. For example, the processing unit may comprise a plurality of processors or one processor and one controller. Other processing configurations are also possible, such as a parallel processor.

The software may include a computer program, code, instructions, or a combination of one or more of the foregoing, and may be configured to configure the processing device to operate as desired or to process it collectively or collectively Device can be commanded. The software and / or data may be in the form of any type of machine, component, physical device, virtual equipment, computer storage media, or device , Or may be permanently or temporarily embodied in a transmitted signal wave. The software may be distributed over a networked computer system and stored or executed in a distributed manner. The software and data may be stored on one or more computer readable recording media.

The method according to an embodiment may be implemented in the form of a program command that can be executed through various computer means and recorded in a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, and the like, alone or in combination. The program instructions to be recorded on the medium may be those specially designed and configured for the embodiments or may be available to those skilled in the art of computer software. Examples of computer-readable media include magnetic media such as hard disks, floppy disks and magnetic tape; optical media such as CD-ROMs and DVDs; magnetic media such as floppy disks; Magneto-optical media, and hardware devices specifically configured to store and execute program instructions such as ROM, RAM, flash memory, and the like. Examples of program instructions include machine language code such as those produced by a compiler, as well as high-level language code that can be executed by a computer using an interpreter or the like. The hardware devices described above may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.

While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it is to be understood that the invention is not limited to the disclosed exemplary embodiments. For example, it is to be understood that the techniques described may be performed in a different order than the described methods, and / or that components of the described systems, structures, devices, circuits, Lt; / RTI > or equivalents, even if it is replaced or replaced.

Therefore, other implementations, other embodiments, and equivalents to the claims are also within the scope of the following claims.

100: LoRa server
110: Memory
120:
130: Database
140: Communication interface
200: LoRa terminal

Claims (10)

Receiving a first LoRa message including session information from the LoRa terminal with the LoRa terminal;
Generating a second LoRa message in which restoration information is set in a specific area when information corresponding to the session information does not exist in the database by referring to the database; And
Transmitting the second LoRa message to the LoRa terminal
Lt; / RTI >
When the recovery information is set in the specific area of the second LoRa message, the LoRa terminal releases a session connection with the LoRa server and then transmits a new session connection request to the LoRa server,
Wherein the second LoRa message includes the same information as the bit information of the corresponding region of the first LoRa message,
How to recover network communication of LoRa server.
The method according to claim 1,
The specific area is an MHDR (Mac Header)
The recovery information includes a specific bit included in the MHDR,
How to recover network communication of LoRa server.
3. The method of claim 2,
The recovery information may include,
The fourth bit of the MHDR,
And setting the recovery information by setting the bit to 1,
How to recover network communication of LoRa server.
The method according to claim 1,
Wherein the session information includes the LoRa terminal information,
How to recover network communication of LoRa server.
The method according to claim 1,
Wherein the LoRa server transmits the first LoRa message to the IoT app server when information corresponding to the session information exists in the database,
How to recover network communication of LoRa server.
A memory for recording a control program;
A central processing unit operating in accordance with the control program;
A database including session information with the LoRa terminal; And
A communication interface for transmitting and receiving information to and from the LoRa terminal and the IoT app server
Lt; / RTI >
Wherein the control program comprises:
Receiving a first LoRa message including session information from the LoRa terminal with the LoRa terminal;
Generating a second LoRa message to be transmitted to the LoRa terminal when the information corresponding to the session information does not exist in the database with reference to the database; And
Transmitting the second LoRa message to the LoRa terminal
Lt; / RTI >
When the recovery information included in the specific area of the second LoRa message is set, the LoRa terminal releases a session connection with the LoRa server, and then transmits a new session connection request to the LoRa server,
Wherein the second LoRa message is configured such that recovery information is set in a specific area and bit information of another area excluding the specific area is the same as bit information of a corresponding area of the first LoRa message,
LoRa server.
The method according to claim 6,
The specific area is an MHDR (Mac Header)
The recovery information includes a specific bit included in the MHDR,
LoRa server.
The method according to claim 6,
The recovery information may include,
The fourth of the MHDR,
And setting the recovery information by setting the bit to 1,
LoRa server.
The method according to claim 6,
Wherein the session information includes the LoRa terminal information,
LoRa server.
The method according to claim 6,
Wherein the LoRa server transmits the first LoRa message to the IoT app server when information corresponding to the session information exists in the database,
LoRa server.

Images