KR20220121693A - Method and apparatus for quaranteeing the reliability of packet in distributed communication system - Google Patents

Abstract

Disclosed is a packet reliability guarantee technique in a distributed communication system. The present invention relates to an operation method of a first communication node in a wireless distributed communication system. Provided is the operation method of the first communication node, which includes the steps of: providing a group code and a primary secret key to a third communication node via a second communication node; receiving, from the third communication node, a first packet including a first group trust field through wireless distributed communication, the first group trust field being generated using the group code and the primary secret key; and performing a trustworthiness check of the received first packet by using the first group trust field included in the received first packet, the group code, and the primary secret key.

Description

Method and apparatus for guaranteeing packet reliability in a distributed communication system

The present invention relates to a packet reliability guarantee technique in a distributed communication system, and more particularly, to a packet trust guarantee technique in a distributed communication system that enables terminals to secure packet reliability by sharing a secret key.

The wireless distributed communication system may be a system in which terminals communicate by sharing radio resources themselves without a control station. In such a wireless distributed communication system, it may be difficult to ensure reliability of distributed packets. In order to solve this problem, according to the prior art, a wireless distributed communication system may use an open trust communication method. Here, the public trust communication method may be a communication method using an open trust packet. In addition, the open trust packet may be a distributed packet including an open trust field (OTF) that can confirm reliability. Accordingly, the terminal can verify the reliability of the received public trust packet by providing the field value of the public trust field to a designated trust authority of the wireless distributed communication system. In this way, the terminal can check the reliability of the distributed packet through the trusted authority.

In a wireless distributed communication system using such an open trust communication method, only a trusted authority designated in advance can perform the reliability check. Accordingly, in a wireless distributed communication system using an open trust communication method, terminals not designated as a trusted authority cannot perform a reliability check on an open trust packet. Accordingly, there may be a need for a method for checking the reliability of packets exchanged between terminals in a wireless distributed communication system. In particular, it may be necessary for terminals to verify the reliability of a packet without the help of a trusted authority.

An object of the present invention to solve the above problems is to provide a method and apparatus for guaranteeing packet reliability in a distributed communication system that enables terminals to secure packet reliability by sharing a secret key.

In order to achieve the above object, a method for guaranteeing packet reliability in a distributed communication system according to a first embodiment of the present invention is a method of operating a first communication node of a wireless distributed communication system, and a third communication node via a second communication node providing a raw group code and a first secret key; receiving a first packet including a first group trust field generated using the group code and the first secret key from the third communication node through distributed wireless communication; and performing a reliability check of the received first packet using the first group trust field, the group code, and the first secret key included in the received first packet.

Here, receiving the first location information of the third node together with the first group trust field from the third communication node; determining whether the third communication node has entered an entry restricted area based on the first location information; and allowing the third communication node to enter the restricted entry area when the reliability of the first packet is confirmed when the third communication node has entered the entry restricted area.

Here, updating the first secret key to generate a second secret key; providing the second secret key to the third communication node via the second communication node; receiving a second packet including a second group trust field generated using the group code and the second secret key from the third communication node; and performing a reliability check of the received second packet using the second group trust field, the group code, and the second secret key included in the received second packet.

Here, receiving a second secret key updated in the first secret key from the second communication node; receiving a second packet comprising a second group trust field generated using the group code and the second secret key from the third communication node; The method may further include performing a reliability check on the received second packet by using the second group trust field, the group code, and the second secret key included in the received second packet.

Here, receiving the second location information of the third node together with the second group trust field from the third communication node;

determining whether the third communication node has entered the entry restricted area based on the second location information; and allowing the third communication node to enter the entry restricted area when the reliability of the received second packet is confirmed when the third communication node has entered the entry restricted area. .

Here, the first group trust field may be generated using the group code and the first secret key using a linear feedback shift register from the third communication node.

Here, when the reliability of the first packet is not confirmed as a result of the reliability check, transmitting a signal disallowing the entry of the entry restricted area to the third communication node; and transmitting, to the second communication node, a signal disallowing the entry of the third communication node from the restricted entry area.

On the other hand, the packet reliability guarantee method in the distributed communication system according to the second embodiment of the present invention for achieving the above object is a method of operating a second communication node of the wireless distributed communication system, from the first communication node to the third communication node A first specific code designating a receiving the packet through wireless distributed communication; transmitting the received first packet and reception time information of the first packet to the third communication node; receiving a work request according to the work content included in the first packet from the third communication node; and performing a task according to the task request with the third node.

Here, after the completion of the work according to the work request with the third node, the step of transmitting a second packet including the end information of the work to the first communication node using distributed wireless communication is further performed. may include

Here, the second packet may include a second specific trust field used when the first communication node, received from the third communication node, performs a trust check, and generation time information of the second specific trust field.

Here, in the step of transferring the received first packet and the reception time information of the first packet to the third communication node, the third communication node performs a trust check instead of the received first packet. Delivering a part of the first packet including the first specific trust field, the contents of the work to be performed by the second communication node and the third communication node, and the address of the first terminal to the third communication node can be characterized as

Meanwhile, in order to achieve the above object, an apparatus for guaranteeing packet reliability in a distributed communication system according to a third embodiment of the present invention, as a second communication node of the distributed communication system, includes: a processor; a memory in electronic communication with the processor; and instructions stored in the memory, wherein when the instructions are executed by the processor, the instructions cause the second communication node to point to a third communication node from the first communication node. Distributed wireless communication for a first packet including a specific code, a first specific trust field used when the third communication node performs a trust check, and a task to be performed between the second communication node and the third communication node to receive; forwarding the received first packet and reception time information of the first packet to the third communication node; receiving a work request according to the work content included in the first packet from the third communication node; and operable to cause performing a task according to the task request with the third node.

Here, the commands include, by the second communication node, after the execution of the operation according to the request for the operation with the third node is finished, a second packet including the termination information of the operation using distributed wireless communication. operable to further cause the first communication node to transmit.

Here, the second packet may include a second specific trust field used when the first communication node, received from the third communication node, performs a trust check, and generation time information of the second specific trust field.

According to the present application, in a wireless distributed communication system, a terminal may use a group trust field (GTF) to ensure reliability of distributed packets. As a result, in a wireless distributed communication system, a terminal can perform a reliability check on a distributed packet received from another terminal belonging to a group without the help of a trust checking authority. In addition, the terminal may execute a job request included in the distributed packet in which reliability is secured.

In addition, according to the present application, in a wireless distributed communication system, a terminal may use a specific trust field (STF) to ensure reliability of a distributed packet. As a result, in the wireless distributed communication system, the terminal can perform a reliability check on the distributed packet received from a specific terminal without the help of a trust check authority. In addition, the terminal may execute a job request included in the distributed packet in which reliability is secured.

1 is a block diagram illustrating a first embodiment of a distributed packet including a group trust field.
2 is a conceptual diagram illustrating a first embodiment of an apparatus for ensuring packet reliability.
3 is a flowchart illustrating a first embodiment of a method for ensuring packet reliability.
4 is a conceptual diagram illustrating a second embodiment of an apparatus for guaranteeing packet reliability.
5 is a flowchart illustrating a second embodiment of a method for ensuring packet reliability.
6 is a block diagram illustrating a first embodiment of a distributed packet including a specific trust field.
7 is a conceptual diagram illustrating a third embodiment of an apparatus for guaranteeing packet reliability.
8 is a flowchart illustrating a third embodiment of a method for ensuring packet reliability.
9 is a block diagram illustrating a second embodiment of a distributed packet including a specific trust field.
10 is a conceptual diagram illustrating a fourth embodiment of an apparatus for guaranteeing packet reliability.
11 is a flowchart illustrating a fourth embodiment of a method for ensuring packet reliability.
12 is a block diagram illustrating a third embodiment of a distributed packet including a specific trust field.
13 is a conceptual diagram for explaining a first embodiment of a communication node in a distributed communication system.

Since the present invention can have various changes and can have various embodiments, specific embodiments are illustrated in the drawings and described in detail. However, this is not intended to limit the present invention to a specific embodiment, it should be understood to include all modifications, equivalents and substitutes included in the spirit and scope of the present invention.

Terms such as first, second, etc. may be used to describe various elements, but the elements should not be limited by the terms. The above terms are used only for the purpose of distinguishing one component from another. For example, without departing from the scope of the present invention, a first component may be referred to as a second component, and similarly, a second component may also be referred to as a first component. and/or includes a combination of a plurality of related listed items or any of a plurality of related listed items.

In embodiments of the present application, “at least one of A and B” may mean “at least one of A or B” or “at least one of combinations of one or more of A and B”. Also, in the embodiments of the present application, “at least one of A and B” may mean “at least one of A or B” or “at least one of combinations of one or more of A and B”.

When a component is referred to as being “connected” or “connected” to another component, it may be directly connected or connected to the other component, but it is understood that other components may exist in between. it should be On the other hand, when it is said that a certain element is "directly connected" or "directly connected" to another element, it should be understood that the other element does not exist in the middle.

The terms used in the present application are only used to describe specific embodiments, and are not intended to limit the present invention. The singular expression includes the plural expression unless the context clearly dictates otherwise. In the present application, terms such as “comprise” or “have” are intended to designate that a feature, number, step, operation, component, part, or combination thereof described in the specification exists, but one or more other features It is to be understood that this does not preclude the possibility of the presence or addition of numbers, steps, operations, components, parts, 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 invention belongs. Terms such as those defined in a commonly used dictionary should be interpreted as having a meaning consistent with the meaning in the context of the related art, and should not be interpreted in an ideal or excessively formal meaning unless explicitly defined in the present application. does not

Throughout the specification, a network is, for example, a wireless Internet such as WiFi (wireless fidelity), a wireless broadband internet (WiBro) or a portable Internet such as a world interoperability for microwave access (WiMax), a global system for mobile communication (GSM). ) or 2G mobile communication networks such as code division multiple access (CDMA), wideband code division multiple access (WCDMA) or 3G mobile networks such as CDMA2000, high speed downlink packet access (HSDPA) or high speed uplink packet access (HSUPA) such as It may include a 3.5G mobile communication network, a 4G mobile communication network such as a long term evolution (LTE) network or an LTE-Advanced network, and a 5G mobile communication network.

