JP6041257B2 - Direct data transmission / reception method between devices via an IEEE 802.15.4 network - Google Patents

Description

  The present invention relates to a direct data transmission / reception method between peripheral devices via an IEEE 802.15.4 wireless personal area network.

  A wireless personal area network is a short-range network that allows devices in a personal work environment to interconnect with devices in their vicinity. In wireless personal area networks, communication devices that are small, inexpensive, and capable of low-power digital wireless communication are mainly used.

  Such devices include wireless sensor networks, home automation, home appliances, and the like. In recent years, the scope of application of such networks includes Smart Utility Network (SUN), Active Radio Frequency Identification (RFID), Medical Body Area Network (MBAN), and Low Energy Critical Infrastructure (LECIM).

  Among these devices, there are devices that require wide connectivity that can connect geographically distant areas and high connectivity while using nodes with a relatively simple configuration. In such communication between devices, a highly redundant network is important, and various network connections including direct data transmission / reception between devices are being researched and developed.

  A network conforming to the IEEE 802.15.4 standard such as IEEE std 802.15.4-2011 [1] can be applied to two network topologies, a star network and a peer-to-peer network.

  FIG. 1 is a diagram showing two network topologies to which an IEEE 802.15.4 network is applied.

  A star network is composed of a PAN coordinator and a plurality of devices. All devices are connected to the PAN coordinator, and the PAN coordinator manages all these devices. Communication in the star network is only performed between the device and the PAN coordinator.

  The peer-to-peer network is composed of a PAN coordinator, a coordinator, and a number of devices connected to the two coordinators.

  The PAN coordinator is performing peer-to-peer network synchronization. According to standards such as IEEE std 802.15.4-2011, information can be directly transmitted and received between any two devices included in the peer-to-peer network.

  An example of a typical peer-to-peer network is a cluster tree type network composed of a PAN coordinator, lower level coordinators and devices. FIG. 2 is a diagram illustrating an example of an IEEE 802.15.4 cluster tree network.

By the way, in the IEEE 802.15.4 network, three types of data transmission / reception transactions are performed.
a. Reception of data sent from the device by the coordinator b. Receiving data transmitted from the coordinator by the device c. Send and receive data between two peer devices

  In the star network, data transmission / reception is performed only between the coordinator and the device, so only the two transactions a and b are performed. In the peer-to-peer network, all the three transactions a to b are performed.

  Data transmission from the device to the coordinator is performed as follows.

<In case of beacon capable PAN>
The device inquires about a network beacon periodically transmitted from the coordinator assigned to the device. When the device receives a beacon from the coordinator, it synchronizes to the superframe. The device then sends data to the coordinator at an appropriate time. At this time, if there is a request from the device, the coordinator notifies the device that the data packet has been received.

<In the case of PAN that cannot beacon>
The device simply sends data to the coordinator, and if there is a request from the device, the coordinator notifies the device that the data has been received.

  Data transmission from the coordinator to the device is performed as follows.

<In case of beacon capable PAN>
The coordinator notifies the device of the presence or absence of unprocessed data using a beacon. The device periodically inquires about beacons, and when unprocessed data is detected, the device transmits a command for requesting data to the coordinator. When receiving the command request data, the coordinator notifies the device that the request command has been received, and transmits the data promptly to the device. When there is a request from the coordinator, the device notifies the coordinator that the data has been received.

<In the case of PAN that cannot beacon>
If there is pending data, the coordinator stores the data for transmission to the device. Then, the device transmits a data request command to the coordinator based on control from the upper layer. When there is pending data to be transmitted to the device, the coordinator responds that there is unprocessed data by a notification command transmitted to the device. Alternatively, if there is no pending data, the coordinator responds with a notification command that there is no pending data for the device. If there is pending data, the coordinator transmits the data to the device after the response to the device data request. When there is a request from the coordinator, the device notifies that data has been received from the coordinator.

