WO2013042207A1 - ノード装置および通信方法 - Google Patents
ノード装置および通信方法 Download PDFInfo
- Publication number
- WO2013042207A1 WO2013042207A1 PCT/JP2011/071401 JP2011071401W WO2013042207A1 WO 2013042207 A1 WO2013042207 A1 WO 2013042207A1 JP 2011071401 W JP2011071401 W JP 2011071401W WO 2013042207 A1 WO2013042207 A1 WO 2013042207A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- node
- relay
- frame
- wait number
- node device
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims description 102
- 238000004891 communication Methods 0.000 title claims description 26
- 235000008694 Humulus lupulus Nutrition 0.000 claims abstract description 29
- 230000005540 biological transmission Effects 0.000 claims description 123
- 238000001514 detection method Methods 0.000 claims description 29
- 238000012546 transfer Methods 0.000 claims description 22
- 230000008859 change Effects 0.000 claims description 12
- 238000012544 monitoring process Methods 0.000 claims description 2
- 230000036541 health Effects 0.000 description 56
- 238000012545 processing Methods 0.000 description 40
- 230000004044 response Effects 0.000 description 39
- 230000008569 process Effects 0.000 description 31
- 238000012217 deletion Methods 0.000 description 18
- 230000037430 deletion Effects 0.000 description 18
- 238000012986 modification Methods 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 238000010187 selection method Methods 0.000 description 2
- 102100040684 Fermitin family homolog 2 Human genes 0.000 description 1
- 102100040612 Fermitin family homolog 3 Human genes 0.000 description 1
- 101000892677 Homo sapiens Fermitin family homolog 2 Proteins 0.000 description 1
- 101000749644 Homo sapiens Fermitin family homolog 3 Proteins 0.000 description 1
- 230000001133 acceleration Effects 0.000 description 1
- 238000012508 change request Methods 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 230000007257 malfunction Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0668—Management of faults, events, alarms or notifications using network fault recovery by dynamic selection of recovery network elements, e.g. replacement by the most appropriate element after failure
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/12—Shortest path evaluation
- H04L45/122—Shortest path evaluation by minimising distances, e.g. by selecting a route with minimum of number of hops
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/18—Loop-free operations
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/74—Address processing for routing
- H04L45/745—Address table lookup; Address filtering
Definitions
- the present invention relates to communication in a network including a plurality of node devices.
- An example of an autonomous distributed network is a wired ad hoc network.
- Wired ad hoc networks may be applied to sensor networks, for example.
- the individual sensors forming the ad hoc network can be embedded in structures such as buildings and bridges, and can be used in places where it is difficult to operate wireless networks such as in the ground or underwater. Installation is possible.
- the wired ad hoc network transmits and receives data by wire, there are advantages such as easy detection of disconnection due to the occurrence of a failure.
- route selection group IDs are set in advance for each gateway and each node device in the network, and each node device has the best communication quality among routes reaching the gateway to which the same group ID is assigned.
- a method for selecting a proper route is known.
- a loop detection method has also been devised. In this method, the first node device transmits the first frame from the first port, and associates the information for identifying the first port with the first identification information for identifying the first frame. Store. When the first node device receives the second frame from the second node device, the first node device compares the first identification information with the second identification information for identifying the second frame. Judge that it was detected.
- a mobile terminal communicates with an external network through one gateway node selected by route search and receives a route break notification during communication to search for a route again and select a gateway node. Yes.
- the mobile terminal continues to communicate with the external network via the newly selected gateway node.
- a redundant route may be selected without selecting a route with the minimum number of hops for a route to the selected gateway.
- An object of the present invention is to enable individual node devices in a network to communicate using the shortest path.
- the node device in the network configured to be able to relay to / from the server by a plurality of relay devices includes a reception unit, a wait number generation unit, a storage unit, a selection unit, and a transmission unit.
- the receiving unit receives a frame from the adjacent node device.
- the wait number generation unit is notified of the number of hops to the adjacent node device together with the synchronization request from the adjacent node device when starting from each relay device of the plurality of relay devices, the hop A wait number obtained by incrementing the number is generated for each relay device.
- the storage unit stores the generated wait number in association with an identifier for identifying the relay device.
- the selection unit selects a relay device having a relatively small wait number stored in the storage unit.
- the transmission unit designates the selected relay device as a relay destination and transmits a data frame in which the server is designated as a destination.
- FIG. 1 shows an example of a network according to the embodiment.
- the network shown in FIG. 1 includes an ad hoc network including eight node devices N1 to N8 and two gateway devices GW1 and GW2, a hub 5, and a server 1.
- the server 1 transmits and receives frames between the node device via the hub 5 and the gateway device.
- each node device included in an ad hoc network stores a route to an adjacent node device or gateway, but does not store routes to other devices included in the network.
- the node device obtains the hop number from the GW 1 to the node device and the hop number from the GW 2 to the node device by transmitting and receiving a frame including the hop number from the gateway device to and from the adjacent node device. For example, since the node N4 is adjacent to the gateway GW2, the node N3 and N8 are notified that the number of hops from the gateway GW2 is 1. Then, since the nodes N3 and N8 are adjacent to the node N4, the nodes N3 and N8 recognize that the number of hops from the gateway GW2 is 2, and notify each adjacent node.
- the minimum value of the number of hops from any gateway device to a node device may be described as a “wait number”.
- the wait number of the node N4 starting from the gateway GW2 is 1.
- the wait number of the node N8 starting from the gateway GW2 is 2.
- one of the shortest paths from the gateway GW1 to the node N8 is a path from the GW1 to N8 via N1, N2, N3, and N7. For this reason, the wait number of the node N8 starting from the gateway GW1 is 5.
- the wait number starting from the gateway GW2 is smaller than the wait number starting from the gateway GW1. Therefore, the node N8 designates the gateway GW2 as a relay destination. For this reason, for example, it is possible to prevent a frame transmitted from the node N8 from being transmitted to the server 1 through a redundant route as indicated by a broken arrow (A) in FIG.
- each node included in the ad hoc network accesses the server 1 via the gateway device that can be reached with the minimum number of hops, the path to the server 1 can be shortened.
- the node device is assumed to be a device (sensor relay node 10) that includes a sensor and relays a frame transmitted from another node device toward the server 1.
- the gateway device does not include a sensor and is a device (core relay node) that relays a frame received from the node device.
- FIG. 2 shows an example of the configuration of the sensor relay node 10.
- the sensor relay node 10 includes a wired ad hoc network port 11 (11a to 11c), a general-purpose port 12, an ad hoc routing control device 20, and a central processing unit (CPU) 40.
- the node device further includes a digital input / digital output (DI / DO) terminal 13, Electrically, Erasable, and Programmable, Read, Only, Memory (EEPROM) 14, and sensor connection ports 15 (15 a to 15 c).
- DI / DO digital input / digital output
- EEPROM Electrically, Erasable, and Programmable, Read, Only, Memory
- the wired ad hoc network port 11 terminates data of an Ethernet frame encapsulating an ad hoc frame transmitted / received to / from another sensor relay node 10 or the backbone relay node 50 (see FIG. 6), Decrypt.
- the number of wired ad hoc network ports 11 provided in the sensor relay node 10 is arbitrary, but in the following description, an example in which three ports P1, P2, and P3 are provided will be described.
- the wired ad hoc network port 11 can include a buffer memory that temporarily holds a transmission frame. In the following description, the wired ad hoc network port 11 may be described as “port” or “reception port”.
- the general-purpose port 12 terminates a LAN (Local Area Network), for example.
- the ad hoc routing control device 20 is realized by, for example, an FPGA (Field Programmable Gate Array) or SRAM (Static Random Access Memory).
- the ad hoc routing control device 20 includes a reception frame control unit 21, a transmission frame control unit 22, a general-purpose port control unit 23, a CPU interface 24, a frame processing unit 26, and a routing control unit 30.
- the ad hoc routing control device 20 also includes an FID (Frame ID) table 27, a PS (Port Status) table 28, and a node management table 29.
- the CPU interface 24 has a register 25.
- the reception frame control unit 21 receives frame data from the wired ad hoc network ports 11a to 11c.
- the reception frame control unit 21 outputs a frame whose destination is the other sensor relay node 10 to the routing control unit 30.
- the reception frame control unit 21 outputs the frame to the CPU interface 24.
- the CPU interface 24 outputs the frame input from the reception frame control unit 21 to the CPU 40.
- the CPU interface 24 uses the register 25 as appropriate.
- the routing control unit 30 performs a routing process using the wait number.
- An example of the configuration of the routing control unit 30 is shown in FIG.
- the routing control unit 30 includes a wait number control unit 31 (31a to 31c), a failure detection unit 36, an initialization request unit 37, and a routing unit 38.
- the wait number control unit 31 a includes a wait number generation unit 32, a storage unit 34, and a selection unit 35, and has a wait number table 33 in the storage unit 34. It is assumed that the wait number control units 31a to 31c process wait numbers starting from different basic relay nodes 50. For example, the wait number control unit 31a processes a wait number starting from the core relay node 50a, and the wait number control unit 31b processes a wait number starting from the core relay node 50b.
- the wait number generation unit 32 increments the wait number included in the frame received from the adjacent sensor relay node 10 to thereby obtain the wait number assigned to the sensor relay node 10 provided with the wait number generation unit 32. decide.
- FIG. 4A shows an example of the wait number table 33.
- the example shown in FIG. 4A is the wait number table 33 in an initialized state, and no data is recorded.
- the wait number table 33 stores the wait number determined by the wait number generation unit 32 and the wait number of the sensor relay node 10 connected via each of the ports P1 to P3.
- the wait number generation unit 32 stores the wait number in association with the identifier (transmission source trunk relay number) that identifies the trunk relay node 50 used as the reference position when determining the wait number.
- the port number of the port that has received the frame used to determine the wait number is also recorded in the wait number table 33.
- a port that has received a frame used to determine a wait number may be referred to as a “master port”.
- one wait number table 33 is shown in FIG. 3, the same number of wait number tables 33 as the number of core relay nodes 50 included in the network are provided.
- Each wait number table 33 stores information on the wait number when one basic relay node 50 is the starting point.
- the selection unit 35 uses the wait number table 33 to determine a core relay node 50 to be designated as a relay destination when transmitting a frame addressed to the server 1.
- the selection unit 35 records the selected result in the node management table 29.
- An example of the node management table 29 is shown in FIG. In the example of FIG. 5, an identifier for identifying the core relay node 50 selected by the selection unit 35 is recorded in the node management table 29, but other arbitrary information is also stored in the node management table 29 according to the implementation. May be included.
- the generation method and use method of the wait number table 33, the operation of the selection unit 35, and the like will be described in detail later.
- the failure detection unit 36 monitors the status of the adjacent sensor relay node 10 and detects the occurrence of a failure when a failure occurs in communication with the adjacent sensor relay node 10.
- the failure detection unit 36 notifies the initialization request unit 37 that a failure has occurred.
- the initialization request unit 37 identifies a wait number that varies depending on the occurrence of a failure, and initializes the identified wait number. Further, the initialization request unit 37 requests the adjacent sensor relay node 10 to initialize the wait number as appropriate.
- the operations of the failure detection unit 36 and the initialization request unit 37 will be described in detail later.
- the routing unit 38 specifies a port to which a frame input from the received frame control unit 21 to the routing control unit 30 is transferred.
- the routing unit 38 refers to the PS table 28, the FID table 27, and the wait number table 33 to determine a transfer destination port.
- the PS table 28 is a table that stores, for each destination, a port to which a frame can be transferred.
- the PS table 28 can be in any format associated with the destination address of the frame and associated with the port number that can transfer the frame to the destination.
- the routing unit 38 outputs the frame to be transferred to the transmission frame control unit 22 together with information for notifying the port number of the transfer destination.
- the FID table 27 is used for loop detection.
- the FID table 27 records the usage status of the wired ad hoc network port 11 in association with the combination of the transmission source address of the frame that has been received and the value of the FID field.
- the usage status of the wired ad hoc network port 11 is, for example, that there is no link from the wired ad hoc network port 11 (link is broken), loop (loop state), unused, and is used for transmitting frames to the destination (transmitting port).
- the connection information of each loop is shown. Note that the usage status of the wired ad hoc network port 11 is determined according to the combination of the frame source address and the value of the FID field.
- the node N2 receives the transmitted frame again from another node device because a loop has occurred.
- the FID table 27 includes one Loop flag for each entry.
- the Loop flag indicates whether or not the own node exists on the route to the destination of the frame specified by the combination of the transmission source address and the FID recorded in the entry.
- the routing unit 38 confirms whether the combination of the source address and the value of the FID field matches any entry in the FID table 27 before transferring the frame. If the entry matches the entry in the FID table 27, the routing unit 38 determines that the received frame has been received and does not transfer it. At this time, the routing unit 38 records that it cannot be transferred to the destination of the frame in association with the combination of the transmission source address of the frame and the value of the FID field. For example, when the routing unit 38 sets a Loop flag for each entry and detects a loop, the Routing unit 38 sets the Loop flag of the corresponding entry to “1”.
- the routing unit 38 returns the frame from the received port without forwarding the frame including the combination of the transmission source address and the FID recorded in the entry in which the Loop flag is set to 1. On the other hand, if there is no matching entry in the FID table 27, the routing unit 38 searches the PS table 28 using the frame destination as a key. If the destination of the frame is recorded in the PS table 28, the frame is transferred by outputting from the port specified in the PS table 28.
- the routing unit 38 can also determine the transfer destination using the wait number assigned to the destination node of the frame to be transferred and the wait number assigned to the own node. When the wait number assigned to the destination of the frame is larger than the wait number of the own node, the routing unit 38 can transfer from the port connected to the node to which the wait number greater than the own node is assigned. Forward frames. On the other hand, if there is no port connected to a node to which a wait number larger than that of its own node is allocated, the routing unit 38 determines that a loop has been detected. Therefore, the routing unit 38 returns the frame to the transmission source node device by returning the frame from the port that received the frame. When a loop is detected, the port use state in the FID table 27 is changed to “loop state” based on the source address of the frame to be transferred and the value of the FID field.
- the routing unit 38 transfers a transfer target frame from a port connected to a node device to which a wait number smaller than that of the own node is allocated. If there is no port connected to a node device to which a wait number smaller than that of its own node is assigned, the routing unit 38 determines that a loop has been detected. When the loop is detected, the routing unit 38 returns the processing target frame to the transmission source node device. In addition, information regarding the port in the FID table 27 is also updated.
- the node device When the wait number assigned to the destination of the received frame matches the wait number of the own node, the node device confirms whether the destination of the frame is the own node. When the frame destination is the own node, the received frame is appropriately processed by the CPU 40 or the like. On the other hand, if the destination is not the own node and the wait number assigned to the destination of the received frame matches the wait number of the own node, the routing unit 38 determines that a loop has been detected. The process performed when a loop is detected is as described above.
- the frame processing unit 26 generates a frame including information acquired by the CPU interface 24 from the CPU 40 and outputs the frame to the routing control unit 30 and the transmission frame control unit 22.
- the transmission frame control unit 22 outputs the frame input from the routing control unit 30 or the transmission frame control unit 22 to the wired ad hoc network port 11 according to the transmission destination.
- the CPU 40 processes information acquired from a sensor (not shown) provided in the sensor relay node 10.
- the CPU 40 includes an FPGA interface 41, a DI / DO interface 42, and a sensor interface 43.
- the FPGA interface 41 transmits and receives sensor information and sensor control information to and from the CPU interface 24.
- the sensor interface 43 transmits / receives information to / from the sensor via the sensor connection port 15.
- the sensor may be any sensor including a temperature sensor, a wind speed sensor, an illuminance sensor, a human sensor, a power meter, an acceleration sensor, a strain sensor, a surveillance camera, and the like, and is selected according to the implementation.
- the sensor interface 43 is also connected to the EEPROM 14.
- the EEPROM 14 stores various sensor information and sensor control information as appropriate.
- the DI / DO terminal 13 is connected to the DI / DO interface 42.
- the DI / DO terminal 13 operates as a data input terminal and a data output terminal.
- Information detected by the sensor and measured data are output from the sensor interface 43 to the CPU interface 24 via the FPGA interface 41.
- the CPU interface 24 outputs the input data and the like to the frame processing unit 26.
- the CPU 40 controls the sensor device designated by the sensor control information based on the sensor control information received via the FPGA interface 41.
- the first embodiment will be described by dividing it into a wait number determination method, a relay destination trunk relay node 50 determination method, and frame transmission / reception after the relay destination is determined.
- FIG. 6 shows an example of a network and an example of determining a wait number.
- the ad hoc network is connected to the server 1 via three basic relay nodes 50, which are basic relay nodes 50a to 50c.
- the ad hoc network of FIG. 6 includes sensor relay nodes 10 of nodes N1 to N21.
- FIG. 6 shows an example of a network, and the number of sensor relay nodes 10 and core relay nodes 50 can be changed according to the implementation.
- FIG. 7 shows an example of a format of a frame transmitted / received in the network of FIG.
- FIG. 7 shows an example of the format of a synchronization request frame, a synchronization request response frame, a health frame, a status notification frame, and a data frame.
- Information contained in each frame and processing performed based on the frame will be described in detail later.
- each type of frame includes a field for storing information on a wait number, and further includes a MAC (Media Access Control). ) Header, ad hoc header, data field, and Frame Check Sequence (FCS).
- MAC Media Access Control
- FCS Frame Check Sequence
- the MAC header includes a DST ID (DeSTination ID) field, an SRC ID (Source ID) field, and a TYPE field.
- DST ID field a 6-byte MAC address assigned to the destination of the frame is set.
- SRC ID field a 6-byte MAC address allocated to the transmission source device is set.
- TYPE field a 2-byte upper layer protocol identification number is set, for example, a value of 0x8847 is set. “0x” indicates that the subsequent numerical value is a hexadecimal number.
- the ad hoc header has a KIND field, an FID field, a TTL field, and a Length field.
- KIND field 2-byte data representing the type of ad hoc frame is set.
- FID field for example, a 2-byte frame identification ID which is a sequential number is set.
- TTL (Time To Live) field 2-byte data indicating an upper limit time during which a frame can exist in the ad hoc network is set.
- a 2-byte value indicating the length of data in the frame is set in the Length field.
- FCS is a redundant code for detecting and correcting errors in a frame.
- a trunk relay number is assigned to each of the trunk relay nodes 50a to 50c, and each trunk relay node 50 stores the assigned trunk relay number.
- the trunk relay number of the trunk relay node 50a is “0”
- the trunk relay number of the trunk relay node 50b is “1”
- the trunk relay number of the trunk relay node 50c is “2”.
- the wait number written in each sensor relay node 10 included in FIG. 6 is a wait number obtained by the procedure described below.
- the number after “# 0:” represents a wait number based on the core relay node 50a.
- the number after “# 1:” represents the core relay node 50b, and the number after “# 2:” represents the wait number with the core relay node 50c as a base point.
- the core relay node 50a generates a synchronization request frame as shown in FIG.
- the synchronization request frame includes a transmission source trunk relay number and a transmission source wait number.
- the core relay node 50a sets the transmission source core relay number to “0” and the transmission source wait number to 0x00.
- a broadcast address is set in the DST ID field.
- the trunk relay node 50 records the address of the trunk relay node 50a in the SRC ID field of the synchronization request frame.
- the node N1 receives the synchronization request frame.
- the wait number generation unit 32 compares 0xFF, which is a value recorded in the wait number column, with the generated wait number 0x01.
- the wait number generation unit 32 recognizes the port that has received the frame used to determine the wait number as the master port. For example, in the example of the node N1, since the wait number is determined based on the synchronization request frame received from the port P1, the master port is the port P1.
- the wait number generation unit 32 recognizes that the wait number of the node connected via the port P1 is 0 because the port for receiving the synchronization request frame is the port P1. That is, the wait number generation unit 32 recognizes that it is connected to the backbone relay node 50 via the port P1.
- the timer in the wait number table 33 is used for confirming whether the connected wait number is valid.
- the wait number generation unit 32 sets the timer value to t1 each time the connection destination wait number connected to each port is confirmed, and decreases the timer value as time elapses. . When the timer value becomes 0, the information on the wait number at the connection destination is invalidated.
- the wait number generation unit 32 of the node N1 generates a synchronization request frame to be transmitted to the adjacent sensor relay node 10.
- the address of the node N1 is set in the SRT ID field, and the transmission source wait number is set to 1.
- the transmission source trunk relay number is set to 0.
- the node N2 and the node N8 receive the synchronization request frame.
- the wait number is set to 2.
- the backbone relay node 50a receives the synchronization request frame transmitted from the node N1 via the port P1 in the procedure (4), but the backbone relay node 50a does not perform processing using the synchronization request frame.
- the node N2 and the node N8 transmit a synchronization request frame to the adjacent sensor relay node 10.
- the operation performed here is the same as the operation described in the procedure (3). Therefore, the node N2 notifies the nodes N1, N3, and N9 that the wait number of the node N2 based on the trunk relay node 50a is 2, and requests synchronization. In addition, the node N8 notifies the nodes N1, N9, and N15 that the wait number of the node N8 based on the trunk relay node 50a is 2, and requests synchronization.
- the node N1 receives the synchronization request frame from the node N2 via the port P2.
- the wait number generation unit 32 of the node N1 increments the transmission source wait number of the synchronization request frame by one, and compares the obtained value with the value recorded in the wait number table 33.
- the wait number generation unit 32 recognizes that the wait number of the node N2 based on the core relay node 50a is 2 based on the synchronization request frame received from the node N2. Since the synchronization request frame from the node N2 is received from the port P2, the information on the port P2 is updated in the node N1 as shown in FIG.
- the node N1 processes the synchronization request frame received from the node N8 via the port P3 in the same manner as the synchronization request frame received from the node N2.
- the core relay node 50b also generates a synchronization request frame and broadcasts it.
- the update procedure is the same as the procedure described in procedure (2). Further, the node N4 transmits a synchronization request frame to the sensor relay node 10 (nodes N3 and N5) adjacent to the node N4 by a procedure similar to the procedure described in the procedure (3).
- each sensor relay node 10 is shown in association with “# 1:” in FIG. A long wait number is required.
- the wait number described after “# 1:” of each sensor relay node 10 is the shortest hop count from the core relay node 50b.
- the trunk relay node 50c also generates a synchronization request frame and broadcasts it.
- the update procedure is the same as the procedure described in procedure (2). Further, the node N7 transmits a synchronization request frame to the sensor relay node 10 (nodes N6 and N14) adjacent to the node N7 by a procedure similar to the procedure described in the procedure (3).
- the wait number described after “# 2:” of each sensor relay node 10 is the shortest hop count from the core relay node 50c.
- FIG. 9 shows the wait number table 33 held by the node N1 when the procedures (1) to (12) are completed.
- FIG. 9A shows the wait number table 33 when the core relay node 50a is used as a base point.
- FIG. 9B shows the wait relay table 50b, and
- FIG. 9C shows the wait number table 33 when the backbone relay node 50c is used as a base point.
- the selection unit 35 compares the wait numbers for each core relay node 50, and determines the core relay node 50 with the smallest wait number.
- the determined trunk relay node 50 is used as a relay destination of a frame transmitted from the sensor relay node 10 to the server 1.
- the selection unit 35 records the determined trunk relay node 50 in the node management table 29 (FIG. 5). For example, in node N1, the wait number is Wait number starting from the core relay node 50a: 1 Wait number starting from the core relay node 50b: 4 Wait number starting from core relay node 50c: 7 It has become. Therefore, the selection unit 35 of the node N1 determines to use the core relay node 50a as a relay destination and records it in the node management table 29.
- the trunk relay node 50 is similarly selected in the other sensor relay nodes 10.
- FIG. 10 shows an example of the relay destination determined by each sensor relay node 10.
- the wait number surrounded by the thick line is the minimum value of the wait number for each sensor relay node 10
- the trunk relay node 50 that is the starting point of the wait number surrounded by the thick line is the relay destination to the server 1.
- the nodes N1, N2, N8, N9, N15, and N16 have the trunk relay node 50a as a relay destination.
- the nodes N3, N4, N5, N10, N11, N12, N17, N18, and N19 use the trunk relay node 50b as a relay destination.
- the nodes N6, N7, N13, N14, N20, and N21 use the core relay node 50c as a relay destination.
- the sensor relay node 10 that designates the trunk relay node 50 as a relay destination may be described as the “management target” sensor relay node 10 for the trunk relay node 50.
- the sensor relay node 10 transmits a synchronization request response frame to the core relay node 50 as a relay destination.
- the synchronization request response frame is used to notify the destination trunk relay node 50 that the source sensor relay node 10 is designated as the relay destination to the server 1.
- An example of the format of the synchronization request response frame is shown in FIG.
- the destination of the synchronization request response frame is set to the address of the core relay node 50 designated as the relay destination, and the transmission destination wait number is set to 0.
- a transmission source wait number is also recorded.
- the value of the KIND field is KIND2. Further, in the synchronization request response frame, the transmission source trunk relay number assigned to the trunk relay node 50 designated as the relay destination to the server 1 is also recorded.
- the selection unit 35 generates a synchronization request response frame and transmits the generated synchronization request response frame to the trunk relay node 50 that has the generated synchronization request response frame as a destination. For example, it is assumed that the node N1 transmits a synchronization request response frame to the trunk relay node 50a.
- the backbone relay node 50a When the backbone relay node 50a receives the synchronization request response frame from the node N1, it stores the transmission source address of the synchronization request response frame and the wait number of the sensor relay node 10 of the transmission source in association with each other.
- the core relay node 50a can store the address of the node N1 and the wait number of the node N1 in association with each other in a table as illustrated in FIG. In FIG. 11A, the address of the node to be managed is represented using a number assigned to the sensor relay node 10 such as “N1” in order to make the table easier to see.
- the sensor relay nodes 10 other than the node N1 also transmit the synchronization request response frame to the trunk relay node 50 that is the relay destination.
- the synchronization request response frame transmitted from the sensor relay node 10 that is not adjacent to the core relay node 50 is transmitted to the core relay node 50 via the other sensor relay node 10 in the ad hoc network.
- the source sensor relay node 10 transmits a synchronization request response frame to the sensor relay node 10 having a smaller wait number starting from the destination core relay node 50.
- the selection unit 35 can refer to the wait number table 33 as appropriate when determining the port that outputs the synchronization request response frame.
- the wait number table 33 shown in FIG. 12 is confirmed.
- the selection unit 35 compares the wait numbers of the connection destinations of the ports P1 to P3 and recognizes that the wait number of the sensor relay node 10 connected to the port P1 is smaller than the wait number of the node N2. Therefore, the selection unit 35 of the node N2 requests the transmission frame control unit 22 to output the synchronization request response frame from the port P1.
- the node N2 transmits a synchronization request response frame from the port P1 to the backbone relay node 50a.
- the node N1 receives the synchronization request response frame from the node N2. Then, the routing unit 38 of the node N1 confirms whether the transmission source trunk relay number of the synchronization request response frame matches the trunk relay number of the trunk relay node 50 that is the relay destination of the node N1. Here, since both match, the node N1 determines to transfer the received synchronization request response frame.
- the routing unit 38 confirms the wait number and determines a port for outputting the received frame. In this case, the routing unit 38 refers to the wait number table 33 shown in FIG. 9A and outputs a received frame from the port P1.
- the routing unit 38 records the destination of the output frame and the output destination port in association with each other in the PS table 28. Accordingly, in the node N1, the output port to the core relay node 50a is recorded in the PS table 28.
- the trunk relay node 50a Since the trunk relay node 50a is connected to the port P1 of the node N1, the synchronization request response frame whose source is the node N2 is received by the processing of the procedure (18).
- the core relay node 50a stores the information of the node N2 as in the procedure (16).
- the synchronization request response frame is also transmitted from the sensor relay nodes 10 other than the nodes N1 and N2.
- the operation performed in the sensor relay node 10 that is the transmission source of the synchronization request response frame is the same as the procedure (17).
- the operation of the sensor relay node 10 that relays the synchronization request response frame is the same as in the procedure (18).
- the core relay nodes 50a to 50c each recognize a target node to relay communication with the server 1. For example, when the relay destination is selected as shown in FIG. 10, the core relay node 50a stores the table shown in FIG. Each core relay node 50 reports the sensor relay node 10 to be managed to the server 1.
- the server 1 determines the backbone relay node 50 that transmits the frame based on information notified from the backbone relay node 50.
- the method described above is an example of a method for determining the wait number and the relay destination trunk relay node 50, and may be changed depending on the implementation.
- the wait number starting from the core relay node 50a is determined, and then the wait number starting from the core relay node 50c is determined. It was decided.
- the determination of the wait number starting from the core relay node 50b or 50c may be started before the determination of the wait number starting from the core relay node 50a is completed.
- the core relay node 50 that is the starting point in determining the wait number is selected by an arbitrary method.
- FIGS. 13A to 13F are flowcharts for explaining an example of the operation of the sensor relay node 10 when a frame is received.
- FIG. 13A illustrates a procedure performed by the sensor relay node 10 when determining the trunk relay node 50 as a relay destination.
- the sensor relay node 10 checks the transmission source trunk relay number and the value of the KIND field in the frame, and determines whether the received frame is a synchronization request frame (steps S1 to S3). The case where the received frame is not a synchronization request frame will be described later with reference to FIGS. 13B to 13F.
- the wait number generation unit 32 obtains information about the port that received the frame in the wait number table 33 when the backbone relay node 50 corresponding to the transmission source trunk relay number of the synchronization request frame is the starting point. Update. That is, the wait number of the connection destination of the port that received the synchronization request frame is set as the transmission source wait number in the synchronization request frame (step S4). In addition, the timer associated with the connection destination wait number updated in step S4 is restarted (step S5). Further, the wait number generation unit 32 confirms whether or not the same frame as the already received frame has been received with reference to the FID table 27 (step S6).
- the wait number generation unit 32 determines that a frame that has already been received has been received (Yes in step S6). In this case, the wait number generation unit 32 deletes the received frame (step S7).
- the wait number generation unit 32 performs processing on the wait number of the node (own node) that received the frame (step) No in S6). Note that in the processing of steps S8 to S13, processing is performed for the wait number starting from the core relay node 50 corresponding to the transmission source core relay number of the received frame.
- the wait number generation unit 32 confirms whether the transmission source wait number in the received frame is the initial value (0xFF) (step S8).
- the wait number generation unit 32 updates the wait number of the node that has received the frame to the initial value (Yes in step S8, step S9).
- the wait number generation unit 32 determines whether the wait number of the node that received the frame is larger than the value obtained by incrementing the wait number of the received frame by one. Confirm (step S10).
- the wait number generation unit 32 updates the wait number of the own node to a value obtained by incrementing the wait number of the received frame by 1, and further updates the master port to the receive port of the frame (steps S11 and S12).
- the wait number of the node that received the frame is equal to or smaller than the value obtained by incrementing the wait number of the received frame by one, the shortest hop count is not updated even if the received frame is used (No in step S10). Therefore, if it is determined No in step S10, the wait number of the own node is not updated.
- the wait number generation unit 32 replaces the wait number of the synchronization request frame with the wait number of the own node, changes the SRC ID to the address of the own node, and transmits from all ports (step S13).
- the trunk number relay node 50 to be relayed to the server 1 is determined using the wait number, a synchronization request response frame is transmitted to the determined trunk relay node 50 (step S14).
- FIG. 14 is a flowchart for explaining an example of the operation of the selection unit 35 when selecting a trunk relay node 50 as a relay destination.
- the sensor relay node 10 When the relay destination is determined, the sensor relay node 10 periodically transmits a health frame toward the adjacent sensor relay node 10.
- the health frame is used to notify an adjacent node that the source sensor relay node 10 is operating normally.
- the wait number When the wait number is changed, the changed wait number is notified by the health frame.
- FIG. 7C An example of a health frame is shown in FIG.
- addresses representing all sensor relay nodes 10 adjacent to the source sensor relay node 10 are set in the DST ID field. Also, the wait number starting from the core relay node 50 corresponding to the source core relay number and the source core relay number is also notified by the health frame.
- the sensor relay node 10 can obtain the wait number from each trunk relay node 50 by using a plurality of health frames.
- the transmission source trunk relay number in the health frame can be the trunk relay node 50 selected by the transmission source sensor relay node 10 according to an arbitrary criterion.
- the sensor relay node 10 can notify the transmission source core relay number indicating the core relay node 50 determined as the relay destination and the wait number starting from the relay destination core relay node 50 using the health frame.
- the value of the KIND field is KIND3.
- step S21 An example of the operation of the sensor relay node 10 when a health frame is received will be described with reference to FIGS. 13A and 13B. If the received frame is not a synchronization request frame, it is determined No in step S3 of FIG. 13A, and it is determined in step S21 of FIG. 13B whether the received frame is a health frame (step S21). Here, it is assumed that the received frame is a health frame (Yes in step S21). Then, the wait number generation unit 32 performs the processes of steps S22 and S23. This process is the same as steps S4 and S5 described with reference to FIG. 13A.
- the wait number generation unit 32 confirms whether the transmission source wait number in the received health frame is the initial value (0xFF) (step S24).
- the case where the transmission source wait number is not the initial value (No in step S24) will be described, and the case where the transmission source wait number is the initial value will be described later.
- the wait number generation unit 32 performs processing on the wait number of the node (own node) that received the frame. In steps S25 to S29, processing is performed for the wait number starting from the core relay node 50 corresponding to the transmission source core relay number of the received frame.
- the wait number generation unit 32 confirms whether the wait number of its own node is larger than the value obtained by incrementing the wait number of the received frame by one (step S25). If the wait number of the node that received the frame is equal to or less than the value obtained by incrementing the wait number of the received frame by one, the process returns to step S1 (No in step S25).
- Step S26 and S27 are the same as steps S11 and S12 described with reference to FIG. 13A.
- the wait number generation unit 32 generates a health frame and outputs it from all ports (step S28). Further, when the wait number of the own node is updated, the wait number generation unit 32 determines the trunk relay node 50 as a relay destination to the server 1 using the wait number. When the relay destination trunk relay node 50 is changed, the wait number generation unit 32 transmits a status notification frame to the trunk relay node 50 (step S29).
- the data frame An example of the data frame is shown in FIG.
- An address representing the destination server 1 or the sensor relay node 10 is set in the DST ID field.
- the data frame also includes a transmission source trunk number and a destination wait number when the trunk relay node 50 corresponding to the transmission source trunk relay number is the starting point.
- a wait number of the trunk relay node 50 as a relay destination that is, 0 is set as the transmission destination wait number.
- the transmission destination wait number is set by the trunk relay node 50.
- the core relay node 50 searches the wait number table as shown in FIG. 11 using the destination of the data frame received from the server 1 as a key, and acquires the wait number of the sensor relay node 10 to be managed.
- the core relay node 50 records the acquired wait number in the data frame, and transfers the processed data frame to the sensor relay node 10.
- the source sensor relay node 10 transmits the data frame from a port connected to a node to which a wait number smaller than the own node is assigned.
- the sensor relay node 10 that relays the data frame also transmits the data frame from a port connected to a node to which a wait number smaller than the wait number of the own node is assigned.
- the core relay node 50 transmits the data frame to the adjacent sensor relay node 10. Further, the sensor relay node 10 that relays the data frame transmits the data frame from the port connected to the node to which the wait number larger than the wait number of the own node is assigned.
- the wait number generation unit 32 of the node that relays the data frame includes the FID table 27. Is used to check for the occurrence of a loop.
- the sensor relay node 10 that has received the data frame also performs the processing of steps S1 to S3 in FIG. 13A.
- the received frame is a data frame
- it is determined No in step S3 it is determined No in step S3
- the determination in step S21 of FIG. 13B is performed.
- the received frame is not a health frame, it is also determined No in step S21, and it is determined in step S31 in FIG. 13C whether the received frame is a deletion notification.
- the deletion notification is a type of control frame, and the deletion notification will be described later.
- the data frame is received, it is determined No in step S31.
- step S38 it is determined whether the destination of the data frame is the local node. If the destination of the data frame is its own node, the data in the data frame is output to the CPU 40 via the CPU interface 24 and processed (Yes in step S38). On the other hand, when the destination of the data frame is not the own node (No in step S38), the routing process shown in FIGS. 13E and 13F is performed.
- the routing unit 38 confirms whether the transmission source trunk relay number is recorded in the data frame (step S51). When the transmission source trunk relay number is not included in the data frame, the routing unit 38 returns the data frame to the reception port (step S52). Next, the routing unit 38 acquires the SRC ID and FID from the data frame, and searches the FID table 27 using the acquired SRC ID and FID as a key (step S53). If there is no hit entry in the FID table 27, the routing unit 38 searches the PS table 28 using the destination address of the data frame as a key (No in step S53, step S54).
- the routing unit 38 determines to transmit a data frame from a port recorded as a port capable of transmitting a data frame in the obtained entry (Yes in step S54). ). Therefore, the routing unit 38 generates an entry including the SRC ID and FID of the data frame in the FID table 27 (step S67). Also, the routing unit 38 records the number of the port that transmits the data frame as “transmitting port” in the generated entry. Thereafter, the routing unit 38 notifies the transmission frame control unit 22 of the transmission port, and causes the transmission frame control unit 22 to transmit the data frame (step S68).
- the routing unit 38 inquires of the transmission frame control unit 22 whether there is a wired ad hoc network port 11 that has not been disconnected other than the port that has received the data frame ( No in step S54). If there is no port that is not broken, the routing unit 38 determines that the data frame cannot be routed, and outputs the data frame from the reception port (No in step S55, step S56). If there is a port that is not broken, the routing unit 38 determines whether the transmission destination wait number set in the received frame is the initial value (0xFF) (Yes in step S55, step S60).
- the routing unit 38 does not execute the routing process using the wait number (Yes in step S60).
- the routing unit 38 selects a port with a young number (or with the same condition as the old number) (step S65).
- the routing unit 38 creates an entry corresponding to the destination address of the received frame in the PS table 28, and sets the port selected in step S65 to “transmitting port” (step S66).
- the routing unit 38 determines that the frame that was once received and transmitted to the other sensor relay node 10 has returned again (step S53). Yes). In this case, the routing unit 38 changes the state of the port set as “transmission port” in the FID table 27 to “loop port” (step S57). Here, setting a certain port to “loop port” means that a frame cannot be transmitted to the destination address from that port. Subsequently, the routing unit 38 searches the PS table 28 using the destination address of the data frame as a key, and sets the “loop state” for the port set to “transmitting port” in the obtained entry ( Step S58). Next, the routing unit 38 searches the corresponding entry on the PS table 28 to determine whether there is a port set to “unused” (step S59).
- the routing unit 38 When there is no unused port (No in step S59), the routing unit 38 extracts an entry associated with the transmission source address of the received frame from the FID table 27, and acquires the RxPort (reception port) of the entry (Ste S72). Then, the routing unit 38 sends the received frame back to the extracted first reception port (step S73).
- step S59 when there is an unused port (Yes in step S59), the routing unit 38 performs the process of step S60 in order to select the unused port and perform the transmission process. If the wait number of the received frame is the initial value (Yes in step S60), the processes in steps S65 to S68 are performed. If the wait number of the received frame is not the initial value (No in step S60), the routing unit 38 determines whether or not the destination wait number in the received frame is greater than the wait number of the own node (step S61). ). If the destination wait number in the received frame is larger than the wait number of the own node, the routing unit 38 recognizes that the frame is relayed toward the sensor relay node 10 that is farther from the server 1 than the own node.
- the routing unit 38 checks whether a frame can be transmitted from a port connected to a node to which a wait number larger than the own node's wait number is assigned (step S62).
- a frame can be transmitted from a port connected to a node to which a wait number larger than the own node's wait number is assigned Yes in step S62
- the processes in steps S65 to S68 are performed.
- the routing unit 38 determines whether the Loop flag of the FID table 27 is “ON”. (Step S69).
- the routing unit 38 sets the Loop flag of the FID table 27 to “ON” (step S71). Thereafter, the routing unit 38 searches the FID table 27 for an entry using the transmission source address (SRC ID) of the received frame as a key, and specifies the RxPort (reception port) of the hit entry (step S72). The routing unit 38 transmits the received frame back to the extracted first reception port (step S73).
- SRC ID transmission source address
- RxPort reception port
- the routing unit 38 determines whether or not the transmission destination wait number in the received frame is smaller than the own node wait number (step S63). If the destination wait number in the received frame is smaller than the wait number of the own node, the routing unit 38 recognizes that the frame is relayed toward the sensor relay node 10 closer to the server 1 than to the own node (step Yes in S63). When the destination wait number in the received frame is smaller than the wait number of the own node, the routing unit 38 receives the frame from the port connected to the node to which the wait number smaller than the own node is assigned. Is checked (step S64). When a frame can be transmitted from a port connected to a node to which a wait number smaller than the own node's wait number is assigned (Yes in step S64), the processes in steps S65 to S68 are performed.
- step S64 when a frame cannot be transmitted from a port connected to a node to which a wait number smaller than that of the own node is assigned (No in step S64), the processing described with reference to steps S69 to S73 is performed. Is called. If it is determined in step S63 that the destination wait number in the received frame is not smaller than the own node wait number, the processing described with reference to steps S69 to S73 is performed.
- the sensor relay node 10 can transmit and receive frames to and from the server 1 with the shortest number of hops. That is, as described above, the trunk relay node 50 that is the relay destination is determined using the wait number, and the trunk relay node 50 that can be reached from each sensor relay node 10 with the shortest number of hops is selected as the relay destination. Further, the route to the core relay node 50 selected as the relay destination is also the route with the shortest hop count. The route selection at this time is performed based on the transmission destination wait number in the received frame, the own node wait number, and the connection destination node wait number for each port. Furthermore, in the method according to the present embodiment, since the trunk relay node 50 that can be reached by the sensor relay node 10 with the shortest number of hops is used as a relay destination, it is possible to prevent concentration of processing on a specific trunk relay node 50.
- FIG. 15 shows an example when a failure occurs in the line between the trunk relay node 50b and the server 1 when the relay destination is determined as shown in FIG.
- a process performed when a failure occurs as illustrated in FIG. 15 will be described as an example.
- the routing of the frame after the relay destination is determined is performed in the same manner as in the first embodiment.
- the trunk relay node 50 detects the occurrence of the failure. For example, the core relay node 50b periodically transmits and receives signals to and from the server 1, and when a signal cannot be received from the server 1 after a certain period of time, between the server 1 and the core relay node 50b. It can be determined that a failure has occurred.
- the core relay node 50b specifies that the adjacent sensor relay node 10 is the node N4. This process is performed, for example, when the trunk relay node 50b specifies the sensor relay node 10 that has notified that the wait number up to the sensor relay node 10b is 1 by the synchronization request response frame in the procedure (19) described above. Is called.
- the wait number of the node N4 is Wait number starting from the core relay node 50a: 4 Wait number starting from the core relay node 50b: 1 Wait number starting from core relay node 50c: 4 It is.
- the wait number generation unit 32 of the node N4 initializes the wait number in response to the request.
- the wait number of the node N4 is Wait number starting from the core relay node 50a: 4 Wait number starting from core relay node 50b: 0xFF Wait number starting from core relay node 50c: 4 It becomes.
- the selection unit 35 of the node N4 compares the wait numbers and determines the trunk relay node 50 as the relay destination.
- the method of determining the relay destination trunk relay node 50 is the same as the method described with reference to FIG. With this processing, the selection unit 35 selects the core relay node 50a as a relay destination.
- the selection unit 35 of the node N4 transmits a state notification frame to the core relay node 50a.
- An example of the status notification frame is shown in FIG.
- the value of the KIND field is set to KIND5.
- the destination of the status notification frame is the core relay node 50 that is newly set as the relay destination, and the transmission destination wait number is set to 0.
- the transmission source wait number is the wait number of the sensor relay node 10 that transmits the status notification.
- the transmission source wait number is set to 4, and the destination address is set to the address of the core relay node 50a.
- the source notification relay number is included in the status notification frame.
- the selection unit 35 sets the value of the transmission source trunk relay number to 0.
- the selection unit 35 confirms the wait number table 33 associated with the core relay node 50a newly set as the relay destination, so that the sensor relay node 10 closer to the core relay node 50a than the node N4 is the node N3. Is identified. Therefore, the selection unit 35 requests the transmission frame control unit 22 to transmit via a port connected to the node N3, and tries to notify that the relay destination has been changed to the core relay node 50a.
- the routing unit 38 of the node N3 recognizes that the KIND field of the received frame is KIND5, it recognizes that the status notification frame has been received. Since the status notification frame is a frame for notifying the change of the relay destination, there is a possibility that the core relay node 50 different from the relay destination of the own node is set as the destination. Therefore, the routing unit 38 acquires the transmission source trunk relay number in the state notification frame without referring to the FID table 27 and the PS table 28 of the node N3, and associates it with the obtained transmission source trunk relay number. A transfer destination is determined based on the wait number table 33.
- the routing unit 38 assigns a wait number smaller than that of the node N3 by checking the wait number table 33 of the trunk relay node 50a. Recognize the port being used. The routing unit 38 transfers the state notification frame to the node N2 by outputting the state notification frame from the recognized port.
- the routing unit 38 performs the transfer process in the node N2, and transfers the status notification frame to the node N1.
- the node N1 transfers the status notification frame to the core relay node 50a.
- the core relay node 50a adds the node N4 to the managed node based on the received status notification frame. Further, by notifying the server 1 that the node N4 is newly managed by the core relay node 50a, the server 1 is made to recognize that the core relay node 50a relays frames addressed to the node N4 thereafter.
- the initialization request unit 37 of the node N4 notifies the change of the wait number by transmitting the health frame (FIG. 7C) to the adjacent nodes N3 and N5.
- the initialization request unit 37 sets the transmission source trunk relay number of the health frame to 1 and the transmission source wait number to 0xFF.
- the wait number of the node N3 is Wait number starting from the core relay node 50a: 3 Wait number starting from core relay node 50b: 2 Wait number starting from the core relay node 50c: 5 It has become.
- the node N3 recognizes that the wait number of the node N4 when starting from the core relay node 50b is changed to 0xFF. Further, the wait number generation unit 32 of the node N3 changes the wait number when starting from the core relay node 50b to 0xFF (initial value). That is, the wait number is Wait number starting from the core relay node 50a: 3 Wait number starting from core relay node 50b: 0xFF Wait number starting from the core relay node 50c: 5 Change to
- the selection unit 35 of the node N3 determines the trunk relay node 50 as the relay destination using the changed wait number.
- the method of determining the relay destination backbone relay node 50 and the method of notifying the change of the relay destination are the same as the procedures (24) to (26). Further, the node N3 transmits a health frame to the adjacent nodes N2 and N10 to notify that the wait number starting from the core relay node 50b has been changed.
- the node N5 changes the wait number starting from the core relay node 50b and transmits the status notification frame.
- These processes are the same as the operations described in the procedures (24) to (27).
- the same processing as the procedures (24) to (27) is performed.
- a state notification frame is not generated when the trunk relay node 50 as a relay destination is not changed even if the wait number is changed, such as the node N2.
- the fact that the wait number has been changed is notified to an adjacent node by a health frame.
- FIG. 16 shows the relay destination of each sensor relay node 10 after the processing of steps (21) to (30) is performed.
- the nodes N3, N4, N10, N11, N17, and N18 change the relay destination from the core relay node 50b to the core relay node 50a.
- the nodes N5, N12, and N19 change the relay destination from the core relay node 50b to the core relay node 50c.
- step S22 the wait number of the connection destination of the port that received the health frame is changed based on the transmission source wait number in the health frame. Furthermore, the processes of steps S23 and S24 are performed. The processing in steps S23 and S24 is as already described.
- step S24 If it is determined in step S24 that the transmission source wait number of the received health frame is the initial value, the process of FIG. 13D is performed.
- the wait number generation unit 32 initializes the wait number of its own node starting from the core relay node 50 designated as the relay destination (step S41). Furthermore, the wait number generation unit 32 initializes the value of the master port in the wait number table 33 associated with the core relay node 50 designated as the relay destination (step S42). Thereafter, the sensor relay node 10 transmits health frames from all ports (step S43). Further, the sensor relay node 10 determines the trunk relay node 50 as a relay destination based on the changed wait number, and when the trunk relay node 50 is changed, the state notification is made to the trunk relay node 50 as a new relay destination. A frame is transmitted (step S44).
- each sensor relay node 10 determines the relay relay backbone 50 based on the changed wait number, and when the relay relay is changed, the relay relay 50 is newly set as the relay relay. Notify specified. For this reason, even if a failure occurs, routing can be performed with the shortest number of hops by using the trunk relay node 50 that can autonomously recover from the failure and reach any sensor relay node 10 with the shortest number of hops as a relay destination. it can.
- ⁇ Third Embodiment> an operation when a failure occurs in the trunk relay node 50 will be described.
- an example of processing when a failure occurs in the core relay node 50b when a relay destination is selected as illustrated in FIG. 10 will be described.
- the routing of the frame after the relay destination is determined is performed in the same manner as in the first embodiment.
- the failure detection unit 36 of the node N4 determines that the trunk relay node 50b has failed.
- the failure detection unit 36 notifies the wait number generation unit 32 and the initialization request unit 37 that the core relay node 50b has failed.
- the wait number generation unit 32 initializes a wait number starting from the core relay node 50b.
- the initialization request unit 37 requests the adjacent sensor relay node 10 to initialize the wait number starting from the core relay node 50b.
- the subsequent processing is the same as the processing after the procedure (24) in the second embodiment.
- FIG. 17 shows an example where the trunk relay node 50 as a relay destination is changed when a malfunction of the trunk relay node 50 is found.
- the sensor relay node 10 adjacent to the trunk relay node 50 detects the failure of the trunk relay node 50 by monitoring the operation of the trunk relay node 50 using the health frame, autonomously. The route and relay destination are changed.
- the failure detection unit 36 of the nodes N4, N12, and N6 determines that the adjacent sensor relay node 10 has failed.
- the failure detection unit 36 identifies a port that cannot receive a health frame. For example, as shown in FIG. 18A, if the node N5 is connected to the port P3 of the node N4, the failure detection unit 36 of the node N4 is connected to the port P3 from the wait number table 33. The wait number is obtained and compared with the wait number of the node N4. Further, the failure detection unit 36 initializes the wait number when a wait number larger than the failed node is set in the comparison result. In other words, the wait number starting from the trunk relay node 50 with which there is a possibility that the node itself communicates via the failed node is initialized.
- the wait number starting from the core relay node 50a is 4 at the node N4, but 5 at the node connected to the port P1.
- the wait number starting from the core relay node 50b is 1 at the node N4, but 2 at the node connected to the port P1.
- the wait number starting from the core relay node 50c is 4 at the node N4, but 3 at the node connected to the port P1.
- the node N4 can communicate with the trunk relay nodes 50a and 50b without going through the node N5, but in order to access the trunk relay node 50c with the shortest number of hops, it indicates that the node N4 goes through the node N5.
- the failure detection unit 36 initially sets the wait number starting from the trunk relay node 50c so that the trunk relay node 50c is not designated as the relay destination. Turn into.
- the wait number table 33 starting from the core relay node 50c in the node N4 is updated as shown in FIG.
- the wait number starting from any of the core relay nodes 50a to 50c is larger than that of the node N5. For this reason, the node N12 also initializes the wait number starting from any of the trunk relay nodes 50a to 50c.
- the wait number table 33 starting from the core relay node 50c in the node N12 is updated as shown in FIG.
- the initialization request unit 37 of the node N4 makes an initialization request in order to prevent being requested to transmit a frame via the failed node.
- the initialization request unit 37 Request number initialization. For example, since the node N4 has initialized the wait number starting from the trunk relay node 50c, the initialization request unit 37 checks the wait number table 33 corresponding to the trunk relay node 50c.
- the initialization request unit 37 starts from the core relay node 50c from a port in which a wait number larger than the wait number of the node N4 before initialization is set. Requests initialization of the wait number.
- the initialization request unit 37 of the node N4 requests the node N3 to initialize the wait number starting from the trunk relay node 50c.
- the wait number generation unit 32 of the node N3 When the wait number generation unit 32 of the node N3 is requested to initialize the wait number starting from the core relay node 50c, the wait number generation unit 32 initializes the wait number in response to the request.
- the wait number table 33 starting from the core relay node 50c in the node N3 is updated as shown in FIG. Also, the initialization request unit 37 is notified of the wait number initialization request received from the core relay node 50c and the wait number before initialization of the node N3 starting from the core relay node 50c. Keep it.
- the node N12 also requests initialization in the same manner as the node N4. Therefore, the node N12 requests the node N19 to initialize the wait number starting from the core relay nodes 50a to 50c.
- FIG. 19D shows a modified example of the wait number table 33 starting from the core relay node 50c in the node N19. Note that processing similar to that performed by the node N3 is performed at the node N19.
- FIG. 19 (c) shows a modification example of the wait number table 33 starting from the core relay node 50c in the node N11. Note that processing similar to that performed by the node N3 is also performed at the node N11.
- the initialization request unit 37 of the node N3 determines the wait number of the output destination node of each port for the wait number table 33 associated with the core relay node 50c before initialization for the own node. Compare with the wait number. As a result of the comparison, the initialization request unit 37 outputs an initialization request from a port connected to a node having a wait number larger than the wait number before initialization of the own node.
- the node N3 requests the nodes N2 and N10 to initialize the wait number starting from the core relay node 50c.
- FIG. 20A shows a state where an initialization request is made to the node N10.
- FIG. 20B shows a modification example of the wait number table 33 starting from the trunk relay node 50c in the node N10.
- the initialization request unit 37 of the node N11 requests the node N18 to initialize the wait number starting from the core relay nodes 50a to 50c as a result of performing the same processing as the node N3.
- the initialization request unit 37 of the node N19 also requests the node N18 to initialize the wait number starting from the core relay nodes 50a and 50b.
- FIG. 20C shows a modification example of the wait number table 33 starting from the core relay node 50c in the node N18.
- the node N17 Upon receiving a request for initialization from the nodes N10 and N18, the node N17 also changes the wait number table 33 as shown in FIG. FIG. 21B shows a modification example of the wait number table 33 starting from the core relay node 50c in the node N17.
- the wait number is similarly changed in the other sensor relay nodes 10. As a result, the wait number is changed as shown in FIG. In FIG. 22, the value on the left side of the arrow is the wait number assigned to each sensor relay node 10 before the failure of the node N5 occurs, and the value on the right side of the arrow is determined by the failure of the node N5. Wait number.
- the sensor relay node 10 that has received the health frame changes the wait number of its own node based on the received wait number when the transmission source wait number included in the health frame is not the initial value.
- the method for changing the wait number based on the transmission source wait number included in the health frame is the same as the method described with reference to steps S25 to S29 in FIG. 13B. For example, if the wait number starting from the node N11 to the trunk relay node 50a is 5, the wait number generation unit 32 of the node N12 determines the wait number of the node N12 starting from the trunk relay node 50a to be 6.
- FIG. 23 shows an example of changing the wait number.
- the selection unit 35 determines the trunk relay node 50 as the relay destination.
- the method of selecting the trunk relay node 50 as the relay destination is the same as the method described with reference to FIG.
- the method for notifying the core relay node 50 that the relay destination has been designated as a new relay destination is the same as in the second embodiment.
- the node N19 changes the relay destination from the core relay node 50b to 50c by the processing of the procedure (61).
- FIGS. 24A and 24B are flowcharts for explaining an example of the operation of the sensor relay node 10 when the adjacent sensor relay node 10 fails. Note that the processing illustrated in FIGS. 24A and 24B is an example, and for example, the order of the combination of steps S92 and S93, the combination of steps S94 and S95, and the combination of steps S96 and S97 can be arbitrarily changed. If there is no frame transmission / reception before the timer of the wait number table 33 times out, the failure detection unit 36 determines that the node connected to the timed out port has failed. Therefore, the failure detection unit 36 sets a variable k for counting the number of core relay nodes 50 that are processing targets to 0 (step S91).
- the failure detection unit 36 confirms whether the wait number is initialized at the port set as the master port (step S98).
- Steps S91 to S102 are repeated until the value obtained by subtracting one from the total number of core relay nodes 50 matches the value of k.
- the sensor relay node 10 transmits a health frame including a wait number to the adjacent sensor relay node 10 (step S103).
- the sensor relay node 10 re-determines the trunk relay node 50 as a relay destination using the obtained wait number (step) S104). Further, the sensor relay node 10 transmits a state notification frame to the changed core relay node 50 (step S105).
- the core relay node 50 recognizes the change of the core relay node 50 performed in the sensor relay node 10 by receiving the state notification frame.
- the trunk relay node 50 that can reach any sensor relay node 10 that is operating normally with the shortest number of hops is used as a relay destination. Routing with the shortest number of hops can be performed.
- FIG. 25 is a diagram illustrating an example of a table stored in the core relay node 50.
- all the basic relay nodes 50 store a common table by transmitting and receiving control information between the basic relay nodes 50. Therefore, the core relay node 50 recognizes the core relay node 50 that manages the sensor relay node 10 even for the sensor relay node 10 that is not a management target.
- each core relay node 50 requests re-determination of the wait number.
- Each sensor relay node 10 determines a trunk relay node 50 as a relay destination according to the redetermined wait number.
- an example is a process in the case where a failure occurs in the sensor relay node 10 of the node N5 when the relay destination is selected.
- the sensor relay node 10 that has detected the occurrence of a failure transmits a frame for notifying the occurrence of the failure to the core relay node 50 that is the relay destination of the sensor relay node 10.
- the frame for notifying the occurrence of a failure is a message requesting that the sensor relay node 10 in which the failure has occurred be deleted from the ad hoc network. Therefore, in the following description, a frame that notifies the occurrence of a failure is referred to as “deletion notification”.
- the sensor relay node 10 that has received the deletion notification transfers the deletion notification to the core relay node 50.
- the nodes N4 and N12 notify the core relay node 50b that a failure has occurred in the node N5.
- the node N6 notifies the core relay node 50c that a failure has occurred in the node N5.
- the trunk relay node 50b notified of the occurrence of the failure notifies the trunk relay nodes 50a and 50c that the failure has occurred in the node N5. Also, when the trunk relay node 50c receives the deletion notification from the node N6, the trunk relay node 50c notifies the trunk relay nodes 50a and 50b that a failure has occurred in the node N5. Therefore, each of the core relay nodes 50a to 50c in the network recognizes the occurrence of a failure at the node N5.
- the trunk relay node 50 requests each sensor relay node 10 to reset the wait number using the synchronization request frame.
- the method for determining the wait number is the same as the method described in the first embodiment. However, since a failure has occurred in the node N5 here, the synchronization request frame is not output from the node N5.
- FIG. 26 shows an example in which the wait number is redetermined based on the synchronization request frame output from the core relay node 50c.
- FIG. 27 shows an example in which the wait number is redetermined when starting from each of the core relay nodes 50a to 50c.
- the selection unit 35 determines the core relay node 50 as a relay destination.
- the method of selecting the trunk relay node 50 as the relay destination is the same as the method described with reference to FIG. Furthermore, the method for notifying the core relay node 50 that the relay destination has been designated as a new relay destination is the same as in the second embodiment. Also in the example of FIG. 27, since the path is changed based on the failure of the node N5, the node N19 changes the relay destination from the core relay node 50b to 50c.
- FIG. 28 is a flowchart for explaining an example of the operation of the sensor relay node 10 in the fifth embodiment.
- the sensor relay node 10 determines whether a failure has occurred in the adjacent sensor relay node 10 (Step S111). If the occurrence of a failure in the adjacent sensor relay node 10 is not detected, it is determined whether a health frame has been received from the adjacent sensor relay node 10 before the timeout (No in step S111, step S112). If the health frame can be received before the timeout, the sensor relay node 10 returns to the process of step S111 (Yes in step S112). When the health frame cannot be received before the timeout, the sensor relay node 10 transmits a deletion notification to the core relay node 50 (Yes in Step S112, Step S113).
- the deletion notification includes an identifier for identifying the sensor relay node 10 that could not receive the health frame.
- the sensor relay node 10 transmits a deletion notification to the backbone relay node 50 (Yes in step S111, step S113). Thereafter, the sensor relay node 10 stands by until a synchronization request frame is received from the core relay node 50 (step S114).
- the sensor relay node 10 re-determines the wait number (step S115). The redetermination of the wait number is performed in the same manner as when the wait number is determined in the first embodiment. Thereafter, the sensor relay node 10 determines the relay destination backbone relay node 50 based on the redetermined wait number, and transmits a status notification frame (step S116).
- FIG. 29 is a flowchart for explaining an example of the operation of the core relay node 50 in the fifth embodiment.
- the core relay node 50 determines whether a deletion notification has been received from the sensor relay node 10 (step S121). When the deletion notification has not been received, the core relay node 50 confirms whether or not the deletion synchronization notification has been received from another core relay node 50 (step S122).
- the “deletion synchronization notification” is a control frame used by the trunk relay node 50 that has recognized the failure of the sensor relay node 10 to notify the other trunk relay node 50 of the fault of the sensor relay node 10.
- the deletion synchronization notification includes the identifier of the sensor relay node 10 in which the failure has occurred.
- the core relay node 50 confirms whether the response of the health frame has timed out with the sensor relay node 10 connected to the core relay node 50 (step S123). ). If the response of the health frame has not timed out, the core relay node 50 returns to step S121 (No in step S123). On the other hand, when it is determined Yes in any of steps S121 to S123, the trunk relay node 50 transmits a deletion synchronization notification to the other trunk relay node 50 (step S124). Thereafter, the core relay node 50 transmits a synchronization request frame to the sensor relay node 10 and requests re-determination of the wait number (step S125).
- the core relay node 50 receives the synchronization response frame from the sensor relay node 10. Further, the core relay node 50 also transfers the received synchronization response frame to other core relay nodes 50. Each backbone relay node 50 repeats reception and transfer of the synchronization response frame until it receives the synchronization response frames from all the sensor relay nodes 10 included in the ad hoc network (step S126). When the synchronization response frames from all the sensor relay nodes 10 are received, the core relay node 50 repeats the processing after step S121 (Yes in step S126).
- FIG. 30 is a flowchart for explaining an example of the operation of the selection unit 35 when selecting a trunk relay node 50 as a relay destination.
- the health frame format can be modified as shown in FIG.
- the wait numbers starting from each of the plurality of trunk relay nodes 50 in the network can be transmitted one frame at a time.
- the format is determined in advance so that the order of the wait numbers in the frame and the core relay node 50 are uniquely associated.
- FIG. 31 is a flowchart illustrating an example of the operation of the sensor relay node 10. Steps S141 to S143 are the same as steps S111 to S113 described with reference to FIG. Next, the sensor relay node 10 confirms whether a wait number is set with the port in which the failure is detected as a master port (step S144). When the port in which the failure is detected is a master port, the sensor relay node 10 updates the master port to unused, and further updates the wait number of the own node to the initial value (steps S145 and S146).
- the sensor relay node 10 transmits health frames from all ports (step S147). Further, the connection destination wait number connected to each port of the sensor relay node 10 is compared to identify a port with a smaller wait number (step S148). The sensor relay node 10 sets a value obtained by incrementing the wait number of the connection destination of the identified port by 1 as the wait number of the own node (step S149). Further, the sensor relay node 10 sets the master port to the port specified in step S148 (step S150). If the sensor relay node 10 has not transmitted a health frame after a state change such as changing the wait number of its own node, the sensor relay node 10 transmits a health frame to the adjacent sensor relay node 10 (steps S151 and S152).
- the sensor relay node 10 transmits a status notification frame to the core relay node 50 (step S153). Thereafter, the sensor relay node 10 confirms whether or not the health frame has been received from all the ports, and if the reception has been completed, returns to step S141 (Yes in step S154). On the other hand, when the reception of the health frame has not ended, the sensor relay node 10 waits for the reception of the health frame and repeats the processing from step S144 (step S155).
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
Abstract
サーバとの間が複数の中継装置によって中継可能なように構成されているネットワーク中のノード装置は、受信部、ウェイト番号生成部、記憶部、選択部、および、送信部を備える。受信部は、隣接ノード装置からフレームを受信する。ウェイト番号生成部は、複数の中継装置の中のそれぞれの中継装置を起点としたときの隣接ノード装置までのホップ数が、隣接ノード装置からの同期要求と共に通知されると、ホップ数をインクリメントしたウェイト番号を中継装置ごとに生成する。記憶部は、生成されたウェイト番号を、中継装置を識別する識別子と対応付けてそれぞれ記憶する。選択部は、記憶部に記憶されているウェイト番号が相対的に小さい中継装置を選択する。送信部は、選択された中継装置を中継先に指定し、サーバを宛先に指定したデータフレームを送信する。
Description
本発明は、複数のノード装置を含むネットワークにおける通信に関する。
自律分散型ネットワークの例として、有線アドホックネットワークが挙げられる。有線アドホックネットワークは、例えば、センサーネットワークに適用されることがある。この場合、アドホックネットワークを形成している個々のセンサーは、建物や橋梁などの構造物内への埋め込みが可能であり、さらに、土中や水中などの無線ネットワークの運用が困難である箇所への設置が可能である。また、有線アドホックネットワークは、有線によりデータの送受信が行われるため、故障の発生による切断の検出が容易であるなどの利点がある。
アドホックネットワークを構築する際には、経路選択、障害発生時の制御などの技術も求められる。経路選択の例として、ネットワーク中の各ゲートウェイと各ノード装置に予めグループIDを設定しておき、各ノード装置は同じグループIDが割り当てられているゲートウェイに到達する経路の中で最も通信品質が良好な経路を選択する方法が知られている。また、ループの検出方法も考案されている。この方法では、第1のノード装置は、第1のポートから第1のフレームを送信するとともに、第1のポートを判別する情報と第1のフレームを識別する第1の識別情報を対応付けて格納する。第1のノード装置は、第2のノード装置から第2のフレームを受信すると、第2のフレームを識別する第2の識別情報と第1の識別情報を比較し、両者が一致すると、ループを検出したと判断する。さらに、移動端末が経路検索により選択した1つのゲートウェイノードを介して外部ネットワークと通信し、通信中に経路断の通知を受信すると、再度経路を検索してゲートウェイノードを選択する方法も知られている。移動端末は、新たに選択したゲートウェイノードを介して外部ネットワークとの通信を継続する。
背景技術で述べた方法によりゲートウェイが選択されると、ノード装置から最もホップ数が小さいゲートウェイが選択されないことがあり、選択されたゲートウェイまでのホップ数が大きいために、経路が冗長になることが多かった。さらに、背景技術で述べた経路の選択方法では、選択されたゲートウェイまでの経路についてもホップ数が最小の経路が選択されずに冗長な経路が選択されてしまうことがある。
本発明は、ネットワーク中の個々のノード装置が最短の経路を用いて通信を行うことができるようにすることを目的とする。
サーバとの間が複数の中継装置によって中継可能なように構成されているネットワーク中のノード装置は、受信部、ウェイト番号生成部、記憶部、選択部、および、送信部を備える。受信部は、隣接ノード装置からフレームを受信する。ウェイト番号生成部は、前記複数の中継装置の中のそれぞれの中継装置を起点としたときの前記隣接ノード装置までのホップ数が、前記隣接ノード装置からの同期要求と共に通知されると、前記ホップ数をインクリメントしたウェイト番号を前記中継装置ごとに生成する。記憶部は、生成された前記ウェイト番号を前記中継装置を識別する識別子と対応付けてそれぞれ記憶する。選択部は、前記記憶部に記憶されているウェイト番号が相対的に小さい中継装置を選択する。送信部は、選択された中継装置を中継先に指定し、前記サーバを宛先に指定したデータフレームを送信する。
ネットワーク中の個々のノード装置は、最短の経路を用いて通信する。
図1は、実施形態に係るネットワークの例を示す。図1に示すネットワークには、ノードN1~N8の8台のノード装置と、ゲートウェイGW1およびGW2の2台のゲートウェイ装置を含むアドホックネットワーク、ハブ5、サーバ1が含まれる。サーバ1は、ハブ5とゲートウェイ装置を介してノード装置との間でフレームを送受信する。以下の説明では、アドホックネットワークに含まれる個々のノード装置は、隣接するノード装置もしくはゲートウェイまでの経路は記憶しているが、ネットワークに含まれているその他の装置への経路は記憶していないものとする。
ノード装置は、隣接するノード装置との間でゲートウェイ装置からのホップ数を含むフレームを送受信することにより、GW1からノード装置までのホップ数と、GW2からノード装置までのホップ数を求める。例えば、ノードN4は、ゲートウェイGW2に隣接しているので、ゲートウェイGW2からのホップ数が1であることをノードN3とN8に通知する。すると、ノードN3とN8は、ノードN4に隣接しているので、ゲートウェイGW2からのホップ数が2であることを認識し、各々に隣接するノードに通知する。
以下の説明では、いずれかのゲートウェイ装置からノード装置までのホップ数の最小値のことを「ウェイト番号」と記載することがある。例えば、ノードN4は、ゲートウェイGW2に隣接しているので、ゲートウェイGW2を起点としたノードN4のウェイト番号は1である。さらに、ノードN8はノードN4に隣接しているので、ゲートウェイGW2を起点としたノードN8のウェイト番号は2となる。一方、ゲートウェイGW1からノードN8までの最短経路の1つは、GW1からN1、N2、N3、N7を経てN8に到達する経路である。このため、ゲートウェイGW1を起点としたノードN8のウェイト番号は5となる。
ノード装置は、サーバ1にフレームを送信する際に、ウェイト番号が最小のゲートウェイ装置を、サーバ1への中継先に指定する。例えば、ノードN8がサーバ1にフレームを送信するときは、ゲートウェイGW2を起点としたノードN8のウェイト番号(=2)と、ゲートウェイGW1を起点としたノードN8のウェイト番号(=5)を比較する。ここでは、ゲートウェイGW2を起点としたウェイト番号のほうが、ゲートウェイGW1を起点としたウェイト番号よりも小さい。そこで、ノードN8は、ゲートウェイGW2を中継先に指定する。このため、例えば、ノードN8から送信されたフレームが図1の破線の矢印(A)で示すような、冗長な経路によりサーバ1に送信されることを防ぐことができる。
このように、アドホックネットワークに含まれる各ノードは、最小のホップ数で到達できるゲートウェイ装置を経由してサーバ1にアクセスするため、サーバ1までの経路を短くすることができる。
さらに、サーバ1宛てのフレームを転送する際に、個々のノードは、中継先のゲートウェイ装置を起点としたウェイト番号が小さいノードを、転送先に選択する。例えば、ノードN8からゲートウェイGW2を中継先に指定して送信されたフレームは、ノードN4に送信されるとゲートウェイGW2に送信される。しかし、ノードN7に送信されると、ゲートウェイGW2を起点としたノードN7のウェイト番号(=3)は、ゲートウェイGW2を起点としたノードN8のウェイト番号(=2)よりも大きいため、フレームはゲートウェイGW2に送信されずにノードN8に送り返される。従って、ノードN8からサーバ1に向けて送信されるフレームは、図1の実線の矢印(B)に示すように、最短経路を介してサーバ1に送信される。
<装置構成>
以下の例では、ノード装置はセンサーを備え、他のノード装置からサーバ1に向けて送信されるフレームを中継する装置(センサー中継ノード10)であるものとする。一方、ゲートウェイ装置は、センサーを備えておらず、ノード装置から受信したフレームの中継を行う装置(基幹中継ノード)であるものとする。
以下の例では、ノード装置はセンサーを備え、他のノード装置からサーバ1に向けて送信されるフレームを中継する装置(センサー中継ノード10)であるものとする。一方、ゲートウェイ装置は、センサーを備えておらず、ノード装置から受信したフレームの中継を行う装置(基幹中継ノード)であるものとする。
図2は、センサー中継ノード10の構成の例を示す。センサー中継ノード10は、有線アドホックネットワークポート11(11a~11c)、汎用ポート12、アドホックルーティング制御デバイス20、Central Processing Unit(CPU)40を備える。ノード装置はさらに、digital input/digital output(DI/DO)端子13、Electrically Erasable and Programmable Read Only Memory(EEPROM)14、センサー接続ポート15(15a~15c)も備える。
有線アドホックネットワークポート11は、他のセンサー中継ノード10または基幹中継ノード50(図6参照)との間で送受信されるアドホックフレームをカプセル化したイーサネットフレームのデータを終端し、送受信フレームの符号化または復号を行う。センサー中継ノード10が備える有線アドホックネットワークポート11の数は任意であるが、以下の説明では、ポートP1、P2、P3の3ポートを備える場合を例として説明する。有線アドホックネットワークポート11は、送信フレームを一時保持するバッファメモリを備えることができる。以下の記載では、有線アドホックネットワークポート11を「ポート」または「受信ポート」など記載することもあるものとする。汎用ポート12は、例えばLAN(ローカルエリアネットワーク)を終端する。
アドホックルーティング制御デバイス20は、例えば、FPGA(Field Programmable Gate Array)やSRAM(Static Random Access Memory)により実現される。アドホックルーティング制御デバイス20は、受信フレーム制御部21、送信フレーム制御部22、汎用ポート制御部23、CPUインタフェース24、フレーム処理部26、ルーティング制御部30を備える。さらに、アドホックルーティング制御デバイス20は、FID(Frame ID)テーブル27、PS(Port Status)テーブル28、ノード管理テーブル29も備える。また、CPUインタフェース24はレジスタ25を有する。
受信フレーム制御部21は、有線アドホックネットワークポート11a~11cからフレームデータを受信する。受信フレーム制御部21は、宛先が他のセンサー中継ノード10であるフレームをルーティング制御部30に出力する。フレームの宛先が自ノードである場合、受信フレーム制御部21は、フレームをCPUインタフェース24に出力する。CPUインタフェース24は、受信フレーム制御部21から入力されたフレームを、CPU40に出力する。なお、CPU40への出力に際して、CPUインタフェース24は、適宜、レジスタ25を使用する。
ルーティング制御部30は、ウェイト番号を用いたルーティング処理を行う。ルーティング制御部30の構成の例を図3に示す。ルーティング制御部30は、ウェイト番号制御部31(31a~31c)、障害検出部36、初期化要求部37、ルーティング部38を備える。ウェイト番号制御部31aは、ウェイト番号生成部32、記憶部34、選択部35を備え、記憶部34にウェイト番号テーブル33を有する。ウェイト番号制御部31a~31cは、互いに異なる基幹中継ノード50を起点とするウェイト番号を処理するものとする。例えば、ウェイト番号制御部31aは基幹中継ノード50aを起点としたウェイト番号を処理し、ウェイト番号制御部31bは基幹中継ノード50bを起点とするウェイト番号を処理する。図3では、単に図を見やすくするために、ウェイト番号制御部31b、31cについては詳細を示していないが、ウェイト番号制御部31bと31cのいずれもウェイト番号制御部31aと同様の構成を有する。ウェイト番号生成部32は、隣接するセンサー中継ノード10から受信したフレームに含まれているウェイト番号をインクリメントすることにより、ウェイト番号生成部32が備えられているセンサー中継ノード10に割り当てられるウェイト番号を決定する。
図4(a)は、ウェイト番号テーブル33の例を示す。なお、図4(a)に示す例は、初期化された状態のウェイト番号テーブル33であり、データは記録されていない。ウェイト番号テーブル33は、ウェイト番号生成部32が決定したウェイト番号と、ポートP1~P3の各々を介して接続されたセンサー中継ノード10のウェイト番号を記憶する。このとき、ウェイト番号生成部32は、ウェイト番号を決定する際の基準位置として用いられた基幹中継ノード50を識別する識別子(送信元基幹中継番号)と対応付けてウェイト番号を記憶する。さらに、ウェイト番号テーブル33には、ウェイト番号の決定に用いたフレームを受信したポートのポート番号も記録される。以下、ウェイト番号の決定に用いたフレームを受信したポートのことを「マスターポート」と記載することがある。図3ではウェイト番号テーブル33を1つ図示しているが、ウェイト番号テーブル33は、ネットワークに含まれている基幹中継ノード50の数と同数備えられている。個々のウェイト番号テーブル33は1つの基幹中継ノード50を起点としたときのウェイト番号に関する情報を格納するものとする。
選択部35は、サーバ1宛てのフレームを送信する際に中継先として指定する基幹中継ノード50を、ウェイト番号テーブル33を用いて決定する。また、選択部35は、選択した結果をノード管理テーブル29に記録する。ノード管理テーブル29の例を図5に示す。図5の例では、ノード管理テーブル29には、選択部35で選択された基幹中継ノード50を識別する識別子が記録されているが、実装に応じて他の任意の情報もノード管理テーブル29に含められることがある。ウェイト番号テーブル33の生成方法や使用方法、選択部35の動作などについては、後で詳しく説明する。
障害検出部36は、隣接するセンサー中継ノード10の状況を監視し、隣接するセンサー中継ノード10との通信に障害が発生すると、障害の発生を検出する。障害検出部36は障害が発生したことを初期化要求部37に通知する。初期化要求部37は、障害が発生したことによって変動するウェイト番号を特定し、特定したウェイト番号を初期化する。さらに、初期化要求部37は、隣接するセンサー中継ノード10に対して、適宜、ウェイト番号の初期化を要求する。障害検出部36と初期化要求部37の動作については後で詳しく説明する。
ルーティング部38は、受信フレーム制御部21からルーティング制御部30に入力されたフレームの転送先のポートを特定する。ルーティング部38は、PSテーブル28、FIDテーブル27、および、ウェイト番号テーブル33を参照して転送先のポートを決定する。ここで、PSテーブル28は、フレームを転送可能なポートを宛先ごとに記憶しているテーブルである。PSテーブル28は、フレームの宛先アドレスに対応付けて、その宛先にフレームを転送することができるポートの番号が対応付けられている任意の形式とすることができる。ルーティング部38は、転送するフレームを、転送先のポート番号を通知する情報と共に、送信フレーム制御部22に出力する。
FIDテーブル27は、ループの検出に用いられる。FIDテーブル27は、受信したことがあるフレームの送信元アドレスとFIDフィールドの値の組み合わせに対応付けて、有線アドホックネットワークポート11の使用状況を記録している。有線アドホックネットワークポート11の使用状況は、有線アドホックネットワークポート11からのリンクが無い(リンク断)、ループ(ループ状態)、未使用、宛先へフレームの送信に使用している(送信中ポート)など、各ループの接続情報を示す。なお、有線アドホックネットワークポート11の使用状況は、フレームの送信元アドレスとFIDフィールドの値の組み合わせに応じて決定される。例えば、ノードN1から送信されたFID=1のフレームの宛先がノードN4であったとする。ノードN2のポートP1からノードN4へフレームを送信できる場合、送信元がノードN1でFID=1のフレームに対応付けられた使用状況は、ノードN2のポートP1では「送信中ポート」になる。一方、ノードN1から送信されたFID=2のフレームの宛先がノードN5であるとする。さらに、ノードN2のポートP1からノードN5へフレームを送信しても、ループが発生しているために送信したフレームをノードN2が他のノード装置から再度、受信してしまうとする。この場合、送信元がノードN1でFID=2のフレームに対応付けられた使用状況は、ノードN2のポートP1では「ループ状態」になる。また、送信元がノードN1でFID=1のフレームを転送したことが無いポートでは、送信元がノードN1でFID=1のフレームに対応付けられた使用状況は「未使用」となる。
さらに、FIDテーブル27は、エントリごとに1つのLoopフラグを含む。ここで、Loopフラグは、エントリに記録されている送信元アドレスとFIDの組合せで特定されるフレームの宛先に至る経路上に、自ノードが存在するかを示す。Loopフラグ=1の場合、エントリに記録されている送信元アドレスとFIDの組合せで特定されるフレームの宛先のノードに至る経路に自ノードが存在しないことを示す。すなわち、Loopフラグ=1は、自ノードがフレームの宛先に向けてそのフレームを転送できないことを示す。一方、Loopフラグ=0の場合、エントリに記録されている送信元アドレスとFIDの組合せで特定されるフレームの宛先のノードに至る経路に自ノードが存在することを示す。すなわち、Loopフラグ=0は、自ノードがフレームの宛先に向けてそのフレームを転送できることを示す。
ルーティング部38は、フレームを転送する前に、送信元アドレスとFIDフィールドの値の組み合わせが、FIDテーブル27のいずれかのエントリと一致するかを確認する。FIDテーブル27中のエントリと一致すると、ルーティング部38は既に受信したフレームを受信したと判断して転送を行わない。このとき、ルーティング部38は、フレームの送信元アドレスとFIDフィールドの値の組み合わせに対応付けて、フレームの宛先に転送できないことを記録する。例えば、ルーティング部38は、Loopフラグをエントリごとに設け、ループを検出した場合、対応するエントリのLoopフラグを「1」に設定する。すると、Loopフラグが1に設定されたエントリに記録されている送信元アドレスとFIDの組合せを含むフレームについては、ルーティング部38は転送を行わずに、受信したポートからフレームを返送する。一方、FIDテーブル27には一致するエントリが無い場合、ルーティング部38は、フレームの宛先をキーとしてPSテーブル28を検索する。フレームの宛先がPSテーブル28に記録されている場合は、PSテーブル28に指定されているポートから出力させることによりフレームを転送する。
また、ルーティング部38は、転送するフレームの宛先のノードに割り振られているウェイト番号と、自ノードに割り振られているウェイト番号を用いて、転送先を決定することもできる。フレームの宛先に割り振られているウェイト番号が、自ノードのウェイト番号よりも大きい場合、ルーティング部38は、自ノードよりも大きなウェイト番号が割り振られているノードに接続されているポートから、転送対象のフレームを転送する。一方、自ノードよりも大きなウェイト番号が割り振られているノードに接続されているポートが無い場合、ルーティング部38は、ループを検出したと判断する。そこで、ルーティング部38は、フレームを受信したポートから返送することにより、送信元のノード装置に向けて返送する。ループが検出されると、転送の対象とされたフレームの送信元アドレスとFIDフィールドの値に基づいて、FIDテーブル27中のポートの使用状態が「ループ状態」に変更される。
次に、フレームの宛先に割り振られているウェイト番号が、自ノードのウェイト番号よりも小さい場合のルーティング部38の動作について述べる。この場合、ルーティング部38は、自ノードよりも小さなウェイト番号が割り振られているノード装置に接続されているポートから、転送対象のフレームを転送する。自ノードよりも小さなウェイト番号が割り振られているノード装置に接続されているポートが無い場合、ルーティング部38は、ループを検出したと判断する。ループを検出した場合、ルーティング部38は、処理対象のフレームを送信元のノード装置に向けて返送する。また、FIDテーブル27のポートに関する情報も更新される。
受信フレームの宛先に割り振られているウェイト番号が、自ノードのウェイト番号と一致する場合、ノード装置は、フレームの宛先が自ノードであるかを確認する。フレームの宛先が自ノードである場合、受信フレームは、適宜、CPU40などで処理される。一方、宛先が自ノードでなく、さらに、受信フレームの宛先に割り振られているウェイト番号が、自ノードのウェイト番号と一致する場合、ルーティング部38は、ループを検出したと判断する。ループを検出した場合に行われる処理は前述のとおりである。
フレーム処理部26は、CPUインタフェース24がCPU40から取得した情報を含むフレームを生成し、ルーティング制御部30や送信フレーム制御部22に出力する。送信フレーム制御部22は、ルーティング制御部30や送信フレーム制御部22から入力されたフレームを、送信先に応じて、有線アドホックネットワークポート11に出力する。
CPU40は、センサー中継ノード10に備えられているセンサー(図示せず)から取得した情報を処理する。CPU40は、FPGAインタフェース41、DI/DOインタフェース42、センサーインタフェース43を備える。FPGAインタフェース41は、CPUインタフェース24との間で、センサー情報やセンサー制御情報等を送受信する。センサーインタフェース43は、センサー接続ポート15を介して、センサーとの間で情報を送受信する。ここで、センサーは、温度センサー、風速センサー、照度センサー、人感センサー、電力検針メーター、加速度センサー、ひずみセンサー、監視カメラなどを含む任意のセンサーであっても良く、実装に応じて選択される。センサーインタフェース43は、EEPROM14とも接続されている。EEPROM14は、各種センサー情報やセンサー制御情報を、適宜、記憶する。DI/DOインタフェース42にはDI/DO端子13が接続される。DI/DO端子13は、データ入力端子およびデータ出力端子として動作する。
センサーにより検出された情報や測定されたデータは、センサーインタフェース43からFPGAインタフェース41を介して、CPUインタフェース24に出力される。CPUインタフェース24は、入力されたデータ等をフレーム処理部26に出力する。なお、CPU40は、FPGAインタフェース41を介して受信したセンサー制御情報に基づいて、センサー制御情報により指定されたセンサー装置を制御する。
<第1の実施形態>
以下、第1の実施形態を、ウェイト番号の決定方法、中継先の基幹中継ノード50の決定方法、および、中継先が決定された後のフレームの送受信に分けて説明する。
以下、第1の実施形態を、ウェイト番号の決定方法、中継先の基幹中継ノード50の決定方法、および、中継先が決定された後のフレームの送受信に分けて説明する。
〔ウェイト番号と中継先の基幹中継ノードの決定方法〕
図6は、ネットワークの例とウェイト番号の決定の例を示す。図6に示すネットワークでは、アドホックネットワークは、基幹中継ノード50a~50cの3台の基幹中継ノード50を介してサーバ1と接続されている。以下の説明では、「ID=Xのセンサー中継ノード10」(ここでXは任意の整数)のことを、表記を短くするために「ノードNX」と記載することがある。例えば、「ID=1のセンサー中継ノード10」のことを「ノードN1」と表記する。また、図6のアドホックネットワークには、ノードN1~N21のセンサー中継ノード10が含まれている。なお、図6はネットワークの例であり、センサー中継ノード10や基幹中継ノード50の数は、実装に応じて変更されうる。
図6は、ネットワークの例とウェイト番号の決定の例を示す。図6に示すネットワークでは、アドホックネットワークは、基幹中継ノード50a~50cの3台の基幹中継ノード50を介してサーバ1と接続されている。以下の説明では、「ID=Xのセンサー中継ノード10」(ここでXは任意の整数)のことを、表記を短くするために「ノードNX」と記載することがある。例えば、「ID=1のセンサー中継ノード10」のことを「ノードN1」と表記する。また、図6のアドホックネットワークには、ノードN1~N21のセンサー中継ノード10が含まれている。なお、図6はネットワークの例であり、センサー中継ノード10や基幹中継ノード50の数は、実装に応じて変更されうる。
図7に、図6のネットワークで送受信されるフレームのフォーマットの例を示す。図7では、同期要求フレーム、同期要求応答フレーム、ヘルスフレーム、状態通知フレーム、データフレームのフォーマットの例を示している。個々のフレームに含まれる情報とフレームに基づいて行われる処理などについては後で詳しく説明するが、いずれの種類のフレームも、ウェイト番号に関する情報を格納するフィールドを含み、さらに、MAC(Media Access Control)ヘッダ、アドホックヘッダ、データフィールド、Frame Check Sequence(FCS)を含む。
MACヘッダは、DST ID(DeSTination ID)フィールド、SRC ID(Source ID)フィールド、およびTYPEフィールドを含む。DST IDフィールドには、フレームの宛先に割り振られている6バイトのMACアドレスが設定される。SRC IDフィールドには、送信元の装置に割り振られている6バイトのMACアドレスが設定される。TYPEフィールドには、2バイトの上位プロトコル識別番号が設定され、例えば、0x8847の値が設定される。なお、「0x」は、それに続く数値が16進数であることを示す。
アドホックヘッダは、KINDフィールド、FIDフィールド、TTLフィールド、およびLengthフィールドを有する。KINDフィールドには、アドホックフレームの種別を表す2バイトのデータが設定される。FIDフィールドには、例えばシーケンシャル番号である2バイトのフレーム識別IDが設定される。TTL(Time To Live)フィールドには、フレームがアドホックネットワークの中に存在することができる上限時間を示す2バイトのデータが設定される。Lengthフィールドには、フレーム中のデータの長さを示す2バイトの値が設定される。FCSは、フレーム中の誤り検出および訂正をするための冗長符号である。
以下、図6に示すネットワークを例として、ウェイト番号の決定方法の例と、サーバ1宛てのフレームを送信する際に中継先とする基幹中継ノード50を選択する方法の例を説明する。以下の説明では、基幹中継ノード50a~50cの各々には、基幹中継番号が割り当てられており、個々の基幹中継ノード50は割り当てられた基幹中継番号を記憶しているものとする。ここでは、基幹中継ノード50aの基幹中継番号は「0」、基幹中継ノード50bの基幹中継番号は「1」、基幹中継ノード50cの基幹中継番号は「2」であるものとする。また、図6に含まれている各センサー中継ノード10に書き込まれたウェイト番号は、以下で説明する手順で得られたウェイト番号である。「#0:」の後の数字は、基幹中継ノード50aを基点としたウェイト番号を表す。「#1:」の後の数字は、基幹中継ノード50b、「#2:」の後の数字は、基幹中継ノード50cを基点としたウェイト番号を表すものとする。
(1)基幹中継ノード50aは、図7(a)に示すような同期要求フレームを生成する。同期要求フレームには、送信元基幹中継番号と送信元ウェイト番号が含まれる。基幹中継ノード50aは、送信元基幹中継番号を「0」、送信元ウェイト番号を0x00に設定する。送信元基幹中継番号=0かつ送信元ウェイト番号=0は、基幹中継ノード50aを基点としたホップ数が0であることを意味し、基幹中継ノード50aのことを表す。
同期要求フレームはブロードキャスト送信されるため、DST IDフィールドには、ブロードキャストアドレスが設定される。基幹中継ノード50は、同期要求フレームのSRC IDフィールドに、基幹中継ノード50aのアドレスを記録する。KINDは同期要求フレームであることを示す値に設定される。ここでは、KIND=1であるものとする。
(2)基幹中継ノード50aが同期要求フレームをブロードキャスト送信すると、ノードN1が同期要求フレームを受信する。ここで、ノードN1は、ポートP1を介して同期要求フレームを受信したものとする。ノードN1の受信フレーム制御部21は、ポートP1を介して受信したフレームのKINDフィールドを確認する。KINDフィールドの値がKIND=1であると、受信フレーム制御部21は、同期要求フレームを受信したと判断して、受信フレームをウェイト番号制御部31aに出力する。このとき、送信フレーム制御部22は、受信ポート番号もウェイト番号制御部31aに出力するものとする。
ウェイト番号生成部32は、ウェイト番号制御部31aに入力された同期要求フレームの送信元ウェイト番号を1つインクリメントして、ノードN1のウェイト番号を求める。さらに、ウェイト番号生成部32は、同期要求フレームの送信元基幹中継番号が0であることを確認すると、生成したウェイト番号=1(0x01)の起点は、基幹中継ノード50aであると認識する。ウェイト番号生成部32は、生成したウェイト番号が、既にウェイト番号テーブル33に記録されているウェイト番号よりも小さい場合、生成したウェイト番号を用いてウェイト番号テーブル33を更新する。例えば、ノードN1において、送信元基幹中継番号=0のウェイト番号テーブル33が図4(a)のとおりであるとする。この場合、ウェイト番号生成部32は、ウェイト番号の欄に記録されている値である0xFFと、生成したウェイト番号0x01を比較する。ここでは、生成したウェイト番号のほうが小さいので、ウェイト番号生成部32は、送信元基幹中継番号=0のウェイト番号テーブル33中のウェイト番号を、0x01に更新する。このとき、ウェイト番号生成部32は、ウェイト番号の決定に用いたフレームを受信したポートをマスターポートとして認識する。例えば、ノードN1の例では、ポートP1から受信した同期要求フレームに基づいてウェイト番号が決定されるので、マスターポートはポートP1となる。なお、ウェイト番号=1は、基幹中継ノード50aからノードN1のセンサー中継ノード10までの最短ホップ数が1であることを示す。
さらに、ウェイト番号生成部32は、同期要求フレームの受信ポートがポートP1であることから、ポートP1を介して接続されているノードのウェイト番号が0であることを認識する。すなわち、ウェイト番号生成部32は、ポートP1を介して基幹中継ノード50と接続されていることを認識する。ウェイト番号生成部32は、得られた情報を送信元基幹中継番号=0のウェイト番号テーブル33に記録する。従って、送信元基幹中継番号=0のウェイト番号テーブル33は、図4(b)に示すように変更される。
なお、ウェイト番号テーブル33中のタイマーは、接続先のウェイト番号が有効であるかを確認するために用いられるものとする。ウェイト番号生成部32は、各ポートに接続されている接続先のウェイト番号が確認されるたびに、タイマーの値をt1にセットし、時間の経過と共にタイマーの値を小さくしていくものとする。タイマー値が0になると、接続先のウェイト番号の情報は無効とされる。
(3)次に、ノードN1のウェイト番号生成部32は、隣接するセンサー中継ノード10に送信するための同期要求フレームを生成する。生成される同期要求フレームでは、SRT IDフィールドにノードN1のアドレスが設定され、送信元ウェイト番号は1に設定される。また、送信元基幹中継番号は0とされる。ウェイト番号生成部32は、生成した送信元基幹中継番号=0の同期要求フレームを、ノードN1の全てのポートから送信するように送信フレーム制御部22に要求する。
(4)ノードN1のポートP1~P3から、手順(3)で生成された同期要求フレームが送信されると、ノードN2とノードN8が同期要求フレームを受信する。ノードN2とノードN8は、それぞれ、手順(2)で説明した処理を行い、送信元基幹中継番号=0のウェイト番号テーブル33を更新する。ここでは、ノードN2とノードN8のいずれも、基幹中継ノード50aからの最短ホップ数は2であるため、ウェイト番号は2に設定される。ここで、ノードN2とノードN8のそれぞれが、ポートP1を介して同期要求フレームを受信したとする。この場合、ノードN2とノードN8のいずれでも、送信元基幹中継番号=0のウェイト番号テーブル33は、図4(c)に示すように更新される。
(5)基幹中継ノード50aは、手順(4)でポートP1を介してノードN1から送信された同期要求フレームを受信するが、基幹中継ノード50aは同期要求フレームを用いた処理は行わない。
(6)ノードN2とノードN8は、ウェイト番号テーブル33の更新が終わると、隣接するセンサー中継ノード10に同期要求フレームを送信する。ここで行われる動作は、手順(3)で述べた動作と同様である。従って、ノードN2は、ノードN1、N3、N9に、基幹中継ノード50aを基点としたノードN2のウェイト番号が2であることを通知して、同期を要求する。また、ノードN8は、ノードN1、N9、N15に、基幹中継ノード50aを基点としたノードN8のウェイト番号が2であることを通知するとともに、同期を要求する。
(7)一方、ノードN1は、ノードN2からポートP2を介して同期要求フレームを受信する。ノードN1のウェイト番号生成部32は、同期要求フレームの送信元ウェイト番号を1つインクリメントして、得られた値を、ウェイト番号テーブル33に記録されている値と比較する。このとき、ウェイト番号生成部32は、処理対象の同期要求フレームの送信元基幹中継番号(=0)と同じ送信元基幹中継番号に対応付けられているウェイト番号テーブル33に記録されているウェイト番号を比較対象とする。ここでは、ノードN1に対して算出されたウェイト番号は3となる。図4(b)に示すように、送信元基幹中継番号=0のウェイト番号として、1が登録されているので、ウェイト番号生成部32は、ウェイト番号テーブル33の中のウェイト番号を更新しない。
また、ウェイト番号生成部32は、ノードN2から受信した同期要求フレームに基づいて、基幹中継ノード50aを基点としたノードN2のウェイト番号が2であることを認識している。ノードN2からの同期要求フレームは、ポートP2から受信されているため、ノードN1において、ポートP2の情報は、図8に示すように更新される。
ノードN1は、ポートP3を介してノードN8から受信した同期要求フレームについても、ノードN2から受信した同期要求フレームと同様に処理する。ノードN8から受信した同期要求フレームの処理によっては、基幹中継ノード50aを基点としたノードN1のウェイト番号は変更されないが、ノードN1は、基幹中継ノード50aを基点としたノードN8のウェイト番号が2であることを認識する。そこで、ウェイト番号生成部32は、送信元基幹中継番号=0のウェイト番号テーブル33のポートP3の情報を、図8に示すように更新する。
(8)隣接するセンサー中継ノード10の間で、送信元基幹中継番号=0の同期要求フレームが送受信されることにより、アドホックネットワークに含まれる全てのセンサー中継ノード10で基幹中継ノード50aを基点としたウェイト番号が求められる。なお、個々のセンサー中継ノード10で行われる処理は、手順(2)~(7)と同様である。基幹中継ノード50aを基点としたウェイト番号を、図6に「#0:」に続く数字として示す。図6に示されるように、各センサー中継ノード10の「#0:」に続くウェイト番号は、基幹中継ノード50aからの最短ホップ数となる。
(9)次に、基幹中継ノード50bも同期要求フレームを生成してブロードキャスト送信する。基幹中継ノード50bで生成された同期要求フレームには、送信元基幹中継番号=1、送信元ウェイト番号=0x00が設定されている。送信元基幹中継番号=1かつ送信元ウェイト番号=0は、基幹中継ノード50bを基点としたホップ数が0であることを表す。
(10)ノードN4は、基幹中継ノード50bから送信元基幹中継番号=1の同期要求フレームを受信すると、送信元基幹中継番号=1のウェイト番号テーブル33を更新する。更新の手順は、手順(2)で説明した手順と同様である。さらに、ノードN4は、手順(3)で説明した手順と同様の手順により、ノードN4に隣接するセンサー中継ノード10(ノードN3およびN5)に、同期要求フレームを送信する。
隣接するセンサー中継ノード10の間で、送信元基幹中継番号=1の同期要求フレームが送受信されることにより、各々のセンサー中継ノード10において、図6に「#1:」に対応付けて示すようなウェイト番号が求められる。各センサー中継ノード10の「#1:」の後に記載されたウェイト番号は、基幹中継ノード50bからの最短ホップ数となる。
(11)基幹中継ノード50cも同期要求フレームを生成してブロードキャスト送信する。基幹中継ノード50cで生成された同期要求フレームには、送信元基幹中継番号=2、送信元ウェイト番号=0x00が設定されている。送信元基幹中継番号=2かつ送信元ウェイト番号=0は、基幹中継ノード50cを基点としたホップ数が0であることを表す。
(12)ノードN7は、基幹中継ノード50cから送信元基幹中継番号=2の同期要求フレームを受信すると、送信元基幹中継番号=2のウェイト番号テーブル33を更新する。更新の手順は、手順(2)で説明した手順と同様である。さらに、ノードN7は、手順(3)で説明した手順と同様の手順により、ノードN7に隣接するセンサー中継ノード10(ノードN6、N14)に、同期要求フレームを送信する。
隣接するセンサー中継ノード10の間で、送信元基幹中継番号=2の同期要求フレームが送受信されることにより、各々のセンサー中継ノード10において、図6に「#2:」に対応付けて示すようなウェイト番号が求められる。各センサー中継ノード10の「#2:」の後に記載されたウェイト番号は、基幹中継ノード50cからの最短ホップ数となる。
(13)手順(1)~(12)が終わったときにノードN1が保持するウェイト番号テーブル33を図9に示す。図9(a)は、基幹中継ノード50aを基点としたときのウェイト番号テーブル33である。また、図9(b)は基幹中継ノード50b、図9(c)は基幹中継ノード50cを基点としたときのウェイト番号テーブル33である。
(14)基幹中継ノード50a~50cの各々についてウェイト番号が決定されると、選択部35は、基幹中継ノード50ごとにウェイト番号を比較し、ウェイト番号が最小の基幹中継ノード50を決定する。決定された基幹中継ノード50は、そのセンサー中継ノード10からサーバ1に送信するフレームの中継先として用いられる。選択部35は、決定した基幹中継ノード50をノード管理テーブル29(図5)に記録する。例えば、ノードN1では、ウェイト番号は、
基幹中継ノード50aを起点としたウェイト番号:1
基幹中継ノード50bを起点としたウェイト番号:4
基幹中継ノード50cを起点としたウェイト番号:7
となっている。そこで、ノードN1の選択部35は、基幹中継ノード50aを中継先とすることを決定し、ノード管理テーブル29に記録する。他のセンサー中継ノード10においても同様に基幹中継ノード50が選択される。
基幹中継ノード50aを起点としたウェイト番号:1
基幹中継ノード50bを起点としたウェイト番号:4
基幹中継ノード50cを起点としたウェイト番号:7
となっている。そこで、ノードN1の選択部35は、基幹中継ノード50aを中継先とすることを決定し、ノード管理テーブル29に記録する。他のセンサー中継ノード10においても同様に基幹中継ノード50が選択される。
図10に各センサー中継ノード10で決定された中継先の例を示す。ここで、太線で囲まれているウェイト番号がセンサー中継ノード10ごとのウェイト番号の最小値であり、太線で囲まれているウェイト番号の起点となった基幹中継ノード50がサーバ1への中継先として用いられる。図10の例では、ノードN1、N2、N8、N9、N15、N16は、基幹中継ノード50aを中継先とする。また、ノードN3、N4、N5、N10、N11、N12、N17、N18、N19は、基幹中継ノード50bを中継先とする。ノードN6、N7、N13、N14、N20、N21は、基幹中継ノード50cを中継先とする。なお、以下では、基幹中継ノード50を中継先に指定したセンサー中継ノード10は、基幹中継ノード50にとって「管理対象」のセンサー中継ノード10であると記載することがある。
(15)センサー中継ノード10は、中継先とする基幹中継ノード50に対して、同期要求応答フレームを送信する。同期要求応答フレームは、宛先の基幹中継ノード50に対して、送信元のセンサー中継ノード10によりサーバ1への中継先に指定されることを通知するために用いられる。同期要求応答フレームのフォーマットの例を図7(b)に示す。同期要求応答フレームの宛先は、中継先に指定される基幹中継ノード50のアドレス、送信先ウェイト番号は0に設定される。また、送信元ウェイト番号も記録される。また、同期要求応答フレームでは、KINDフィールドの値はKIND2であるものとする。さらに、同期要求応答フレームには、サーバ1への中継先に指定される基幹中継ノード50に割り振られた送信元基幹中継番号も記録される。選択部35は、同期要求応答フレームを生成し、生成した同期要求応答フレームを宛先とする基幹中継ノード50に向けて送信する。例えば、ノードN1が基幹中継ノード50aあてに同期要求応答フレームを送信したとする。
(16)基幹中継ノード50aは、ノードN1から同期要求応答フレームを受信すると、同期要求応答フレームの送信元アドレスと、送信元のセンサー中継ノード10のウェイト番号を対応付けて記憶する。基幹中継ノード50aは、例えば、図11(a)に示すようなテーブルに、ノードN1のアドレスとノードN1のウェイト番号を対応付けて記憶することができる。なお、図11(a)では、テーブルを見やすくするために管理対象のノードのアドレスは、「N1」などのように、センサー中継ノード10に割り振られた番号を用いて表している。
(17)ノードN1以外のセンサー中継ノード10も、同様に同期要求応答フレームを中継先の基幹中継ノード50に向けて送信する。ここで、基幹中継ノード50に隣接していないセンサー中継ノード10から送信された同期要求応答フレームは、アドホックネットワーク中の他のセンサー中継ノード10を経由して基幹中継ノード50に送信される。このとき、送信元のセンサー中継ノード10は、送信先の基幹中継ノード50を起点としたウェイト番号が小さいセンサー中継ノード10に向けて同期要求応答フレームを送信するものとする。選択部35は、同期要求応答フレームを出力するポートを決定する際に、適宜、ウェイト番号テーブル33を参照することができる。
図12は、図6のようにウェイト番号が割り振られた場合にノードN2が備える送信元基幹中継番号=0のウェイト番号テーブル33の例を示す。ノードN2が基幹中継ノード50aに同期要求応答フレームを送信する場合、図12に示すウェイト番号テーブル33を確認する。選択部35は、ポートP1~P3の接続先のウェイト番号を比較して、ポートP1に接続されているセンサー中継ノード10のウェイト番号がノードN2のウェイト番号よりも小さいことを認識する。そこで、ノードN2の選択部35は、同期要求応答フレームをポートP1から出力することを送信フレーム制御部22に要求する。ノードN2は、同期要求応答フレームをポートP1から基幹中継ノード50aに向けて送信する。
(18)ノードN1は、ノードN2から同期要求応答フレームを受信する。すると、ノードN1のルーティング部38は、同期要求応答フレームの送信元基幹中継番号と、ノードN1が中継先としている基幹中継ノード50の基幹中継番号が一致するかを確認する。ここでは、両者が一致するので、ノードN1は、受信した同期要求応答フレームを転送することを決定する。ルーティング部38は、ウェイト番号を確認し、受信したフレームを出力するポートを決定する。この場合、ルーティング部38は、図9(a)に示すウェイト番号テーブル33を参照して、ポートP1から受信フレームを出力する。また、ルーティング部38は、出力したフレームの宛先と出力先のポートを対応付けてPSテーブル28に記録する。従って、ノードN1では、基幹中継ノード50aへの出力ポートがPSテーブル28に記録される。
(19)基幹中継ノード50aは、ノードN1のポートP1に接続されているため、手順(18)の処理により、ノードN2が送信元である同期要求応答フレームを受信する。基幹中継ノード50aは、手順(16)と同様にノードN2の情報を記憶する。
(20)ノードN1、N2以外のセンサー中継ノード10からも、同期要求応答フレームが送信される。ここで、同期要求応答フレームの送信元のセンサー中継ノード10で行われる動作は、手順(17)と同様である。また、同期要求応答フレームを中継するセンサー中継ノード10の動作は、手順(18)と同様である。同期要求応答フレームにより、基幹中継ノード50a~50cは、各々がサーバ1との通信を中継する対象のノードを認識する。例えば、図10のように中継先が選択された場合、基幹中継ノード50aは、図11(b)に示すテーブルを記憶する。個々の基幹中継ノード50は、管理対象のセンサー中継ノード10をサーバ1に報告する。サーバ1は、センサー中継ノード10にフレームを送信する際には、基幹中継ノード50から通知された情報に基づいて、フレームを送信する基幹中継ノード50を決定する。
なお、以上で述べた方法は、ウェイト番号や中継先の基幹中継ノード50を決定する方法の例であり、実装に応じて変更されることがある。例えば、前述の説明では、基幹中継ノード50aを起点としたウェイト番号の決定が終わった後に基幹中継ノード50bを起点としたウェイト番号が決定され、その後、基幹中継ノード50cを起点としたウェイト番号が決定されていた。しかし、基幹中継ノード50aを起点としたウェイト番号の決定が終わる前に、基幹中継ノード50bや50cを起点としたウェイト番号の決定が開始されても良い。また、ウェイト番号の決定の際に起点とする基幹中継ノード50は、任意の方法で選択される。
図13A~図13Fは、フレームを受信したときのセンサー中継ノード10の動作の例を説明するフローチャートである。図13Aは、中継先の基幹中継ノード50を決定する際にセンサー中継ノード10で行われる手順を説明している。センサー中継ノード10は、フレームを受信すると、フレーム中の送信元基幹中継番号とKINDフィールドの値を確認し、受信したフレームが同期要求フレームかを判断する(ステップS1~S3)。受信フレームが同期要求フレームではない場合については、図13B~図13Fを参照しながら後で説明する。
同期要求フレームを受信すると、ウェイト番号生成部32は、同期要求フレームの送信元基幹中継番号に対応する基幹中継ノード50を起点としたときのウェイト番号テーブル33について、フレームを受信したポートの情報を更新する。すなわち、同期要求フレームを受信したポートの接続先のウェイト番号を、同期要求フレーム中の送信元ウェイト番号にする(ステップS4)。また、ステップS4で更新した接続先のウェイト番号に対応付けられているタイマーをリスタートする(ステップS5)。さらに、ウェイト番号生成部32は、既に受信したフレームと同一のフレームを受信したかを、FIDテーブル27を参照して確認する(ステップS6)。すなわち、受信したフレームのSRC IDフィールドの値とFIDフィールドの値の組み合わせが、FIDテーブル27に登録されているかを判断する。SRC IDフィールドの値とFIDフィールドの値の組み合わせが、FIDテーブル27に登録されている場合、ウェイト番号生成部32は、既に受信したフレームを受信したと判断する(ステップS6でYes)。この場合、ウェイト番号生成部32は、受信フレームを削除する(ステップS7)。
SRC IDフィールドの値とFIDフィールドの値の組み合わせが、FIDテーブル27に登録されていない場合、ウェイト番号生成部32は、フレームを受信したノード(自ノード)のウェイト番号についての処理を行う(ステップS6でNo)。なお、ステップS8~S13の処理では、受信フレームの送信元基幹中継番号に対応する基幹中継ノード50を起点としたウェイト番号についての処理が行われる。
ウェイト番号生成部32は、受信したフレーム中の送信元ウェイト番号が初期値(0xFF)であるかを確認する(ステップS8)。受信したフレーム中の送信元ウェイト番号が初期値である場合、ウェイト番号生成部32は、フレームを受信したノードのウェイト番号を初期値に更新する(ステップS8でYes、ステップS9)。一方、受信したフレーム中の送信元ウェイト番号が初期値でない場合、ウェイト番号生成部32は、フレームを受信したノードのウェイト番号は、受信フレームのウェイト番号を1つインクリメントした値よりも大きいかを確認する(ステップS10)。フレームを受信したノードのウェイト番号が受信フレームのウェイト番号を1つインクリメントした値よりも大きい場合、受信フレームにより最短ホップ数が更新されることを意味する(ステップS10でYes)。そこで、ウェイト番号生成部32は、自ノードのウェイト番号を受信フレームのウェイト番号を1つインクリメントした値に更新し、さらに、マスターポートをフレームの受信ポートに更新する(ステップS11、S12)。一方、フレームを受信したノードのウェイト番号が受信フレームのウェイト番号を1つインクリメントした値以下の場合、受信フレームを用いても最短ホップ数が更新されない(ステップS10でNo)。そこで、ステップS10でNoと判断されると、自ノードのウェイト番号は更新されない。
その後、ウェイト番号生成部32は、同期要求フレームのウェイト番号を自ノードのウェイト番号に差し替え、SRC IDを自ノードのアドレスに変更した上で、全ポートから送信する(ステップS13)。また、ウェイト番号を用いてサーバ1への中継先の基幹中継ノード50を決定すると、決定した基幹中継ノード50に同期要求応答フレームを送信する(ステップS14)。
図14は、中継先の基幹中継ノード50を選択する際の選択部35の動作の例を説明するフローチャートである。選択部35は、ネットワーク中の全ての基幹中継ノード50を起点としたウェイト番号が決定されると、選択部35は、最小のウェイト番号を示す変数mに0xFFを設定する(ステップS81)。また、選択部35は、中継先に選択される基幹中継ノード50に割り振られた基幹中継番号を特定するための変数nを0に設定する(ステップS82)。次に、選択部35は、基幹中継番号=nの基幹中継ノード50を起点としたときのウェイト番号がmより小さいかを判定する(ステップS83)。基幹中継番号=nの基幹中継ノード50を起点としたときのウェイト番号がmより小さい場合、選択部35は、基幹中継番号=nの基幹中継ノード50を起点としたときのウェイト番号をmの値に設定する(ステップS84)。次に、選択部35は、nの値を1つインクリメントする(ステップS85)。一方、基幹中継番号=nの基幹中継ノード50を起点としたときのウェイト番号がm以上である場合(ステップS83でNo)、ステップS84とS85の処理は行われない。その後、選択部35は、nの値を基幹中継ノード50の総数から1を引いた数と比較し、両者が一致するまでステップS83~S86の処理を繰り返す。両者が一致すると、選択部35は、nに設定されている値と同じ基幹中継番号が割り振られている基幹中継ノード50を中継先に選択する。
〔中継先が決定された後のフレームの送受信〕
中継先が決定されると、センサー中継ノード10は、隣接するセンサー中継ノード10に向けて定期的にヘルスフレームを送信する。ヘルスフレームは、送信元のセンサー中継ノード10が正常に動作していることを、隣接ノードに通知するために使用される。また、ウェイト番号に変動があった場合、ヘルスフレームにより変更後のウェイト番号が通知される。
中継先が決定されると、センサー中継ノード10は、隣接するセンサー中継ノード10に向けて定期的にヘルスフレームを送信する。ヘルスフレームは、送信元のセンサー中継ノード10が正常に動作していることを、隣接ノードに通知するために使用される。また、ウェイト番号に変動があった場合、ヘルスフレームにより変更後のウェイト番号が通知される。
ヘルスフレームの例を図7(c)に示す。ヘルスフレームでは、DST IDフィールドに、送信元のセンサー中継ノード10に隣接する全てのセンサー中継ノード10を表すアドレスが設定される。また、送信元基幹中継番号と送信元基幹中継番号に対応する基幹中継ノード50を起点とするウェイト番号も、ヘルスフレームにより通知される。図7(c)では送信元基幹中継番号とウェイト番号が1組含まれているので、センサー中継ノード10は複数のヘルスフレームを用いることにより、各基幹中継ノード50からのウェイト番号を取得できる。ここで、ヘルスフレーム中の送信元基幹中継番号は、送信元のセンサー中継ノード10により任意の基準で選択された基幹中継ノード50とすることができる。例えば、センサー中継ノード10は、中継先に決定した基幹中継ノード50を示す送信元基幹中継番号と、中継先の基幹中継ノード50を起点としたウェイト番号をヘルスフレームにより通知することができる。また、ヘルスフレームの場合、KINDフィールドの値はKIND3であるものとする。
図13Aと図13Bを参照しながら、ヘルスフレームを受信した場合のセンサー中継ノード10の動作の例を説明する。受信フレームが同期要求フレームではない場合、図13AのステップS3でNoと判定され、図13BのステップS21において、受信フレームがヘルスフレームであるか判定される(ステップS21)。ここでは、受信フレームがヘルスフレームであったとする(ステップS21でYes)。すると、ウェイト番号生成部32により、ステップS22、S23の処理が行われる。この処理は図13Aを参照しながら説明したステップS4、S5と同様の処理である。
ウェイト番号生成部32は、受信したヘルスフレーム中の送信元ウェイト番号が初期値(0xFF)であるかを確認する(ステップS24)。ここでは、送信元ウェイト番号が初期値ではない場合(ステップS24でNo)について説明し、送信元ウェイト番号が初期値である場合については後述する。送信元ウェイト番号が初期値ではない場合、ウェイト番号生成部32は、フレームを受信したノード(自ノード)のウェイト番号についての処理を行う。なお、ステップS25~S29では、受信フレームの送信元基幹中継番号に対応する基幹中継ノード50を起点としたウェイト番号についての処理が行われる。
ウェイト番号生成部32は、自ノードのウェイト番号は、受信フレームのウェイト番号を1つインクリメントした値よりも大きいかを確認する(ステップS25)。フレームを受信したノードのウェイト番号は、受信フレームのウェイト番号を1つインクリメントした値以下の場合、ステップS1に戻る(ステップS25でNo)。
フレームを受信したノードのウェイト番号が受信フレームのウェイト番号を1つインクリメントした値よりも大きい場合は、自ノードが中継先を決定した後に、より短い経路が発見されたことを示す。このため、ヘルスフレームによりウェイト番号が変更される(ステップS26、S27)。ステップS26、S27は、図13Aを参照しながら説明したステップS11、S12と同様である。その後、ウェイト番号生成部32は、ヘルスフレームを生成して全ポートから出力する(ステップS28)。また、自ノードのウェイト番号が更新されると、ウェイト番号生成部32は、ウェイト番号を用いてサーバ1への中継先の基幹中継ノード50を決定する。中継先の基幹中継ノード50が変更されると、ウェイト番号生成部32は、基幹中継ノード50に状態通知フレームを送信する(ステップS29)。
次に、センサー中継ノード10とサーバ1の間で行われるデータフレームの送受信について説明する。データフレームの例を図7(d)に示す。データフレームでは、DST IDフィールドに、宛先のサーバ1もしくはセンサー中継ノード10を表すアドレスが設定される。また、送信元基幹中継番号と送信元基幹中継番号に対応する基幹中継ノード50を起点としたときの送信先のウェイト番号も、データフレームに含まれる。センサー中継ノード10からサーバ1にデータフレームが送信される場合、送信先ウェイト番号には中継先とする基幹中継ノード50のウェイト番号、すなわち、0が設定される。一方、サーバ1から特定のセンサー中継ノード10にデータフレームが送信される場合、送信先ウェイト番号は、基幹中継ノード50によって設定される。基幹中継ノード50は、サーバ1から受信したデータフレームの宛先をキーとして、図11に示したようなウェイト番号のテーブルを検索し、管理対象のセンサー中継ノード10のウェイト番号を取得する。基幹中継ノード50は、取得したウェイト番号をデータフレームに記録し、処理後のデータフレームをセンサー中継ノード10に転送する。
データフレームがサーバ1に向けて送信される場合、送信元のセンサー中継ノード10は、自ノードのウェイト番号よりも小さいウェイト番号が割り当てられているノードに接続されたポートから、データフレームを送信する。また、データフレームを中継するセンサー中継ノード10も、自ノードのウェイト番号よりも小さいウェイト番号が割り当てられているノードに接続されたポートから、データフレームを送信する。
一方、データフレームがサーバ1から特定のセンサー中継ノード10に向けて送信される場合、基幹中継ノード50は、隣接するセンサー中継ノード10に、データフレームを送信する。さらに、データフレームを中継するセンサー中継ノード10は、自ノードのウェイト番号よりも大きいウェイト番号が割り当てられているノードに接続されたポートから、データフレームを送信する。
さらに、データフレームがサーバ1に向けて送信される場合と、特定のセンサー中継ノード10に向けて送信される場合のいずれも、データフレームを中継するノードのウェイト番号生成部32は、FIDテーブル27を用いてループの発生をチェックしている。
図13A、図13B、図13C、図13E、および、図13Fを参照しながら、データフレームが転送される場合の処理の例を説明する。データフレームを受信したセンサー中継ノード10においても、図13AのステップS1~S3の処理が行われる。受信されたフレームがデータフレームである場合、ステップS3において、Noと判定され、図13BのステップS21の判断が行われる。受信フレームがヘルスフレームではない場合、ステップS21でもNoと判定され、図13CのステップS31において、受信フレームが削除通知であるかの判断が行われる。削除通知は、制御フレームの一種であり、削除通知については後述する。データフレームが受信された場合、ステップS31でNoと判定されるので、ステップS38において、データフレームの宛先が自ノードであるかが判定される。データフレームの宛先が自ノードである場合、データフレーム中のデータはCPUインタフェース24を介してCPU40に出力され、処理が行われる(ステップS38でYes)。一方、データフレームの宛先が自ノードではない場合(ステップS38でNo)、図13Eと図13Fに示すルーティング処理が行われる。
ルーティング部38は、データフレームに送信元基幹中継番号が記録されているかを確認する(ステップS51)。データフレームに送信元基幹中継番号が含まれていない場合、ルーティング部38は、データフレームを受信ポートに返送する(ステップS52)。次に、ルーティング部38は、データフレームから、SRC IDとFIDを取得し、取得したSRC IDとFIDをキーとして、FIDテーブル27を検索する(ステップS53)。FIDテーブル27にヒットするエントリが無い場合、ルーティング部38は、データフレームの宛先アドレスをキーとしてPSテーブル28を検索する(ステップS53でNo、ステップS54)。PSテーブル28中にヒットするエントリが有る場合、ルーティング部38は、得られたエントリにデータフレームを送信可能なポートとして記録されているポートからデータフレームを送信することを決定する(ステップS54でYes)。そこで、ルーティング部38は、FIDテーブル27に、データフレームのSRC IDとFIDを含むエントリを生成する(ステップS67)。また、ルーティング部38は、生成したエントリに、データフレームを送信するポートの番号を「送信中ポート」として記録する。その後、ルーティング部38は、送信ポートを送信フレーム制御部22に通知し、データフレームを送信フレーム制御部22から送信させる(ステップS68)。
PSテーブル28中にヒットするエントリが無い場合、ルーティング部38は、データフレームを受信したポート以外にリンク断とはなっていない有線アドホックネットワークポート11があるかを、送信フレーム制御部22に問い合わせる(ステップS54でNo)。リンク断でないポートがない場合、ルーティング部38は、データフレームのルーティングができないと判断し、データフレームを受信ポートから出力する(ステップS55でNo、ステップS56)。リンク断でないポートがある場合、ルーティング部38は、受信フレームに設定されている送信先ウェイト番号が初期値(0xFF)であるか判定する(ステップS55でYes、ステップS60)。
データフレームの送信先ウェイト番号が初期値である場合、ルーティング部38は、ウェイト番号を用いたルーティング処理は実行しない(ステップS60でYes)。ルーティング部38は、送信フレーム制御部22から通知されたポートが複数ある場合には、若番(若しくは老番等と条件を統一させる)のポートを選択する(ステップS65)。次に、ルーティング部38は、受信フレームの宛先アドレスに対応するエントリをPSテーブル28に生成し、ステップS65で選択したポートを「送信中ポート」に設定する(ステップS66)。
一方、ステップS53で、FIDテーブル27にヒットするエントリが見つかった場合、ルーティング部38は、以前に一度受信して他のセンサー中継ノード10に送信したフレームが、再び戻ってきたと判断する(ステップS53でYes)。この場合、ルーティング部38は、FIDテーブル27で「送信中ポート」とされているポートの状態を「ループポート」に変更する(ステップS57)。ここで、あるポートが「ループポート」に設定されることは、そのポートからは宛先アドレスにフレームを送信できないことを意味するものとする。続いて、ルーティング部38は、データフレームの宛先アドレスをキーとしてPSテーブル28を検索し、得られたエントリにおいて「送信中ポート」に設定されているポートに対して「ループ状態」を設定する(ステップS58)。次に、ルーティング部38は、PSテーブル28上の該当するエントリを検索することにより、「未使用状態」に設定されているポートがあるかを判定する(ステップS59)。
未使用ポートがない場合(ステップS59でNo)ルーティング部38は、FIDテーブル27から、受信フレームの送信元アドレスに対応付けられたエントリを抽出し、そのエントリのRxPort(受信ポート)を取得する(ステップS72)。そして、ルーティング部38は、抽出された最初の受信ポートに、受信フレームを戻して送信する(ステップS73)。
一方、未使用ポートがある場合(ステップS59でYes)、ルーティング部38は、その未使用ポートを選択して送信処理を行うために、ステップS60の処理を行う。受信フレームのウェイト番号が初期値である場合(ステップS60でYes)、ステップS65~S68の処理が行われる。受信フレームのウェイト番号が初期値ではない場合(ステップS60でNo)、ルーティング部38は、受信フレーム内の送信先ウェイト番号が、自ノードのウェイト番号よりも大きいか否かを判定する(ステップS61)。受信フレーム内の送信先ウェイト番号が、自ノードのウェイト番号よりも大きい場合、ルーティング部38は、自ノードよりもサーバ1から遠いセンサー中継ノード10に向けてフレームを中継することを認識する。そこで、ルーティング部38は、自ノードのウェイト番号よりも大きなウェイト番号が割り当てられているノードに接続されているポートからフレームの送信が可能であるかを確認する(ステップS62)。自ノードのウェイト番号よりも大きなウェイト番号が割り当てられているノードに接続されているポートからフレームを送信できる場合(ステップS62でYes)、ステップS65~S68の処理が行われる。一方、自ノードよりも大きなウェイト番号が割り当てられているノードにフレームを送信できない場合(ステップS62でNo)、ルーティング部38は、FIDテーブル27のLoopフラグが“ON”となっているかを判定する(ステップS69)。Loopフラグが“ON”である場合、データフレームの宛先となっているセンサー中継ノード10は、自ノードの接続先には存在しないことが既に記録されている(ステップS69でYes)。そこで、ルーティング部38は、データフレームを受信したポートに返送する(ステップS70)。
一方、Loopフラグが“OFF”である場合、データフレームの宛先となっているセンサー中継ノード10は、自ノードの接続先には存在しないことがFIDテーブル27には記録されていない(ステップS69でNo)。そこで、ルーティング部38は、FIDテーブル27のLoopフラグを“ON”にする(ステップS71)。その後、ルーティング部38は、FIDテーブル27を受信フレームの送信元アドレス(SRC ID)をキーとしてエントリを検索し、ヒットしたエントリのRxPort(受信ポート)を特定する(ステップS72)。ルーティング部38は、抽出された最初の受信ポートに、受信フレームを戻して送信する(ステップS73)。
次に、ステップS61の判定がNOの場合には、ルーティング部38は、受信フレーム内の送信先ウェイト番号が自ノードのウェイト番号よりも小さいかを判定する(ステップS63)。受信フレーム内の送信先ウェイト番号が、自ノードのウェイト番号よりも小さい場合、ルーティング部38は、自ノードよりもサーバ1に近いセンサー中継ノード10に向けてフレームを中継することを認識する(ステップS63でYes)。受信フレーム内の送信先ウェイト番号が自ノードのウェイト番号よりも小さい場合、そこで、ルーティング部38は、自ノードのウェイト番号よりも小さなウェイト番号が割り当てられているノードに接続されているポートからフレームの送信が可能であるかを確認する(ステップS64)。自ノードのウェイト番号よりも小さなウェイト番号が割り当てられているノードに接続されているポートからフレームを送信できる場合(ステップS64でYes)、ステップS65~S68の処理が行われる。
一方、自ノードのウェイト番号よりも小さなウェイト番号が割り当てられているノードに接続されているポートからフレームを送信できない場合(ステップS64でNo)、ステップS69~S73を参照しながら説明した処理が行われる。また、ステップS63で、受信フレーム内の送信先ウェイト番号が自ノードのウェイト番号よりも小さくないと判定された場合、ステップS69~S73を参照しながら説明した処理が行われる。
以上説明した中継先の選択方法とルーティング方法を用いることにより、センサー中継ノード10は、最短ホップ数によりフレームをサーバ1との間で送受信できる。すなわち、前述のとおり、ウェイト番号を用いて中継先の基幹中継ノード50が決定され、個々のセンサー中継ノード10から最短のホップ数で到達できる基幹中継ノード50が中継先に選択される。さらに、中継先に選択された基幹中継ノード50までの経路も、最短ホップ数の経路とされる。このときの経路の選択は、受信フレーム内の送信先ウェイト番号、自ノードのウェイト番号、および、ポート毎の接続先ノードのウェイト番号に基づいて行われる。さらに、本実施形態にかかる方法では、センサー中継ノード10が最短ホップ数で到達できる基幹中継ノード50を中継先とするので、特定の基幹中継ノード50への処理の集中を防ぐことができる。
<第2の実施形態>
第2の実施形態では、基幹中継ノード50とサーバ1の間で障害が発生した場合の復旧方法について説明する。図15は、図10に示すように中継先が決定されていたときに、基幹中継ノード50bとサーバ1の間の回線で障害が発生した場合の例を示す。以下、図15に示すように障害が発生した場合に行われる処理を例として説明する。なお、第2の実施形態においても、中継先が決定された後のフレームのルーティングは、第1の実施形態と同様に行われる。
第2の実施形態では、基幹中継ノード50とサーバ1の間で障害が発生した場合の復旧方法について説明する。図15は、図10に示すように中継先が決定されていたときに、基幹中継ノード50bとサーバ1の間の回線で障害が発生した場合の例を示す。以下、図15に示すように障害が発生した場合に行われる処理を例として説明する。なお、第2の実施形態においても、中継先が決定された後のフレームのルーティングは、第1の実施形態と同様に行われる。
(21)基幹中継ノード50bとサーバ1の間の回線に障害が発生すると、基幹中継ノード50は、障害の発生を検出する。基幹中継ノード50bは、例えば、サーバ1との間で定期的に信号を送受信しており、一定時間を越えて信号がサーバ1から受信できなかったときに、サーバ1と基幹中継ノード50bの間に障害が発生したと判定することができる。
(22)基幹中継ノード50bは、隣接するセンサー中継ノード10がノードN4であることを特定する。この処理は、例えば、前述の手順(19)で同期要求応答フレームにより、センサー中継ノード10bまでのウェイト番号が1であることを通知したセンサー中継ノード10を基幹中継ノード50bが特定することにより行われる。基幹中継ノード50bは、ノードN4に対して、基幹中継ノード50bを起点としたウェイト番号の初期値(0xFF)への変更を要求する。このとき、基幹中継ノード50bは、基幹中継ノード50bの基幹中継番号=1を合せてノードN4に通知するものとする。
(23)基幹中継ノード50bとサーバ1の間での障害が通知される前は、ノードN4のウェイト番号は、
基幹中継ノード50aを起点としたウェイト番号:4
基幹中継ノード50bを起点としたウェイト番号:1
基幹中継ノード50cを起点としたウェイト番号:4
である。
基幹中継ノード50aを起点としたウェイト番号:4
基幹中継ノード50bを起点としたウェイト番号:1
基幹中継ノード50cを起点としたウェイト番号:4
である。
ノードN4が基幹中継ノード50bからウェイト番号の変更の要求を受信すると、ノードN4のウェイト番号生成部32は、要求に応じてウェイト番号を初期化する。この処理により、ノードN4のウェイト番号は、
基幹中継ノード50aを起点としたウェイト番号:4
基幹中継ノード50bを起点としたウェイト番号:0xFF
基幹中継ノード50cを起点としたウェイト番号:4
となる。
基幹中継ノード50aを起点としたウェイト番号:4
基幹中継ノード50bを起点としたウェイト番号:0xFF
基幹中継ノード50cを起点としたウェイト番号:4
となる。
(24)ノードN4の選択部35は、ウェイト番号を比較して、中継先の基幹中継ノード50を決定する。中継先の基幹中継ノード50を決定する方法は、図14を参照しながら説明した方法と同様である。この処理により、選択部35は、基幹中継ノード50aを中継先に選択する。
(25)ノードN4の選択部35は、基幹中継ノード50aに向けて状態通知フレームを送信する。状態通知フレームの例を図7(e)に示す。状態通知フレームではKINDフィールドの値がKIND5に設定されるものとする。また、状態通知フレームの宛先は、新たに中継先とされる基幹中継ノード50であり、送信先ウェイト番号は0に設定される。送信元ウェイト番号は、状態通知を送信するセンサー中継ノード10のウェイト番号である。この例では、送信元ウェイト番号は4、宛先アドレスは、基幹中継ノード50aのアドレスに設定される。さらに、状態通知フレームには、送信元基幹中継番号が含まれている。選択部35は、送信元基幹中継番号の値を0に設定する。
選択部35は、新たに中継先とした基幹中継ノード50aに対応付けられたウェイト番号テーブル33を確認することにより、ノードN4よりも基幹中継ノード50aに近いセンサー中継ノード10がノードN3であることを特定する。そこで、選択部35は、ノードN3に接続されているポートを介して送信することを送信フレーム制御部22に要求し、中継先を基幹中継ノード50aに変更したことを通知しようとする。
(26)ノードN3のルーティング部38は、受信したフレームのKINDフィールドがKIND5であることを認識すると、状態通知フレームを受信したと認識する。状態通知フレームの場合は、中継先の変更を通知するフレームであるため、自ノードの中継先とは異なる基幹中継ノード50が宛先とされている可能性がある。そこで、ルーティング部38は、ノードN3のFIDテーブル27やPSテーブル28を参照せずに、状態通知フレーム中の送信元基幹中継番号を取得し、得られた送信元基幹中継番号に対応付けられたウェイト番号テーブル33に基づいて転送先を決定する。ここでは、送信元基幹中継番号=0の状態通知フレームを受信しているので、ルーティング部38は、基幹中継ノード50aのウェイト番号テーブル33を確認することにより、ノードN3よりも小さいウェイト番号が割り当てられているポートを認識する。ルーティング部38は、認識したポートから状態通知フレームを出力することにより、状態通知フレームをノードN2に転送する。
ノードN2でも同様にルーティング部38が転送処理を行い、ノードN1に状態通知フレームを転送する。ノードN1は、状態通知フレームを基幹中継ノード50aに転送する。基幹中継ノード50aは、受信した状態通知フレームに基づき、管理対象のノードにノードN4を加える。さらに、ノードN4が新たに基幹中継ノード50aの管理対象となったことをサーバ1に通知することにより、以後はノードN4宛てのフレームを基幹中継ノード50aが中継することをサーバ1に認識させる。
(27)ノードN4の初期化要求部37は、ヘルスフレーム(図7(c))を隣接するノードN3とN5に送信することにより、ウェイト番号の変更を通知する。ここで、初期化要求部37は、ヘルスフレームの送信元基幹中継番号を1、送信元ウェイト番号を0xFFに設定する。
(28)ノードN4からのヘルスフレームを受信する前は、ノードN3のウェイト番号は、
基幹中継ノード50aを起点としたウェイト番号:3
基幹中継ノード50bを起点としたウェイト番号:2
基幹中継ノード50cを起点としたウェイト番号:5
となっている。
基幹中継ノード50aを起点としたウェイト番号:3
基幹中継ノード50bを起点としたウェイト番号:2
基幹中継ノード50cを起点としたウェイト番号:5
となっている。
ノードN3は、受信したヘルスフレームを解析することにより、基幹中継ノード50bを起点としたときのノードN4のウェイト番号が0xFFに変更されたことを認識する。さらに、ノードN3のウェイト番号生成部32は、基幹中継ノード50bを起点としたときのウェイト番号を0xFF(初期値)に変更する。すなわち、ウェイト番号を、
基幹中継ノード50aを起点としたウェイト番号:3
基幹中継ノード50bを起点としたウェイト番号:0xFF
基幹中継ノード50cを起点としたウェイト番号:5
に変更する。
基幹中継ノード50aを起点としたウェイト番号:3
基幹中継ノード50bを起点としたウェイト番号:0xFF
基幹中継ノード50cを起点としたウェイト番号:5
に変更する。
(29)ノードN3の選択部35は、変更後のウェイト番号を用いて、中継先の基幹中継ノード50を決定する。中継先の基幹中継ノード50を決定する方法や、中継先の変更を通知する方法は、手順(24)~(26)と同様である。さらに、ノードN3は、隣接するノードN2とN10にヘルスフレームを送信し、基幹中継ノード50bを起点とするウェイト番号が変更されたことを通知する。
(30)ノードN5でも、同様に基幹中継ノード50bを起点とするウェイト番号の変更と状態通知フレームの送信が行われる。これらの処理は、手順(24)~(27)で説明した動作と同様である。また、その他のノードにおいてもウェイト番号の変更が行われ、ウェイト番号の変更に伴い中継先の基幹中継ノード50が変更される場合、手順(24)~(27)と同様に処理される。一方、ノードN2などのように、ウェイト番号が変更されても中継先の基幹中継ノード50が変更されない場合、状態通知フレームは生成されない。しかし、中継先の基幹中継ノード50が変更されない場合でも、ウェイト番号を変更したことは、隣接するノードにヘルスフレームにより通知される。
図16は、手順(21)~(30)の処理が行われた後の、各センサー中継ノード10の中継先を示す。図16に示すように、ノードN3、N4、N10、N11、N17、N18は、中継先を基幹中継ノード50bから基幹中継ノード50aに変更する。また、ノードN5、N12、N19は、中継先を基幹中継ノード50bから基幹中継ノード50cに変更する。
第2の実施形態において、ヘルスフレームを受信したセンサー中継ノード10の動作の例を、図13A、図13B、図13Dを参照しながら説明する。フレームを受信すると、センサー中継ノード10では図13AのステップS1~S3の処理が行われ、ステップS3においてNoと判定される。なお、ステップS1~3の処理は、既に説明したとおりである。すると、図13BのステップS21の処理に進み、ヘルスフレームを受信したかの判定が行われる。ここでは、ヘルスフレームが受信されているので、ステップS22において、ヘルスフレームを受信したポートの接続先のウェイト番号が、ヘルスフレーム中の送信元ウェイト番号に基づいて変更される。さらに、ステップS23、S24の処理が行われる。ステップS23、24の処理は、既に説明したとおりである。
ステップS24において、受信したヘルスフレームの送信元ウェイト番号が初期値であると判定されると、図13Dの処理が行われる。まず、ウェイト番号生成部32は、中継先に指定している基幹中継ノード50を起点とした自ノードのウェイト番号を初期化する(ステップS41)。さらに、ウェイト番号生成部32は、中継先に指定している基幹中継ノード50に関連付けられたウェイト番号テーブル33において、マスターポートの値を初期化する(ステップS42)。その後、センサー中継ノード10は、全てのポートからヘルスフレームを送信する(ステップS43)。さらに、センサー中継ノード10は、変更後のウェイト番号に基づいて中継先とする基幹中継ノード50を決定し、基幹中継ノード50を変更した場合、新たに中継先とした基幹中継ノード50に状態通知フレームを送信する(ステップS44)。
このように、基幹中継ノード50とサーバ1の間の回線に障害が発生すると、基幹中継ノード50からの通知を契機として、個々のセンサー中継ノード10においてウェイト番号が変更される。さらに、個々のセンサー中継ノード10は、変更後のウェイト番号に基づいて中継先の基幹中継ノード50を決定し、中継先を変更した場合は新たに中継先とした基幹中継ノード50に中継先に指定したことを通知する。このため、障害が発生しても、自律的に障害から復旧し、いずれのセンサー中継ノード10も最短ホップ数で到達できる基幹中継ノード50を中継先として、最短ホップ数でのルーティングを行うことができる。
<第3の実施形態>
第3の実施形態では、基幹中継ノード50に障害が発生した場合の動作について説明する。以下、図10に示すように中継先が選択されているときに、基幹中継ノード50bに障害が発生した場合の処理を例として説明する。なお、第3の実施形態においても、中継先が決定された後のフレームのルーティングは、第1の実施形態と同様に行われる。
第3の実施形態では、基幹中継ノード50に障害が発生した場合の動作について説明する。以下、図10に示すように中継先が選択されているときに、基幹中継ノード50bに障害が発生した場合の処理を例として説明する。なお、第3の実施形態においても、中継先が決定された後のフレームのルーティングは、第1の実施形態と同様に行われる。
(41)基幹中継ノード50bで故障が発生すると、基幹中継ノード50bに隣接しているノードN4は、基幹中継ノード50bとの間でヘルスフレームを送受信できなくなる。ヘルスフレームが一定時間以上、基幹中継ノード50bから受信できない場合、ノードN4の障害検出部36は、基幹中継ノード50bが故障したと判断する。
(42)障害検出部36は、基幹中継ノード50bが故障したことをウェイト番号生成部32と初期化要求部37に通知する。ウェイト番号生成部32は、基幹中継ノード50bを起点としたウェイト番号を初期化する。また、初期化要求部37は、隣接するセンサー中継ノード10に対して、基幹中継ノード50bを起点としたウェイト番号の初期化を要求する。以降の処理は、第2の実施形態の手順(24)以降の処理と同様である。
図17に、基幹中継ノード50の故障を発見したときに中継先の基幹中継ノード50を変更した場合の例を示す。このように、基幹中継ノード50に隣接したセンサー中継ノード10が、ヘルスフレームを用いて基幹中継ノード50の動作を監視することにより、基幹中継ノード50の故障を発見したときにも、自律的に経路や中継先の変更が行われる。
<第4の実施形態>
次に、センサー中継ノード10に障害が発生した場合の処理について説明する。以下、図10に示すように中継先が選択されているときに、ノードN5のセンサー中継ノード10に障害が発生した場合の処理を例として説明する。
次に、センサー中継ノード10に障害が発生した場合の処理について説明する。以下、図10に示すように中継先が選択されているときに、ノードN5のセンサー中継ノード10に障害が発生した場合の処理を例として説明する。
(51)ノードN5で故障が発生すると、ノードN5に隣接しているノードN4、N12、N6は、ノードN5との間でヘルスフレームを送受信できなくなる。ヘルスフレームが一定時間以上、ノードN5から受信できない場合、ノードN4、N12、N6の障害検出部36は、隣接するセンサー中継ノード10が故障したと判断する。
(52)隣接するセンサー中継ノード10が故障したと判断した場合、障害検出部36はヘルスフレームが受信できないポートを特定する。例えば、図18(a)に示すように、ノードN4のポートP3にノードN5が接続されているとすると、ノードN4の障害検出部36は、ウェイト番号テーブル33からポートP3に接続されているノードのウェイト番号を取得し、ノードN4のウェイト番号と比較する。さらに、障害検出部36は、比較結果のうち、故障したノードよりも大きなウェイト番号が設定されている場合、ウェイト番号を初期化する。すなわち、故障したノードを介して自ノードが通信する可能性がある基幹中継ノード50を起点とするウェイト番号を初期化する。
例えば、基幹中継ノード50aを起点としたウェイト番号は、ノードN4では4であるが、ポートP1に接続されているノードでは5である。基幹中継ノード50bを起点としたウェイト番号は、ノードN4では1であるが、ポートP1に接続されているノードでは2である。さらに、基幹中継ノード50cを起点としたウェイト番号は、ノードN4では4であるが、ポートP1に接続されているノードでは3である。この場合、ノードN4は、基幹中継ノード50a、50bについてはノードN5を介さずに通信できるが、基幹中継ノード50cに最短ホップ数でアクセスするためには、ノードN5を経由することを示す。しかし、経由するノードとなるノードN5が故障しているので、基幹中継ノード50cは中継先として指定することが無いように、障害検出部36は、基幹中継ノード50cを起点としたウェイト番号を初期化する。ノードN4において基幹中継ノード50cを起点とするウェイト番号テーブル33は、図18(b)に示すように更新される。
(53)ノードN12では、基幹中継ノード50a~50cのいずれの基幹中継ノード50を起点としたウェイト番号もノードN5よりも大きい。このため、ノードN12では、基幹中継ノード50a~50cのいずれの基幹中継ノード50を起点としたウェイト番号も初期化される。ノードN12において基幹中継ノード50cを起点とするウェイト番号テーブル33は、図18(c)に示すように更新される。
(54)ノードN4の初期化要求部37は、故障したノードを介したフレームの送信を依頼されることを防ぐために、初期化要求を行う。初期化要求部37は、障害検出部36で初期化したウェイト番号の基点と同じ基幹中継ノード50が起点とされたウェイト番号が、自ノードに設定されていたウェイト番号よりも大きい場合、そのウェイト番号の初期化要求を行う。例えば、ノードN4は、基幹中継ノード50cを起点としたウェイト番号を初期化したので、初期化要求部37は、基幹中継ノード50cに対応するウェイト番号テーブル33を確認する。初期化要求部37は、基幹中継ノード50cに対応するウェイト番号テーブル33において、初期化の前のノードN4のウェイト番号よりも大きなウェイト番号が設定されているポートから、基幹中継ノード50cを起点とするウェイト番号の初期化を要求する。図19(a)の例では、ノードN4の初期化要求部37は、ノードN3に基幹中継ノード50cを起点としたウェイト番号の初期化を要求する。
ノードN3のウェイト番号生成部32は、基幹中継ノード50cを起点としたウェイト番号の初期化を要求されると、要求に応じてウェイト番号を初期化する。ノードN3において基幹中継ノード50cを起点とするウェイト番号テーブル33は、図19(b)に示すように更新される。また、基幹中継ノード50cを起点としたウェイト番号の初期化の要求を受けたことと、基幹中継ノード50cを起点としたノードN3の初期化前のウェイト番号を、初期化要求部37に通知しておく。
(55)ノードN12も、ノードN4と同様に初期化の要求を行う。このため、ノードN12では、基幹中継ノード50a~50cを起点としたウェイト番号の初期化をノードN19に求める。図19(d)に、ノードN19において基幹中継ノード50cを起点とするウェイト番号テーブル33の変更例を示す。なお、ノードN19でもノードN3と同様の処理が行われる。
(56)一方、ノードN12は、ノードN11に対して、基幹中継ノード50b、50cを起点としたウェイト番号の初期化を求める。図19(c)に、ノードN11において基幹中継ノード50cを起点とするウェイト番号テーブル33の変更例を示す。なお、ノードN11でもノードN3と同様の処理が行われる。
(57)ノードN3の初期化要求部37は、基幹中継ノード50cに対応付けられたウェイト番号テーブル33について、各ポートの出力先のノードのウェイト番号を、自ノードについて初期化の前に決定されていたウェイト番号と比較する。初期化要求部37は、比較の結果、自ノードの初期化の前のウェイト番号よりも大きなウェイト番号のノードに接続されているポートから、初期化の要求を出力する。ここでは、ノードN3は、ノードN2、N10に対して基幹中継ノード50cを起点としたウェイト番号の初期化を要求する。図20(a)は、ノードN10に対しての初期化の要求が行われた場合の様子を示す。また、図20(b)に、ノードN10において基幹中継ノード50cを起点とするウェイト番号テーブル33の変更例を示す。
(58)ノードN11の初期化要求部37は、ノードN3と同様の処理を行った結果、ノードN18に対して、基幹中継ノード50a~50cを起点としたウェイト番号の初期化を要求する。ノードN19の初期化要求部37も、ノードN18に対して、基幹中継ノード50a、50bを起点としたウェイト番号の初期化を要求する。また、図20(c)に、ノードN18において基幹中継ノード50cを起点とするウェイト番号テーブル33の変更例を示す。
(59)ノードN17も、ノードN10、N18から初期化の要求を受けると、図21(a)に示すようにウェイト番号テーブル33を変更する。また、図21(b)に、ノードN17において基幹中継ノード50cを起点とするウェイト番号テーブル33の変更例を示す。
(60)その他のセンサー中継ノード10においても同様にウェイト番号の変更が行われる。その結果、図22に示すようにウェイト番号が変更される。図22において、矢印の左側の値はノードN5の障害が発生する前に各センサー中継ノード10に割り当てられていたウェイト番号であり、矢印の右側の値はノードN5に障害が発生したことにより決定されたウェイト番号である。
(61)次に、ヘルスフレームを受信したセンサー中継ノード10は、ヘルスフレームに含まれている送信元ウェイト番号が初期値ではない場合、受信したウェイト番号に基づいて、自ノードのウェイト番号を変更する。ヘルスフレームに含まれている送信元ウェイト番号に基づいてウェイト番号を変更する方法は、図13BのステップS25~S29を参照しながら説明した方法と同様である。例えば、ノードN11から基幹中継ノード50aを起点としたウェイト番号が5であると、ノードN12のウェイト番号生成部32は、基幹中継ノード50aを起点としたノードN12のウェイト番号を6に決定する。図23に、ウェイト番号の変更の例を示す。
(62)手順(61)で変更されたウェイト番号に従って、選択部35は、中継先の基幹中継ノード50を決定する。中継先の基幹中継ノード50の選択方法は、図14を参照しながら説明した方法と同様である。さらに、中継先を変更した場合に新たな中継先として指定したことを基幹中継ノード50に通知する方法は、第2の実施形態と同様である。この例では、手順(61)の処理により、ノードN19は中継先を、基幹中継ノード50bから50cに変更する。
図24Aと図24Bは、隣接するセンサー中継ノード10が故障した場合のセンサー中継ノード10の動作の例を説明するフローチャートである。なお、図24Aと図24Bに示す処理は一例であり、例えば、ステップS92とS93の組合せ、ステップS94とS95の組合せ、および、ステップS96とS97の組合せの順序は任意に変更できる。障害検出部36は、ウェイト番号テーブル33のタイマーがタイムアウトするまでの間にフレームの送受信が無かった場合、タイムアウトしたポートに接続されているノードが故障したと判断する。そこで、障害検出部36は、処理対象とされた基幹中継ノード50の数を計数するための変数kを0に設定する(ステップS91)。障害検出部36は、タイムアウトしたタイマーはポートP1に対応付けられていたかを確認する(ステップS92)。ポートP1に対応付けられたタイマーがタイムアウトした場合、障害検出部36は、基幹中継番号=kのウェイト番号テーブル33において、ポートP1に接続されているノードのウェイト番号を初期化する(ステップS92でYes、ステップS93)。一方、ポートP1に対応付けられたタイマーがタイムアウトしていない場合、ポートP1に接続されているノードのウェイト番号は更新されない。
次に、障害検出部36は、タイムアウトしたタイマーはポートP2に対応付けられていたかを確認する(ステップS94)。ポートP2に対応するタイマーがタイムアウトした場合、障害検出部36は、基幹中継番号=kのウェイト番号テーブル33において、ポートP2に接続されているノードのウェイト番号を初期化する(ステップS94でYes、ステップS95)。さらに、障害検出部36は、タイムアウトしたタイマーはポートP3に対応付けられていたかを確認する(ステップS96)。ポートP3に対応付けられたタイマーがタイムアウトした場合、障害検出部36は、基幹中継番号=kのウェイト番号テーブル33において、ポートP3に接続されているノードのウェイト番号を初期化する(ステップS96でYes、ステップS97)。
次に、障害検出部36は、マスターポートに設定されていたポートでウェイト番号が初期化されているかを確認する(ステップS98)。マスターポートでウェイト番号が初期化されていることは、最短ホップ数が変更されることを意味する。そこで、マスターポートのウェイト番号が初期化されている場合、基幹中継番号=kの基幹中継ノード50を起点とした自ノードのウェイト番号を初期化し、マスターポートの設定も初期化する(ステップS99、S100)。その後、kの値を1つインクリメントして、基幹中継ノード50の総数から1つ引いた値とkの値を比較する(ステップS101、S102)。基幹中継ノード50の総数から1つ引いた値とkの値が一致するまでステップS91~S102の処理が繰り返される。基幹中継ノード50の総数から1つ引いた値とkの値が一致すると、センサー中継ノード10は、ウェイト番号を含むヘルスフレームを、隣接するセンサー中継ノード10に送信する(ステップS103)。ヘルスフレームを送受信することにより、ウェイト番号の初期化やウェイト番号の再決定が終わると、センサー中継ノード10は、得られたウェイト番号を用いて中継先の基幹中継ノード50を再決定する(ステップS104)。さらに、センサー中継ノード10は、変更後の基幹中継ノード50に向けて状態通知フレームを送信する(ステップS105)。基幹中継ノード50は、状態通知フレームを受信することにより、センサー中継ノード10において行われた基幹中継ノード50の変更を認識する。
このように、本実施形態によると、センサー中継ノード10に故障が発生した場合でも、正常に動作しているいずれのセンサー中継ノード10も最短ホップ数で到達できる基幹中継ノード50を中継先とし、最短ホップ数でのルーティングを行うことができる。
<第5の実施形態>
次に、センサー中継ノード10に障害が発生した場合に、基幹中継ノード50からの要求によってウェイト番号を設定する方法について説明する。
次に、センサー中継ノード10に障害が発生した場合に、基幹中継ノード50からの要求によってウェイト番号を設定する方法について説明する。
図25は、基幹中継ノード50が記憶するテーブルの例を示す図である。本実施形態では、基幹中継ノード50同士が制御情報を送受信することにより、全ての基幹中継ノード50が共通のテーブルを記憶する。このため、基幹中継ノード50は、管理対象ではないセンサー中継ノード10についても、そのセンサー中継ノード10を管理する基幹中継ノード50を認識している。例えば、図25では、基幹中継ノード50a(基幹中継番号=0)は、ノードN4が基幹中継ノード50b(基幹中継番号=1)に管理されていることを認識している。また、あるセンサー中継ノード10で故障が発生した場合、故障が発生したことを通知する情報を受信した基幹中継ノード50は、他の基幹中継ノード50に故障の発生を、故障したセンサー中継ノード10のIDと共に通知する。センサー中継ノード10での通知を認識すると、各基幹中継ノード50は、ウェイト番号の再決定を要求する。各センサー中継ノード10は、再決定されたウェイト番号に応じて中継先の基幹中継ノード50を決定する。
以下、具体例を挙げて、本実施形態で行われる動作を説明する。ここでも、図10に示すように中継先が選択されているときに、ノードN5のセンサー中継ノード10に障害が発生した場合の処理を例とする。
(71)ノードN5の障害が発生したことが検出は、第4の実施形態の手順(51)と同様に行われる。従って、ノードN4、N12、N6がノードN5での障害の発生を検出する。
(72)障害の発生を検出したセンサー中継ノード10は、そのセンサー中継ノード10が中継先としている基幹中継ノード50に対して、障害の発生を通知するフレーム送信する。障害の発生を通知するフレームは、障害が発生したセンサー中継ノード10をアドホックネットワークから削除することを要求するメッセージである。そこで、以下の記載では、障害の発生を通知するフレームのことを「削除通知」と記載する。削除通知を受信したセンサー中継ノード10は、基幹中継ノード50に向けて削除通知を転送する。
ここでは、ノードN4とN12は、基幹中継ノード50bに対して、ノードN5に障害が発生したことを通知する。一方、ノードN6は、基幹中継ノード50cに対して、ノードN5に障害が発生したことを通知する。
(73)障害の発生が通知された基幹中継ノード50bは、基幹中継ノード50aと50cに対して、ノードN5に障害が発生したことを通知する。また、基幹中継ノード50cも、ノードN6から削除通知を受信すると、基幹中継ノード50aと50bに対して、ノードN5に障害が発生したことを通知する。このため、ネットワーク中の基幹中継ノード50a~50cの各々は、ノードN5での障害の発生を認識する。
(74)ノードN5で障害が発生したことが通知されると、基幹中継ノード50は、同期要求フレームを用いて、各センサー中継ノード10にウェイト番号の再設定を要求する。ウェイト番号の決定方法は、第1の実施形態で説明した方法と同様である。ただし、ここでは、ノードN5に障害が発生しているので、ノードN5からは同期要求フレームが出力されない。図26に、基幹中継ノード50cから出力された同期要求フレームに基づいてウェイト番号が再決定された場合の例を示す。
(75)基幹中継ノード50a、50bも同様に、センサー中継ノード10に同期要求フレームを出力することにより、ウェイト番号の再決定を要求する。図27に、基幹中継ノード50a~50cの各々を起点としたときのウェイト番号が再決定された場合の例を示す。
(76)ウェイト番号が決定されると、選択部35は、中継先とする基幹中継ノード50を決定する。中継先の基幹中継ノード50の選択方法は、図14を参照しながら説明した方法と同様である。さらに、中継先を変更した場合に新たな中継先として指定したことを基幹中継ノード50に通知する方法は、第2の実施形態と同様である。図27の例でも、ノードN5の障害に基づいて経路が変更されるため、ノードN19は中継先を、基幹中継ノード50bから50cに変更する。
図28は、第5の実施形態でのセンサー中継ノード10の動作の例を説明するフローチャートである。センサー中継ノード10は、隣接するセンサー中継ノード10で障害が発生したことを検出したかを判定する(ステップS111)。隣接するセンサー中継ノード10での障害の発生を検出していない場合、隣接するセンサー中継ノード10からタイムアウトの前にヘルスフレームを受信できたかを判定する(ステップS111でNo、ステップS112)。タイムアウトの前にヘルスフレームを受信できた場合、センサー中継ノード10は、ステップS111の処理に戻る(ステップS112でYes)。タイムアウト前にヘルスフレームを受信できなかった場合、センサー中継ノード10は、基幹中継ノード50に削除通知を送信する(ステップS112でYes、ステップS113)。ここで、削除通知には、ヘルスフレームを受信できなかったセンサー中継ノード10を識別する識別子が含まれているものとする。また、ステップS111で隣接するセンサー中継ノード10での障害の発生を検出した場合も、センサー中継ノード10は、基幹中継ノード50に削除通知を送信する(ステップS111でYes、ステップS113)。その後、センサー中継ノード10は、基幹中継ノード50から同期要求フレームを受信するまで待機する(ステップS114)。同期要求フレームを受信すると、センサー中継ノード10は、ウェイト番号を再決定する(ステップS115)。ウェイト番号の再決定は、第1の実施形態でウェイト番号を決定した場合と同様に行われる。その後、センサー中継ノード10は、再決定したウェイト番号に基づいて、中継先の基幹中継ノード50を決定し、状態通知フレームを送信する(ステップS116)。
図29は、第5の実施形態での基幹中継ノード50の動作の例を説明するフローチャートである。基幹中継ノード50は、センサー中継ノード10から削除通知を受信したかを判定する(ステップS121)。削除通知を受信していない場合、基幹中継ノード50は、他の基幹中継ノード50から、削除同期化通知を受信したかを確認する(ステップS122)。ここで、「削除同期化通知」は、センサー中継ノード10の故障を認識した基幹中継ノード50が、他の基幹中継ノード50にセンサー中継ノード10の障害を通知するために用いる制御フレームである。削除同期化通知には、障害が発生したセンサー中継ノード10の識別子が含まれている。削除同期化通知を受信していない場合、基幹中継ノード50は、基幹中継ノード50と接続されているセンサー中継ノード10との間でヘルスフレームの応答がタイムアウトしていないかを確認する(ステップS123)。ヘルスフレームの応答がタイムアウトしていない場合、基幹中継ノード50は、ステップS121に戻る(ステップS123でNo)。一方、ステップS121~S123のいずれかでYesと判定された場合、基幹中継ノード50は、他の基幹中継ノード50に削除同期化通知を送信する(ステップS124)。その後、基幹中継ノード50は、センサー中継ノード10に同期要求フレームを送信し、ウェイト番号の再決定を要求する(ステップS125)。基幹中継ノード50は、センサー中継ノード10から同期応答フレームを受信する。さらに、基幹中継ノード50は、受信した同期応答フレームを、他の基幹中継ノード50にも転送する。各基幹中継ノード50は、アドホックネットワークに含まれる全てのセンサー中継ノード10からの同期応答フレームを受信するまで、同期応答フレームの受信と転送を繰り返す(ステップS126)。全てのセンサー中継ノード10からの同期応答フレームを受信すると、基幹中継ノード50はステップS121以降の処理を繰り返す(ステップS126でYes)。
<その他>
なお、実施形態は上記に限られるものではなく、様々に変形可能である。以下にその例をいくつか述べる。
なお、実施形態は上記に限られるものではなく、様々に変形可能である。以下にその例をいくつか述べる。
図30は、中継先の基幹中継ノード50を選択する際の選択部35の動作の例を説明するフローチャートである。選択部35は、ネットワーク中の全ての基幹中継ノード50を起点としたウェイト番号が決定されると、選択部35は、最小のウェイト番号を示す変数mに0xFFを設定する(ステップS131)。また、選択部35は、中継先に選択される基幹中継ノード50に割り振られた基幹中継番号を特定するための変数nを、基幹中継ノード50の総数に設定する(ステップS132)。次に、選択部35は、基幹中継番号=nの基幹中継ノード50を起点としたときのウェイト番号がmより小さいかを判定する(ステップS133)。基幹中継番号=nの基幹中継ノード50を起点としたときのウェイト番号がmより小さい場合、選択部35は、基幹中継番号=nの基幹中継ノード50を起点としたときのウェイト番号をmの値に設定する(ステップS134)。次に、選択部35は、nの値を1つデクリメントする(ステップS135)。一方、基幹中継番号=nの基幹中継ノード50を起点としたときのウェイト番号がm以上である場合(ステップS133でNo)、ステップS134とS135の処理は行われない。選択部35は、nの値が1になるまでステップS83~S86の処理を繰り返す。nの値が1になると、選択部35は、nに設定されている値と同じ基幹中継番号が割り振られている基幹中継ノード50を中継先に選択する。
さらに、ヘルスフレームのフォーマットを図7(f)に示すように変形することもできる。図7(f)に示すヘルスフレームでは、ネットワーク中の複数の基幹中継ノード50各々を起点としたときのウェイト番号を一度に1つのフレームで送信できる。なお、この場合、フレーム中のウェイト番号の順序と基幹中継ノード50が一意に対応付けられるように予めフォーマットが決定されているものとする。
また、センサー中継ノード10が自律的にウェイト番号を変更する場合でも、センサー中継ノード10が基幹中継ノード50に削除要求を送信するように変形される場合もある。図31は、センサー中継ノード10の動作の例を示すフローチャートである。ステップS141~S143は、図28を参照しながら説明したステップS111~113と同様である。次に、センサー中継ノード10は、障害が検出されたポートをマスターポートとしてウェイト番号が設定されているかを確認する(ステップS144)。障害が検出されたポートがマスターポートであった場合、センサー中継ノード10は、マスターポートを未使用に更新し、さらに、自ノードのウェイト番号を初期値に更新する(ステップS145、S146)。センサー中継ノード10は、全てのポートからヘルスフレームを送信する(ステップS147)。さらに、センサー中継ノード10の各ポートに接続されている接続先のウェイト番号を比較して、ウェイト番号が小さいポートを特定する(ステップS148)。センサー中継ノード10は、特定したポートの接続先のウェイト番号を1つインクリメントした値を自ノードのウェイト番号とする(ステップS149)。また、センサー中継ノード10は、マスターポートを、ステップS148で特定したポートに設定する(ステップS150)。センサー中継ノード10は、自ノードのウェイト番号を変更するなどの状態変化の後でヘルスフレームを送信していなければ、隣接するセンサー中継ノード10にヘルスフレームを送信する(ステップS151、S152)。また、センサー中継ノード10は、基幹中継ノード50に状態通知フレームを送信する(ステップS153)。その後、センサー中継ノード10は、全てのポートからヘルスフレームを受信できたかを確認し、受信が終了していれば、ステップS141に戻る(ステップS154でYes)。一方、ヘルスフレームの受信が終了していない場合、センサー中継ノード10は、ヘルスフレームの受信を待ってステップS144以降の処理を繰り返す(ステップS155)。
1 サーバ
5 ハブ
10 センサー中継ノード
11 有線アドホックネットワークポート
12 汎用ポート
13 DI/DO端子
14 EEPROM
15 センサー接続ポート
20 アドホックルーティング制御デバイス
21 受信フレーム制御部
22 送信フレーム制御部
23 汎用ポート制御部
24 CPUインタフェース
25 レジスタ
26 フレーム処理部
27 FIDテーブル
28 PSテーブル
29 ノード管理テーブル
30 ルーティング制御部
31 ウェイト番号制御部
32 ウェイト番号生成部
33 ウェイト番号テーブル
34 記憶部
35 選択部
36 障害検出部
37 初期化要求部
38 ルーティング部
40 CPU
41 FPGAインタフェース
42 DI/DOインタフェース
43 センサーインタフェース
5 ハブ
10 センサー中継ノード
11 有線アドホックネットワークポート
12 汎用ポート
13 DI/DO端子
14 EEPROM
15 センサー接続ポート
20 アドホックルーティング制御デバイス
21 受信フレーム制御部
22 送信フレーム制御部
23 汎用ポート制御部
24 CPUインタフェース
25 レジスタ
26 フレーム処理部
27 FIDテーブル
28 PSテーブル
29 ノード管理テーブル
30 ルーティング制御部
31 ウェイト番号制御部
32 ウェイト番号生成部
33 ウェイト番号テーブル
34 記憶部
35 選択部
36 障害検出部
37 初期化要求部
38 ルーティング部
40 CPU
41 FPGAインタフェース
42 DI/DOインタフェース
43 センサーインタフェース
Claims (12)
- サーバとの間が複数の中継装置によって中継可能なように構成されているネットワーク中のノード装置であって、
隣接ノード装置からフレームを受信する受信部と、
前記複数の中継装置の中のそれぞれの中継装置を起点としたときの前記隣接ノード装置までのホップ数が、前記隣接ノード装置からの同期要求と共に通知されると、前記ホップ数をインクリメントしたウェイト番号を前記中継装置ごとに生成するウェイト番号生成部と、
生成された前記ウェイト番号を前記中継装置を識別する識別子と対応付けてそれぞれ記憶する記憶部と、
前記記憶部に記憶されているウェイト番号が相対的に小さい中継装置を選択する選択部と、
選択された中継装置を中継先に指定し、前記サーバを宛先に指定したデータフレームを送信する送信部
を備えることを特徴とするノード装置。 - 前記受信部で受信された受信フレームから、前記受信フレームの宛先である宛先ノード装置に割り振られた宛先ウェイト番号と、前記宛先ウェイト番号の起点とされた中継装置を識別する宛先識別子を取得し、前記宛先識別子に対応付けて前記記憶部に記憶されているウェイト番号を前記宛先ウェイト番号と比較した結果により、前記受信フレームのルーティングを行うルーティング部をさらに備え、
前記宛先ウェイト番号のほうが大きい場合、前記ルーティング部は、前記宛先識別子で識別される中継装置を起点としたウェイト番号が前記記憶部に記憶されているウェイト番号よりも大きな隣接ノード装置に、前記受信フレームを送信できるかを判定し、
前記受信フレームが送信できないと判定した場合、前記ルーティング部は、ループを検出したと判断する
ことを特徴とする請求項1に記載のノード装置。 - 前記宛先ウェイト番号のほうが小さい場合、前記ルーティング部は、前記宛先識別子で識別される中継装置を起点としたウェイト番号が前記記憶部に記憶されているウェイト番号よりも小さな隣接ノード装置に、前記受信フレームを送信できるかを判定し、
前記受信フレームが送信できないと判定した場合、前記ルーティング部は、ループを検出したと判断する
ことを特徴とする請求項2に記載のノード装置。 - 前記隣接ノード装置の通信状態を監視すると共に、通信障害を検出する障害検出部
を備え、
前記障害検出部により通信障害が検出されると、前記ウェイト番号生成部は、前記記憶部に記憶されている前記通信障害が検出された隣接ノードから受信した同期要求を用いて生成された生成ウェイト番号を初期値に変更し、
前記選択部は、対応付けられている生成ウェイト番号が前記初期値ではない中継装置の中で、前記対応付けられている生成ウェイト番号が相対的に小さい中継装置を選択する
ことを特徴とする請求項1~3のいずれか1項に記載のノード装置。 - 複数のネットワークポートを備え、
前記記憶部には、前記複数のネットワークポートを介して接続されている複数の隣接ノード装置について、前記複数の隣接ノードの各々で生成されたウェイト番号である隣接ウェイト番号を、前記隣接ウェイト番号の生成に用いられたホップ数をカウントする際の起点とされた中継装置を識別する識別子、および、前記隣接ウェイト番号を含むフレームを受信したネットワークポートの番号に対応付けて記録されており、
前記障害検出部により通信障害が検出されたときに、前記通信障害を起こしていない隣接ノード装置についての中継装置を起点とした隣接ウェイト番号が前記中継装置を起点とした生成ウェイト番号よりも大きいポートから、前記中継装置を起点とするウェイト番号の初期化を要求するフレームを生成する初期化要求部
をさらに備え、
前記送信部が前記初期化を要求するフレームを送信する
ことを特徴とする請求項4に記載のノード装置。 - 前記複数の中継装置のうちの第1の中継装置と前記サーバの間で通信障害が発生したことが通知されると、前記初期化要求部は、前記隣接ノード装置に、前記第1の中継装置に対応付けられたウェイト番号の初期化を要求するフレームを生成し、
前記ウェイト番号生成部は、前記第1の中継装置に対応付けられているウェイト番号を初期化する
ことを特徴とする請求項5に記載のノード装置。 - データの宛先であるサーバとの間が複数の中継装置によって中継可能なように構成されているネットワークに所属する第1のノード装置に隣接する第2のノード装置による通信方法であって、
前記第1のノード装置から、同期の要求とともに、前記複数の中継装置の中の第1の中継装置から前記第1のノード装置までのホップ数である第1のウェイト番号が通知されると、前記第1のウェイト番号をインクリメントして第2のウェイト番号を生成し、
前記第2のウェイト番号を前記第1の中継装置を識別する第1の識別子に対応付けて記憶し、
前記第2のノード装置に隣接する第3のノード装置から、同期の要求とともに、前記複数の中継装置の中の第2の中継装置から前記第3のノード装置までのホップ数である第3のウェイト番号が通知されると、前記第3のウェイト番号をインクリメントして第4のウェイト番号を生成し、
前記第4のウェイト番号を前記第2の中継装置を識別する第2の識別子に対応付けて記憶し、
前記第2のウェイト番号が前記第4のウェイト番号より小さい場合、前記第2のノード装置は、前記第1の中継装置を中継先に指定して、データフレームを前記サーバに送信する
ことを特徴とする通信方法。 - 前記第1のノード装置は、前記第1の中継装置から前記第1のノード装置に隣接する第4のノード装置までのホップ数である第5のウェイト番号を、前記第4のノード装置から取得し、
前記第1のノード装置は、前記第2のノード装置から前記データフレームを受信すると、前記第1のウェイト番号と前記第5のウェイト番号を比較し、
前記第5のウェイト番号が前記第1のウェイト番号より小さい場合、前記第1のノード装置は、前記データフレームを前記第4のノード装置に転送する
ことを特徴とする請求項7に記載の通信方法。 - 前記第1のノード装置は、前記第1の中継装置を起点としたホップ数が前記第1のウェイト番号よりも小さいノード装置に、前記第2のノード装置から受信したデータフレームを送信できない場合、前記データフレームを前記第2のノード装置に送信し、
前記第2のノード装置は、前記サーバを宛先としたフレームに対応付けた前記第1のノード装置に接続したポートの状態を、ループ状態に設定する
ことを特徴とする請求項8に記載の通信方法。 - 前記第1の中継装置と前記サーバの間で通信障害が発生すると、前記第1の中継装置は、前記第1の中継装置を起点とするホップ数を用いて算出されたウェイト番号の初期化を要求する初期化フレームをブロードキャスト送信し、
前記第2のノード装置は、前記初期化フレームを受信すると、前記第2のウェイト番号を初期値に設定すると共に、前記サーバに宛てたフレームの中継先に前記第1の中継装置を指定しない
ことを特徴とする請求項7~9のいずれか1項に記載の通信方法。 - 前記第2のノード装置は、前記第3のノード装置に同期を求める際に、前記第2のウェイト番号を前記第1の中継装置に対応付けて前記第3のノード装置に通知し、
前記第3のノード装置は、前記第2のウェイト番号をインクリメントして得られた第6のウェイト番号を前記第1の中継装置と対応付けて記憶し、
前記第2のノード装置で障害が発生すると、前記第3のノード装置は、前記第2のウェイト番号と前記第6のウェイト番号を比較し、
前記第3のノード装置は、前記第6のウェイト番号が前記第2のウェイト番号よりも大きいことを認識すると、前記第6のウェイト番号を初期値に設定すると共に、前記第1の中継装置を前記サーバ宛てのフレームを送信する際の中継先に指定しない
ことを特徴とする請求項7~10のいずれか1項に記載の通信方法。 - 前記第2のノード装置は、前記第1のノード装置に通信障害が発生すると、前記第1のノード装置に前記通信障害が発生したことを、前記第1の中継装置に通知し、
前記第1の中継装置は、前記第1のノード装置で通信障害が発生したことを前記第2の中継装置に通知し、
前記第1の中継装置は、前記第1の中継装置を起点とするホップ数を用いて算出されたウェイト番号の再計算を要求するフレームをブロードキャストし、
前記第2の中継装置は、前記第2の中継装置を起点とするホップ数を用いて算出されたウェイト番号の再計算を要求するフレームをブロードキャストし、
前記第2のノード装置は、新たに計算されたウェイト番号を用いて、前記サーバとの間の通信の中継先を決定する
ことを特徴とする請求項7~11のいずれか1項に記載の通信方法。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/JP2011/071401 WO2013042207A1 (ja) | 2011-09-20 | 2011-09-20 | ノード装置および通信方法 |
JP2013534491A JP5786948B2 (ja) | 2011-09-20 | 2011-09-20 | ノード装置および通信方法 |
US14/219,353 US20140204728A1 (en) | 2011-09-20 | 2014-03-19 | Node equipment and method for communication |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/JP2011/071401 WO2013042207A1 (ja) | 2011-09-20 | 2011-09-20 | ノード装置および通信方法 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/219,353 Continuation US20140204728A1 (en) | 2011-09-20 | 2014-03-19 | Node equipment and method for communication |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2013042207A1 true WO2013042207A1 (ja) | 2013-03-28 |
Family
ID=47914019
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2011/071401 WO2013042207A1 (ja) | 2011-09-20 | 2011-09-20 | ノード装置および通信方法 |
Country Status (3)
Country | Link |
---|---|
US (1) | US20140204728A1 (ja) |
JP (1) | JP5786948B2 (ja) |
WO (1) | WO2013042207A1 (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2016090758A1 (zh) * | 2014-12-08 | 2016-06-16 | 中国科学院声学研究所 | 一种树结构网络自治管理和节点加入方法 |
WO2023188860A1 (ja) * | 2022-03-29 | 2023-10-05 | 株式会社日立ハイテク | 分散システムおよび分散システムにおける通信経路作成方法 |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20150236911A1 (en) * | 2014-02-18 | 2015-08-20 | Aruba Networks, Inc. | Detecting characteristics of a data path loop on a network |
US9986585B2 (en) * | 2014-07-31 | 2018-05-29 | Conversant Intellectual Property Management Inc. | Relay systems and methods for wireless networks |
JP6459558B2 (ja) * | 2015-01-27 | 2019-01-30 | 富士通株式会社 | 無線通信装置、無線通信方法、および無線通信プログラム |
EP3311535B1 (en) | 2015-06-17 | 2019-10-02 | Telefonaktiebolaget LM Ericsson (PUBL) | Reducing latency in a mesh network |
CN107171820B (zh) * | 2016-03-08 | 2019-12-31 | 北京京东尚科信息技术有限公司 | 信息传输、发送、获取方法和装置 |
JP6791253B2 (ja) * | 2016-09-30 | 2020-11-25 | 富士通株式会社 | 通信制御プログラム、装置、及び方法 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH07177143A (ja) * | 1993-06-28 | 1995-07-14 | At & T Corp | リンクメトリック割当方法 |
JP2009188647A (ja) * | 2008-02-05 | 2009-08-20 | Sony Corp | 無線通信装置、通信システム、プログラム、および経路判断方法 |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
TWI276244B (en) * | 2004-06-04 | 2007-03-11 | Wistron Neweb Corp | Wireless communication device capable of switching antennas according to data transmission information on network |
JP4374307B2 (ja) * | 2004-10-20 | 2009-12-02 | 株式会社日立コミュニケーションテクノロジー | ラベルスイッチパスの経路制御方法 |
JP4622546B2 (ja) * | 2005-01-31 | 2011-02-02 | パナソニック株式会社 | 通信方法及び無線通信装置 |
US7944853B2 (en) * | 2006-01-06 | 2011-05-17 | Belair Networks Inc. | Virtual root bridge |
JP5088062B2 (ja) * | 2007-09-20 | 2012-12-05 | 横河電機株式会社 | 無線制御システム |
JP5088162B2 (ja) * | 2008-02-15 | 2012-12-05 | 富士通株式会社 | フレーム伝送装置およびループ判定方法 |
US20100014460A1 (en) * | 2008-07-11 | 2010-01-21 | Electronics And Telecommunications Research Institute | Sensor network mac system for multihop communication |
KR101208230B1 (ko) * | 2009-05-11 | 2012-12-05 | 후지쯔 가부시끼가이샤 | 노드 장치, 노드 장치의 실행 방법 및 프로그램을 기억한 컴퓨터 판독가능한 기억 매체 |
JP5664768B2 (ja) * | 2011-03-31 | 2015-02-04 | 富士通株式会社 | ノード、リンク形成方法およびリンク形成プログラム |
-
2011
- 2011-09-20 WO PCT/JP2011/071401 patent/WO2013042207A1/ja active Application Filing
- 2011-09-20 JP JP2013534491A patent/JP5786948B2/ja not_active Expired - Fee Related
-
2014
- 2014-03-19 US US14/219,353 patent/US20140204728A1/en not_active Abandoned
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH07177143A (ja) * | 1993-06-28 | 1995-07-14 | At & T Corp | リンクメトリック割当方法 |
JP2009188647A (ja) * | 2008-02-05 | 2009-08-20 | Sony Corp | 無線通信装置、通信システム、プログラム、および経路判断方法 |
Non-Patent Citations (2)
Title |
---|
HIROSHI NAGAZONO: "Cloud Jidai no Jisedai Datacenter, Technology for constructing environmentally friendly data centers and Fujitsu's approach", FUJITSU, vol. 61, no. 3, 10 May 2010 (2010-05-10), pages 241 - 246 * |
TOSHIHIDE MORIOKA ET AL.: "Gateway Selection Method for Traffic Reducion in Mobile Ad Hoc Networks", IEICE TECHNICAL REPORT, vol. 110, no. 448, 24 February 2011 (2011-02-24), pages 257 - 262 * |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2016090758A1 (zh) * | 2014-12-08 | 2016-06-16 | 中国科学院声学研究所 | 一种树结构网络自治管理和节点加入方法 |
WO2023188860A1 (ja) * | 2022-03-29 | 2023-10-05 | 株式会社日立ハイテク | 分散システムおよび分散システムにおける通信経路作成方法 |
Also Published As
Publication number | Publication date |
---|---|
JPWO2013042207A1 (ja) | 2015-03-26 |
JP5786948B2 (ja) | 2015-09-30 |
US20140204728A1 (en) | 2014-07-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5786948B2 (ja) | ノード装置および通信方法 | |
US10728094B2 (en) | Control traffic in software defined networks | |
US8672566B2 (en) | Node apparatus and communication method | |
JP5353882B2 (ja) | 中継装置およびネットワークシステム及び経路切替方法並びにプログラム | |
US9491089B2 (en) | Automatic aggregation of inter-device ports/links in a virtual device | |
JP4743201B2 (ja) | パケットリングネットワークシステム、パケットリング間の接続方法、およびリング間接続ノード | |
JP5115819B2 (ja) | Ipネットワークシステム | |
US10075366B2 (en) | Communication device, communication system, communication control method, and communication control program | |
JP5310956B2 (ja) | ネットワークにおけるルーティング方法及びノード装置 | |
JP6868958B2 (ja) | パケット送信プログラム、情報処理装置、および、障害検出方法 | |
JP2015192386A (ja) | データ転送制御装置、データ転送制御方法、及び、プログラム | |
WO2016135828A1 (ja) | 中継装置および通信システム | |
JP5954000B2 (ja) | 通信方法および通信装置 | |
JPWO2013042209A1 (ja) | データ転送方法およびそれを用いるノード装置 | |
KR102294197B1 (ko) | IoT 제어 네트워크의 자동 설정 방법 및 그 시스템 | |
US9325606B2 (en) | Communication system, communication route control method, and communication apparatus | |
JP2006157716A (ja) | ネットワークノード装置およびその経路情報更新方法 | |
JP5853227B2 (ja) | マルチホップ通信方法、マルチホップ通信システム、および通信端末 | |
KR101751891B1 (ko) | 오픈플로우 무선 메쉬 네트워크 환경에서의 오픈플로우 컨트롤러, 오픈플로우 컨트롤러의 토폴로지 디스커버리 방법, 오픈플로우 메쉬 장치 및 오픈플로우 메쉬 장치의 피어 탐지 방법 | |
WO2012132013A1 (ja) | ノード、リンク形成方法およびリンク形成プログラム | |
JP2009077285A (ja) | パケットリングネットワークシステム、およびフォワーディングデータベース管理方法 | |
JP6977604B2 (ja) | 無線通信装置、無線通信プログラム、無線通信方法、並びに、無線通信システム | |
JP2008154016A (ja) | 無線端末及び無線通信システム | |
JP5778357B2 (ja) | ネットワークシステムおよびその制御方法 | |
JP2013046245A (ja) | 監視システム、監視システムに用いる親端末、および子端末 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 11872831 Country of ref document: EP Kind code of ref document: A1 |
|
ENP | Entry into the national phase |
Ref document number: 2013534491 Country of ref document: JP Kind code of ref document: A |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 11872831 Country of ref document: EP Kind code of ref document: A1 |