Throughout the specification, a terminal is a mobile station, a mobile terminal, a subscriber station, a portable subscriber station, a user equipment, and an access terminal. and the like, and may include all or some functions of a terminal, a mobile station, a mobile terminal, a subscriber station, a portable subscriber station, a user equipment, an access terminal, and the like.

Here, a desktop computer that can communicate with a terminal, a laptop computer, a tablet PC, a wireless phone, a mobile phone, a smart phone, a smart watch (smart watch), smart glass, e-book reader, PMP (portable multimedia player), portable game console, navigation device, digital camera, DMB (digital multimedia broadcasting) player, digital voice Digital audio recorder, digital audio player, digital picture recorder, digital picture player, digital video recorder, digital video player ) can be used.

Throughout the specification, a base station is an access point, a radio access station, a Node B, an advanced nodeB, a base transceiver station, MMR ( It may refer to mobile multihop relay)-BS, and the like, and may include all or some functions of a base station, an access point, a wireless access station, a Node B, an eNodeB, a transceiver base station, and an MMR-BS.

Hereinafter, preferred embodiments of the present invention will be described in more detail with reference to the accompanying drawings. In describing the present invention, in order to facilitate the overall understanding, the same reference numerals are used for the same components in the drawings, and duplicate descriptions of the same components are omitted.

On the other hand, the wireless distributed communication system may be a system in which terminals communicate by sharing radio resources themselves without a control station. In such a wireless distributed communication system, it may be difficult to ensure reliability of distributed packets. In order to solve this problem, according to the prior art, a wireless distributed communication system may use an open trust communication method. Here, the public trust communication method may be a communication method using an open trust packet. In addition, the open trust packet may be a distributed packet including an open trust field (OTF) that can confirm reliability. Accordingly, the terminal can verify the reliability of the received public trust packet by providing the field value of the public trust field to a designated trust authority of the wireless distributed communication system. In this way, the terminal can check the reliability of the distributed packet through the trusted authority.

Such an open trust communication method may be used, for example, for communication between drones. In general, in a wireless distributed communication system, the public trust field may be designed to be non-replicable. In a wireless distributed communication system, the public trust field may be changed for every slot. In such a communication environment, the illegal drone may receive an open trust packet including a public trust field of a past slot.

In addition, the illegal drone may create and transmit a new public trust packet by duplicating the public trust field included in the received public trust packet. Then, a nearby terminal may receive the public trust packet including the public trust field copied from the illegal drone. In addition, the terminal may inquire about the reliability of the public trust packet received from the illegal drone to the trust authority. In this case, since the trust authority has received the public trust field of the past slot from the terminal, it can confirm to the terminal with an unreliable packet.

In a wireless distributed communication system using such an open trust communication method, only a trusted authority designated in advance can perform the reliability check. Accordingly, in a wireless distributed communication system using an open trust communication method, terminals not designated as a trusted authority cannot perform a reliability check on an open trust packet. Accordingly, there may be a need for a method for checking the reliability of packets exchanged between terminals in a wireless distributed communication system. In particular, it may be necessary for terminals to verify the reliability of a packet without the help of a trusted authority.

Here, the wireless distributed communication system may include not only terminals transmitting and receiving distributed packets, but also terminals supporting communication activities of these terminals. In such a wireless distributed communication system, two terminals may perform one-to-one communication. In this case, the terminals can perform reliable one-to-one communication through mutual registration. However, a wireless distributed communication system may generally have a communication method of many-to-many communication. Therefore, it may not be important to secure the reliability of the packet in one-to-one communication. In addition, trust in the transmitted and received wireless distributed communication packet itself may be more important than confirming trust in the terminal.

1 is a configuration diagram illustrating a first embodiment of a distributed packet including a group trust field (GTF).

Referring to FIG. 1 , a distributed packet may include a packet header field 110 , a source address field 120 , a public trust field 130 , a data field 140 , and a cyclical redundancy check (CRC) field 150 . have.

Here, the packet header field 110 may be a field used to indicate a packet type. In this case, the packet type may be, for example, a location broadcast packet. The terminal may indicate that it is a location broadcast packet by using, for example, hexadecimal 0x0A in the packet header field 110 . Next, the source address field 120 may be a field for indicating the source address of the distributed packet. The UE may transmit by designating its own identifier (ID) in the source address field 120 . In addition, the public trust field 130 may be a field that allows the trust of the distributed packet to be confirmed through a trusted authority designated by the wireless distributed communication system.

Meanwhile, the data field 140 may include a location parsing block 141 , a group trust field parsing block 142 , and a general data field 143 . Here, the location parsing block 141 may be a parsing block related to location information. The location parsing block 141 may include a first parsing header field 141-1 and a location information field 141-2. In this case, the first parsing header field 141-1 may be a field for indicating characteristics of information included in the location parsing field 141 .

As an example, the terminal may indicate that the location information field 141-2 including location information continues by configuring the distributed packet to include hexadecimal 0x01 in the first parsing header field 141-1. Here, the location information field 141-2 may be a field indicating location information of the terminal. The terminal may broadcast its GPS coordinates by configuring a distributed packet to include, for example, global positioning system (GPS) coordinate information in the location information field 141-2.

Next, the group trust field parsing block 142 may be a parsing block related to the group trust field. The group trust field parsing block 142 may include a second parsing header field 142-1, a group code field 142-2, and a group trust field 142-3. Here, the second parsing header field 142-1 may be a field for indicating characteristics of information included in the group trust field block 142 . As an example, the terminal configures a distributed packet to include hexadecimal 0x02 in the second parsing header field 142-1, and a group code field 142-2 including a group code and a group trust field including group trust bits ( 142-3) may indicate that it is continuing. Here, the group code field 142 - 2 may be a field for indicating a group code.

Next, the group trust field 142 - 3 may refer to a field inserted into a distribution packet so that terminals belonging to a predetermined group can perform a reliability check with each other in wireless distributed communication. The group trust field 142 - 3 may include group trust bits generated using a group code and a secret key. Here, the terminal may generate the group trust bits using the group code secret key and time information. Here, the time information means information on the transmission time of the distributed packet or the generation time of the distributed packet.

Alternatively, the terminal may generate the group trust bits using the group code, the secret key, the time information and the terminal identifier. The terminal may transmit a distributed packet including the group trust bits by designating the group trust bits in the group trust field 142 - 3 .

Meanwhile, the general data field 140 - 3 may include data that the terminal needs to transmit. The terminal may transmit the distributed packet including the transmission time or generation time of the distributed packet by including, for example, the transmission time or generation time of the distributed packet in the general data field 140-3. Next, the CRC field 150 may be a field that designates a CRC to determine whether there is an error.

Meanwhile, terminals belonging to the same group may share a corresponding group code and may share the same secret key. Accordingly, any one terminal belonging to the same group may generate group trust bits using the group code and the secret key. In addition, any one terminal belonging to the same group may transmit a distributed packet including a group trust field consisting of a group code and generated group trust bits. Accordingly, other terminals belonging to the same group may receive the distributed packet from any one terminal.

In addition, another terminal belonging to the same group may perform a reliability check on the group trust bits included in the received distributed packet using the group code and the secret key. Here, terminals belonging to the same group may receive and share the group code and the secret key from the management authority. Alternatively, any one terminal belonging to the same group may generate a group code and a secret key and transmit it to the management authority. Then, other terminals belonging to the same group may receive and share the group code and the secret key from the management authority.

On the other hand, the nuclear power plant server that manages the nuclear power plant facility may prohibit the drone from flying close to the nuclear power plant facility. However, the nuclear power plant server may utilize a drone for observation of the nuclear power plant facility. To this end, the nuclear power plant server may need to allow the drone to fly close to the nuclear power plant facility. In addition, the nuclear power plant server may need to allow drones to fly close to the nuclear power plant facility for other reasons. In this case, the nuclear power plant server can provide the group code and secret key to the drone. In addition, the nuclear power plant server may receive the group trust bits generated by using the group code and the secret key from the drone to determine whether to allow the flight.

2 is a conceptual diagram illustrating a first embodiment of an apparatus for ensuring packet reliability.

Referring to FIG. 2 , the apparatus for ensuring packet reliability may include a nuclear power plant server 210 , a nuclear power plant transceiver 220 , a flight permission approval server 230 , a drone controller 240 , and a drone 250 . In such a packet trust guarantee apparatus, the nuclear power plant server 210 may manage the nuclear power plant equipment, and may manage the group code and the primary secret key. The nuclear power plant server 210 may provide the group code and the primary secret key to the flight permission approval server 230 .

In addition, the nuclear power plant server 210 may inform the flight authorization approval server 230 about a method of generating group trust bits (ie, group trust field) using the group code and the primary secret key. As an example, a method of generating group trust bits using a group code and a primary secret key may include a method of using a linear feedback shift register (LFSR). In general, the drone 250 may use the transmission time or generation time of a packet together when generating group confidence bits in order to generate a different confidence field for every slot.

Accordingly, the nuclear power plant server 210 may inform the flight permission approval server 230 about a method of generating group trust bits using the group code, the primary secret key, and the transmission time. As an example, a method of generating the group trust bits using the group code, the primary secret key, and the transmission time may include a method of using a linear feedback shift register. A method of generating these group trust bits may be previously agreed upon between the nuclear power plant server 210 and the drone 250 . In this case, the drone 250 may store and manage a method of generating group trust bits. Accordingly, the nuclear power plant server 210 may not inform the drone 250 of a method of generating group trust bits.

In addition to this, the drone 250 may additionally further use the drone identifier when generating the group trust bits. Accordingly, the nuclear power plant server 210 may inform the flight permission approval server 230 about a method of generating the group code, the primary secret key, the transmission time, the drone identifier, and the group trust bits. As an example, a method of generating group trust bits using a group code, a primary secret key, a transmission time, and a drone identifier may be a method using a linear feedback shift register.

In addition, the nuclear power plant server 210 may receive a distributed packet including at least one of a group code, group trust bits, and location information from the drone 250 using the nuclear power plant transceiver 220 . Accordingly, the nuclear power plant server 210 may acquire the location information of the drone 250 from the received distributed packet. In addition, the nuclear power plant server 210 may determine whether the location of the drone 250 is located in the nuclear power plant entry restricted area. As a result of the determination, if the location of the drone 250 is located in the nuclear power plant entry restriction zone, the nuclear power plant server 210 may perform a reliability check on the distributed packet including the location information received from the drone 250 . In this case, the nuclear power plant server 210 may acquire the group code from the distributed packet received from the drone 250 .