IEEE Std 802.15.4-2011: IEEE Standard for Local and Metropolitan Area Networks-Part 15.4: LowRate Wireless Personal Area Networks (LR-WPANs), New York, 5 September 2011

  The IEEE 802.15.4-2011 standard merely provides technical details regarding the two data transmission / receptions a and b. There is no detailed technical standard for peer-to-peer data transmission / reception, and the transmission / reception procedure is created based on IEEE802.15.4-2011. That is, in the star-type and peer-to-peer IEEE 802.15.4-2011 networks, data transmission / reception is performed by the two methods a and b described above.

  In this method, since a coordinator is required for communication between two devices, multi-hop relay is performed even though the two devices are within the range where radio waves reach each other. This data transmission / reception method has a problem that it takes a long time for transmission / reception as compared with a method of direct data transmission / reception between devices, and causes an increase in power consumption and an increase in a frequency band to be used. These problems are particularly serious in a device that is easily affected by an increase in transmission / reception time and a device that has restrictions on usable power and frequency band.

  Accordingly, the present invention has been devised in view of the above-described problems, and an object thereof is to provide a new data transmission / reception method that enables direct communication between neighboring IEEE 802.15.4 devices. .

  In order to solve the above-mentioned problems, the present inventor makes it possible to directly exchange data packets between neighboring devices within the reach of radio waves, thereby shortening the time required for communication and reducing power consumption. We have invented a direct data transmission / reception method between devices via an IEEE 802.15.4 network that can suppress and reduce the frequency band used.

  According to the present invention, there is provided a direct data transmission / reception method between devices via an IEEE802.15.4 network, wherein a first device transmits a detection request, and at least one second device that has received the detection request transmits to the first device. Directly transmitting a first response command; receiving the first response command by the first device; and receiving data from the first device directly from the first device to the second device. And when the first response command is transmitted to a plurality of specific second devices in a neighboring device list, the plurality of specific second devices are transmitted within a second predetermined time. The data is directly transmitted only when the first response command is received from all.

  According to the present invention having the above-described configuration, data packets can be directly exchanged between neighboring devices within the range where radio waves reach each other. In addition, intermediation by a coordinator is unnecessary in communication between neighboring devices, so that it is possible to reduce the time required for communication, reduce power consumption, and reduce the frequency band used.