In addition, the nuclear power plant server 210 may determine whether the acquired group code is the same as the group code transmitted to the flight permission approval server 230 . As a result of the determination, if the group code is the same, the nuclear power plant server 210 generates group reliability bits by using the group code and the primary secret key to generate the group trust bits informed to the flight authorization approval server 230. can In this case, the nuclear power plant server 210 may additionally use at least one of a transmission time and a drone identifier to generate group trust bits. In addition, the nuclear power plant server 210 may determine whether the generated group reliability bits are identical to the group reliability bits in the distributed packet received from the drone 250 . The nuclear power plant server 210 may confirm that the distributed packet can be trusted if the generated group reliability bits are the same as the group reliability bits received from the drone 250 .

In this way, when the nuclear power plant server 210 confirms the reliability of the distributed packet (that is, when the distributed packet passes the reliability check), it transmits a flight permission message to the flight permission approval server 230 to may be permitted to fly. In addition, when the reliability of the received distributed packet is confirmed, the nuclear power plant server 210 may transmit a flight permission message to the drone 250 through the nuclear power plant transceiver 220 to permit the flight. Here, the nuclear power plant entry restriction zone is a certain area located above the nuclear power plant facility, and may be an area in which flying of unauthorized drones is prohibited in order to protect the nuclear power plant facility.

In contrast, the nuclear power plant server 210 performs a reliability check on the distributed packet received from the drone 250 and, when the reliability is not confirmed, transmits a flight permission message to the flight permission approval server 230 to send the drone 250 . may not be permitted to fly. In addition, the nuclear power plant server 210 performs a reliability check on the distributed packet received from the drone 250 and, when the reliability is not confirmed, transmits a flight prohibition message to the drone 250 through the nuclear power plant transceiver 220 . Flight may not be permitted. In this case, the nuclear power plant server 210 may transmit a dispatch request message to the police station server to prevent illegal intrusion of the corresponding drone 250 .

Unlike this, after the nuclear power plant server 210 first performs a reliability check of the distributed packet transmitted by the drone 250, it can be determined whether the location of the drone 250 is located in the nuclear power plant entry restricted area. At this time, when the reliability check for the distributed packet is confirmed, the nuclear power plant server 210 transmits a flight permission message to the flight permission approval server 230 when the location of the drone 250 is located in the nuclear power plant entry restricted area to the drone ( 250) may be permitted to fly. Also, the nuclear power plant server 210 may transmit a flight permission message to the drone 250 through the nuclear power plant transceiver 220 to permit flight. In this case, the nuclear power plant server 210 may disallow the flight of the drone 250 by transmitting a flight prohibition message to the flight authorization approval server 230 when the reliability check for the distributed packet is not confirmed. In addition, the nuclear power plant server 210 may disallow the flight by transmitting a flight prohibition message to the drone 250 through the nuclear power plant transceiver 220 .

On the other hand, the flight permission approval server 230 may receive the group code and the primary secret key from the nuclear power plant (240). In addition, the flight permission approval server 230 may receive information on a method of generating group trust bits from the nuclear power plant 240 . In addition, the flight permission approval server 230 may transmit the received group code and the primary secret key to the drone controller 240 . In addition, the flight permission approval server 230 may transmit information on a method of generating group trust bits to the drone controller 240 .

In addition, the flight permission approval server 230 may receive a flight permission message from the nuclear power plant server 240 when the nuclear power plant server 240 permits the drone 250 to fly. In addition, the flight permission approval server 230 may transmit the received flight permission message to the drone controller 240 . Alternatively, the flight permission approval server 230 may receive a flight disallowing message from the nuclear power plant server 240 when the nuclear power plant server 240 disallows the flight of the drone 250 . In addition, the flight permission approval server 230 may transmit the received flight permission message to the drone controller 240 .

Next, the drone controller 240 may control the flight of the drone 250 by the user's manipulation. In this case, the drone controller 240 may receive the group code and the primary secret key from the flight permission approval server 230 . In addition, the drone controller 240 may receive information on a method of generating group trust bits from the flight authorization approval server 230 . In addition, the drone controller 240 may transmit the received group code and the primary secret key to the drone 250 .

Also, the drone controller 240 may transmit information on a method of generating group trust bits to the drone 250 . When a method for generating group trust bits is promised in advance, information on the generation method may not be transmitted. Meanwhile, the drone controller 240 may receive a flight permission message from the flight permission approval server 230 to inform the user of the flight permission. Of course, the drone controller 240 may receive a non-flight message from the flight permission approval server 230 to inform the user of non-flight.

Meanwhile, the drone 250 may fly around the nuclear power plant according to the control signal of the drone controller 240 . In this case, the drone 250 may receive the group code and the primary secret key from the drone controller 240 . The drone 250 may receive information on a method of generating group trust bits from the drone controller 240 . In addition, the drone 250 may generate group trust bits using the received group code and the primary secret key. In this case, the drone 250 may use the transmission time when generating group confidence bits. The drone 250 may further use the drone identifier when generating group trust bits.

Thereafter, the drone 250 may generate a distributed packet including at least one of a source address (ie, a drone identifier), location information, a group code, group trust bits, and a transmission time. In addition, the drone 250 may transmit a distributed packet including the generated location information to the nuclear power plant server 210 . Then, the nuclear power plant server 210 may receive a distributed packet including at least one of a group code, group trust bits, location information, and a transmission time from the drone 250 using the nuclear power plant transceiver 220 . Accordingly, the nuclear power plant server 210 may acquire the location information of the drone 250 from the received distributed packet. In addition, the nuclear power plant server 210 may determine whether the location of the drone 250 is located in the nuclear power plant entry restricted area. As a result of the determination, if the location of the drone 250 is located in the nuclear power plant entry restriction zone, the nuclear power plant server 210 may perform a reliability check on the distributed packet including the location information received from the drone 250 . At this time, when the nuclear power plant server 210 confirms the reliability of the distributed packet (ie, when the distributed packet passes the reliability check), the flight may be permitted by transmitting a flight permission message to the drone 250 . Accordingly, the drone 250 may receive a flight permission message from the nuclear power plant server 210 . In addition, the drone 250 may transmit the received flight permission message to the drone controller 240 . Contrary to this, the nuclear power plant server 210 transmits a flight prohibition message to the drone 250 through the nuclear power transceiver device 220 when the reliability check is not confirmed by performing a reliability check on the distributed packet received from the drone 250 . may not allow you to fly. Accordingly, the drone 250 may receive a flight prohibition message from the nuclear power plant server 210 . In addition, the drone 250 may transmit the received flight prohibition message to the drone controller 240 .

As such, the distributed packet may have a public trust field and a group trust field. In this case, an operator who operates a wireless distributed communication system may use the public trust field to confirm the reliability of the corresponding distributed packet. In addition, the nuclear power plant server 210 may use the group trust field to confirm the legal flight of the surrounding drones.

In this case, as described above, the nuclear power plant server 210 may change the primary secret key over time to generate and use the secondary secret key to increase the security of the secret key. The drone 250 may broadcast a distributed packet almost once every second. Accordingly, a malicious terminal may continuously receive these distributed packets for a long time. And, the malicious terminal may calculate the primary secret key of the corresponding distributed packet.

Accordingly, if the nuclear power plant server 210 periodically changes the primary secret key, the security can be further improved. However, the nuclear power plant server 210 may transmit the changed secondary secret key back to the flight permission approval server 230 . Accordingly, the flight authorization approval server 230 may receive the changed secondary secret key and update the secret key. In addition, the flight permission approval server 230 may provide the updated secondary secret key to the drone controller 240 .

Accordingly, the drone controller 240 may receive the updated secondary secret key from the flight permission approval server 230 . In addition, the drone controller 240 may provide the received secondary secret key to the drone 250 . Accordingly, the drone 250 may broadcast the location information by generating a distributed packet using the updated secondary secret key.

Here, the nuclear power plant server 210 may be configured to generate a secondary secret key and provide it to the flight permission approval server 220 . However, unlike this, the flight permission approval server may generate a secondary secret key using the primary secret key, and may be implemented to provide the generated secondary secret key to the nuclear power plant server 210 and the drone 250 . An operation of the apparatus for guaranteeing packet reliability will be described with reference to FIG. 3 as follows.

3 is a flowchart illustrating a first embodiment of a method for ensuring packet reliability.

Referring to FIG. 3 , in the packet trust guarantee method, the nuclear power plant server may transmit the group code and the primary secret key to the flight permission approval server ( S301 ). In this case, the nuclear power plant server may inform about a method of generating group trust bits using the group code and the primary secret key as the flight permission approval server. Then, the flight authorization approval server may receive the group code and the primary secret key from the nuclear power plant server. In addition, the flight authorization approval server may receive information on a method of generating group trust bits by using the group code and the primary secret key from the nuclear power plant server.

Then, the flight permission approval server may transmit the group code and the primary secret key to the drone controller (S302). In this case, the flight permission approval server may inform the drone controller about a method of generating group trust bits using the group code and the primary secret key. Then, the drone controller may receive the group code and the primary secret key from the flight authorization approval server. In addition, the drone controller may receive information on a method of generating group trust bits by using the group code and the primary secret key from the flight permission approval server.

Accordingly, the drone controller may transmit the group code and the primary secret key to the drone (S303). Also, the drone controller may transmit a method of generating group trust bits by using the group code and the primary secret key to the drone. Then, the drone may receive the group code and the primary secret key from the drone controller. In addition, the drone may receive information on a method of generating group trust bits by using the group code and the primary secret key from the drone controller. Thereafter, the drone may generate group trust bits based on a method of generating group trust bits using the group code and the primary secret key.

In this case, the drone may use the transmission time when generating group confidence bits. In addition, the drone may further use the drone identifier when generating the group trust bits. Then, the drone may use a distributed packet including at least one or more of a source address, location information, group code, group trust bits, and transmission time. can create In addition, the drone may transmit the generated distributed packet to the nuclear power plant transceiver. Then, the nuclear power plant transceiver may receive a distributed packet including location information from the drone. In addition, the nuclear power plant transceiver may transmit a distributed packet including location information to the nuclear power plant server.

Then, the nuclear power plant server may receive the distributed packet including the location information including the group code and group trust bits from the nuclear power transceiver device (S304). In this case, the nuclear power plant server may obtain the location information of the drone from the distributed packet. In addition, the nuclear power plant server may determine whether the location of the drone is located in the nuclear power plant entry restricted area. As a result of the determination, if the location of the drone is located in the restricted area of the nuclear power plant, the nuclear power plant server performs a reliability check on the distributed packet including the location information received from the drone to ensure reliability, and sends a flight permission message to the flight permission approval server It is possible to permit the flight of the drone by transmitting (S305a). In addition, the nuclear power plant server may obtain the location information of the drone and display the drone on the 3D map it has.

Accordingly, the flight authorization approval server may receive the flight authorization message from the nuclear power plant server. Then, the flight permission approval server may transmit the received flight permission message to the drone controller (S305b). Then, the drone controller may receive a flight authorization message from the flight authorization approval server. Thereafter, the drone controller may notify the user of the permission to fly.

In addition, when the reliability check is performed on the distributed packet received from the drone and the reliability is secured, the nuclear power plant server may transmit a flight permission message to the drone through the nuclear power plant transceiver device to allow flight (S306a). Accordingly, the drone may receive a flight permission message from the nuclear power plant server. Then, the drone may transmit the received flight permission message to the drone controller (S306b). Then, the drone controller may receive a flight permission message from the drone. Thereafter, the drone controller may notify the user of the permission to fly.

Here, the nuclear power plant server checks the location information of the drone and performs the reliability check when it is located in the nuclear power plant entry restricted area, but unlike this, the nuclear power plant server may first perform the reliability check of the distributed packet. In addition, the nuclear power plant server may determine whether the location of the drone is located in the nuclear power plant entry restricted area when the reliability check for the distributed packet is confirmed. Thereafter, when the location of the drone is located in the nuclear power plant entry restricted area as a result of determination, the nuclear power plant server may transmit a flight permission message to the flight permission approval server to allow the drone to fly. In addition, the nuclear power plant server may permit the flight by transmitting a flight permission message to the drone through the nuclear power plant transceiver. In this case, when the reliability check for the distributed packet is not confirmed, the nuclear power plant server may disallow the flight of the drone by transmitting a flight disallowing message to the flight permit approval server. Also, the nuclear power plant server may disallow flight by transmitting a flight prohibition message to the drone through the nuclear power plant transceiver.

On the other hand, the nuclear power plant server can increase the security of the secret key by periodically generating and using the secondary secret key based on the primary secret key. Accordingly, the nuclear power plant server may periodically transmit the secondary secret key to the flight permission approval server (S307). Accordingly, the flight authorization approval server may receive the changed secondary secret key and update the secret key. Then, the flight permission approval server may provide the updated secondary secret key to the drone controller (S308).

Accordingly, the drone controller may receive the updated secondary secret key from the flight authorization approval server. Then, the drone controller may provide the received secondary secret key to the drone (S309). Accordingly, the drone may broadcast the location information by generating a distributed packet using the updated secondary secret key (S310).

At this time, the drone may further use the transmission time when generating group confidence bits. And, the drone may further use the drone identifier when generating group trust bits. Thereafter, the drone may generate a distributed packet including at least one of a source address, location information, a group code, group trust bits, and a transmission time. In addition, the drone may transmit the generated distributed packet to the nuclear power plant transceiver. Then, the nuclear power plant transceiver may receive a distributed packet including location information from the drone. In addition, the nuclear power plant transceiver may transmit a distributed packet including location information to the nuclear power plant server.

Then, the nuclear power plant server may receive the distributed packet including the location information including the group code and the group trust bits from the nuclear power transceiver device. In this case, the nuclear power plant server may obtain the location information of the drone from the distributed packet. In addition, the nuclear power plant server may determine whether the location of the drone is located in the nuclear power plant entry restricted area. As a result of the determination, when the location of the drone is located in the restricted area of the nuclear power plant, the nuclear power plant server obtains and provides the location information of the drone when reliability is secured by performing a reliability check on the distributed packet including the location information received from the drone. It is possible to change the position of the drone on the present 3D map (S311).

Of course, as a result of the determination, if the location of the drone is located in the nuclear power plant entry restricted area, the nuclear power plant server may transmit a flight permission message to the flight permission approval server to allow the drone to fly. In addition, the nuclear power plant server may permit the flight by transmitting a flight permission message to the drone through the nuclear power plant transceiver.

Here, the nuclear power plant server checks the location information of the drone and performs the reliability check when it is located in the nuclear power plant entry restricted area, but unlike this, the nuclear power plant server may first perform the reliability check of the distributed packet. In addition, the nuclear power plant server may determine whether the location of the drone is located in the nuclear power plant entry restricted area when the reliability check for the distributed packet is confirmed. Thereafter, when the location of the drone is located in the nuclear power plant entry restricted area as a result of determination, the nuclear power plant server may transmit a flight permission message to the flight permission approval server to allow the drone to fly. In addition, the nuclear power plant server may permit the flight by transmitting a flight permission message to the drone through the nuclear power plant transceiver. In addition, the nuclear power plant server may acquire the location information of the drone and change the location of the drone on the 3D map provided. In this case, when the reliability check for the distributed packet is not confirmed, the nuclear power plant server may disallow the flight of the drone by transmitting a flight disallowing message to the flight permit approval server. Also, the nuclear power plant server may disallow flight by transmitting a flight prohibition message to the drone through the nuclear power plant transceiver.

Meanwhile, drones can be expected to operate autonomously in the future. For such autonomous operation, the drone may need to avoid moving obstacles that are difficult to be included in the 3D map. In general, a drone can avoid terrain features by mounting a 3D map, but there may be moving obstacles that are difficult to be included in the 3D map.

The obstacle device installed on the moving obstacle may broadcast the location of the moving obstacle using wireless distributed communication. In this case, the obstacle device may use the public trust field. However, the drone cannot verify the reliability of the distributed packet transmitted from the obstacle device using the public trust field. The reason may be that only authorized trust checking authorities can perform trust checks on public trust fields. Thus, the obstacle device may use the group trust field.

On the other hand, there may be differences between the example of the nuclear power plant server and the example of the obstacle device. The nuclear power plant server may transmit the secret key it generated to the flight authorization approval server. However, it may be difficult for the obstacle device to directly access the flight authorization approval server.

If the obstacle device is directly connected to the flight authorization approval server, a separate communication means for connection may be required. For this purpose, the obstacle device may rely on mobile communication. As a result, costs may rise, larger hardware may be required, and more power may be required.

Therefore, it may be more economical for the obstacle device to rely on the manual input of the administrator than to receive the group code and secret key from the flight authorization approval server through communication. However, the problem with such manual entry may be that it is difficult to update the secret key. It can be too cumbersome for an administrator to manually enter the periodically updated secret key into the obstacle device. Thus, multiple secret key structures may be required.

4 is a conceptual diagram illustrating a second embodiment of an apparatus for guaranteeing packet reliability.

Referring to FIG. 4 , the apparatus for ensuring packet reliability may include a flight permission approval server 410 , an obstacle device 420 , and a drone 430 . In such a packet trust guarantee device, the flight authorization approval server 410 may manage a group code, a primary secret key, and a periodically updated secondary secret key from the primary secret key. The flight authorization approval server 410 may provide the group code and the primary secret key to the obstacle device 420 . In addition, the flight permission approval server 410 may provide information on a method of updating the primary secret key to the obstacle device 420 .

In addition, the flight permission approval server 410 may inform the obstacle device 420 of a method of generating group trust bits using the group code and the updated secondary secret key from the primary secret key. In addition, the flight permission approval server 410 may provide the group code and the secondary secret key to the drone 430 . In addition, the flight permission approval server 410 may inform the drone 430 of a method of generating group trust bits using the group code and the secondary secret key.

On the other hand, the obstacle device 420 may receive the group code and the primary secret key from the flight permission approval server (410). In addition, the obstacle device 420 may periodically update the primary secret key to generate an updated secondary secret key. Thereafter, the obstacle device 420 may generate group trust bits using the received group code and the secondary secret key. In this case, the obstacle device 420 may further use at least one of the transmission time and the obstacle device identifier when generating the group confidence bits.

Thereafter, the obstacle device 420 may generate a distributed packet including at least one of a source address, location information, group code, group trust bits, and transmission time. In addition, the obstacle device 420 may transmit the generated distributed packet to the drone 430 . Accordingly, the drone 430 may receive a distributed packet from the obstacle device 420 . In this case, the drone 430 may perform a reliability check on the distributed packet received from the obstacle device 420 . That is, the drone 430 may obtain the group code from the received distributed packet.

In addition, the drone 430 may determine whether the acquired group code is the same as the group code received from the flight permission approval server 410 . As a result of the determination, if the group code is the same, the drone 430 generates the group reliability bits using a method of generating the group trust bits received from the flight authorization approval server 410 using the group code and the secondary secret key. can In this case, the drone 430 may additionally use at least one of a transmission time and an obstacle device identifier to generate group confidence bits. Then, the drone 430 may determine whether the generated group reliability bits are the same as the group reliability bits in the distributed packet received from the obstacle device 420 . The drone 430 may confirm that the distributed packet can be trusted if the generated group reliability bits are the same as the group reliability bits received from the obstacle device 420 .

The drone 430 may acquire the location information of the obstacle device 420 and display the obstacle device 420 on the provided 3D map when reliability is confirmed as a result of the reliability test. Alternatively, the drone 430 may ignore the location information of the obstacle device 420 when reliability is not confirmed as a result of the inspection. An operation of the apparatus for guaranteeing packet reliability will be described with reference to FIG. 5 as follows.

5 is a flowchart illustrating a second embodiment of a method for ensuring packet reliability.

Referring to FIG. 5 , in the packet trust guarantee method, the flight permission approval server may provide the group code and the primary secret key to the obstacle device (S501). Then, the flight permission approval server may provide the group code and the secondary secret key to the drone (S502).

On the other hand, the obstacle device may receive the group code and the primary secret key from the flight authorization approval server. And, the obstacle device may generate an updated secondary secret key by periodically updating the primary secret key. Thereafter, the obstacle device may generate group trust bits using the received group code and the secondary secret key. In this case, the obstacle device may use at least one of the transmission time and the obstacle identifier when generating the group confidence bits.