It is a figure which shows two network topologies to which an IEEE802.15.4 network is applied. 1 is a diagram illustrating an example of an IEEE802.15.4 cluster tree network. FIG. It is a flowchart which shows the procedure of the direct data transmission / reception between the devices via an IEEE 802.15.4 network. 6 is a flowchart showing a neighbor device detection procedure in the IEEE 802.15.4 network. It is a message sequence chart in neighbor device detection. It is a flowchart which shows the procedure of unicasting data directly to the neighboring device in an IEEE 802.15.4 network. It is a message sequence chart which shows the unicast procedure of the data to the neighbor device in an IEEE 802.15.4 network. It is a flowchart which shows the direct data transmission procedure by the multicast to the device in a neighbor device list | wrist. It is a flowchart which shows the polling procedure of the data to a neighboring device. 6 is a message sequence chart used for polling data to neighboring devices in an IEEE 802.15.4 network. It is a figure which shows the format of a neighbor device detection request command. It is a figure which shows the format of a neighbor device detection response command. It is a figure which shows the format of a probe command frame. It is a figure which shows the format of a data polling command. It is a figure which shows the format of a destination address area | region.

  Hereinafter, an IEEE 802.15.4 wireless personal area network will be described in detail as an embodiment of the present invention.

  In order to perform direct data transmission / reception between devices, the present inventor has (a) probe mode direct data transmission, (b) polling mode direct data transmission, (c) broadcast mode direct data transmission, and (d) multicast. Invented four operation modes of mode direct data transmission.

  In probe mode direct data transmission, the device performs unicast data transmission to neighboring devices. Prior to data transmission to the neighboring device, the neighboring device is probed, and data is transmitted only when there is a response to the probe.

  In polling mode direct data transmission, the device polls the neighboring devices for data. If the response to the poll indicates the presence of data, the polled device receives data from neighboring devices.

  In broadcast mode direct data transmission, the device transmits data to the surroundings and any neighboring device can receive the data.

  In multicast mode direct data transmission, data is transmitted from a device to one or more specific neighboring devices.

  The present invention also includes a neighbor device detection method based on the IEEE 802.15.4 method, and by this method, a neighbor device capable of transmitting and receiving data in one hop can be detected.

  Hereinafter, the present invention related to direct data transmission / reception between devices via an IEEE 802.15.4 network and detection of neighboring devices will be described using a flowchart showing a procedure, a message sequence chart, and a command frame.

  FIG. 3 is a flowchart showing a procedure of direct data transmission / reception between devices via the IEEE 802.15.4 network.

  In the present invention, “device” refers to a node constituting a star network according to IEEE 802.15.4, a leaf device of a cluster tree network, a coordinator that is not a PAN coordinator of a cluster tree network, or a device of a peer-to-peer mesh network Is shown. The device is not limited to a full-function device (FFD) but may be a reduced function device (RFD).

  As shown in FIG. 3, when the device is powered on, a connection between the device and the coordinator (including the PAN coordinator) is established (step S1). If the connection with the coordinator is successful, the device starts a neighbor device detection operation (step S2). The purpose of this operation is to detect a peer device within the reach of radio waves. Details of the neighbor device detection operation will be described later.

When a neighboring device is detected, the device performs a plurality of operations described below.
a. The device receives a neighbor device detection request from the neighbor device (step S3).
b. The device in the immediately higher hierarchy holds data for one or more neighboring devices (step S4).
c. The device receives a probe command from a neighboring device (step S5). The probe command is used to detect whether the device holds data to be transmitted to neighboring devices.
d. The device in the immediately higher hierarchy requests to poll the neighboring device for data (step S6).
e. The device receives a data polling command from a neighboring device (step S7). The data polling command is used for polling data to neighboring devices.
f. The device shifts to the sleep mode (step S8).
g. The device turns off.

  When the device receives the neighbor detection request command from the neighbor device, if there is a request from the neighbor device, the device transmits a neighbor device detection response command to the neighbor device (step S9).

  When the device in the immediately higher hierarchy holds unicast data as data for the neighboring device (step S10: Yes), the probe mode direct data transmission / reception of the present invention is used for data transmission to the neighboring device. A unicast procedure (step S11) of data to neighboring devices by probe mode direct data transmission / reception will be described later.

  On the other hand, if unicast is not performed (step S10: No), and the device holds data to be transmitted to all neighboring devices (step S12: Yes), the device Broadcast at an appropriate time defined by the CSMA-CA algorithm used in IEEE 802.15.4-2011 [1] (step S13).

  When the device holds data to be transmitted to a limited number of neighboring device lists (step S12: No), the device uses multicast mode direct data transmission / reception to directly send data to neighboring devices (step S12). S14). Data multicasting by multicast mode direct data transmission / reception will be described later.

  When the device receives the probe command from the neighboring device (step S5), the device determines that the neighboring device holds data to be transmitted to itself. Then, the device notifies the neighboring device that it is in an awake state (step S15).

  Then, within macMaxFrameTotalWaitTime, the device makes the receiver that receives the notification ready to receive the corresponding data frame from the neighboring device, and receives data from the neighboring device (step S16). When the device is requested to respond after receiving data from the neighboring device, the device transmits a reception response to the neighboring device (step S17).

  When the device in the immediately higher hierarchy requests the neighboring device to poll the data (step S6), a neighboring device data polling procedure described later is executed (step S18).

  When the device receives a data polling command from the neighboring device (step S7), it checks whether there is data to be transmitted to the neighboring device in the data held by itself (step S19).

  The device notifies the neighboring devices of whether or not the data is held. If data to be transmitted to the neighboring device is held (step S19: Yes), a data polling command indicating that the neighboring device has the data is transmitted (step S20), and the device directly transmits data to the neighboring device. Is transmitted (step S21). On the other hand, when the data to be transmitted to the neighboring device is not held (step S19: No), the neighboring device is notified that there is no data (step S24).

  When the device shifts to the sleep mode (step S8), the device maintains the “sleep” status until receiving an instruction from the device in the immediately higher hierarchy, and when receiving the instruction, the device enters the “awake” status (step S22). When the “Awake” status is entered, the device determines whether or not the neighboring device needs to be detected (step S23). If necessary (step S23: Yes), the device again detects the neighboring device based on the detailed application (step S23). Step S2).

  FIG. 4 is a flowchart showing a neighbor device detection procedure in the IEEE 802.15.4 network (see step S2 in FIG. 3). As described above, a device compliant with IEEE 802.15.4 detects a neighboring device at an appropriate timing when it receives an instruction from the layer immediately above after being connected to the coordinator.

  In a beacon enabled PAN, a coordinator (except for the PAN coordinator) detects neighboring devices in the active time of the received superframe. The received superframe is a superframe in which a coordinator (including a PAN coordinator) for the coordinator transmits a beacon.

  In accordance with the neighbor device detection procedure, the device sends a neighbor device detection request command to the surroundings (step S31) and starts measuring time by the timer T_1 (step S32). The time keeping duration of the timer T_1 may be macMaxFrameTotalWaitTime.

Prior to the end of timing by the timer T_1, the device receives a neighboring device detection response command from the neighboring device (step S34), and whether or not the transmission source of the command is included in the neighboring device list. If the source is not included in the list, the device adds the source to the list (step S35) .

  On the other hand, the device may receive a neighbor device detection request command from the neighbor device. At this time, the device responds to the neighboring device by transmitting a neighboring device detection response command. A plurality of conditions can be added to the neighbor device detection request message.

  As an example of such a limiting condition, there is a condition that the neighboring device requires having a coordinator common to the upper level. In this case, when the device receives the neighboring device detection request command, the device checks whether or not the transmission source of the neighboring device detection request command has a common coordinator. If the device has a common coordinator, the device responds to the transmission source by transmitting a neighboring device detection response command. On the other hand, if the device does not have a common coordinator, the device ignores the neighbor device detection request command.

  FIG. 5 is a message sequence chart in the neighboring device detection. When the device 10 in the immediately higher hierarchy detects a neighboring device, the device transmits a basic MLME-NBR.Request to a device MLME (Mac Layer Management Entity) 20 (step S41).

  Next, the device MLME 20 transmits a neighbor device detection request command to the neighbor device MLME 30 (step S42).

  When the neighboring device MLME 30 receives the neighboring device detection request command, the neighboring device MLME 30 returns a neighboring device detection response command (step S43).

  Next, the device MLME 20 that has received the neighbor device detection response command transmits MLME-NBR.Confirm to the immediately higher layer (step S44).

  FIG. 6 is a flowchart showing a procedure for directly unicasting data to neighboring devices in the IEEE 802.15.4 network. When the device holds unicast data to be transmitted to the neighboring device (corresponding to step S10 in FIG. 2), the device executes the procedure shown in the flowchart in FIG. 6 (corresponding to step S11 in FIG. 2). .

  First, the device transmits a probe command to the neighboring device in order to detect whether the neighboring device is in the “awake” state (step S51).

  In addition, the device starts measuring time by the timer T_2 immediately after transmitting the probe command (step S52). The time keeping duration of the timer T_2 may be macMaxFrameTotalWaitTime.

  Next, the device checks whether or not the device has received a response to the probe command from the neighboring device by the end of the time measurement by the timer T_2 (step S53). If not received by the end of timing (step S53: No), the device determines whether or not a coordinator relay is required (step S59). Depending on the result of step S59, there are two possible operation options for the device.

  The first option is to use the coordinator for data transmission to neighboring devices when the coordinator relay is required (step S59: Yes). In this case, the device uses the conventional data transmission / reception method to coordinator. The data is transmitted to (step S60).

  Another option is that if the coordinator relay is not needed (step S59: No), the device once saves the data and later tries to send again, or the data is pending in the application requirements (step S61).

  On the other hand, when a response to the probe command from the neighboring device is received in step S53 (step S53: Yes), the device directly transmits data to the neighboring device (step S54).

  Next, the device checks whether or not there is a request for the probe command (step S55).

  When a response to the probe command is not requested (step S55: No), the device ends a series of operations.

  On the other hand, when a response to the probe command is requested (step S55: Yes), the device starts measuring time by the timer T_3 (step S56).

  Next, the device determines whether or not the device has received a data response from a neighboring device by the end of timing by the timer T_3 (step S57).