Thereafter, the obstacle device may generate a distributed packet including at least one of a source address, location information, a group code, group trust bits, and a transmission time. Then, the obstacle device may transmit a distributed packet including the generated location information to the drone (S503). Accordingly, the drone may receive a distributed packet from the obstacle device. In this case, the drone may perform a reliability check on the distributed packet received from the obstacle device. When the reliability is confirmed as a result of the reliability test, the drone acquires location information of the obstacle device and displays the obstacle device on the 3D map it has. In contrast, the drone may ignore the location information of the obstacle device when reliability is not secured as a result of the reliability check.

6 is a configuration diagram illustrating a first embodiment of a distributed packet including a special trust field (STF).

Referring to FIG. 6 , the distributed packet includes a packet header field 610 , a source address field 620 , a destination address field 630 , a public trust field 640 , a data field 650 , and a CRC field 660 . can do. Here, the packet header field 610 may be a field for indicating a packet type. In this case, the packet type may be, for example, a payment request packet. The terminal may indicate that it is a payment request packet by using, for example, hexadecimal 0x0B in the packet header field 610 . Next, the source address field 620 may be a field for indicating the source address of the distributed packet.

The terminal may transmit by designating its identifier (ID) in the source address field 620 . And, the destination address field 630 may be a field for indicating the destination address of the distributed packet. The terminal may designate a destination address in the destination address field 630 . In addition, the public trust field 640 may be a field that allows the trust of the distributed packet to be confirmed through a trusted authority designated by the wireless distributed communication system.

Meanwhile, the data field 650 may include a company payment parsing block 651 and a general data field 652 . Here, the company payment parsing block 651 may be a parsing block related to company payment. The company payment parsing block 651 may include a parsing header field 651-1, a company code field 651-2, and a specific trust field 651-3. Here, the parsing header field 651-1 may be a field for indicating characteristics of information included in the company payment parsing block 651 .

The terminal may provide the company code through the company code field 651-2 that follows using hexadecimal 0x06 as an example, and may indicate that specific trust bits are provided through the specific trust field 651-3. have. In addition, the company code field 651 - 2 may be a field for indicating a company code. The terminal may transmit by designating the company code in the company code field 651-2.

Next, the specific trust field 651-3 may refer to a field inserted into a packet so that a reliability check can be performed between any two specific terminals in wireless distributed communication. The specific trust field 651-3 may include specific trust bits generated using a company code and a secret key. Here, the terminal may generate specific trust bits using a company code and a secret key. A method of generating specific trust bits using a group code and a secret key may include a method of using a linear feedback shift register. In this case, the terminal may generate specific trust bits using a company code, a terminal identifier, and a secret key.

Alternatively, the terminal may generate specific trust bits using the company code, the terminal identifier, the transmission time and the secret key. The UE may transmit by designating specific trust bits in the specific trust field 651-3. In addition, the general data field 652 may include data that the terminal needs to transmit, and may include, for example, a transmission time of a distributed packet. Regarding the transmission time, in the synchronous wireless distributed communication, the terminal may not transmit the transmission time through the general data field 652 . This may be because, in synchronous wireless distributed communication, the slot time at which the corresponding distributed packet is transmitted may be the time at which specific confidence bits are generated. Next, the CRC field 660 may designate a CRC to determine whether there is an error.

In such a distributed packet, a specific trust field can be used for multiple purposes. After the two terminals simply share each other's identifier and a secret key for generating a specific trust field, the two terminals can authenticate each other through this. However, such a method may correspond to simple one-to-one communication. Therefore, there may be no reason for the terminal to use a specific trust field. That is, the two terminals can use a general one-to-one security technique.

Accordingly, in the present application, the wireless distributed communication system may use a specific trust field in a many-to-many communication structure. To this end, in the present application, it can be specifically assumed that the first terminal and the third terminal can use distributed communication. In addition, it may be assumed that the second terminal and the third terminal are connected by different communication means. Also, it may be assumed that the first terminal can be connected to the second terminal through the third terminal.

First, the first terminal and the second terminal may generate a specific trust field. The first terminal and the second terminal may share each other's identifier and a secret key for generating a specific trust field in order to perform a reliability check. Accordingly, the first terminal may transmit the identifier and the secret key to the second terminal. In this case, the second terminal may store the identifier and the secret key of the first terminal. Similarly, the second terminal may transmit the identifier and the secret key to the first terminal. The first terminal may store the identifier and the secret key of the second terminal.

Here, the first terminal may use a specific code designating itself instead of the identifier. The first terminal may transmit a specific code designating itself instead of the identifier to the second terminal. The second terminal may store the identifier and the secret key of the first terminal. And, the second terminal may use a specific code designating itself instead of the identifier. Accordingly, the second terminal may transmit a specific code designating itself instead of the identifier to the first terminal. In this case, the first terminal may store the specific code and secret key of the second terminal. In this case, the first terminal and the second terminal may each have received a specific code to be shared in advance from the management organization of the wireless distributed communication system.

The first terminal may generate a specific trust field by using the secret key shared with the second terminal. In addition, the first terminal may transmit a distributed packet including the generated specific trust field, the corresponding specific code, and the required work to the third terminal that does not share the secret key. Here, there may be two methods for the first terminal to include the requested job information in the packet. One may be to construct a packet using a packet header indicating request operation information. Another method may be to include request operation information in a data field of a packet.

The third terminal may receive the distributed packet from the first terminal. In this case, since the third terminal does not have a related secret key, it cannot perform a reliability check on it. Accordingly, the third terminal may deliver the received distributed packet to the second terminal matching the specific code. The second terminal may perform a reliability check on the distributed packet received from the third terminal by using the secret key shared with the first terminal. In this case, when reliability is secured as a result of the reliability check, the second terminal may perform a request operation included in the distributed packet. If reliability is not secured as a result of the reliability check, the second terminal may not perform the request operation included in the distributed packet.

An example in which such a wireless distributed communication system uses a specific trust field may be illustrated in FIG. 7 . If drone taxis are commercialized in the future, drone taxis can use a landing pad for drone taxis. Drone taxis may obtain a landing permit prior to landing on the landing pad. At this time, the drone taxi company may pay a drone usage fee to the landing site server. Here, the landing site can be viewed as an entry restricted area.

7 is a conceptual diagram illustrating a third embodiment of an apparatus for guaranteeing packet reliability.

Referring to FIG. 7 , the apparatus for ensuring packet reliability may include a landing site transceiver 710 , a landing site server 720 , a drone company server 730 , and a drone taxi 740 . Here, the landing site server 720 and the drone company server 730 may be connected through reliable communication.

In such a packet trust guarantee device, the landing gear transceiver 710 may receive a payment request through a company for landing and a distributed packet requesting a landing permission according to payment processing from the drone taxi 730 . Here, the payment request through the company and the landing permission according to the payment processing may be work to be processed by the landing site server 720 . In addition, the payment request through the company may be a task to be processed by the drone company server 730 . In addition, the landing site transceiver 710 may transmit a distributed packet requesting a landing permission according to a request for payment received from the drone taxi 730 and payment processing to the landing site server 720 . Meanwhile, the landing site transceiver 710 may receive a landing permission signal transmitted from the landing site server 720 upon completion of the payment processing. In addition, the landing site transceiver 710 may transmit the received landing permission signal to the drone taxi 730 .

Next, the landing site server 720 may have a list of company codes of drone companies using the landing site. Such a landing site server 720 may receive a payment request for landing of the drone taxi 730 and a distributed packet requesting a landing permission according to payment processing from the landing site receiving device 710 . In addition, the landing site server 720 may obtain the company code of the distributed packet received from the drone taxi 730 through the landing site transceiver 710 . And, the landing server 720 may request payment while transmitting the distributed packet to the drone company server 730 corresponding to the company code obtained from the distributed packet with reference to the company code list of the drone companies it has. In this case, the landing site server 720 may additionally transmit additional information (eg, account number, payment amount) necessary for payment to the drone company server 730 . In this case, the landing site server 720 may provide the reception time information of the distributed packet to the drone company server 730 .

Of course, the landing site server 720 may request payment while transmitting a part of the distributed packet received from the drone taxi 730 through the landing site transceiver 710 to the drone company server 730 . Here, a part of the distributed packet transmitted by the landing server 720 to the drone company server 730 is an identifier (ie, source address) of the drone taxi 740, payment request information, and specific trust bits (ie, a specific trust field). ) may be included. In this case, the landing site server 720 may additionally transmit additional information (eg, account number, payment amount) necessary for payment to the drone company server 730 . In this case, the landing site server 720 may provide the reception time information of the distributed packet to the drone company server 730 .

Meanwhile, the landing site server 720 may receive a work request according to the work content (ie, payment processing request) from the drone company server 730 . In addition, the landing site server 720 may receive a landing site usage fee from the drone company server 730 by performing a payment operation with the drone company server 730 according to the work request. Then, the landing site server 720 may transmit a landing permission signal to the drone taxi 740 through the landing site transceiver 710 . Of course, the landing site server 720 may not be able to proceed with payment with the drone company server 730 through this process. Then, the landing site server 720 may not receive a landing site usage fee from the drone company server 730 . Accordingly, the landing site server 720 may transmit a landing permission signal to the drone taxi 740 through the landing site transceiver 710 .

Next, the drone company server 730 may manage the drone taxi identifier, company code, and secret key. In addition, the drone company server 730 may transmit a company code and a secret key for generating a specific trust field to the drone taxi 740 and share it with the drone taxi 740 . In addition, the drone company server 730 may share the method of generating specific trust bits by using the company code and the secret key to the drone taxi 740 .

Thereafter, the drone company server 730 may receive a distributed packet including a payment request related to the landing of the drone taxi 740 from the landing site server 720 . In addition, the drone company server 730 may receive additional payment information (eg, account number of the landing site server, payment amount) necessary for processing payment related to the landing of the drone taxi 740 from the landing site server 720 . . In addition, the drone company server 730 may receive the reception time information of the distributed packet from the landing server 720 . As such, the drone company server 730 may receive the distributed packet, payment additional information, and reception time information generated by the drone taxi 740 from the landing site server 720 . Alternatively, the drone company server 730 may receive a part of the distributed packet generated by the drone taxi 740 , payment additional information, and reception time information from the landing site server 720 . Here, a part of the distribution packet may include an identifier (ie, a source address) of the drone taxi 740, payment request information, and specific trust bits (ie, a specific trust field).

Accordingly, the drone company server 730 may perform a trust check using the received company code and a specific trust field. The drone company server 730 may determine whether the acquired company code is the same as the company code transmitted to the drone taxi 740 . As a result of the determination, the drone company server 730 may generate specific reliability bits using a method of generating specific trust bits notified to the drone taxi 740 using the company code and the secret key if the company code is the same. In this case, the drone company server 730 may additionally use at least one of a transmission time and a drone taxi identifier to generate specific trust bits. Then, the drone company server 730 may determine whether the generated specific reliability bits are the same as the specific reliability bits in the distributed packet received from the drone taxi 740 . The drone company server 730 may confirm that the distributed packet can be trusted if the generated specific reliability bits are the same as the specific reliability bits received from the drone taxi 740 .

In this case, the drone company server 730 may perform a trust check by using the transmission time or reception time information in addition to the received company code, a specific trust field, and the drone taxi identifier. As a result of such a trust check, when reliability is secured, the drone company server 730 may perform a payment operation with the landing site server 720 to pay the landing site usage fee to the payment server 720 . If, as a result of the trust check, reliability is not secured, the drone company server 730 may not perform a payment operation with the landing site server 720 .

Meanwhile, the drone taxi 740 may receive a company code and a secret key from the drone company server 740 . In addition, the drone taxi 740 may receive a method of generating specific trust bits by using the company code and the secret key from the drone company server 740 .

In addition, the drone taxi 740 arriving near the landing may transmit a distributed packet to the landing transceiver 710 . In this case, the distributed packet transmitted by the drone taxi 740 may include a packet header field, a source address field, a destination address field, a public trust field, a data field, and a CRC field. Here, the packet header field may include a packet header indicating that it is a payment request packet.

In addition, the source address field may include an identifier of the drone 740 . In addition, the destination address field may include an identifier of the landing site server 720 . The data fields may include the drone company's company code, specific trust fields, and related data. Thereafter, the drone taxi 740 may receive a landing permission signal from the landing transceiver 710 . Accordingly, the drone taxi 740 may land on the landing pad. The operation of the packet reliability guarantee apparatus may be as follows with reference to FIG. 8 .

8 is a flowchart illustrating a third embodiment of a method for ensuring packet reliability.

Referring to FIG. 8 , in the packet trust guarantee method, the drone company server may manage a drone taxi identifier, a company code, and a secret key. Then, the drone company server may transmit a company code and a secret key for generating a specific trust field to the drone taxi and share it with the drone taxi (S801). In addition, the drone company server can share the method of generating specific trust bits by using the company code and secret key to the drone taxi. Meanwhile, the drone taxi may receive the company code and secret key from the drone company server. In addition, the drone taxi may receive a method of generating specific trust bits using the company code and secret key from the drone company server.

Then, the drone taxi arriving near the landing site may transmit a distributed packet for requesting a payment request and a landing permission to the landing site transceiver device (S802). In this case, the distributed packet transmitted by the drone taxi may include a packet header field, a source address field, a destination address field, a public trust field, a data field, and a CRC field. Here, the packet header field may include a packet header indicating that it is a payment request packet. And, the source address field may include an identifier of the drone taxi. And, the destination address field may include an identifier of the landing server. The data fields may include the drone company's company code, specific trust fields, and related data.

Accordingly, the landing transceiver device may receive a distributed packet requesting payment through a company for landing from the drone taxi. Then, the landing transceiver device may transmit the payment request received from the drone taxi and the distributed packet requesting the landing permission to the landing site server (S803). Then, the landing site server may receive a payment request for the landing of the drone taxi and a distributed packet for the landing request from the landing site receiving device. In addition, the landing site server may request payment while transmitting a distributed packet requesting payment received from the drone taxi through the landing site transceiver device to the drone company server (S804). In this case, the landing site server may transmit the reception time information of the distributed packet to the drone company server.

In this case, the landing site server may additionally transmit additional information (eg, account number, payment amount) necessary for payment to the drone company server. Of course, the landing site server may request payment while transmitting a part of the distributed packet requesting payment received from the drone taxi through the landing site transceiver device to the drone company server. Here, a part of the distributed packet transmitted by the landing server to the drone company server may include an identifier (ie, source address) of the drone taxi, request operation information (ie, payment request), and a specific trust field. In this case, the landing site server may transmit the reception time information of the distributed packet to the drone company server.

In this case, the landing site server may additionally transmit additional information (eg, account number, payment amount) necessary for payment to the drone company server. The drone company server may receive a payment request related to the landing of the drone taxi from the landing site server. In this way, the drone company server may receive distributed packets generated by the drone taxi and payment-related information from the landing site server. Alternatively, the drone company server may receive a part of the distributed packet generated by the drone taxi and payment related information from the landing site server.

Accordingly, the drone company server may perform a reliability check using the received company code and a specific trust field. In this case, the drone company server may perform a reliability check using the received company code and secret key. In addition, the drone company server may perform a reliability check using the received company code, secret key, and transmission time. In addition, the drone company server may perform a reliability check using the received company code, secret key, transmission time, and drone taxi identifier. In addition, the drone company server may perform a reliability check using the received company code, secret key, and reception time information. In addition, the drone company server may perform a reliability check using the received company code, secret key, reception time information, and drone taxi identifier. As a result of such a reliability check, when reliability is secured, the drone company server may perform a payment operation with the landing site server (S805) to pay the landing site usage fee to the landing site server. If reliability is not secured as a result of the reliability check, the drone company server may not perform payment with the landing site server.

On the other hand, the landing site server can receive a landing site usage fee from the drone company server by making a payment with the drone company server through this process. Then, the landing site server may transmit a landing permission signal to the drone taxi through the landing site transceiver (S806, S807). Of course, the landing site server may not be able to make payments with the drone company server through this process. Then, you cannot receive the landing fee from the drone company server. Accordingly, the landing site server may transmit a landing disapproval signal to the drone taxi through the landing site transceiver. Accordingly, the drone taxi may receive a landing permission signal from the landing transceiver. Accordingly, the drone taxi can land on the landing pad.

9 is a block diagram illustrating a second embodiment of a distributed packet including a specific trust field.

Referring to FIG. 9 , the distributed packet includes a packet header field 910 , a source address field 920 , a destination address field 930 , a public trust field 940 , a data field 950 , and a CRC field 960 . can do. Here, the packet header field 910 may be a field for indicating a packet type. In this case, the packet type may be, for example, a card payment request packet. The terminal may indicate that it is a card payment request packet by using, for example, 0x0C in hexadecimal in the packet header field 910 . Next, the source address field 920 may be a field for indicating the source address of the distributed packet.

The terminal may transmit by designating its identifier (ID) in the source address field 920 . And, the destination address field 930 may be a field for indicating the destination address of the distributed packet. The terminal may transmit by designating the destination address in the destination address field 930 . In addition, the public trust field 940 may be a field that allows the trust of a distributed packet to be confirmed through a trusted authority designated by the wireless distributed communication system.

Meanwhile, the data field 950 may include a card company payment parsing block 951 and a general data field 952 . Here, the card company payment parsing block 951 may be a parsing block related to card payment. The card company payment parsing block 951 may include a parsing header field 951-1, a card company code field 951-2, a card information field 951-3, and a specific trust field 951-4. . Here, the parsing header field 951-1 may be a field for indicating characteristics of information included in the card company payment parsing block 951 .

The parsing header field 951-1 may provide a card company code through the card company code field 951-2 that follows using hexadecimal 0x07, for example, and card information through the card information field 951-2. may be provided, and may indicate that specific trust bits can be provided through the specific trust field 951-4. Also, the card company code field 951-2 may be a field for indicating a card company code. The terminal may transmit by designating the card company code in the card company code field 951-2.

Next, the card information field 951-3 is for providing card information and may include a card number. In addition, the specific trust field 951-4 may refer to a field inserted into a packet so that a mutual trust check can be performed between any two specific terminals in wireless distributed communication. The specific trust field 951-4 may include specific trust bits generated using a card company code and a secret key.

Here, the terminal may generate specific trust bits using a card company code and a secret key. Alternatively, the terminal may generate specific trust bits using the card company code, the terminal identifier, and the secret key. Alternatively, the terminal may generate specific trust bits using the card company code, the terminal identifier, the transmission time and the secret key. The UE may transmit by designating specific trust bits in the specific trust field 951-4. And, the general data field 952 may include data that the terminal needs to transmit. As an example, the general data field 952 may include a transmission time of a distributed packet. Next, the CRC field 960 may designate a CRC to determine whether there is an error.

10 is a conceptual diagram illustrating a fourth embodiment of an apparatus for guaranteeing packet reliability.

Referring to FIG. 10 , the apparatus for ensuring packet reliability may include a landing site transceiver 1010 , a landing site server 1020 , a card company server 1030 , and a drone taxi 1040 . Here, the landing server 1020 and the card company server 1030 may be connected through reliable communication.

In such a packet trust guarantee device, the landing site transceiver 1010 may receive a payment request through a card company and a distributed packet requesting landing permission for landing from the drone taxi 1030 . In addition, the landing site transceiver 1010 may transmit a card payment request received from the drone taxi 1030 and a distributed packet requesting landing permission to the landing site server 1020 .

Meanwhile, the landing site transceiver 1010 may receive a card payment result signal transmitted from the landing site server 1020 upon completion of the card payment processing. In addition, the landing transceiver 1010 may transmit the received card payment result signal to the drone taxi 1030 . In addition, the landing site transceiver 1010 may receive a landing permission signal transmitted from the landing site server 1020 upon completion of card payment processing. In addition, the landing site transceiver 1010 may transmit the received landing permission signal to the drone taxi 1030 .

Next, the landing site server 1020 may receive a card payment request for landing of the drone taxi 1030 and a distributed packet requesting landing permission from the landing site receiving device 1010 . Also, the landing site server 1020 may request card payment while transmitting the distributed packet received from the drone taxi 1030 through the landing site transceiver 1010 to the card company server 1030 . In this case, the landing server 1020 may additionally transmit additional information (eg, account number, payment amount) necessary for payment to the card company server 1030 . In this case, the landing server 1020 may additionally transmit the reception time of the distributed packet and propagation delay time information from the drone taxi 1040 to the payment server 1020 to the card company server 1030 .