When the data response is not received (step S57: No), the device determines that the data is not correctly received by the neighboring device. In this case, the device once saves the data and tries again later, or the data is pending in the application requirements (step S58). The time keeping duration of the timer T_3 may be macMaxFrameTotalWaitTime.
Next, a data unicast procedure (corresponding to step S11 in FIG. 2) of data to neighboring devices by the device will be described.

  FIG. 7 is a message sequence chart showing a unicast procedure of data to neighboring devices in the IEEE 802.15.4 network.

  First, the data generator 40 in the immediately upper layer transmits MCPC-DATA.Request to the generator MLME 50 (step S71).

  Then, the generation source MLME 50 transmits a probe command to the reception destination MLME 60 (step S72).

  When receiving the probe command, the destination MLME 60 transmits a response to the probe command to the generation source MLME 50 (step S73).

  When receiving the response from the destination MLME 60, the generation source MLME 50 transmits data to the destination MLME 60 (step S74).

  If a data reception response is requested, the destination MLME transmits a data reception response to the generation source MLME 50 (step S75), and transmits MCPS-DATA.Indication to the upper layer reception destination 70 (step S75). S76). The generation source MLME 50 transmits MCPS-DATA.Confirm to the generation level 40 immediately below (step S77).

  Next, a multicast mode direct data transmission / reception procedure (corresponding to step S14 in FIG. 3) to neighboring devices will be described. FIG. 8 is a flowchart showing a direct data transmission procedure by multicast to a device in the neighbor device list.

  If the data needs to be multicast, the device sends the data to one or more neighboring devices at the appropriate time (step S81).

  Next, the device checks whether or not there is a response request for data (step S82). When there is no response request (step S82: No), the device ends the operation.

  On the other hand, when there is a response request (step S82: Yes), the device starts time measurement by the timer T_4 immediately after data transmission (step S83). The time keeping duration of the timer T_4 may be macMaxFrameTotalWaitTime.

  Next, the device determines whether or not a data receipt response has been received from one or all of the designated neighboring devices before the timer T_4 has elapsed (based on the multicast data receipt notification request) (step S84). ).

  When the receipt response is received (step S84: Yes), the device ends the operation.

  On the other hand, if the receipt response has not been received (step S84: No), the device temporarily saves the data and tries again later, or the data is pending depending on application requirements (step S85).

  Next, a data polling procedure (corresponding to step S18 in FIG. 3) to neighboring devices by polling mode direct data transmission / reception will be described. FIG. 9 is a flowchart showing a procedure for polling data to neighboring devices.

  First, when the device receives an instruction from the upper layer to poll the neighboring device for data, it transmits a data polling command to one or a plurality of neighboring devices at an appropriate time (step S91) and uses the timer T_5. Time measurement is started (step S92). The time keeping duration of the timer T_5 may be macMaxFrameTotalWaitTime.

  Next, the device checks whether or not a response to the data polling command has been received before the timer T_5 elapses (step S93).

  If no response is received (step S93: No), the device ends the procedure.

  On the other hand, when the device receives a response (step S93: Yes), the device determines which of the presence / absence of the pending data is the response (step S94).

  If the response indicates that there is no pending data (step S94: No), the device ends the procedure.

  On the other hand, if the response indicates that there is pending data (step S94: Yes), the device can receive data from the neighboring device after receiving the data polling command if it is within macMaxFrameTotalWaitTime. (Step S95).

  After receiving the data, the device determines whether there is a response to the data reception (step S96).

  When a response to the data is not requested (step S96: No), the device ends the procedure. If the response is requested (step S96: Yes), the device transmits the response (step S97) and ends the procedure.

  FIG. 10 is a message sequence chart used for polling data to neighboring devices in the IEEE 802.15.4 network.

  When it is necessary to perform data polling with respect to the neighboring device, the device 100 in the immediately higher hierarchy transmits an MLME-POLL.Request to the device MLME 110 (step S100).

  Next, the device MLME 110 transmits a data polling command to the neighboring device MLME 120 (step S101).

  When the neighboring device MLME 120 holds the data, the neighboring device MLME 120 transmits a response to the data polling command to the device MLME 110 (step S102) and transmits the data (step S103).

  The device MLME 110 receives the data, and when a response to the data is requested, transmits the response to the neighboring device MLME 120 (step S104).

  Then, the device MLME 110 transmits MLME-POLL.Confirm to the immediately upper layer device 100 (step S105) and transmits MCPS-DATA.Indication (step S106).

  Next, a MAC command frame for direct data transmission / reception between devices will be described.

  First, the neighbor device detection request command will be described. The neighbor device detection request command is used in the neighbor device detection procedure described with reference to step S2 of FIG. 3 and FIG.

FIG. 11 is a diagram illustrating a format of a neighbor device detection request command. This format is a new MAC command frame added to the command frame described in Table 5 of IEEE 802.15.4-2011 [1]. The format is composed of an MHR area and a MAC payload and conforms to the IEEE 802.15.4-2011 standard.
MHR area: An address area including a source address.
MAC payload: In order to identify the neighbor device detection request command, it is necessary to use a new command frame identifier as a new MAC command frame.

  Next, the neighbor device detection response command will be described. The neighboring device detection response command is used in the neighboring device detection procedure described with reference to step S2 in FIG. 3 and FIG.

FIG. 12 is a diagram showing a format of a neighboring device detection response command. This format is a new MAC command frame added to the command frame described in Table 5 of IEEE 802.15.4-2011 [1]. The format is composed of an MHR area and a MAC payload and conforms to the IEEE 802.15.4-2011 standard.
MHR area: An address area that includes a source address and a destination address.
MAC payload: In order to identify a neighboring device detection request command, it is necessary to use a new command frame identifier as a new MAC command frame, and this field includes capability information of neighboring devices.

  Next, the probe command will be described. When the device holds data to be unicast to the neighboring device, the device transmits a probe command to the neighboring device (see step S5 in FIG. 2 and step S51 in FIG. 6).

FIG. 13 is a diagram showing the format of the probe command frame. This format is a new MAC command frame added to the command frame described in Table 5 of IEEE 802.15.4-2011 [1]. The format is composed of an MHR area and a MAC payload.
MHR area: An address area that includes a source address and a destination address.
MAC payload: In order to identify the neighbor device detection request command, it is necessary to use a new command frame identifier as a new MAC command frame.

  Next, the data polling command will be described. When the device polls data for one or more neighboring devices (corresponding to step S18 in FIG. 3), as described above, the device transmits a data polling command to the neighboring devices (see step S91 in FIG. 9). ).