In contrast, the landing site server 1020 may request payment while transmitting a part of the distributed packet requesting card payment received from the drone taxi 1030 through the landing site transceiver 1010 to the card company server 1030 . Here, a part of the distributed packet transmitted by the landing server 1020 to the card company server 1030 may include an identifier (ie, source address) of the drone taxi 1040, work request information, card information, and a specific trust field. have. In this case, the landing server 1020 may additionally transmit additional information (eg, account number, payment amount) necessary for payment to the card company server 1030 . In addition, the landing server 1020 may additionally transmit the reception time of the distributed packet and propagation delay time information from the drone taxi 1040 to the payment server 1020 to the card company server 1030 .

Meanwhile, the landing site server 1020 may receive a work request according to the work content (ie, payment processing request) from the card company server 1030 . In addition, the landing server 1020 may receive a card payment result signal from the card company server 1030 by performing a payment with the card company server 1030 according to such a work request. Then, the landing site server 1020 may transmit a card payment result signal to the drone taxi 1040 through the landing site transceiver 1010 . In addition, the landing site server 1020 may transmit a landing permission signal to the drone taxi 1040 through the landing site transceiver 1010 . Of course, the landing server 1020 may not be able to proceed with payment with the card company server 1030 through this process. Then, the landing site server 1020 may not receive a landing site usage fee from the card company server 1030 . Accordingly, the landing site server 1020 may transmit a landing permission signal to the drone taxi 1040 through the landing site transceiver 1010 .

Next, the card company server 1030 may manage the drone taxi identifier, the card company code, and the secret key. In addition, the card company server 1030 may transmit a card company code and a secret key for generating a specific trust field to the drone taxi 1040 and share it with the drone taxi 1040 . In addition, the card company server 1030 may share a method of generating specific trust bits by using the card company code and the secret key to the drone taxi 1040 .

Thereafter, the card company server 1030 may receive a card payment request related to the landing of the drone taxi 1040 from the landing site server 1020 . In this case, the card company server 1030 may receive the distributed packet generated by the drone taxi 1040 and card payment related information from the landing site server 1020 . In addition to this, the card company server 1030 additionally receives the reception time of receiving the distributed packet from the drone taxi 1040 from the landing server 1020 and the propagation delay time information from the drone taxi 1040 to the payment server 1020. can do. Alternatively, the card company server 1030 may receive a part of the distributed packet generated by the drone taxi 1040 and payment related information from the landing server 1020 . In addition to this, the card company server 1030 additionally receives the reception time of receiving the distributed packet from the drone taxi 1040 from the landing server 1020 and the propagation delay time information from the drone taxi 1040 to the payment server 1020. can do.

Accordingly, the card company server 1030 may perform a reliability check using the secret key shared with the drone taxi 1040 and the card company code and specific trust bits included in the distributed packet.

Accordingly, the card company server 1030 may perform a trust check using the received card company code and a specific trust field. The card company server 1030 may determine whether the obtained card company code is the same as the card company code transmitted to the drone taxi 1040 . As a result of the determination, the card company server 1030 may generate specific reliability bits using a method of generating specific trust bits notified to the drone taxi 1040 using the card company code and the secret key if the card company code is the same. have. In this case, the card company server 1030 may additionally use at least one of a transmission time and a drone taxi identifier to generate specific trust bits.

In addition, the card company server 1030 may determine whether the generated specific reliability bits are the same as the specific reliability bits in the distributed packet received from the drone taxi 1040 . The card company server 1030 may confirm that the distributed packet can be trusted if the generated specific reliability bits are the same as the specific reliability bits received from the drone taxi 1040 . In this case, the drone company server 1030 may perform a trust check by using the transmission time in addition to the received card company code, a specific trust field, and the drone taxi identifier.

In this case, when the transmission time cannot be found in the distributed packet, the card company server 1030 may use the reception time and propagation delay time received from the landing server 1020 to calculate the transmission time and use it. Looking at this in more detail, the card company server 1030 may use the calculated transmission time by calculating the transmission time by subtracting the propagation delay time from the reception time. Meanwhile, the card company server 1030 may perform a reliability check using the shared secret key, the card company code included in the distributed packet, specific trust bits, the transmission time, and the drone taxi identifier.

As a result of the reliability check, when reliability is confirmed, the card company server 1030 may perform a payment operation with the landing server 1020 and transmit a card payment result signal to the landing server 1020 when payment is completed. If, as a result of the reliability check, reliability is not confirmed, the card company server 1030 may not perform a payment operation with the landing server 1020 .

Meanwhile, the drone taxi 1040 may receive a card company code and a secret key from the card company server 1040 . In addition, the drone taxi 1040 may receive and share a method of generating specific trust bits by using the card company code and the secret key from the card company server 1040 .

In addition, the drone taxi 1040 arriving near the landing may transmit a distributed packet requesting payment to the card company to the landing transceiver 1010 . In this case, the distributed packet transmitted by the drone taxi 1040 may include a packet header field, a source address field, a destination address field, a public trust field, a data field, and a CRC field. Here, the packet header field may include a packet header indicating that it is a card payment request packet. In addition, the source address field may include an identifier of the drone taxi 1040 .

In addition, the destination address field may include an identifier of the landing site server 1020 . The data field may include a card company code of the card company, card information, a specific trust field, and related data. Thereafter, the drone taxi 1040 may receive a card payment result signal from the landing transceiver 1010 . Accordingly, the drone taxi 1040 may land on the landing pad. In addition, the drone taxi 1040 may receive a landing permission signal from the landing transceiver 1010 . Accordingly, the drone taxi 1040 may land on the landing pad. The operation of such a packet reliability guaranteeing apparatus may be as shown in FIG. 11 .

11 is a flowchart illustrating a fourth embodiment of a method for ensuring packet reliability.

Referring to FIG. 11 , in the packet trust guarantee method, the card company server may manage a drone taxi identifier, a card company code, and a secret key. Then, the card company server may transmit a card company code and a secret key for generating a specific trust field to the drone taxi and share it with the drone taxi (S1101). Meanwhile, the drone taxi may receive the card company code and secret key from the card company server.

And, the drone taxi arriving near the landing may transmit a distributed packet to the landing transceiver device (S1102). In this case, the distributed packet transmitted by the drone taxi may include a packet header field, a source address field, a destination address field, a public trust field, a data field, and a CRC field. Here, the packet header field may include a packet header indicating that it is a card payment request packet. And, the source address field may include an identifier of the drone taxi. And, the destination address field may include an identifier of the landing server. The data field may include a card company code of the card company, card information, a specific trust field, and related data. Here, the related data may be the transmission time of the distributed packet.

Accordingly, the landing transceiver device may receive a distributed packet requesting card payment through a card company for landing from the drone taxi. In addition, the landing site transceiver device may transmit a distributed packet requesting card payment received from the drone taxi to the landing site server (S1103). Then, the landing site server may receive a distributed packet requesting card payment for the landing of the drone taxi from the landing site receiving device. In addition, the landing site server may request payment while transmitting a distributed packet requesting card payment received from the drone taxi through the landing site transceiver device to the card company server (S1104).

In this case, the landing server server may additionally transmit information necessary for payment (eg, account number, payment amount) to the card company server. In addition, the landing site server may additionally transmit the reception time of the distributed packet and propagation delay time information from the drone taxi to the payment server to the card company server.

Alternatively, the landing site server may request payment while transmitting a part of the distributed packet requesting card payment received from the drone taxi through the landing site transceiver device to the card company server. Here, a part of the distributed packet transmitted by the landing server to the card company server may include an identifier (ie, source address) of the drone taxi, requested operation information, encrypted card information, and a specific trust field.

In this case, the landing server server may additionally transmit information necessary for payment (eg, account number, payment amount) to the card company server. In addition, the landing site server may additionally transmit the reception time of the distributed packet and propagation delay time information from the drone taxi to the payment server to the card company server.

The card company server may receive a payment request related to the landing of the drone taxi from the landing site server. In this case, the card company server may receive the distributed packet generated by the drone taxi and card payment related information from the landing site server. Alternatively, the card company server may receive a part of the distributed packet generated by the drone taxi and payment related information from the landing site server.

Accordingly, the card company server may perform a reliability check using the secret key shared with the drone taxi and the card company code and specific trust bits included in the distributed packet. Alternatively, the card company server may perform the reliability check using the shared secret key, the card company code included in the distributed packet, specific trust bits, and the transmission time. In this case, when the transmission time cannot be found in the distributed packet, the card company server may calculate the transmission time by using the reception time and the propagation delay time received from the landing server server and use it.

Looking at this in more detail, the card company server may use the calculated transmission time by calculating the transmission time by subtracting the propagation delay time from the reception time. Meanwhile, the card company server may perform the reliability check using the shared secret key, the card company code included in the distributed packet, specific trust bits, the transmission time, and the drone taxi identifier.

As a result of the reliability check, if the reliability is confirmed, the card company server may perform a payment operation with the landing server and when the payment is completed, the card payment result signal may be transmitted to the landing server server (S1106). In this case, the card result signal transmitted from the card company server to the landing server may include a card payment result, a generation time of reliability bits, and reliability bits. If reliability is not verified as a result of the reliability check, the card company server may not perform payment with the landing server server.

Meanwhile, the landing site server may receive a card payment result signal from the card company server. In addition, the landing site server may transmit a card payment result signal having the configuration as shown in FIG. 12 to the landing site transceiver device (S1107). Then, the landing site transceiver may receive a card payment result signal from the landing site server. And, the landing transceiver device may transmit a card payment result signal to the drone taxi (S1108). Accordingly, the drone taxi may receive a card payment result signal from the landing transceiver device. And, the drone taxi can land on the landing pad.

12 is a block diagram illustrating a fourth embodiment of a distributed packet including a specific trust field.

Referring to FIG. 12 , the distributed packet includes a packet header field 1210 , a source address field 1220 , a destination address field 1230 , a public trust field 1240 , a data field 1250 , and a CRC field 1260 . can do. Here, the packet header field 1210 may be a field for indicating a packet type. In this case, the packet type may be, for example, a card payment result packet. The landing site server may indicate that it is a card payment result packet by using, for example, hexadecimal 0x0D in the packet header field 1210 .