FIG. 14 is a diagram showing the format of the data polling command. This format is a new MAC command frame added to the command frame described in Table 5 of IEEE 802.15.4-2011 [1]. The format is composed of an MHR area and a MAC payload and conforms to the IEEE 802.15.4-2011 standard.
-MHR region: When polling for only one neighboring device, the address region includes a source address and a destination address. When polling data for a plurality of neighboring devices, the address area includes a source address.
MAC payload: Composed of a command frame identifier and an address area.
Command frame identifier: In order to identify a data polling command, it is necessary to use a new command frame identifier as a new MAC command frame.
Destination address area: FIG. 15 is a diagram showing the format of the destination address area. If multiple neighboring devices are polled, this field displays the destination address of the data polling command. In this case, the destination address is not included in the address area of the MHR area. The destination address area of the MAC payload conforms to the same standard as the “pending address area” of the beacon frame based on IEEE802.15.4-2011. As shown in FIG. 15, the destination address area includes a destination address specification and a destination address list. The destination address specification indicates the number of neighboring devices that are destinations, and conforms to the same standard as IEEE 802.15.4-2011 5.2.2.1.6. The destination address list indicates the destination of the device as the destination, and conforms to the same standard as 5.1.2.2.7 of IEEE802.15.4-2011.

  According to the direct data transmission / reception between devices according to the present invention, it is possible to directly transmit / receive data between neighboring devices. Therefore, compared to the conventional data transmission / reception method of IEEE802.15.4-2011, it is not necessary to mediate a coordinator when transmitting / receiving data, so the time required for data transmission / reception can be shortened and energy waste is prevented. The frequency band used can be reduced.

10 Hierarchical device 20 Device MLME
30 Neighboring Device MLME
40 Generation source 50 directly above Generation MLME
60 Recipient MLME
70 Directly Hierarchical Recipient 100 Directly Hierarchical Device 110 Device MLME
120 Neighboring device MLME

Claims (5)

A first device sending a detection request;
The at least one second device receiving the detection request directly sends a first response command to the first device;
The first device receiving the first response command;
The first device receiving the first response command directly transmits data to the second device ;
When the data is transmitted to a plurality of specific second devices in the neighboring device list , the data reception response is received from all of the plurality of specific second devices within a second predetermined time. To finish the procedure only
If the first response command is not received from the plurality of specific second devices within the second predetermined time, the first device once saves the data and tries again later, A method for directly transmitting and receiving data between devices via an IEEE802.15.4 network, characterized by pending data. If the first device holds the neighbor device list, the first response command is sent to a plurality of specific second devices;
The IEEE802 according to claim 1, wherein when the first device holds data to be transmitted to all the second devices, the data is broadcast to all the second devices. .15.4 Direct data transmission / reception method between devices via network. The first device sends a neighbor device detection request command to the surroundings and starts timing by a timer,
Before the end of timing by the timer, the first device receives a neighboring device detection response command from the second device, and confirms whether or not the transmission source of the command is included in the neighboring device list And
3. If the source is not included in the neighboring device list, the first device adds the source to the neighboring device list, directly between devices via the IEEE 802.15.4 network according to claim 1 or 2. Data transmission and reception method. A step of transmitting a probe command to the second device when the response command is transmitted from one second device;
The first device directly transmits the data when receiving a second response command from the second device within a first predetermined time in response to the probe command;
If the second response command from the second device is not received within the first predetermined time, determine whether a coordinator relay connected to the first device is necessary;
If a coordinator relay is needed, use the coordinator for data transmission to neighboring devices, and if the coordinator relay is not needed, the first device will store the data once and try again later, 4. The method for direct data transmission / reception between devices via an IEEE 802.15.4 network according to claim 1, wherein data is pending . The second device further comprises polling the first device for data;
If the first device holds pending data, it directly sends the pending data to the polled second device;
The method for direct data transmission / reception between devices via an IEEE 802.15.4 network according to claim 2.

Images