Next, the source address field 1220 may be a field for indicating the source address of the distributed packet. The landing server may transmit by designating its own identifier (ID) in the source address field 1220 . In addition, the destination address field 1230 may be a field for indicating the destination address of the distributed packet. The landing site server may transmit by designating the destination address in the destination address field 1230 . The landing site server, for example, may designate and transmit the identifier of the drone taxi. In addition, the public trust field 1240 may be a field that allows the trust of the distributed packet to be confirmed through a trusted authority designated by the wireless distributed communication system.

Meanwhile, the data field 1250 may include a card payment result parsing block 1251 and a general data field 1252 . Here, the card payment result parsing block 1251 may be a parsing block related to the card payment result. The card payment result parsing block 1251 may include a parsing header field 1251-1, a card payment result field 1251-2, a specific bit generation time field 1251-3, and a specific trust field 1251-4. can Here, the parsing header field 1251-1 may be for indicating characteristics of information included in the card payment result parsing block 1251 .

The landing site server may provide the card payment result through the card payment result field 1251-2 followed by using, for example, hexadecimal 0x09 in the parsing header field 1251-1, and a specific bit generation time field 1251-2 ) may provide the time at which specific bits are generated, and may indicate that specific confidence bits may be provided through the specific confidence field 1251-3. Here, the card payment result field 1251 - 2 may be used to inform the card payment result.

The landing site server may include and transmit information related to the card payment result (eg, card number, payment time, payment amount, and fee) in the card payment field 1251 - 2 . Here, the information related to the card payment result may include data generated as a result of a payment operation such as card points generated due to payment.

Next, the specific bit generation time field 1251-3 may be a field for indicating the time at which specific bits are generated. The specific bit generation time field 1251-3 may include a generation time for generating specific bits in the card company server. The specific trust field 1251-3 may refer to a field inserted into a packet so that a mutual trust check can be performed between any two specific terminals in wireless distributed communication.

The specific trust field 1251-4 may include specific trust bits generated by the card company server. Here, the card company server may generate specific trust bits using the card company code and the secret key. Alternatively, the card company server may generate a specific trust field using the card company code, the drone taxi identifier, and the secret key. Alternatively, the card company server may generate a specific trust field using the card company code, the drone taxi identifier, the transmission time (ie, specific bits generation time), and the secret key.

The landing server may receive certain trust bits from the card company server. In addition, the landing site server may include the received specific trust bits in the specific trust field 1251-3 and transmit the received specific trust bits to the drone taxi. In addition, the general data field 1252 may include data that the landing server needs to transmit. Next, the CRC field 1260 may designate a CRC to determine whether there is an error.

Meanwhile, the card company server may notify the landing server of the card payment failure when the card payment fails as a result of performing the card payment. In this case, the card company server may inform the reason for the failure of the card payment. Then, the landing server may notify the drone taxi of the card payment failure, and may inform the reason for the card payment failure.

Meanwhile, in the synchronous wireless distributed communication method, the first terminal (eg, drone, drone taxi) may not transmit the generation time of specific trust bits to the third terminal (eg, the landing server). As such, the reason why the first terminal does not transmit the generation time of specific confidence bits to the third terminal is because the time when specific confidence bits are generated in synchronous wireless distributed communication is promised to be the transmission slot time of the corresponding distributed packet. can

Alternatively, in the asynchronous wireless distributed communication method, the first terminal may transmit the generation time of specific trust bits to the third terminal. In addition, the first terminal may randomly select a time for generating the trust field in order to increase the security of the trust field. In this case, the randomly selected trust field generation time information may be included in the distribution packet together with the trust field.

13 is a block diagram showing a first embodiment of a communication node constituting a communication system.

Referring to FIG. 13 , the communication node 1300 may include at least one processor 1310 , a memory 1320 , and a transceiver 1330 connected to a network to perform communication. Also, the communication node 1300 may further include an input interface device 1340 , an output interface device 1350 , a storage device 1360 , and the like. Each of the components included in the communication node 1300 may be connected by a bus 1370 to communicate with each other. However, each of the components included in the communication node 1300 may be connected through an individual interface or an individual bus centered on the processor 1310 instead of the common bus 1370 . For example, the processor 1310 may be connected to at least one of the memory 1320 , the transceiver 1330 , the input interface device 1340 , the output interface device 1350 , and the storage device 1360 through a dedicated interface. .

The processor 1310 may execute a program command stored in at least one of the memory 1320 and the storage device 1360 . The processor 1310 may refer to a central processing unit (CPU), a graphics processing unit (GPU), or a dedicated processor on which methods according to embodiments of the present invention are performed. Each of the memory 1320 and the storage device 1360 may be configured as at least one of a volatile storage medium and a non-volatile storage medium. For example, the memory 1320 may be configured as at least one of a read only memory (ROM) and a random access memory (RAM). Here, the communication node 1300 may be a drone, a flight permission approval server, a nuclear power plant server, an obstacle device, a drone taxi, a landing site server, a drone company server, or a card company server.

The methods according to the present invention may be implemented in the form of program instructions that can be executed by 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 recorded on the computer readable medium may be specially designed and configured for the present invention, or may be known and available to those skilled in the art of computer software. Examples of computer-readable media may include hardware devices specially configured to store and execute program instructions, such as ROM, RAM, flash memory, and the like. Examples of program instructions may include not only machine language codes such as those generated by a compiler, but also high-level language codes that can be executed by a computer using an interpreter or the like. The hardware device described above may be configured to operate as at least one software module to perform the operations of the present invention, and vice versa.

In addition, the above-described method or apparatus may be implemented by combining all or part of its configuration or function, or may be implemented separately. Although the above has been described with reference to preferred embodiments of the present invention, those skilled in the art can variously modify and change the present invention within the scope without departing from the spirit and scope of the present invention as set forth in the claims below. You will understand that it can be done.

Claims (14)

A method of operating a first communication node in a wireless distributed communication system, comprising:
providing the group code and the first secret key to the third communication node via the second communication node;
receiving a first packet including a first group trust field generated using the group code and the first secret key from the third communication node through distributed wireless communication; and
and performing a reliability check of the received first packet using the first group trust field, the group code, and the first secret key included in the received first packet. how it works. The method according to claim 1,
receiving first location information of the third node along with the first group trust field from the third communication node;
determining whether the third communication node has entered an entry restricted area based on the first location information;
If the third communication node has entered the entry restricted area, further comprising the step of allowing the third communication node to enter the restricted entry area when the reliability of the first packet is confirmed, the first communication node how it works. The method according to claim 1,
updating the first secret key to generate a second secret key;
providing the second secret key to the third communication node via the second communication node;
receiving a second packet including a second group trust field generated using the group code and the second secret key from the third communication node; and
The method further comprising the step of performing a reliability check of the received second packet by using the second group trust field, the group code, and the second secret key included in the received second packet, the first communication node how it works. The method according to claim 1,
receiving a second secret key updated in the first secret key from the second communication node;
receiving a second packet comprising a second group trust field generated using the group code and the second secret key from the third communication node; and
The method further comprising: performing a reliability check on the received second packet by using the second group trust field, the group code, and the second secret key included in the received second packet; How communication nodes work. 5. The method according to claim 4,
receiving second location information of the third node along with the second group trust field from the third communication node;
determining whether the third communication node has entered the entry restricted area based on the second location information; and
If the third communication node has entered the restricted entry zone, further comprising the step of allowing the third communication node to enter the entry restricted zone when the reliability of the received second packet is confirmed, the first How communication nodes work. The method according to claim 1,
and the first group trust field is generated using the group code and the first secret key using a linear feedback shift register from the third communication node. 3. The method according to claim 2,
transmitting a signal disallowing entry into the restricted access zone to the third communication node when the reliability of the first packet is not confirmed as a result of the reliability check; and
The method of operating a first communication node, further comprising transmitting a signal disallowing entry of the third communication node to the restricted entry area to the second communication node. A method of operating a second communication node in a wireless distributed communication system, comprising:
A first specific code for designating a third communication node from a first communication node, a first specific trust field used when the third communication node performs a trust check, and the second communication node and the third communication node perform Receiving a first packet including the work to be done through wireless distributed communication;
transmitting the received first packet and reception time information of the first packet to the third communication node;
receiving a work request according to the work content included in the first packet from the third communication node; and
Comprising the step of performing a task according to the task request with the third node, the operating method of the second communication node. 9. The method of claim 8,
After the completion of the operation according to the operation request with the third node, the method further comprising the step of transmitting a second packet including the operation termination information to the first communication node using distributed wireless communication. , the method of operation of the second communication node. 10. The method of claim 9,
The second packet includes a second specific trust field used when the first communication node performs a trust check, received from the third communication node, and generation time information of the second specific trust field, a second communication node how it works. 9. The method of claim 8,
In the step of transferring the received first packet and the reception time information of the first packet to a third communication node,
A first specific trust field used when the third communication node performs a trust check on behalf of the received first packet, the contents of the work to be performed by the second communication node and the third communication node, and the second communication node A method of operating a second communication node, characterized in that transferring a part of the first packet including the address of the first terminal to the third communication node. A second communication node in a distributed communication system, comprising:
processor;
a memory in electronic communication with the processor; and
Including instructions stored in the memory,
When the instructions are executed by the processor, the instructions cause the second communication node to:
A first specific code for designating a third communication node from a first communication node, a first specific trust field used when the third communication node performs a trust check, and the second communication node and the third communication node perform receiving a first packet including work to be done through wireless distributed communication;
forwarding the received first packet and reception time information of the first packet to the third communication node;
receiving a work request according to the work content included in the first packet from the third communication node; and
a second communication node operative to cause performing a task according to the work request with the third node. 13. The method of claim 12,
The instructions indicate that the second communication node is
After completion of the operation according to the request for the operation with the third node, the operation of further causing transmission of a second packet including the termination information of the operation to the first communication node using distributed wireless communication a second communication node. 14. The method of claim 13,
The second packet includes a second specific trust field used when the first communication node performs a trust check, received from the third communication node, and generation time information of the second specific trust field, a second communication node .

Images