WO2009130918A1 - ノード装置及びプログラム - Google Patents

ノード装置及びプログラム Download PDF

Info

Publication number
WO2009130918A1
WO2009130918A1 PCT/JP2009/001924 JP2009001924W WO2009130918A1 WO 2009130918 A1 WO2009130918 A1 WO 2009130918A1 JP 2009001924 W JP2009001924 W JP 2009001924W WO 2009130918 A1 WO2009130918 A1 WO 2009130918A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
frame
destination
node device
information
Prior art date
Application number
PCT/JP2009/001924
Other languages
English (en)
French (fr)
Inventor
岩尾忠重
増渕健太郎
中嶋千明
池本健太郎
古賀俊介
高橋勇治
Original Assignee
富士通株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 富士通株式会社 filed Critical 富士通株式会社
Priority to CA2721911A priority Critical patent/CA2721911C/en
Priority to EP09734953.4A priority patent/EP2273732B1/en
Priority to BRPI0911155A priority patent/BRPI0911155A2/pt
Priority to CN200980113894.2A priority patent/CN102017543B/zh
Priority to JP2010509093A priority patent/JP4888598B2/ja
Priority to AU2009239253A priority patent/AU2009239253B2/en
Publication of WO2009130918A1 publication Critical patent/WO2009130918A1/ja
Priority to US12/908,169 priority patent/US8817616B2/en

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/54Organization of routing tables
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • H04L45/021Ensuring consistency of routing table updates, e.g. by using epoch numbers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • H04L45/026Details of "hello" or keep-alive messages
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/26Route discovery packet
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04BTRANSMISSION
    • H04B7/00Radio transmission systems, i.e. using radiation field
    • H04B7/24Radio transmission systems, i.e. using radiation field for communication between two or more posts
    • H04B7/26Radio transmission systems, i.e. using radiation field for communication between two or more posts at least one of which is mobile
    • H04B7/2603Arrangements for wireless physical layer control
    • H04B7/2606Arrangements for base station coverage control, e.g. by using relays in tunnels
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W40/00Communication routing or communication path finding
    • H04W40/02Communication route or path selection, e.g. power-based or shortest path routing
    • H04W40/12Communication route or path selection, e.g. power-based or shortest path routing based on transmission quality or channel quality

Definitions

  • the present invention relates to a route selectable apparatus / program in a network including a plurality of nodes.
  • IP Internet Protocol
  • MPLS Multi-Protocol-Labeled Switching
  • AODV Alignment-Demand Vector
  • OLSR Optimized Link State Routing
  • routing is determined according to the IP address. Since the IP address itself has a tree structure, the frame can be finally transmitted to the target terminal by transmitting to the network device that manages the matching IP network from the top of the IP address. Routing is determined by an IP address system. Which network device manages which IP network is defined by a routing table. The routing table is often set manually, but may be automatically updated by RIP (Routing Information Protocol). RIP is a method in which an IP network managed by a network device is broadcast to the surroundings, and the network devices confirm each other's managed IP network.
  • RIP Central Information Protocol
  • LSR Label-Switch-Router
  • a frame from the external network is taken into the internal network by a network device called an edge node that extends over both the external network and the internal network.
  • a label is inserted at the head of the external frame.
  • Each LSR has a label transfer table.
  • the label transfer table holds the label of the input frame, the label of the output frame, and the destination.
  • the LSR takes out the label of the input frame, finds the corresponding label from the label transfer table, rewrites it to the label of the output frame, and sends it to the corresponding destination. This is performed by LDP (Label Distribution Protocol) of the label transfer table.
  • LDP Label Distribution Protocol
  • AODV is a technique in which another communication node device repeatedly broadcasts and finds a route to a target node device using broadcast for route search.
  • the communication node device sends a frame “Route Request (RREQ)” to the surroundings in order to find a target route.
  • RREQ Range Request
  • the communication node ID of the search target is specified.
  • the surrounding communication node device When the surrounding communication node device has not searched for itself, it newly creates an RREQ frame and repeats broadcasting to the surroundings. At this time, each communication node device records from which adjacent communication node device the source message is received.
  • the target communication node device When the RREQ message reaches the target communication node device, the target communication node device creates a “Route Reply (RREP)” frame, and sends the route through which the RREQ frame has been sent to the source node.
  • the RREP frame is transmitted as follows. In this way, a bidirectional communication path is created.
  • OLSR Optimized Link State Routing
  • MPR Multi (Point Relay).
  • MPR Multi (Point Relay)
  • TC Topic Control
  • the network topology known by the communication node device itself as the transmission source is referred to, and the frame is entrusted to the adjacent communication node device to be sent.
  • the adjacent node device performs the same process, and finally delivers the frame to the target node device.
  • each node broadcasts information including the presence of its own node as a hello message and the route metric to the own node, and receives the hello message.
  • a node adds a route metric for a route between a node that has broadcast a hello message and its own node to the received route metric and uses the route metric after the addition (for example, provided).
  • the route metric here is a value representing the cost between the transmission source and the destination, which is calculated based on factors such as the number of hops and link quality.
  • the premise is that the network itself has a structure depending on the address. Since the IP address has a tree structure, the route is determined by selecting the direction in which the address matches from the top. These are based on a wired connection. Wired connection between the two communication terminals can be performed stably, and a communication device that is not connected does not receive a frame. Therefore, it can be determined simply by the number of hops of the communication device.
  • wireless communication when wireless communication is assumed, it is difficult to create a route with good communication quality with these methods.
  • communication quality is poor compared to wired communication, and affects other communication terminals that are not directly related to communication.
  • Communication quality is highly dependent on distance and surrounding environment, and is subject to temporal changes.
  • the algorithm may try to pass through a distant communication terminal if it is determined only by the number of hops.
  • the communication quality is correspondingly low, so a very poor quality route is created.
  • AODV places a load on the network when creating a route. There is no problem when the number of communication terminals is small, but when the number of communication terminals increases and the amount of communication increases, the load on the network increases. As a result, communication node devices that have already established communication are also affected, and there is a high possibility that a link break will occur. As a result, the number of node devices that can communicate is very small, and most of them cannot establish a route. Moreover, since the number of hops is based as described above, a route with poor communication quality may be created.
  • OLSR In OLSR, all node devices need to know the network topology. This limits the scale. Also, it takes time to determine the topology of all node devices. As described above, regardless of wired wireless communication, the communication quality between node devices may change due to the amount of communication and the influence of the surrounding environment. For this reason, when a network including a very large number of node devices is considered, it is not practical to install a server that controls the network and manage the network by the server. This is because there are a large number of node devices, so even if a control instruction is transmitted from the server, a heavy load is imposed. Therefore, when a network is made up of a large number of node devices, it is desired that each node device autonomously performs operations such as route selection and alive monitoring.
  • each node device when relaying a transmission frame addressed to a certain node device, the currently effective route is set to each node.
  • the device needs to know. For example, methods such as network with a fixed structure and binary tree search, which is a general search method, know the entire network and tree from the beginning, so it is easy to determine how far the route has been searched.
  • methods such as network with a fixed structure and binary tree search, which is a general search method, know the entire network and tree from the beginning, so it is easy to determine how far the route has been searched.
  • each node device knows which node device is linked ahead of surrounding node devices. Since there is not, a mechanism is needed to know how far the route has been searched.
  • the present invention provides a node device / program having a simple structure and capable of autonomously selecting an appropriate route without imposing a load on the network.
  • the node device includes identification information for uniquely identifying a frame as information of a frame transmitted by the node in the node device in a network including a plurality of node devices, and the frame information.
  • An identification information management table for storing information about destination nodes, a weighting table for each destination node for storing weighting information about other nodes as destinations for relaying frames for each final destination node of the frame, and other nodes Corresponding to the identification information when the frame receiving means for receiving the frame transmitted to the own node from the frame and the identification information of the frame received by the frame receiving means are stored in the identification information management table For the destination node stored attached, it corresponds to the final destination of the frame.
  • Frame destination determination means for determining a destination node for relaying the frame with reference to the weighting table for each destination node corresponding to the final destination node.
  • the node to be transferred is determined with reference to the weighting table for each destination node.
  • the transfer destination node is determined according to the weight, and the weight is updated according to the success or failure of the frame transfer to another node.
  • the node device can learn the route autonomously.
  • the destination node-by-destination weighting table updating means stores the sending information stored in association with the identification information when the identification information of the frame received by the frame receiving means is stored in the identification information management table. For the destination node, the weight for the destination node in the weighting table for each destination node corresponding to the final destination of the frame may be updated so that the priority becomes lower.
  • an adjacent node management table that stores information related to other nodes existing around the own node, information that informs the presence of the own node as a hello message, and information read from the adjacent node management table, Based on information on a source node of a hello message received by the hello message receiving means, a hello message receiving means for receiving a hello message transmitted from another node, and a hello message receiving means for transmitting a hello message transmitted from another node.
  • an adjacent node management table update means for updating the adjacent node management table, and when the first node in a predetermined state is detected in the adjacent node management table, the weighting for each destination node
  • the table updating means is a weight for each destination node Only the destination node table may be updated data is a node of the first such priority is lowered.
  • each node device refers to the information about the weight held and determines the transfer destination node, and the weight Update information about. This makes it possible to autonomously learn the optimal route and perform communication without grasping the entire network.
  • FIG. 1 is an overall conceptual diagram of a communication system. It is the schematic of the node apparatus which concerns on embodiment of this invention. It is a detailed schematic diagram of a node device according to an embodiment of the present invention. It is a figure which shows the structure of an adjacent node management table. It is a frame format example. 6 is a description of a format example of the frame in FIG. 5. It is a figure explaining the data transfer process based on an adjacent node management table. It is a figure explaining the process which operates the information regarding a weight with the transfer result of a flame
  • a “frame” refers to a data unit handled by a protocol.
  • “Frame” includes, for example, “hello frame” and “data frame”, but is not limited thereto.
  • Hazier frame refers to a special frame transmitted from a node device according to an embodiment of the present invention to another node device to confirm each other's existence and state.
  • Data frame refers to data that the network intends to transmit (from the start node to the goal node).
  • the node device according to the embodiment of the present invention can have appropriate means for distinguishing between a “hello frame” and a “data frame”.
  • LD Local Destination
  • LD refers to a destination node ID representing an adjacent node device to which a frame is to be passed next when a certain node device is viewed as a subject.
  • the LD may be referred to as a “local destination address”.
  • “Local Source (LS)” refers to the node ID that represents the node device that directly sends the frame to the LD (that is, the local node device for the LD). In the present specification, LS may be referred to as “local source address”.
  • Global Destination refers to the node ID that is the final destination for a series of propagation of data frames across the network. In the present specification, GD may be referred to as “global destination address”.
  • Global Source refers to the node ID that is the first source for a series of propagations across the network of data frames. In the present specification, GS may be referred to as “global source address”.
  • “Frame ID (FID)” is unique identification information of each frame. For example, a series of numbers can be used as the FID, but the FID is not limited thereto.
  • the “weight” is a value that is considered when selecting a frame propagation path according to the embodiment of the present invention. Examples of weights include return link weights, forward link weights, bidirectional link weights, route quality weights, return route quality weights, and interlink arrival weights, but are not limited thereto. In the description of the present specification, the term “weight” or “information about weight” should be interpreted as referring to a value calculated using some kind of weight.
  • Return link weight refers to the weight associated with the frame that is on the return path.
  • the “outward link weight” is a weight related to a frame going on the forward path.
  • the “bidirectional link weight” is a weight calculated by combining the forward link weight and the return link weight described above.
  • “inbound link weight”, “outbound link weight”, and “bidirectional link weight” are data that can be included in an adjacent node management table described in detail later. However, in other embodiments, other combinations may be included.
  • Ring quality weight refers to the numerical value of the delay on the route to GD.
  • the “return path quality weight” refers to a numerical value of communication quality in a direction from the partner node device to the own node device.
  • Interlink arrival weight is a value obtained by quantifying the success or failure of transfer between links of a frame.
  • route quality weight “return route quality weight”, and “interlink arrival weight” are data that can be included in a weighting table described in detail later. However, in other embodiments, other combinations may be included.
  • FIG. 1 is an overall conceptual diagram of a communication system.
  • the network includes node devices (a, b,..., S, t) connected to each other.
  • each node device operates as a relay when transmitting information from the start node (node device b in the example of FIG. 1) to the goal node (node device t in the example of FIG. 1).
  • Each node device has its own identification information (ID, Identification).
  • ID assigned to each node device is hereinafter referred to as a node ID.
  • Each node device does not grasp node devices adjacent to each other or the entire network. In the initial state, there is no mutual link, and each node device does not grasp the presence / state of node devices other than itself.
  • detection of surrounding node devices is performed.
  • a certain node device periodically notifies its own existence to a node device existing in the vicinity.
  • Information related to route creation is attached to the notification to the neighboring node device.
  • each node device can create a list of the surrounding node devices and grasp the presence of the surrounding node devices.
  • the node device that detects the surrounding node device determines a node device to which information is to be transferred based on the created list, and transfers the information to the node device.
  • a node device decides a node device to which information is to be transferred, which node device should be entrusted with information among a plurality of node devices existing in the vicinity, can the information reach the target goal node? This node device is still unknown at this point. Therefore, in the node device according to the present embodiment, a weighting table indicating which of the surrounding node devices should be preferentially transferred information is created, and information transfer is performed according to the information regarding the weight stored in the weighting table. The node device to be the target of the determination is determined.
  • FIG. 2 is a schematic diagram of the node device according to the present embodiment.
  • a node device 1 whose outline is roughly shown in FIG. 2 includes a frame processing unit 2, a link management unit 3, a routing determination unit 4, an FID (frame ID) management table 5, an adjacent node management table 6, and a weighting table 7.
  • any type of storage device eg, DRAM or flash memory
  • includes an FID (frame ID) management table 5, an adjacent node management table 6, and a weighting table. 7 can be stored as a data table.
  • the frame processing unit 2 processes a data frame exchanged with a node device adjacent to the node device 1.
  • the frame processing unit 2 accesses a storage device (not shown in FIG. 2) and uses the FID management table 5 (corresponding to the identification information management table in the claims), and loops. It also detects the occurrence of
  • the link management unit 3 accesses a storage device (not shown in FIG. 2) and uses the adjacent node management table 6 to manage the aliveness and link strength of the adjacent node device.
  • the routing determination unit 4 accesses the storage device (not shown in FIG. 2), refers to the weighting table 7 (corresponding to the weighting table for each destination node in the claims), and then specifies the frame to which adjacent node device Decide what to transfer.
  • the weighting table 7 is created for each final destination (ie, Global Destination (GD)) of the frame.
  • Each of the plurality of node devices constructing the network shown in FIG. 1 has a structure as shown in FIG. 2, but in the following description, the node device is distinguished from other node devices. The description is given with “1” or “1a”. Each node device may be connected wirelessly or may be connected by wire. If desired, the embodiment of the present invention also assumes that the apparatus or program according to the embodiment of the present invention can be applied to a network in which wireless and wired are mixed.
  • FIG. 3 is a more detailed schematic diagram for further explaining the node device according to the embodiment.
  • the suffix “a” attached to the reference number refers to a component that is the same as or similar to the component of the same number. In the present specification, for example, both a device XXX and a device XXXa can be included in the embodiment.
  • the suffix of a reference number is abbreviate
  • the FID management table 5a, the adjacent node management table 6a, and the weighting table 7a can be stored in any appropriate storage device.
  • the storage device can be stored inside the node device 1a or can be installed outside. Further, such a storage device may be single for each node device, or a plurality of storage devices may exist.
  • the frame branching processing unit 12 identifies the type of the frame and performs processing according to the type. Fork. As will be described in detail later, the frame branch processing unit 12 can use an identifier for indicating the type of the frame attached to the frame.
  • the frame branch processing unit 12 passes the frame to the link management unit 3a.
  • the link management unit 3a accesses the storage device storing the adjacent node management table 6a, and manages the aliveness and link strength of the adjacent node device.
  • the link management unit 3a accesses the storage device that stores the weighting table 7a, and registers or updates information related to the weight (details will be described later).
  • the frame branch processing unit 12 passes the frame to the frame processing unit 2a.
  • the frame processing unit 2a accesses the storage device storing the FID management table 5a, and manages information related to the FID, LD, and GS.
  • the frame processing unit 2a passes the frame to the routing determination unit 4a.
  • the frame processing unit 2a accesses the storage device that stores the weighting table 7a, and registers or updates information about the weight (details will be described later).
  • the routing determination unit 4a accesses the storage device storing the weighting table 7a to obtain information on the weight, and then determines which node device to transmit the frame to. Then, the frame is passed to the transmission unit 20.
  • the transmission unit 20 When transmitting the frame received from the routing determination unit 4a to another node device, the transmission unit 20 causes the transmission processing unit 22 to access the storage device storing the FID management table 5a, and obtains information on the FID, LD, and GS. Register / update.
  • tables such as an adjacent node device management table, an FID (frame ID) management table, and a weighting table are used.
  • FIG. 4 is a diagram showing the structure of the adjacent node management table 6 or 6a.
  • the adjacent node management table 6 or 6a includes the node ID, the last update time, and the link strength.
  • the node ID is identification information assigned to each node device in order to identify the node device that constructs the network.
  • the last update time is the date and time information when the information was last updated for the node device indicated by each node ID. Specifically, for example, date information when the link strength is updated can be stored as the last update time.
  • the link strength is calculated based on the link strength included in the hello frame received by the node device 1 or 1a from the adjacent node device, and stored in an appropriate storage device.
  • the link strength can be calculated using, for example, the radio wave strength or the frame arrival rate.
  • the link strength corresponds to, for example, a bidirectional link weight.
  • a notification frame (hello frame) is exchanged between adjacent nodes in order to construct a network in advance. Then, the adjacent node management table 6 shown in FIG. 2 or the adjacent node management table 6a shown in FIG. 3, and the weighting table 7 shown in FIG. 2 or the weighting table 7a shown in FIG. As described in the description of FIG. 1, the node device 1 according to the present embodiment does not need to grasp the network topology.
  • a node device to which a frame is to be transferred is determined among the adjacent nodes storing information corresponding to the adjacent node management table 6 or 6a.
  • the weighting table 7 that is referred to when determining the node device to which the frame is to be transferred is updated in the process after the frame is received from the adjacent node device.
  • the frame shown in FIG. 5 includes the node ID (LD) for the destination node (Local Destination) of the adjacent node, the node ID (LS) for the transmission source node (Local Source) of the adjacent node, and the destination node (Global Destination).
  • the node ID (GD), the node ID (GS) for the transmission source node (Global (Source), the frame ID (FID), the frame type (TYPE), the data length (DATALEN), and the data body (DATA) are included.
  • LD stores the node ID of the destination node that transfers the frame among the adjacent nodes of the node device 1.
  • LSL stores the node ID of the source node device that transfers the frame to the adjacent node device serving as the LD. For example, if the LD is a node ID of one of the node devices adjacent to the node device 1, the LS is the node ID of the node device 1.
  • GD stores the original destination node ID of the frame
  • GS stores the original source node ID of the frame.
  • the frame ID stores identification information for identifying a frame.
  • the frame type stores information indicating the type of the frame. Examples of the frame type include, but are not limited to, a data frame and a hello frame.
  • the data length stores the length of the data body (also referred to as data length or frame size).
  • FIG. 7 is a diagram illustrating frame transfer processing based on the adjacent node management table 6 or 6a according to an embodiment.
  • FIG. 7A is a diagram showing an outline of the weight for each adjacent node device
  • FIG. 7B is a diagram showing a simple example of the adjacent node management table 6 or 6a.
  • the node 1 or 1a When the node 1 or 1a according to this embodiment receives a frame from any of the adjacent node devices, the node 1 or 1a has a higher priority in consideration of the information related to the weight among the node devices other than the frame transmission source, that is, the LS.
  • the frame is transferred to the node device.
  • the node device 1 or 1a assigns a link number to each of the adjacent node devices, thereby identifying each adjacent node device.
  • a value used as information about weight is set as a range of 0 or more and 1 or less. The smaller this value, the higher the priority. For example, 0.5 can be set as the information initial value regarding the weight, and can be changed according to the success or failure of the subsequent frame transfer, the presence or absence of the loop detection, and the like.
  • weight operation function for example, a function considering link strength. Since the weight manipulation function affects the behavior of the entire network, it may need to be changed according to the purpose of the network.
  • FIG. 7 (a) shows a method of determining a transfer destination node device based on information on weights when a frame is received from an adjacent node device of link number i.
  • the node device 1 or 1a When receiving the frame transferred from the adjacent node device with the link number i, the node device 1 or 1a refers to the weighting table corresponding to the GD node device in the adjacent node management table 6 or 6a held. Then, the received frame is transferred to the adjacent node device having the highest priority and the link number other than “i” based on the information regarding the weight.
  • the adjacent node management table 6 or 6a stores the link number assigned to each adjacent node device and the weight of the adjacent node device associated with the link number.
  • the link number can be substituted with a node ID.
  • the node device 1 or 1a updates the adjacent node management table 6 or 6a according to the frame received from the adjacent node device with the link number i, and manipulates information regarding the weight.
  • FIG. 8 is a diagram for explaining the process of manipulating the weight according to the data transfer result.
  • the link numbers 1, 2, 3, 4 and the weights w 1 , w 2 , w 3 , w 4 are set for the adjacent node devices A, B, C, D as the information on the weights, respectively. It is.
  • the environment at the time of communication and the distance between the node devices may affect the communication quality
  • traffic volume may affect communication quality.
  • the initial value of the weight is 0.5 and the range of the value is 0 or more and 1 or less, but this is only an example, and a weight that can take other values is used. Embodiments can be envisaged. In this embodiment, the lower the weight (closer to 0), the higher the priority, but this is also an example. An embodiment in which other priorities are determined (for example, a method in which the priority is higher as the weight is larger) is also envisaged.
  • the weighting table may store information indicating adjacent node devices to be preferentially transferred when transferring frames and other node devices. For example, it is possible to prepare a flag or the like and set a value in the weighting table according to the success or failure of the frame transfer.
  • the node device 1 or 1a operates information on the weight (for example, bidirectional link weight) according to the result of transferring the frame to the adjacent node device so far.
  • the weight for example, bidirectional link weight
  • the magnitude relationship of each weight is w 1 ⁇ w 2 ⁇ w 3 ⁇ w 4 . That is, it is assumed that the priority for the adjacent node device A is the highest and the priority for the adjacent node device D is the lowest.
  • the node device 1 or 1a when the node device 1 or 1a receives the frame from the adjacent node device i other than the adjacent node devices A to D, the node device 1 or 1a transfers the frame in order from the adjacent node device A having the highest priority. try to. If the data transfer to the adjacent node device A fails, the data is transferred to the node device B having the next highest priority.
  • the node device 1 or 1a weights the adjacent node devices A and B. Is set to the maximum (worst value) and the priority is set to the lowest. Then, the weight for the adjacent node device C is reduced, and the priority is set high.
  • the frame transfer is attempted from the adjacent node device C having a high value.
  • FIG. 9 is a diagram showing an example of the configuration of the FID management table 5 or 5a.
  • the FID management table 5 or 5a is, for example, a FIFO (First In First Out) type buffer.
  • the FID management table 5 or 5a includes a frame ID (FID), a node ID of the transmission source node GS, a node ID of the transfer destination node LD, and a node ID of the transmission source node LS.
  • FID frame ID
  • the definition of the FID and GS / LD / LS node ID is the same as the corresponding field of the data frame shown in FIG.
  • the node device 1 or 1a compares the FID and GS field values of the frame with the record stored in the FID management table 5 or 5a. As a result of the comparison, when a record having the same FID and GS as the received frame is stored in the FID management table 5, the node device 1 or 1a is the same frame as the frame received once in the past. Therefore, it is assumed that “a loop has occurred” or “a return has occurred due to interruption of a route on the way”. When occurrence of a loop or return is detected, the weighting table 7 or 7a is updated, and the worst value (maximum value in this embodiment) is set in the information related to the weight corresponding to the LS node ID of the frame. To do.
  • the node device 1 or 1a extracts values from the FID, GS, LD, and LS fields from the received frame, and the FID management table. 5 records one record.
  • FIG. 10 and FIG. 11 are flowcharts showing processing at the time of data frame reception of the node device 1 or 1a according to an embodiment.
  • step S1 initialization processing is executed.
  • the initialization processing in step S1 for example, when wirelessly communicating with an adjacent node device, processing for matching the used frequency, processing for determining a modulation method, and the like are executed.
  • the initialization process in step S1 is executed only when the node device 1 or 1a is installed in the network.
  • step S2 reception of a data frame is awaited.
  • the process proceeds to step S3, and it is determined whether or not the node ID stored in the LD field is the node ID of the own apparatus. If a node ID other than the own device is stored in the LD, the process returns to step S2 and continues waiting.
  • the network construction process using the hello frame is also performed between the process of step S1 and the process of step S2, but the process shown in FIGS. The description is omitted here because it is executed by a different thread.
  • step S3 If it is determined in step S3 that the node ID of the own device is stored in the LD field, the process proceeds to step S4.
  • step S4 it is determined whether or not the node ID stored in the GD field is the node ID of the own device. If it is determined in step S4 that the node ID of the own device is stored in the GD field, this means that the end point of a series of data propagation across the network is the own node device. Accordingly, the flow proceeds to step S10, where the received data frame is processed (in the upper layer), and the series of processing ends.
  • step S4 If it is determined in step S4 that the node ID stored in the GD field is a node ID other than the own device, the flow proceeds to step S5.
  • step S5 it is determined whether or not a record having a combination of FID and GS that respectively matches the FID and GS of the received data frame exists in the FID management table 5.
  • step S5 If it is determined in step S5 that there is a record that matches the FID and GS of the data frame in the FID management table 5, the flow proceeds to step S6.
  • step S6 the LD is extracted from the record in which the FID and GS are determined to match the FID and GS of the data frame in the FID management table 5.
  • step S7 the weighting table 7 or 7a corresponding to the GD of the data frame is updated for the record having the node ID that matches the LD extracted in step S6.
  • the node ID that sent the frame having the last FID in the FID management table is set as the term Last.
  • the information regarding the weight corresponding to this term Last can be changed to the worst value (for example, 1.0) having the lowest priority.
  • step S5 determines whether or not the weighting table 7 or 7a corresponding to the GD of the data frame exists.
  • step S8 If it is determined in step S8 that the weighting table 7 or 7a for the node device indicated by the GD of the data frame does not exist, the flow proceeds to step S9. In step S9, the weighting table 7 or 7a for the GD of the data frame is created, and then the flow proceeds to symbol (A) in FIG.
  • a weighting table may be created with reference to the link strength of the adjacent node management table 6 or 6a shown in FIG.
  • step S8 If it is determined in step S8 that the weighting table 7 or 7a for the node device indicated by the GD of the data frame exists, the process proceeds to symbol (A) in FIG.
  • step S11 the process proceeds from step (S) to step S11, and the node ID corresponding to the evaluation value with the highest priority is obtained from the weighting table 7 or 7a.
  • step S12 it is determined whether an appropriate node device corresponding to the acquired node ID can be found.
  • step S12 If it is determined in step S12 that an appropriate node device has been found, the flow proceeds to step S13, and the data frame is transferred to the node ID acquired in step S11.
  • step S14 the FID and GS of the frame, LD, and LS are added to the FID management table 5 based on the data included in the transferred data frame.
  • step S15 it is determined from the response from the transfer destination node device whether or not the data frame transfer is successful. For example, when the ack signal is received from the transfer destination node device, it is determined that the transfer is successful, and when the ack signal is not received even after a predetermined time has elapsed, it can be determined that the transfer has failed. If it is determined that the operation has succeeded, the evaluation value corresponding to the node ID of the transfer destination node device is operated on the weighting table 7 or 7a for the node device indicated by the GD of the data frame in step S16. The priority is increased and the processing returns to the symbol (B) in FIG.
  • step S17 the evaluation value corresponding to the node ID of the transfer destination node device is manipulated to lower the priority, and step S11. Return to.
  • step S11 the processing from step S11 is repeated until the transfer of the data frame is successful or the appropriate node ID does not exist in the weighting table.
  • step S12 When it is determined in step S12 that an appropriate node device (node ID) cannot be found from the weighting table 7 or 7a, the process proceeds to step S18, and the received data frame is transferred to the node device indicated by LS. Return to symbol (B).
  • the node device 1 or 1a when transferring a data frame, the node device to be preferentially transferred is determined by referring to the weighting table 7 or 7a that is held. Then, the information on the weight (for example, evaluation value) is updated depending on the success or failure of the data transfer. By determining the node device that should preferentially transfer frames according to the weight information, the route that was able to communicate until then was blocked by the return of the data frame due to the occurrence of a loop or the change of the network status. The return of the data frame at the time is detected, and based on this, it is possible to bypass the route and continue communication with the optimum route. As described above, the weighting table 7 or 7a can be created for each GD, but it should be noted that only one weighting table is considered here for the sake of simplicity.
  • each node device monitors the state of the network.
  • a network monitoring method by the node device according to the present embodiment will be described.
  • each node apparatus transmits a hello frame including information related to the communication quality of radio waves received from other node apparatuses.
  • the node device refers to the hello frame received from another node device, calculates the communication quality of the adjacent node device, and holds information related to the calculated communication quality in the adjacent node management table 6 or 6a shown in FIG. .
  • the communication quality is determined by the delay and the number of hops.
  • FIG. 12 is a diagram showing a format of a hello header stored in a predetermined area of the hello frame.
  • the hello header includes a global destination address (ie, GD), the number of hops h, a route quality weight d, a return route quality weight, and a node type.
  • the global destination address (GD) is, for example, information on the global destination address (GD) corresponding to the weighting table 7 possessed by the node device that is the first transmission source (GS) of the hello frame including the hello header shown in FIG. .
  • the number of hops h is, for example, information on the number of hops from the transmission source of this hello frame to the node device that is the final destination (GD).
  • the value obtained from the delay on the route to the GD is stored as the route quality weight d.
  • the return path quality weight a value obtained based on the communication quality in the direction from the partner node device (here, the node device that transmitted the hello frame) to the own node device is stored.
  • the node type defines types such as a gateway, a repeater, and a terminal.
  • FIG. 13 is a conceptual diagram illustrating a method for measuring communication quality by delay in the node device 1 or 1a according to the present embodiment.
  • the “source” node device periodically sends a hello frame to the outside.
  • a hatched portion shown in an ellipse in FIG. 13 indicates a range in which a hello frame transmitted by the source node device can be received.
  • the node devices a and b receive the hello frame sequentially transmitted from the source node device, and measure the time required from receiving one frame to receiving the next frame.
  • the time required to receive the next frame is also referred to as a “reception cycle”.
  • the relationship between the reception cycle and the number of receptions in the node devices a and b is shown in the graph (the vertical axis is the number of appearances and the horizontal axis is the reception interval). As shown in the figure, the relationship between the reception cycle and the number of receptions in each node device is generally a normal distribution.
  • the node device b In general, in the node device b that is relatively far from the source node device, frame loss is likely to occur. Therefore, the node device b is more likely to have a frame missing due to a frame loss than the node device a, and the time until the next frame is received tends to be longer. From this, in an embodiment according to the present invention, approximation is performed such that a large reception cycle T is regarded as a large delay, and communication quality is obtained from the reception cycle T. .
  • the standard deviation obtained by the above equation (1) is stored as a return link weight in a predetermined field (not shown) of the adjacent node management table 6 or 6a.
  • the partner node device can obtain the forward link weight from the received information. In this way, the return link weight is obtained in the own device by the hello frame received from the other node device, and the obtained return link weight is now included in the hello frame and exchanged with the other node device. You can get the weight.
  • the bidirectional link weight can be calculated by the following equation (2).
  • (Bidirectional link weight) [ ⁇ (outbound link weight) +1 ⁇ ⁇ (inbound link weight) +1 ⁇ -1] 1/2 (2)
  • FIG. 14 is a diagram for explaining in detail a detailed format of a hello frame including a hello header, which can be used in an ad hoc network according to an embodiment of the present invention. It should be noted that other embodiments of the present invention may use a different format, and other embodiments may be encompassed within the scope of the present invention.
  • the frame shown in FIG. 14 is roughly divided into an ad hoc header, a compressed header, and a payload.
  • the ad hoc header includes a “local destination address” (LD), a “local source address” (LS), a “frame type” indicating the type of frame, and a size of the compressed frame ". It has a field called “frame size”.
  • the compression header has fields of “compression type” indicating the payload compression method and “frame size” indicating the size of the frame before compression. Each node device can appropriately decompress the payload in consideration of this compression type.
  • a hello message header In the payload, a hello message header, one or more hello headers, and a hash indicating a signature are compressed and included.
  • the reason why compression is performed with the frame according to this embodiment is to obtain the effect of reducing the frame size and saving the communication band.
  • frames having data without compression are also included in other embodiments of the present invention.
  • a “service type” indicating the type of service
  • “division information” indicating the division status in the payload
  • “number of hello headers” indicating the number of hello headers included in the payload
  • a field of “device ID” indicating the ID of the node device and “access key” for decrypting the encrypted information is included.
  • the field of “device ID” can store the ID of the node device that is the transmission source of the hello request described later with reference to FIG.
  • One or more hello headers included in the payload include a “global source address” (GS), a “GW information hop number” indicating the number of hops for gateway (GW) information, and the above-mentioned “route quality weight” ( d) and "Return Quality Weight” fields.
  • GS global source address
  • GW information hop number indicating the number of hops for gateway (GW) information
  • d route quality weight
  • FIG. 15 is a diagram for explaining the structure of the weighting table 7 or 7a in more detail.
  • the weighting table 7 or 7a illustrated in FIG. 15 includes a global destination address (GD), a local destination address (LD), a hop count h, an interlink arrival weight w, a route quality weight d, and an evaluation value E.
  • the weighting table 7 or 7 a may include other information, for example, may include data of the last update time indicating time information when the data is updated. As described above, such a weighting table is provided in each node device.
  • the global destination address (GD) includes a received hello frame (in this case, a hello frame receiving process described later with reference to FIGS.
  • the data shown in the field of the global destination address (GD) in the hello header of the eaves is stored.
  • LS local source address
  • the hop count h is data in which the hop count from the node device having this weighting table to the GD is stored. That is, a value obtained by adding 1 to the value indicated by the number of hops in the hello header of the received hello frame is stored.
  • the node type is data that defines the type of node, and stores data indicated by the node type in the hello header of the received hello frame.
  • the inter-link arrival weight w is a numerical value of the success or failure of transfer of data frames between links.
  • the saddle data calculated based on the return path weight in the hello header of the received hello frame is stored as the inter-link arrival weight w.
  • the route quality weight d is a value calculated based on the variance of the reception period of the hello frame, as described with reference to FIGS.
  • the evaluation value E stores comprehensive route evaluation information calculated using the number of hops h, the interlink arrival weight w, and the route quality weight d in the hello header of the received hello frame.
  • a method for appropriately deriving the evaluation value E may be used, and such a method may be included in the group of embodiments of the present invention.
  • at least one of the number of hops h, path quality weight d, interlink arrival weight w, received signal strength, or any other parameter deemed appropriate in the art. Can be used to appropriately derive the evaluation value E.
  • the node device 1 or 1a can monitor the state of the network based on the reception status of the hello frame from another node device.
  • FIGS. 16 to 21 are detailed flowcharts showing processing at the time of receiving a hello frame in the node device according to the embodiment of the present invention.
  • the processing of the node device according to the embodiment of the present invention will be roughly described below.
  • the adjacent node management table is updated in steps S1600 to S1614.
  • steps S1700 to S1710 ′ for each GD of the hello header using the hello header of the hello frame, the evaluation value of the transmission source (LS) of the hello frame registered in the weighting table of the own node device Update.
  • steps S1850 to S1700 ′ the evaluation value of the weighting table possessed by the own node device whose GD is the hello transmission source (LS) is updated.
  • steps S2000 to S2010 ′ if the transmission source (LS) of the hello frame is not registered in the weighting table of the own node device, it is newly registered, and the hello header is added to the weighting table of the own node device. If GD is not registered, newly register.
  • the flow according to this embodiment starts when the hello frame is received by the node device (local node device) that places the viewpoint in FIG.
  • the node device local node device
  • steps S1600 to S1614 information on the weight in the record of the adjacent node management table corresponding to the transmission source (LS) of the hello (HELLO) frame is updated.
  • step S1600 the node device that has received the hello frame performs a search to check whether a record corresponding to the node device of the transmission source (LS) of the hello frame exists in the adjacent node management table of the node device. I do.
  • this search the previous hello frame reception time from this LS and the current hello frame reception time are compared. In this way, it is possible to determine whether there is an LS “spoofing” (that is, a frame sent with a false LS) by checking whether the reception time is reversed.
  • LS transmission source
  • step S1602 If it is determined in step S1602 that the hello frame transmission source (LS) is not in the adjacent node management table by the search, the flow proceeds to step S1604. Then, a new LS is added to the adjacent node management table, and an initial value of the return link weight is set. If it is determined in step S1602 that the transmission source (LS) of the hello frame is in the adjacent node management table by the search, the flow proceeds to step S1606. Then, the value of the return link weight is updated in the record corresponding to LS in the adjacent node management table.
  • step S1608 a search is performed to determine whether the hello header in the hello frame includes information (ID, etc.) of the own node device. At this time, reference is made to link quality information between nodes of the LS (that is, return link weight from the LS). If it is determined in step S1610 that the information of the own node device exists, the flow proceeds to step S1612, and the forward link weight for the adjacent node device is calculated.
  • step S1614 a bidirectional link weight related to the adjacent node device is calculated. Then, the process proceeds to the symbol (I) in FIG.
  • step S1700 of FIG. 17 first, a repeat process (loop process) is started for each record in the weighting table of the own node device.
  • step S1710 the repeat process for each hello header included in the hello frame is further nested.
  • step S1712 it is determined whether the GD of the weighting table matches the GD of the hello header in the hello frame (that is, what was originally included in the weighting table of the transmission source (LS) of the hello frame).
  • step S1714 If the GD of the weighting table does not match the GD of the hello header in step S1714, the flow jumps to the symbol (IV) in FIG. 17, and one repeat cycle is completed in step S1710 '. If the GD of the weighting table matches the GD of the hello header in step S1714, the flow proceeds to step S1716.
  • step S1716 a search is made as to whether there is an LD candidate serving as a destination to which the node device sends a frame in the weighting table corresponding to the transmission source (LS) of the hello frame.
  • step S1718 If there is a destination LD candidate (destination LD candidate) in step S1718, the number of hops h is updated as the number of hops in the hello header + 1 in the record for that destination LD candidate in the weighting table in step S1720. To do.
  • step S 1722 the route quality weight d related to the hello frame is calculated, and the route quality weight d related to the destination LD candidate is updated.
  • the path quality weight d related to the hello frame here is, for example, the entire path (or the path quality weight calculated from the dispersion of the reception period of the hello frame and the path quality weight viewed from the hello frame transmission source (or A value obtained by adding or performing some operation on the bidirectional link weight in at least a part of the entire route, that is, the route quality weight.
  • the route quality weight d related to the received hello frame is added to the route quality weight d in the weighting table, and the updated route quality weight d thus obtained is transmitted this time.
  • the route quality weight stored in the hello frame is transmitted to the next node device.
  • the sum of the bidirectional link weights for each hello header becomes the route quality weight d of the weighting table.
  • the bidirectional link weights obtained during a series of repeat processing S1710 to S1710 ′ or repeat processing S1700 to S1700 ′ are integrated, and the path quality of the weighting table subjected to the repeat processing is accumulated. The weight d can be calculated. Then, the flow proceeds to symbol (II) in FIG.
  • step S1824 the received power related to the destination LD candidate (note that the field for received power is not shown in FIG. 15) is updated as the received power when this hello frame is received.
  • step S1826 the evaluation value E related to the hello frame is calculated as described above, and the evaluation value E related to the destination LD candidate is updated.
  • step S1828 the aging counter (means for setting the valid period of the weighting table) regarding the destination LD candidate is reset.
  • step S1840 where the destination LD candidates are sorted in the order of evaluation values, and the candidates that are preferred in terms of priority can be narrowed down.
  • step S1710 ' one repeat cycle is completed.
  • step S1718 the transmission source (LS) of the hello frame is newly registered as the destination LD candidate in the weighting table, and the flow is The process proceeds to step S1730.
  • step S1730 the number of hops h is updated as the number of hops in the hello header + 1 in the record for the new destination LD candidate.
  • step S1732 the route quality weight d related to the hello frame is calculated, and the route quality weight d related to the destination LD candidate is updated.
  • the flow proceeds to symbol (III) in FIG.
  • step S1834 the received power related to the destination LD candidate is updated as the received power when this hello frame is received.
  • step S1836 the evaluation value E related to the hello frame is calculated as described above, and the evaluation value E related to the destination LD candidate is updated.
  • step S1850 When the repeat processing S1710 to S1710 'is completed, the flow proceeds to step S1850.
  • step S1850 it is confirmed whether or not the destination LD candidate using the hello header has been updated in the processing in repeat processing S1710 to S1710 ', that is, whether or not the processing has proceeded from step S1714 to S1716 even once. If there is an update, the flow jumps to the symbol (VII) in FIG. 19, and one repeat cycle is completed in step S1700 '. If there is no update, the flow proceeds to step S1852. In step S1852, it is determined whether the value corresponding to the node device (LS) that is the transmission source of the hello frame corresponds to the GD of the weighting table (as shown in FIG. 15). In this embodiment, the routing is evaluated in this way.
  • LS node device
  • step S1700 one repeated cycle is completed.
  • step S1854 If the node device (LS) that is the transmission source of the hello frame matches the GD of the weighting table, the flow proceeds to step S1854. Then, it searches for a candidate for an adjacent node in the weighting table corresponding to the transmission source (LS) of the hello frame. If there is a destination LD candidate in step S1900 across the symbol (V) in FIG. 19, the flow advances to step S1910. In step S1910, the route quality weight d related to the hello frame is calculated, and the route quality weight d related to the destination LD candidate is updated. In step S1912, the received power related to the destination LD candidate is updated as the received power when this hello frame is received.
  • step S1914 the evaluation value E related to the hello frame is calculated as described above, and the evaluation value E related to the destination LD candidate is updated.
  • step S1916 the aging counter related to the destination LD candidate is reset. Although omitted due to the paper width, when there are a plurality of destination LD candidates, step S1910 to step S1916 can be repeated by the number. Then, the flow proceeds to step S1930 to sort the destination LD candidates in the order of evaluation values, and one repeat cycle is completed in step S1700 '.
  • step S1920 the number of hops of a new destination LD candidate is set to an initial value (1 here).
  • an initial value for example, 0.5
  • the route quality weight d related to the hello frame is calculated, and the route quality weight d related to the destination LD candidate is updated.
  • step S1926 the received power related to the destination LD candidate is updated as the received power when this hello frame is received.
  • step S1928 the evaluation value E related to the hello frame is calculated as described above, and the evaluation value E related to the destination LD candidate is updated.
  • step S1929 the aging counter related to the destination LD candidate is reset. Then, the flow proceeds to step S1930 to sort the destination LD candidates in the order of evaluation values, and one repeat cycle is completed in step S1700 '.
  • step S2000 it is determined whether or not an entry corresponding to the node device (LS) that is the transmission source of the hello frame (the LS is GD) exists in the weighting table (group) of the own node device. Check. If there is a corresponding entry in the weighting table, the flow jumps to step S2010. If there is no corresponding entry in the weighting table, the flow proceeds to step S2001.
  • LS node device
  • group the weighting table
  • step S2001 a new weighting table with the LS as GD is created.
  • step S2002 the number of hops of a new destination LD candidate is set to an initial value (here, 1).
  • step S2003 an initial value (for example, 0.5) is set to the interlink arrival weight w of the destination LD candidate.
  • step S2004 the route quality weight d related to the hello frame is calculated, and the route quality weight d related to the destination LD candidate is updated.
  • step S2005 the received power related to the destination LD candidate is updated as the received power when this hello frame is received.
  • step S2006 the evaluation value E related to the hello frame is calculated as described above, and the evaluation value E related to the destination LD candidate is updated.
  • step S2007 the aging counter related to the destination LD candidate is reset. The flow then proceeds to step S2010.
  • step S2010 the repetition process for each hello header included in the hello frame is started.
  • step S2100 of FIG. 21 across the symbol (IX) it is confirmed whether the GD of the hello header exists in the weighting table of the own node device. If there is a corresponding entry in the weighting table, the flow jumps to step S2010 ', and one repeat cycle is completed. If there is no corresponding entry in the weighting table, the flow proceeds to step S2101.
  • step S2101 a new weighting table corresponding to the GD of the hello header is created, and an entry having the LS of the ad hoc header of the hello frame as the value of the field LD is created in the table.
  • step S2102 the hop count h of the new destination LD candidate is set as the hop count +1 of the hello header.
  • step S2103 an initial value (for example, 0.5) is set for the inter-link arrival weight w of the destination LD candidate.
  • step S2104 the route quality weight d relating to the hello header is used to recalculate the route quality weight d, and the route quality weight d relating to the destination LD candidate is initialized.
  • step S2105 the received power related to the destination LD candidate is updated as the received power when this hello frame is received.
  • step S2106 the evaluation value E related to the hello header is calculated, and the evaluation value E related to the destination LD candidate is updated.
  • step S2107 the aging counter related to the destination LD candidate is reset. Then the flow proceeds to step S2010 'and one repeat cycle is completed.
  • FIG. 22 is a diagram showing a hello frame exchange sequence.
  • Each node device broadcasts a hello frame toward neighboring node devices.
  • the hello frame includes link information determined to be optimal in the route to each node.
  • Each node device when receiving the hello frame, creates and updates information about the weight for each node device as compared with the adjacent node management table 6 or 6a and the weighting table 7 or 7a that it holds.
  • the link information of the hello frame is updated with reference to the adjacent node management table 6 or 6a. By repeating this operation a plurality of times for each node device, the node device can have a plurality of link destination information that enables routing to each of the other node devices.
  • the specific node when the node device 1 or 1a cannot receive a hello frame that has been received from a specific node device within a predetermined period (for example, within 30 minutes), the specific node It can be assumed that the device is in a communication disabled state and can notify the gateway device to that effect. In addition, if an abnormality is detected after making a determination based on the contents of the received hello frame, it is possible to notify the gateway device to that effect. Further, when an abnormality is detected for a certain node device with reference to the adjacent node management table 6 or 6a, the corresponding weight in the weighting table 7 or 7a is updated, and the priority for that node device is updated. May be lowered.
  • the life and death of the gateway device can be monitored by transmitting / receiving a hello frame to / from the gateway device.
  • a hello frame is not received from the partner node device within a predetermined time, a hello frame generation request is transmitted to the partner node device, and a hello frame is transmitted from the partner node device.
  • a structure may be adopted in which the state of the partner node device is monitored depending on whether or not a frame is received.
  • each node device monitors a network using a hello frame, so that it is not necessary to distribute a network monitoring frame separately, and the number of distribution frames can be suppressed.
  • the turnaround is reduced compared to the case where a network monitoring frame is sent from the center and the status is monitored by the response. Real-time monitoring is possible.
  • FIG. 23 is a schematic diagram showing hardware capable of executing the node device or the program according to the embodiment of the present invention.
  • FIG. 23 first shows a microprocessor unit (MPU) 2300 responsible for various calculation processes.
  • the microprocessor unit 2300 is communicably connected to a wired physical layer processing unit (PHY) 2312 and an MII (Media Independent Interface) / MDIO (Management Data Input / Output) interface 2310 (“MII / MDIO”). Means "MII or MDIO"). Both MII and MDIO are interfaces between the physical layer and the MAC sublayer (Media Access Control sublayer).
  • the microprocessor 2300 is communicably connected to a timer IC 2322 for measuring time and the like via an I 2 C (Inter-Integrated Circuit) / PIO (Parallel Input / Output) bus 2320 (“I 2 ”).
  • I 2 C Inter-Integrated Circuit
  • PIO Parallel Input / Output
  • C / PIO means “I 2 C or PIO”).
  • the microprocessor 2300 is communicably connected to a dynamic random access memory (DRAM) 2332 and a flash memory 2334 as storage means and a wireless LAN processing unit 2336 as a network interface via a PCI (Peripheral Component Interconnect) bus 2330.
  • DRAM dynamic random access memory
  • flash memory 2334 as storage means
  • wireless LAN processing unit 2336 as a network interface via a PCI (Peripheral Component Interconnect) bus 2330.
  • PCI Peripheral Component Interconnect
  • the MPU 2300 can execute various processes by loading various programs such as firmware stored in the flash memory 2334, which is a kind of nonvolatile storage device, onto the DRAM 2332 and executing the programs.
  • the MPU 2300 can execute various programs such as a firmware program for causing the node device 1 to execute the various processes described above.
  • the DRAM 2332 can also be used as a frame transmission buffer and a reception buffer.
  • the flash memory 2334 can store a firmware program and the like as described above.
  • the flash memory 2334 can also store information (for example, node ID and MAC address) unique to the node device 1 or 1a itself.
  • the wired PHY processing unit 2312 is a circuit that performs physical layer processing in wired connection.
  • the wireless LAN processing unit 2336 is hardware that performs physical layer processing in wireless LAN connection.
  • the wireless LAN processing unit 2336 can include, for example, an antenna, an ADC (Analog-to-Digital Converter), a DAC (Digital-to-Analog Converter), a modulator, a demodulator, and the like. I do. Therefore, in the present embodiment, the node device 1 or 1a can perform both wired communication and wireless communication. Of course, an embodiment in which the node device 1 or 1a performs only one of wired communication and wireless communication is also possible.
  • the timer IC 2322 is a circuit that performs a count-up operation until a set time elapses, and outputs an interrupt signal when the set time elapses.
  • control program that causes a computer to execute the above method is also included in an example of the embodiment of the present invention.
  • the control program may be provided by being stored in a computer-readable storage medium such as a magnetic disk, a magneto-optical disk, a nonvolatile semiconductor memory, or an optical disk, loaded into a computer, and executed by the computer.
  • a computer that executes the control program is built in or connected to a node device (not shown), and the node device (not shown) operates in the same manner as the node device 1 or 1a of the embodiment in accordance with the control program.
  • a node device (not shown) is controlled.
  • the MPU 2300 which is a built-in computer of the node device 1 or 1a, controls the node device 1 or 1a according to the control program stored in the flash memory 2334, and performs the above processes. It can be considered that the node device 1 or 1a is carrying out.
  • each node device performs route optimization based on information received from adjacent node devices. And monitoring the network.
  • an example of a table format is disclosed for easy understanding of various types of data.
  • the present invention is not limited to this example, and other management formats such as an XML or a tree structure that can be managed by associating data are adopted. May be.

Abstract

 簡易な構造で、かつ、ネットワークに負荷をかけずに、自律的に適切な経路を選択可能なノード装置/プログラムを提供する。通信ネットワークの中のノード装置1において、FID管理テーブル5にフレームを一意に識別するFIDとフレームの送出先ノードに関する情報とを格納し、重み付けテーブル7にフレームの最終宛先ノードごとに、フレームを中継するため送出先とする他ノードについての重み付け情報を格納する。自ノード宛に送信されたフレームを受信すると、受信したフレームのFIDがFID管理テーブル5に格納されている場合には、FIDと対応付けられた送出先ノードについてのデータを更新する。フレーム受信手段により受信したフレームのFIDが、FID管理テーブル5に格納されていない場合には、フレームの宛先ノードに該当する重み付けテーブル5を参照して、フレームを中継するための宛先とする他ノードを決定する。

Description

ノード装置及びプログラム
 本発明は、複数のノードを含むネットワークにおける、経路選択可能な装置/プログラムに関する。
 ネットワーク装置は、これまで非常に多くの研究がなされている。最も普及しているのは、IP(Internet Protocol)ネットワークを利用したネットワーク装置である。また、複数のプロトコルやネットワークを収容することを目的としたMPLS(Multi Protocol Labeled Switching)は、自動的に経路を作成する機構を持つネットワーク装置である。また、アドホックアルゴリズムの代表例としてAODV(Ad-hoc On-Demand Vector)やOLSR(Optimized Link State Routing)がある。
 IPネットワーク装置では、IPアドレスに従いルーティングを決定する。IPアドレス自体が木構造を持つため、IPアドレスの上位から合致するIPネットワークを管理するネットワーク装置に伝送することで、最終的に目標とする端末へフレームを伝送することができる。ルーティングはIPアドレス体系により決定されている。どのネットワーク装置かどのIPネットワークを管理しているかは、ルーティングテーブルによって規定される。ルーティングテーブルは主に手動で設定されることも多いが、RIP(Routing Information Protocol)により自動的に更新されることもある。RIPとは、ネットワーク装置が管理するIPネットワークを周囲にブロードキャストし、ネットワーク装置が互いの管理するIPネットワークを確認する方式である。
 MPLSでは、ネットワークがLSR(Label Switch Router)と呼ばれるネットワーク装置間と外部ネットワークとに分離される。外部ネットワークからのフレームは、エッジノードと呼ばれる外部ネットワークと内部ネットワークの両方にまたがるネットワーク装置によって内部ネットワークに取り込まれる。このとき、外部フレームの先頭にはラベルが挿入される。各LSRは、それぞれがラベル転送テーブルを持つ。ラベル転送テーブルは、入力フレームのラベルと出力フレームのラベルおよびあて先を保持する。LSRは入力されるフレームのラベルを取り出し、該当するラベルをラベル転送テーブルから発見し、出力フレームのラベルに書き換え、該当するあて先に送出する。ラベル転送テーブルのLDP(Label Distribution Protocol)によって行われる。LDPは、まずRIPなどによりルーティングテーブルの作成を行い、これにラベルを付加し、隣接ノード間で通知しあうプロトコルである。
 AODVは、経路検索にブロードキャストを用いて、他の通信ノード装置がブロードキャストを繰り返し目的のノード装置への経路を発見する手法である。通信ノード装置は、目標とする経路を発見するために周囲に「Route Request(RREQ)」というフレームを送出する。このフレームには、検索目標の通信ノードIDが明記されている。周囲の通信ノード装置は、自身を検索していない場合は、新たにRREQフレームを作成して、周囲へのブロードキャストを繰り返し行う。このとき各通信ノード装置は、送り元のメッセージが、隣接するどの通信ノード装置から受信されたものなのかを記録する。RREQメッセージが目的の通信ノード装置に達したとき、その目的の通信ノード装置は、「Route Reply(RREP)」フレームを作成し、送り元のノードに対して、RREQフレームが送られてきた経路をたどるようにしてRREPフレームを送信する。このようにして、双方向の通信経路が作成されている。
 OLSR(Optimized Link State Routing)では、通信ノード装置同士が定期的にフレームを交換しあうことで、ネットワーク全体を把握し、目的の通信ノードまでの経路を検出するという方式を採用している。通信ノード装置は、周期的にHELLO(ハロー)フレームを送出し、互いにその存在を通知しあう。通信相手となる通信ノード装置の存在が判明したところで次に効率的にネットワーク全体にフレームを配信するためのフラッディング用のパスを生成する。これをMPR(Multi Point Relay)と呼ぶ。MPRにより、各通信ノード装置から効率よくフレームをネットワーク全体へブロードキャストできる。次にこのMPRを用いて、経路作成メッセージであるTC(Topology Control)フレームをノード装置同士が互いに配信することで全ノード装置がネットワークトポロジーを知ることができる。フレームを、目標とする通信ノード装置に送るには、送出元となる通信ノード装置自身が知っているネットワークトポロジーを参照し、送るべき隣接通信ノード装置にフレームを託す。隣接ノード装置も同様に処理を行い、最終的に目標ノード装置にフレームを届ける。
 アドホック無線通信ネットワークに関しては、公知の技術として、各ノードがハローメッセージとして自ノードの存在を通知する情報と、自ノードまでのルートメトリックとを含んだ情報を放送し、該ハローメッセージを受信した他ノードは、受信したルートメトリックにハローメッセージを放送してきたノードと自ノードとの間のルートのためのルートメトリックを追加し、該追加後のルートメトリックを使用する技術について提供されている(例えば、特許文献1)。ここでのルートメトリックは、ホップ数、リンク品質等の因子により算出される、送信元と宛先とのコストを表す値である。
特表2006-526937号公報
 IPネットワーク装置やMPLSでは、前提としてアドレスによってネットワーク自体が構造を持っていることを利用している。IPアドレスが木構造であるため、アドレスが上位からマッチしていく方向を選択することにより経路が決定する。また、これらは有線の接続を前提としている。2つの通信端末間で有線接続は安定した通信ができ、接続されていない通信機器はフレームを受信することはないため、単純に通信機のホップ数だけで決めることができる。
 しかし無線通信を前提としたとき、これらの方式では通信品質のよい経路作成は困難である。無線通信では、通信品質は有線通信と比較した場合に悪く、かつ通信とは直接関係しない他の通信端末にも影響を与える。また通信品質は、距離や周囲の環境の依存性も高く、時間的変化も伴う。このような環境下で上記プロトコルを実施した場合、ホップ数のみで決定すると、アルゴリズムが遠くの通信端末を経由しようとする場合がありえる。しかしながら、距離が遠ければその分通信品質も悪いため非常に品質の悪い経路を作成してしまう。
 AODVは、経路作成時にネットワークに負荷をかける。通信端末数が少ない場合は問題ないが、通信端末数が多くなり通信量が増えた場合ネットワークへの負荷が高くなってしまう。その結果、通信がすでに確立している通信ノード装置にも影響を与え、リンク切れを起こす可能性が高く、結果的に通信できるノード装置は非常に少なくなりそのほとんどが経路確立できなくなる。また、上記のようにホップ数をベースとしているため通信品質の悪い経路を作成してしまうことも考えられる。
 OLSRでは、全ノード装置がネットワークトポロジーを知る必要がある。このためスケールに限界が生じる。また、全ノード装置のトポロジーが判明する時間が必要となる。
 上記のとおり、有線無線を問わず、ネットワークにおいては、通信量や周囲の環境影響によりノード装置間の通信品質が変化することがあり、特に無線では変化が大きい。このため、非常に多くのノード装置を含んだネットワークを考えた場合、ネットワークを統括するサーバを設置し、該サーバによってネットワークの管理を行うことは実用的ではない。というのは、ノード装置の個数が多いのでサーバから制御指示を送信するだけでも大変な負荷になってしまうからである。そこで、非常に多くのノード装置からネットワークがつくられている場合には、各ノード装置が自律的に経路選択や死活監視などの動作をすることが望まれる。
 さて、各ノード装置が自律的に動作することを考えた場合、上述の通り通信品質は変化するので、あるノード装置に宛てた送信フレームを中継する際には、現時点で有効な経路を各ノード装置が把握しておく必要がある。例えば、固定的な構造を持つネットワークや一般的な検索手法である二分木探索などの手法では、ネットワークや木の全体像が初めからわかっているため、どこまで経路を探索したかを容易に判別可能であるのに対し、本願が対象とするノード装置間のリンクが変化してゆくようなネットワークでは、各ノード装置は、周囲のノード装置の先にどのようなノード装置がリンクされているかを知らないので、どこまで経路を探索したかを知るための仕組が必要になる。
 本発明では、簡易な構造で、かつ、ネットワークに負荷をかけずに、自律的に適切な経路を選択可能なノード装置/プログラムを提供する。
 本発明の実施形態にかかるノード装置は、複数のノード装置を含むネットワークの中の、ノード装置において、自ノードが送信したフレームの情報として、フレームを一意に識別するための識別情報と該フレームの送出先ノードに関する情報とを格納する識別情報管理テーブルと、フレームの最終宛先ノードごとに、フレームを中継するため送出先とする他ノードについての重み付け情報を格納する宛先ノード別重み付けテーブルと、他ノードから自ノードに宛てて送信されたフレームを受信するフレーム受信手段と、前記フレーム受信手段により受信した前記フレームの識別情報が、前記識別情報管理テーブルに格納されている場合に、該識別情報と対応付けて格納されている前記送出先ノードについて、該フレームの最終宛先に対応する前記宛先ノード別重み付けテーブルのデータを更新する宛先ノード別重み付けテーブル更新手段と、前記フレーム受信手段により受信した前記フレームの識別情報が、前記識別情報管理テーブルに格納されていない場合に、前記フレームの最終宛先ノードに該当する前記宛先ノード別重み付けテーブルを参照して、該フレームを中継するための送出先とする他ノードを決定するフレーム送出先決定手段とを備える。
 他ノードからフレームを受信すると、宛先ノード別重み付けテーブルを参照し、転送すべきノードを決定する。転送先のノードを重みにしたがって決定し、また、他ノードへのフレームの転送の成否に応じて重みが更新される。ノード装置は、自律的に経路を学習できる。
 前記宛先ノード別重み付けテーブル更新手段は、前記フレーム受信手段により受信した前記フレームの識別情報が、前記識別情報管理テーブルに格納されている場合に、該識別情報と対応付けて格納されている前記送出先ノードについて、該フレームの最終宛先に対応する前記宛先ノード別重み付けテーブルの該送出先ノードに対する重み付けを、優先度が低くなるように更新するようにしてもよい。
 更には、自ノードの周囲に存在する他ノードに関する情報を格納する隣接ノード管理テーブルと、ハローメッセージとして、自ノードの存在を知らせる情報と、前記隣接ノード管理テーブルから読み出した情報であって、周囲の経路に関する情報とを送信するハローメッセージ送信手段と、他ノードからの送信されたハローメッセージを受信するハローメッセージ受信手段と、前記ハローメッセージ受信手段により受信したハローメッセージの送出元ノードに関する情報に基づき、前記隣接ノード管理テーブルを更新する隣接ノード管理テーブル更新手段と、を更に備え、前記隣接ノード管理テーブルにおいて、所定の状態になった第1のノードを検出した場合には、前記宛先ノード別重み付けテーブル更新手段は、前記宛先ノード別重み付けテーブルの送出先ノードが該第1のノードであるデータを優先度が低くなるように更新するようにしてもよい。
 本発明の実施形態にかかるノード装置によれば、ノード装置間のリンクが変化するようなネットワークにおいても、各ノード装置は、保有する重みに関する情報を参照して転送先のノードを決定し、重みに関する情報を更新する。これにより、ネットワークの全体を把握せずとも、自律的に最適な経路を学習して通信を行うことが可能となる。
通信システムの全体概念図である。 本発明の実施形態に係るノード装置の概略図である。 本発明の実施形態に係るノード装置の詳細な模式図である。 隣接ノード管理テーブルの構造を示す図である。 フレームのフォーマット例である。 図5のフレームのフォーマット例の説明である。 隣接ノード管理テーブルに基づくデータ転送処理を説明する図である。 フレームの転送結果により重みに関する情報を操作する処理を説明する図である。 FID管理テーブルの例を示す図である。 本発明の実施形態に係るノード装置のデータフレーム受信時の処理を示したフローチャートの概略(その1)である。 本発明の実施形態に係るノード装置のデータフレーム受信時の処理を示したフローチャートの概略(その2)である。 ハローヘッダのフォーマットを示す図である。 本発明の実施形態に係るノード装置において、遅延により通信品質を計測する方法を説明する図である。 ハローヘッダを含んだハローフレームの詳細なフォーマットを示す図である。 重み付けテーブルの構造を詳細に説明する図である。 本発明の実施形態に係るノード装置のフレーム受信時の処理を示した詳細なフローチャート(その1)である。 本発明の実施形態に係るノード装置のフレーム受信時の処理を示した詳細なフローチャート(その2)である。 本発明の実施形態に係るノード装置のフレーム受信時の処理を示した詳細なフローチャート(その3)である。 本発明の実施形態に係るノード装置のフレーム受信時の処理を示した詳細なフローチャート(その4)である。 本発明の実施形態に係るノード装置のフレーム受信時の処理を示した詳細なフローチャート(その5)である。 本発明の実施形態に係るノード装置のフレーム受信時の処理を示した詳細なフローチャート(その6)である。 ハローフレームの交換シーケンスを示す図である。 本発明の実施形態にかかるノード装置もしくはプログラムを実施可能なハードウェアを示す概要図である。
 以下、本発明の好適な実施の形態について、図面を参照して詳細に説明する。
 まず、本明細書での用語について説明をする。
 「フレーム」とは、プロトコルが扱うデータ単位のことを指す。「フレーム」には、例えば「ハローフレーム」「データフレーム」が含まれるが、これらに限定はされない。
 「ハローフレーム(HELLOフレーム)」とは、本発明の実施形態にかかるノード装置が、別のノード装置に対して互いの存在・状態の確認のために送出する特別なフレームのことを指す。
 「データフレーム」とは、ネットワークが(スタートノードからゴールノードへと)伝送しようとするデータのことを指す。なお当然のことながら本発明の実施形態にかかるノード装置は、「ハローフレーム」と「データフレーム」を識別するための適切な手段を有することができる。
 「Local Destination (LD)」とは、或るノード装置を主体として観たときに、次にフレームを渡すべき隣接ノード装置を表すあて先ノードIDのことを指す。なお本明細書ではLDのことを、「ローカル宛先アドレス」と称することもある。
 「Local Source (LS)」とは、LDへフレームを送るその直接の送り元となるノード装置(すなわち、LDにとっての自ノード装置)を表したノードIDのことを指す。なお本明細書ではLSのことを、「ローカル差出アドレス」と称することもある。
 「Global Destination (GD)」とは、データフレームのネットワークに跨った一連の伝播に関する最終的なあて先となるノードIDのことを指す。なお本明細書ではGDのことを、「グローバル宛先アドレス」と称することもある。
 「Global Source (GS)」とは、データフレームのネットワークに跨った一連の伝播に関する最初の送り元であるノードIDのことを指す。なお本明細書ではGSのことを、「グローバル差出アドレス」と称することもある。
 「フレームID (FID)」とは、各フレームが持つ固有の識別情報のことである。FIDとしては例えば一連の番号を用いることができるが、これに限定はされない。
 「重み」とは、本発明の実施形態にかかるフレーム伝播経路選択にあたって考慮される値である。重みとしては、復路リンク重み、往路リンク重み、双方向リンク重み、経路品質重み、復路品質重み、リンク間到達重み、が本明細書に例示されているが、これらに限定はされない。なお本明細書の記載において「重み」または「重みに関する情報」と言うときには、何らかの種類の重みを用いて算定した値のことを指すこともあると解釈されたい。
 「復路リンク重み」とは、復路を来たるフレームに関する重みのことである。なお、或るノード装置を主体として考えるとき、そのノード装置が別の隣接するノード装置からフレームを受けるとするなら、そのフレームは「復路」を通ってきたことになる。
 「往路リンク重み」とは、往路を行くフレームに関する重みのことである。なお、或るノード装置を主体として考えるとき、そのノード装置が別の隣接するノード装置へフレームを送るとするなら、そのフレームは「往路」を通ることになる。
 「双方向リンク重み」とは、上述した往路リンク重みと復路リンク重みとを組み合わせて算出する重みのことである。本発明の実施形態では、「復路リンク重み」「往路リンク重み」「双方向リンク重み」は、後に詳述する隣接ノード管理テーブルが含むことができるデータである。しかし他の実施形態では、これ以外の組み合わせを含むようにしてもかまわない。
 「経路品質重み」とは、GDまでの経路上での遅延を数値化したものを指す。
 「復路品質重み」とは、相手となるノード装置から自ノード装置へ至る方向への通信品質を数値化したものを指す。
 「リンク間到達重み」とは、フレームのリンク間での転送の成否を数値化した値である。本発明の実施形態では、「経路品質重み」「復路品質重み」「リンク間到達重み」は、後に詳述する重み付けテーブルが含むことができるデータである。しかし他の実施形態では、これ以外の組み合わせを含むようにしてもかまわない。
 図1は、通信システムの全体概念図である。図1に示すように、ネットワークにはノード装置(a、b、…、s、t)が互いに接続されて含まれている。本通信システムにおいては、スタートノード(図1の例ではノード装置b)からゴールノード(図1の例ではノード装置t)へと情報を伝達するにあたり、各ノード装置が中継器として動作する。
 各ノード装置は、それぞれ固有の識別情報(ID、Identification)を保有する。各ノード装置に割り当てられたIDを、以下ノードIDとする。各ノード装置は、互いに隣接しているノード装置やネットワーク全体については把握していない。初期状態においては、互いのリンクは存在しておらず、各ノード装置は、自身以外のノード装置についてはその存在・状態を把握していない。
 そこで、図1に示す通信システムにおいてスタートノード{b}からゴールノード{t}へと情報を伝達するには、まず、ネットワークを構築する必要がある。ネットワークを構築する手順は、以下のとおりである。
 まず行われるのは、周囲のノード装置の検出である。或るノード装置は、自身の存在を近隣に存在するノード装置へ周期的に通知する。近隣ノード装置への通知には、経路作成に関連した情報が付随されている。各ノード装置は、通知を受信すると、周囲のノード装置についてのリストを作成して、自装置の周囲のノード装置の存在を把握することができる。
 周囲のノード装置を検出したノード装置は、作成したリストに基づいて、自身が情報を転送する相手となるべきノード装置を決定して、そのノード装置に情報を転送する。
 或るノード装置が、情報を転送すべきノード装置を決定するにあたって、周囲に存在する複数のノード装置のうちいずれのノード装置に情報を託せば、目的とするゴールノードに情報を到達させられるかについては、この時点では未だこのノード装置は識らない。そこで、本実施形態に係るノード装置では、周囲のノード装置のいずれに優先的に情報を転送すべきかを示す重み付けテーブルを作成し、重み付けテーブルに格納されている重みに関する情報にしたがって、情報の転送の対象となるべきノード装置を決定する。
 以下、本実施形態に係るノード装置について、具体的に説明する。
 図2は、本実施形態に係るノード装置の概略図である。図2におおまかな概要を示すノード装置1は、フレーム処理部2、リンク管理部3、ルーティング決定部4、FID(フレームID)管理テーブル5、隣接ノード管理テーブル6、及び重み付けテーブル7を有する。図2には明示されていないが、当該技術分野において既知である何らかの種類の記憶装置(例えば、DRAMもしくはフラッシュメモリ)が、FID(フレームID)管理テーブル5、隣接ノード管理テーブル6、及び重み付けテーブル7をデータテーブルとして格納できる。
 フレーム処理部2は、ノード装置1に隣接するノード装置との間で交換されるデータフレームの処理を行う。フレーム処理部2はまた、データフレームを受信した場合に、記憶装置(図2には示されていない)にアクセスしてFID管理テーブル5(請求項の識別情報管理テーブルに相当)を用い、ループの発生の検出も行う。
 リンク管理部3は、記憶装置(図2には示されていない)にアクセスして隣接ノード管理テーブル6を用い、隣接するノード装置の死活及びリンク強度を管理する。
 ルーティング決定部4は、記憶装置(図2には示されていない)にアクセスして重み付けテーブル7(請求項の宛先ノード別重み付けテーブルに相当)を参照し、フレームを次にどの隣接ノード装置に転送すべきかを決定する。重み付けテーブル7は、フレームの最終的な宛先(すなわち、Global Destination (GD))ごとに作成される。
 なお、図1に示すネットワークを構築する複数のノード装置の各々は、それぞれが図2に示すような構造をとるが、以下の説明においては、他のノード装置と区別して、自ノード装置について符号「1」もしくは「1a」を付して説明している。また、各ノード装置は、無線によって接続されていてもよいし、有線によって接続されていても構わない。所望であれば、無線と有線が混在したネットワークに本発明の実施形態にかかる装置もしくはプログラムを適用できることも、本発明の実施形態では想定されている。
 図3は、実施形態に係るノード装置をさらに説明するための、より詳細な模式図である。なお、参照番号についた接尾辞"a"は、同番号の構成要素(element)と同様であるかもしくは類似した構成要素を指していることに留意されたい。なお本明細書では、例えば或る装置XXXと装置XXXaがともに実施形態に包摂されうる。また、参照番号の接尾辞を省略して、接尾辞が無いものと有るものとを包括する概念を指すこともある。例えば、装置XXXと表記したとき、矛盾が生じないかぎりは、装置XXXaのことも含んでいると解釈される。
 図3のノード装置1aは、フレーム処理部2a、リンク管理部3a、ルーティング決定部4a、FID管理テーブル5a、隣接ノード管理テーブル6a、重み付けテーブル7a、受信部10、送信部20を有する。なお、FID管理テーブル5a、隣接ノード管理テーブル6a、及び重み付けテーブル7aは、任意の適切な記憶装置に格納できる。そしてその記憶装置をノード装置1aの内部に収めることもできるし、外部に設置することも可能である。また、そうした記憶装置は、各ノード装置ごとに単一のものであってもよいし、複数存在してもよい。
 上述したLSに対応するノード装置1aが、受信部10にてフレーム(データフレームおよびハローフレームを含む)を受信すると、フレーム分岐処理部12がフレームの種別を識別して、その種別に応じて処理を分岐させる。詳しくは後述するが、フレーム分岐処理部12は、フレームに付されたそのフレームの種別を表すための識別子を用いることができる。
 受信されたフレームがハローフレームであった場合には、フレーム分岐処理部12が、フレームをリンク管理部3aに渡す。リンク管理部3aは、隣接ノード管理テーブル6aを格納した記憶装置にアクセスし、隣接するノード装置の死活及びリンク強度を管理する。そしてリンク管理部3aは、ループが検出された場合には、重み付けテーブル7aを格納した記憶装置にアクセスし、重みに関する情報の登録または更新を行う(詳しくは後述する)。
 受信されたフレームがデータフレームであった場合には、フレーム分岐処理部12が、フレームをフレーム処理部2aに渡す。フレーム処理部2aは、FID管理テーブル5aを格納した記憶装置にアクセスし、FID、LD、およびGSに関する情報を管理する。そしてフレーム処理部2aはフレームをルーティング決定部4aに渡す。また、フレーム処理部2aは、ループが検出された場合には、重み付けテーブル7aを格納した記憶装置にアクセスし、重みに関する情報の登録または更新を行う(詳しくは後述する)。
 ルーティング決定部4aは、重み付けテーブル7aを格納した記憶装置にアクセスして重みに関する情報を得たうえで、フレームをどのノード装置へ送信するかを決定する。そして、送信部20にフレームを渡す。
 送信部20は、ルーティング決定部4aから受けとったフレームを他のノード装置へ送信するにあたり、送信処理部22にFID管理テーブル5aを格納した記憶装置にアクセスさせて、FIDとLDおよびGSに関する情報を登録・更新する。
 本発明の実施形態では、上述したように、隣接ノード装置管理テーブル、FID(フレームID)管理テーブル、重み付けテーブルといったテーブルを使用する。まず、隣接ノード装置管理テーブルについての説明を行う。
 図4は、隣接ノード管理テーブル6もしくは6aの構造を示す図である。隣接ノード管理テーブル6もしくは6aは、ノードID、最終更新時間及びリンク強度を含む。
 ノードIDは、ネットワークを構築するノード装置を識別するために各ノード装置に割り当てられた識別情報である。
 最終更新時間は、各ノードIDが示すノード装置について、最後に情報が更新された日時情報である。具体的には例えば、最終更新時間としてリンク強度が更新された日時情報を格納できる。
 リンク強度は、ノード装置1もしくは1aが、隣接するノード装置から受信したハローフレームに含まれるリンク強度に基づき算出され、適切な記憶装置に格納される。リンク強度は例えば、電波強度やフレーム到達率を用いて算出できる。リンク強度は例えば、双方向リンク重みに対応している。
 上記のとおり、まず、事前にネットワークを構築するために、隣接ノード間で通知用のフレーム(ハローフレーム)が交換される。そして、図2に示す隣接ノード管理テーブル6もしくは図3に示す隣接ノード管理テーブル6a、ならびに図2に示す重み付けテーブル7もしくは図3に示す重み付けテーブル7aが、各ノード装置において作成される。図1の説明においても述べたとおり、本実施形態に係るノード装置1においては、ネットワークトポロジーを把握する必要はない。
 隣接ノード管理テーブル6もしくは6aが作成されると、隣接ノード管理テーブル6もしくは6aに対応する情報が格納されている隣接ノードのうち、フレームを転送すべきノード装置を決定する。フレームを転送すべきノード装置を決定するときに参照される重み付けテーブル7は、フレームを隣接ノード装置から受信したあとの処理にて更新される。
 図5および図6は、フレームのフォーマット例である。図5に示すフレームは、隣接ノードの宛先ノード(Local Destination)についてのノードID(LD)、隣接ノードの送信元ノード(Local Source)についてのノードID(LS)、宛先ノード(Global Destination)についてのノードID(GD)、送信元ノード(Global Source)についてのノードID(GS)、フレームID(FID)、フレームタイプ(TYPE)、データ長(DATALEN)、及びデータ本体(DATA)を含む。
 LDには、ノード装置1の隣接ノードのうち、フレームを転送する宛先ノードのノードIDが格納される。
 LS には、LDとなる隣接ノード装置へフレームを転送する送信元のノード装置のノードIDが格納される。例えば、LDがノード装置1に隣接するノード装置のいずれかのノードIDであったならば、LSはそのノード装置1のノードIDとなる。
 GDには、フレームの本来の宛先のノードIDが格納され、GSには、フレームの本来の送信元のノードIDが格納される。
 フレームIDは、フレームを識別するための識別情報が格納される。
 フレームタイプには、そのフレームの種類を示す情報が格納される。フレームの種類としては、例えば、データフレームや、ハローフレーム等があるが、これらに限定はされない。
 データ長には、データ本体の長さ(データ長、またはフレームサイズとも称する)が格納される。
 データ本体には、ネットワークを伝播する対象であるデータが格納される。
 なおここに示したフォーマットはあくまで一例であることに留意されたい。本発明の別の実施形態では、これとは異なったフォーマットを使用することもでき、かつその別の実施形態は本発明の範囲に包摂されうる。
 図7は、或る実施形態にかかる、隣接ノード管理テーブル6もしくは6aに基づくフレーム転送処理を説明する図である。このうち、図7(a)は、隣接ノード装置ごとの重みの概要を示す図であり、図7(b)は、隣接ノード管理テーブル6もしくは6aの簡単な例を示す図である。
 この実施形態に係るノード1もしくは1aは、隣接するノード装置のうちいずれかからフレームを受信すると、フレームの送信元すなわちLSであるノード装置以外のうち、重みに関する情報に鑑みてより優先度の高いノード装置に、そのフレームを転送する。ノード装置1もしくは1aは、隣接ノード装置のそれぞれに対してリンク番号を付しており、これによって各隣接ノード装置を識別している。
 なお、この実施形態においては、重みに関する情報(例えば、双方向リンク重みなど)として用いる値を、0以上1以下の範囲として設定してある。この値が小さいほど、優先度が高いものとして扱う。重みに関する情報初期値として例えば0.5を設定しておき、その後のフレーム転送の成否やループの検出の有無等に応じて変更してゆくことができる。
 重みに関する情報の設定及び更新は、後述する重み操作関数(例えば、リンク強度を考慮した関数)により行う。重み操作関数は、ネットワーク全体の振る舞いに影響するため、ネットワークの用途に応じて変更する必要があるだろう。
 図7(a)においては、リンク番号iの隣接ノード装置からフレームを受信した場合の、重みに関する情報による転送先ノード装置の決定方法を示している。
 リンク番号iの隣接ノード装置から転送されたフレームを受信すると、ノード装置1もしくは1aは、保有する隣接ノード管理テーブル6もしくは6aのうち、GDのノード装置に対応する重み付けテーブルを参照する。そして、重みに関する情報を踏まえて最も優先度が高く、リンク番号が「i」以外である隣接ノード装置に対して、受信したフレームが転送されることになる。
 図7(b)に示すように、隣接ノード管理テーブル6もしくは6aでは、隣接ノード装置ごとに割り当てられるリンク番号と、リンク番号に対応付けた隣接ノード装置の重みを格納する。なお、リンク番号は、ノードIDで代用することも可能である。ノード装置1もしくは1aは、リンク番号iの隣接ノード装置から受信したフレームにしたがって、隣接ノード管理テーブル6もしくは6aを更新し、重みに関する情報を操作する。
 図8は、データの転送結果により重みを操作する処理を説明する図である。
 図8に示す例では、重みに関する情報として、隣接ノード装置A、B、C、Dに対しそれぞれ、リンク番号1, 2, 3, 4 および重み w1, w2, w3, wを設定してある。
 なお、例えばノード装置間の通信が無線である場合には、通信時における環境やノード装置間の距離等が通信品質に影響することがあり、ノード装置間の通信が有線である場合には、例えばトラフィック量が通信品質に影響することがある。その影響を考慮し、ここでは重みの初期値を0.5とし、かつその値の範囲を0以上1以下としているが、これはあくまで一例であって、それ以外の値をとりうる重みを用いる実施形態が想定できる。また、この実施形態においては、重みが小さい(0に近い)ほど優先度が高いとしているが、これもまた一例である。それ以外の優先度の定めかた(例えば、重みが大きいほど優先度が高いような定めかた)をした実施形態もまた想定されている。
 また、重み付けテーブルには、フレームを転送する際に優先的に転送すべき隣接ノード装置と、それ以外のノード装置とを示す情報を格納してもよい。例えば、フラグ等を用意しておき、フレームの転送の成否に応じて値を重み付けテーブルに設定することも可能である。
 ノード装置1もしくは1aは、これまで隣接ノード装置にフレームを転送した結果に応じて重みに関する情報(例えば双方向リンク重み)を操作する。まず、各重みの大小関係が、w<w<w<wであるとする。すなわち、隣接ノード装置Aについての優先度が最も高く、隣接ノード装置Dについての優先度が最も低いと仮定する。
 このような場合にノード装置1もしくは1aがフレームを隣接ノード装置A~D以外の隣接ノード装置iから受信すると、ノード装置1もしくは1aは、最も優先度の高い隣接ノード装置Aから順にフレームを転送しようとする。隣接ノード装置Aへのデータ転送に失敗すると、次に優先度の高いノード装置Bにデータを転送する。
 最終的に、隣接ノード装置A及びBのいずれについてもデータ転送が失敗し、隣接ノード装置Cについてはデータ転送が成功したとすると、ノード装置1もしくは1aは、隣接ノード装置A、Bについては重みを最大(最悪値)にして、優先度を最低に設定する。そして、隣接ノード装置Cについての重みが減らされ、優先度が高く設定されることになる。
 次回以降のデータフレーム転送においては、このようにして更新された重みの関係(w<w<w=w)に基づいて、フレームの転送先(LD)を決定し、最も優先度の高い隣接ノード装置Cからフレームの転送を試みることとなる。
 次に、ループの発生を検出する方法について説明する。
 図9は、FID管理テーブル5もしくは5aの構成の一例を示す図である。図9に示した実施形態においては、FID管理テーブル5もしくは5aは例えば、FIFO(First In First Out)型バッファである。FID管理テーブル5もしくは5aには、フレームID(FID)、送信元ノードGSのノードID、転送先ノードLDのノードID、及び送信元ノードLSのノードIDが含まれる。FID、GS/LD/LSのノードIDの定義については、図6に示すデータフレームのそれぞれ対応するフィールドと同様である。
 ノード装置1もしくは1aは、隣接ノード装置からフレームを受信すると、フレームのFID及びGSのフィールドの値と、FID管理テーブル5もしくは5aに格納されているレコードとを比較する。比較した結果、受信したフレームと同じFID及びGSを有するレコードがFID管理テーブル5に格納されていた場合は、ノード装置1もしくは1aは、そのフレームが過去に一度受信したフレームと同一のフレームであると判断して、「ループが発生した」か、「途中の経路の遮断により戻りが発生した」と見做す。ループまたは戻りの発生が検出された場合には、重み付けテーブル7もしくは7aを更新し、そのフレームのLSのノードIDに対応する重みに関する情報に、最悪値(この実施形態では最大の値)を設定する。
 一方、同一のFID及びGSを有するレコードが存在しなかった場合には、ノード装置1もしくは1aが、受信したフレームからFID、GS、LD、及びLSの各フィールドから値を取り出して、FID管理テーブル5に1レコード登録する。
 つづいて、ノード装置がデータフレームを受信した際に行う処理に関し、よりいっそう詳しく説明を行ってゆく。
 図10及び図11は、或る実施形態に係るノード装置1もしくは1aのデータフレーム受信時の処理を示したフローチャートである。
 まず、ステップS1で、初期化処理を実行する。ステップS1の初期化処理においては、例えば、無線で隣接ノード装置と通信を行う場合には、使用周波数を合わせる処理や、変調方式を決定する処理等を実行する。なお、ステップS1の初期化処理は、ノード装置1もしくは1aをネットワークに設置したときにのみ実行される。
 ステップS2では、データフレームの受信を待機する。ステップS2で、データフレームを受信すると、ステップS3に進み、LDのフィールドに格納されているノードIDが自装置のノードIDであるか否かを判定する。LDに自装置以外のノードIDが格納されていた場合には、ステップS2に戻って待機を続ける。
 また、ステップS1の処理とステップS2の処理との間には、上記のとおり、ハローフレームによるネットワーク構築処理も行われているが、ハローフレームの送受信については図10及び図11に示す処理とは異なるスレッドによって実行されるため、ここでは説明を省略する。
 ステップS3で、LDのフィールドに自装置のノードIDが格納されていると判定されると、ステップS4に進む。
 ステップS4では、GDのフィールドに格納されているノードIDは、自装置のノードIDであるか否かを判定する。ステップS4において、GDのフィールドに、自装置のノードIDが格納されていると判定された場合は、つまりネットワークに跨る一連のデータ伝播の終着点が自ノード装置であったということである。したがってフローはステップS10に進み、受信したデータフレームを(上位層で)処理し、一連の処理を終了する。
 ステップS4において、GDのフィールドに格納されているノードIDが、自装置以外のノードIDであると判定されると、フローはステップS5に進む。そして、ステップS5で、FID管理テーブル5に、受信したデータフレームのFID及びGSとそれぞれ一致するFID及びGSの組み合わせを有するレコードが、存在するか否かを判定する。
 ステップS5において、FID管理テーブル5にデータフレームのFID及びGSと一致するレコードが存在したと判定されると、フローはステップS6に進む。ステップS6では、FID管理テーブル5のうち、FID及びGSがいずれもデータフレームのFID及びGSと一致すると判定されたレコードから、LDを取り出す。そして、ステップS7で、データフレームのGDに対応する重み付けテーブル7もしくは7aについて、ステップS6において取り出したLDと一致するノードIDを有するレコードについて更新を行う。例えばこの実施形態では、項LastとしてFID管理テーブルで最後にFIDを持つフレームを送出したノードIDを設定している。そしてこの項Lastに対応する重みに関する情報が、優先度がもっとも低い最悪値(例えば1.0)となるように変更できる。重み付けテーブル7もしくは7aを更新すると、図11の記号(A)に進む。
 一方、ステップS5において、FID管理テーブル5に一致するFID及びGSは存在しないと判定されると、フローはステップS8に進む。ステップS8では、データフレームのGDに対応する重み付けテーブル7もしくは7aが存在するか否かを判定する。
 ステップS8において、データフレームのGDが示すノード装置についての重み付けテーブル7もしくは7aが存在しないと判定されると、フローはステップS9に進む。そして、ステップS9では、データフレームのGDについての重み付けテーブル7もしくは7aを作成し、その後フローは図11の記号(A)に進む。
 なお他の実施形態においては、ステップS9にて、例えば、図5に示す隣接ノード管理テーブル6もしくは6aのリンク強度を参照して重み付けテーブルを作成してもよい。
 ステップS8において、データフレームのGDが示すノード装置についての重み付けテーブル7もしくは7aが存在すると判定された場合には、特に処理を行わず、図11の記号(A)に進む。
 図11に示す処理においては、まず記号(A)からステップS11に進み、重み付けテーブル7もしくは7aから最も優先度の高い評価値に対応するノードIDを取得する。そしてステップS12で、取得したノードIDに対応する適切なノード装置を発見することができるか否かを判定する。
 ステップS12において、適切なノード装置を発見することができたと判定された場合には、フローはステップS13に進み、ステップS11で取得したノードIDに対してデータフレームを転送する。
 そして、ステップS14では、転送したデータフレームに含まれるデータに基づき、FID管理テーブル5にフレームのFID及びGSと、LDと、LSとを追加する。
 つづいてステップS15で、データフレームの転送が成功したか否かを転送先ノード装置からの応答により判断する。例えば、転送先ノード装置からack信号を受信した場合には転送が成功したと判定し、所定時間経過してもack信号を受信しなかった場合には失敗したと判定するようにできる。成功したと判定された場合には、ステップS16で、データフレームのGDが示すノード装置についての重み付けテーブル7もしくは7aについて、転送先のノード装置についてのノードIDに対応する評価値を操作しての優先度を上げ、図10の記号(B)に戻る。
 一方、ステップS15において、データフレームの転送が失敗したと判定された場合には、ステップS17で、転送先のノード装置についてのノードIDに対応する評価値を操作して優先度を下げ、ステップS11に戻る。
 以降は、データフレームの転送が成功するか、重み付けテーブルに適切なノードIDが存在しなくなるまで、ステップS11以降の処理を繰り返す。
 ステップS12において、重み付けテーブル7もしくは7aから適切なノード装置(ノードID)が発見できないと判定された場合には、ステップS18に進み、受信したデータフレームをLSが示すノード装置に転送し、図10の記号(B)に戻る。
 以上説明したように、本実施形態に係るノード装置1もしくは1aによれば、データフレームを転送するときに、保有する重み付けテーブル7もしくは7aを参照して優先的にデータ転送すべきノード装置を判断し、データ転送の成否により重みに関する情報(例えば評価値)を更新する。重みに関する情報にしたがって優先的にフレームを転送すべきノード装置を判断することで、ループの発生にともなうデータフレームの戻りや、ネットワークの状態の変化によりそれまで通信可能であった経路が遮断された際のデータフレームの戻りを検出し、そのことを踏まえて経路を迂回して最適な経路で通信を継続することが可能となる。なお上述したように、重み付けテーブル7もしくは7aはGDごとに作成されうるものであるが、ここではあくまで一例として、わかりやすくするためにひとつの重み付けテーブルだけを考えていることに留意されたい。
 ところで、図1に示す通信システムにおいては、各ノード装置がネットワークの状態を監視している。以下、本実施形態に係るノード装置によるネットワークの監視方法について説明する。
 上記のとおり、各ノード装置は、ハローフレームに他のノード装置から受信した電波の通信品質に関わる情報を含めて送信している。ノード装置は、他のノード装置から受信したハローフレームを参照して、隣接ノード装置の通信品質を算出し、図5に示す隣接ノード管理テーブル6もしくは6aに算出した通信品質に関わる情報を保持する。或る実施形態においては、遅延及びホップ数により通信品質を決定する。
 図12は、ハローフレームのうちの所定の領域に格納されるハローヘッダのフォーマットを示す図である。図12に示すように、ハローヘッダは、グローバル宛先アドレス(すなわちGD)、ホップ数h、経路品質重みd、復路品質重み、及びノードタイプを含む。
 グローバル宛先アドレス(GD)は例えば、図12に示すハローヘッダを含むハローフレームの最初の送信元(GS)であるノード装置が持つ、重み付けテーブル7に対応するグローバル宛先アドレス(GD)の情報である。
 ホップ数h は例えば、このハローフレームの送信元から最終目的地(GD)であるノード装置までのホップ数の情報である。
 経路品質重みdは、GDまでの経路上での遅延から求めた値が格納される。
 復路品質重みは、相手のノード装置(ここでは、ハローフレームを送信したノード装置)から自ノード装置へ至る方向の通信品質に基づいて求めた値が格納される。
 ノードタイプには、ゲートウェイ、中継器、及び端末等の種類が定義される。
 ハローヘッダに格納される情報のうち、経路品質重みdを求める方法について、図13を参照してさらに具体的に説明してゆく。
 図13は、本実施形態に係るノード装置1もしくは1aにおいて、遅延により通信品質を計測する方法を説明する概念図である。「発生元」のノード装置は、定期的にハローフレームを外部に向けて送出している。図13中に楕円形に示している網掛け部は、発生元ノード装置が送信するハローフレームを受信可能な範囲を示している。ノード装置a及びbは、発生元のノード装置から順次送出されるハローフレームを受信し、1つのフレームを受信してから次のフレームを受信するまでに要する時間を計測する。以下、次のフレームを受信するまでに要する時間を、「受信周期」とも称する。
 図13において、ノード装置a及びbにおける受信周期と受信回数との関係を図中のグラフ(縦軸は出現回数、横軸は受信間隔)に示す。図示するとおり、各ノード装置における受信周期と受信回数との関係は、一般的に、正規分布となる。
 そして、一般的に、発生元のノード装置からの距離が比較的遠いノード装置bでは、フレームロスが発生しやすくなる。従って、ノード装置bでは、ノード装置aよりもフレームロスによるフレームの受信抜けが発生しやすくなり、次のフレームを受信するまでの時間が長くなる傾向にある。このことから、本発明にかかる或る実施形態においては、受信周期Tが大きいことを、遅延が大きいことであると見做すような近似を行って、受信周期Tにより通信品質を求めている。
 受信周期により通信品質を求めるやりかたを説明する。まず、ある時刻tにハローフレームを受信し、次に時刻がt+tにハローフレームを受信したとする。この場合、受信周期T=tである。所定の期間に観測された受信周期の集合をT{t、t、…、t|n∈N}(t(i=1、2、…、n)は各時点での観測値)とする。この場合の観測された受信周期に基づく標準偏差lは、以下の式(1)で表される。なお、式中の
Figure JPOXMLDOC01-appb-M000001
は、受信周期の観測値の平均値である。
Figure JPOXMLDOC01-appb-M000002
                   (1) 
 上記(1)式により得られる標準偏差を、復路リンク重みとして、隣接ノード管理テーブル6もしくは6aの所定のフィールド(不図示)に格納する。なお、(1)式で求めた復路リンク重みを、ハローフレームに格納して相手のノード装置に送信すると、相手のノード装置は、受信した情報から往路リンク重みを得られる。このように、互いに相手のノード装置から受信したハローフレームにより自装置内で復路リンク重みを求め、求めた復路リンク重みを今度はハローフレームに含めて相手のノード装置と交換することで、往路リンク重みを得られるのである。
 取得した往路リンク重み及び復路リンク重みから、双方向リンク重みを算出するにあたっては、当該技術分野において適切とされるさまざまな手法を使用可能である。その一例として、双方向リンク重みは、以下の式(2)で算出可能である。
  (双方向リンク重み) = [{(往路リンク重み)+1}{(復路リンク重み)+1}-1]1/2 (2)
 図14は、本発明の或る実施形態がアドホックネットワークにおいて使用可能な、ハローヘッダを含んだハローフレームの詳細なフォーマットを詳細に説明するための図である。なお、本発明の別の実施形態では、これとは異なったフォーマットを使用でき、かつその別の実施形態は本発明の範囲に包摂されうる。
 図14に示したフレームは、おおまかには、アドホックヘッダと、圧縮ヘッダと、ペイロードとに分けられる。
 この実施形態においては、アドホックヘッダは、"ローカル宛先アドレス"(LD)と、"ローカル差出アドレス"(LS)と、フレームの種別を表す"フレームタイプ"と、圧縮後のフレーム のサイズを表す"フレームサイズ"というフィールドを有している。
 圧縮ヘッダは、ペイロードの圧縮手法を示す"圧縮タイプ"と、圧縮前のフレームのサイズを表す"フレームサイズ"というフィールドを有している。各ノード装置は、この圧縮タイプを考慮して、適切にペイロードの伸張を行うことができる。
 また、ペイロードには、ハローメッセージヘッダと、一個以上のハローヘッダと、署名を示すハッシュとが圧縮して含まれている。なお、この実施形態にかかるフレームで圧縮を行っているのはフレームのサイズを軽減して通信帯域を節約するという効果を得るためである。当然のことながら、圧縮をせずにデータを有するようなフレームもまた、本発明の他の実施形態に包摂されている。
 ペイロードに含まれるハローメッセージヘッダには、サービスの種別を表す"サービスタイプ"と、ペイロード内の分割状況を表す"分割情報"と、ペイロードが含むハローヘッダの個数を示す"ハローヘッダ数"と、ノード装置のIDを示す"装置ID"と、暗号化された情報を復号するための"アクセスキー"というフィールドが含まれる。なおこの"装置ID"というフィールドには、図22に関連して後述するハロー要求の送信元であるノード装置のIDが格納できる。 
 そしてペイロードに含まれる一個以上のハローヘッダは、"グローバル差出アドレス"(GS)と、ゲートウェイ(GW)の情報についてのホップ数を表す"GW情報ホップ数"と、前述の"経路品質重み"(d)および"復路品質重み"というフィールドを含んでいる。
 なお以上に述べてきたフィールドの種類および順番はあくまで例に過ぎない。本発明の他の実施形態においては、上述したフィールドとそれ以外の当業者が適切と考える任意のフィールドとを、任意の適切な順番で各ヘッダ内に配置できる。
 図15は、重み付けテーブル7もしくは7aの構造をさらに詳細に説明する図である。図15に示す重み付けテーブル7もしくは7aは、グローバル宛先アドレス(GD)、ローカル宛先アドレス(LD)、ホップ数h、リンク間到達重みw、経路品質重みd、及び評価値Eを含む。また図15には示していないが、重み付けテーブル7もしくは7aはこの他の情報を含んでもよく、例えば、データを更新した時間情報を示す最終更新時間のデータを含んでもよい。上述したように、こうした重み付けテーブルは、それぞれのノード装置が有するものである。
 グローバル宛先アドレス(GD)には、受信したハローフレーム(ここでは、ノード装置を起動してから、図16~図21に関連させて後述するハローフレーム受信処理が複数回行われたとして、そのいずれかの受信処理において受信したハローフレーム、という意味として解釈されたい) のハローヘッダ内のグローバル宛先 アドレス(GD)のフィールドに示されるデータが格納される。
 ローカル宛先アドレス(LD)には、受信したハローフレームに含まれているローカル差出アドレス(LS)に示されるデータが格納される。つまり、このハローフレームを受信したノード装置を主体として考えたとき、受信したハローフレームのLSが、次に別のフレームを送信する際のLD候補となるということである。
 ホップ数hは、この重み付けテーブルを有するノード装置からGDまでのホップ数が格納されるデータである。つまり、受信したハローフレームのハローヘッダ内のホップ数に示される値に1を加算した値が格納される。
 ノードタイプは、ノードの種類を定義するデータであって、受信したハローフレームのハローヘッダ内のノードタイプに示されるデータが格納される。
 リンク間到達重みwは、データフレームのリンク間での転送の成否を数値化したものである。この実施形態では、リンク間到達重みwとして、受信したハローフレームのハローヘッダ内の復路品質重みに基づいて算出された データが格納される。
 経路品質重みdは、図12及び図13を参照して説明したとおり、ハローフレームの受信周期の分散に基づいて算出される値である。
 評価値Eは、受信したハローフレームのハローヘッダ内の上記ホップ数h、リンク間到達重みw、及び経路品質重みdを用いて算出した、総合的な経路評価情報が格納される。
 本技術分野では、ホップ数hが増すにつれ指数関数的に通信不安程度が高まる(スループットが低下する)ことが経験的に知られている。これを踏まえて、例えば、評価値Eを以下の(3)式で表すことができる。
      E(h,w,d)=2(h+w)+d   (3)
 とはいえ、上述した(3)式を用いること以外にも、適切に評価値Eを導出する手法を用いてもよく、かつそうした手法は本発明の実施形態群に包摂されうる。本発明の他の実施形態においては、ホップ数h、経路品質重みd、リンク間到達重みw、受信信号強度、もしくはその他の当該技術分野にて適切と考えられる任意のパラメータ、のうちの少なくとも一種を使って、適切に評価値Eを導出することができる。例えば、E = d+h+5w+20/r という式を使って評価値Eを算出してもよい(ここでdは経路品質重み、hはホップ数、wはリンク間到達重み、rは最新のハローフレームを受信した際の受信信号(電力)強度である)。
 更に、上記リンク間到達重みwを定義し、データ転送が失敗した場合にはw=w+1、成功した場合にはw=w-1(例えば、0を最小値とする)とし、wを上記(3)式のようにすることで、データ転送時の隣接ノードの微調整を行うことができる。
 このように、本実施形態に係るノード装置1もしくは1aは、他のノード装置からのハローフレームの受信状況に基づき、ネットワークの状態を監視することができる。
 図16から図21は、本発明の実施形態に係るノード装置のハローフレーム受信時の処理を示した詳細なフローチャートである。以下、これらの図にわたってフローを説明してゆく。以下に本発明の実施形態に係るノード装置の処理をおおまかに述べる。
(i) ステップS1600からS1614にて隣接ノード管理テーブルの更新を行う。
(ii) ステップS1700からS1710’にて、ハローフレームのハローヘッダを用いてハローヘッダのGDごとに、自ノード装置の持つ重み付けテーブルに登録しているハローフレームの送信元(LS)の評価値の更新を行う。
(iii) ステップS1850からS1700’にて、GDがハロー送信元(LS)である自ノード装置の持つ重み付けテーブルの評価値の更新を行う。
(iv) ステップS2000からS2010’にて、自ノード装置の持つ重み付けテーブルにハローフレームの送信元(LS)が登録されていない場合に新たに登録し、自ノード装置の持つ重み付けテーブルにハローヘッダのGDが登録されていない場合に新たに登録する。
 この実施形態にかかるフローはまず、図16にて、視点を置くノード装置(自ノード装置)にハローフレームが受信されたところから始まる。
 ステップS1600からS1614では、ハロー(HELLO)フレームの送信元(LS)に対応する隣接ノード管理テーブルのレコードにおける重みに関する情報を更新する。
 ステップS1600では、ハローフレームを受けとったノード装置が、そのノード装置が有する隣接ノード管理テーブル中にハローフレームの送信元(LS)のノード装置に該当するレコードが存在するかどうかを確認するために検索を行う。この検索に際しては、このLSからの前回のハローフレーム受信時刻および今回のハローフレーム受信時刻とを比較する。こうすることで、受信時刻の逆転が起こっていないかを確認してLSの"なりすまし"(つまり、LSを偽って送られているフレーム)が無いかを判断することも可能となる。
 ステップS1602にて、検索によりハローフレームの送信元(LS)が隣接ノード管理テーブル内に無いことがわかったならば、フローはステップS1604へ進む。そして、隣接ノード管理テーブルにLSを新規に追加し、復路リンク重みの初期値を設定する。ステップS1602にて、検索によりハローフレームの送信元(LS)が隣接ノード管理テーブル内に在ることがわかったならば、フローはステップS1606へ進む。そして、隣接ノード管理テーブル中でのLSに該当するレコードにて、復路リンク重みの値を更新する。
 その後のステップS1608では、ハローフレーム内のハローヘッダに、自ノード装置の情報(IDなど)が含まれているかという検索を行う。このときに、LSの持つノード間のリンク品質情報(すなわち、LSからの復路リンク重み)を参照する。そしてステップS1610にて自ノード装置の情報が存在することがわかった場合に、フローはステップS1612に進み、隣接ノード装置に関する往路リンク重みの計算を行う。
 その後のステップS1614では、隣接ノード装置に関する双方向リンク重みを算出する。そして図17の記号(I)へ進む。
 図17のステップS1700では、まず自ノード装置が有する重み付けテーブルのレコード一個ごとについてのくりかえし処理(ループ処理)を開始する。そしてステップS1710でさらに、ハローフレームに含まれるハローヘッダ一個ごとのくりかえし処理をネストする。
 ステップS1712では、重み付けテーブルのGDと、ハローフレーム内のハローヘッダのGD(つまり、本来はハローフレームの送信元(LS)が持つ重み付けテーブルに含まれていたもの)が一致するかを判定する。
 ステップS1714にて重み付けテーブルのGDとハローヘッダのGDとが一致しなかったら、フローは図17の記号(IV)へ飛び、ステップS1710’にて1つのくりかえしサイクルを了える。ステップS1714にて重み付けテーブルのGDとハローヘッダのGDとが一致したら、フローはステップS1716に進む。
 ステップS1716では、ハローフレームの送信元(LS)に対応する重み付けテーブルに、自ノード装置がフレームを送る宛先となるLD候補が存在するかを検索する。
 ステップS1718にて、宛先となるLD候補(宛先LD候補)が存在したら、ステップS1720にて重み付けテーブル中のその宛先LD候補についてのレコードで、ホップ数hを、ハローヘッダのホップ数+1として更新する。そしてステップS1722で、このハローフレームに関する経路品質重みdを算出し、宛先LD候補に関する経路品質重みdを更新する。なおここでいうハローフレームに関する経路品質重みdとは例えば、ハローフレームの送信元から観た経路品質重みと、ハローフレームの受信周期の分散から得られる復路品質重みとから算出される経路全体(もしくは経路全体の少なくとも一部分)での双方向リンク重みを、加算または何らかの演算を施した値が、すなわち経路品質重みとなる。これは要するに、或るノード装置において、受信したハローフレームに関する経路品質重みdを、重み付けテーブルの経路品質重みdに加えられ、そうして得られた更新された経路品質重みdが、今度は送信されるハローフレームに収められた経路品質重みとなって、次のノード装置へと送信される、ということである。端的にいえば、ハローヘッダごとの双方向リンク重みの積算が、重み付けテーブルの経路品質重みdとなると考えてもよい。 この実施形態においては、一連のくりかえし処理S1710~S1710’またはくりかえし処理S1700~S1700’のあいだに得られる各々の双方向リンク重みを積算して、くりかえし処理の対象となっていた重み付けテーブルの経路品質重みdを算出できる。さてそれから図18の記号(II)へフローを進める。
 ステップS1824では、宛先LD候補に関する受信電力(なお、図15では受信電力についてのフィールドは示していない)を、このハローフレームを受信した際の受信電力として更新する。ステップS1826では、このハローフレームに関する評価値Eを上述したように算出して、宛先LD候補に関する評価値Eを更新する。それからステップS1828にて、宛先LD候補に関するエージングカウンタ(重み付けテーブルの有効期間を設定するための手段)をリセットする。そしてフローはステップS1840に進み、宛先LD候補を評価値の順にソートして、優先度的に好ましい候補を絞りこむようにできる。そしてステップS1710’にて1つのくりかえしサイクルが完了する。
 一方、ステップS1718にて、宛先となるLD候補が存在しなかった場合には、まずそのハローフレームの送信元(LS)を、重み付けテーブルに宛先となるLD候補として新規に登録をし、フローはステップS1730に進む。ステップS1730にてその新たな宛先LD候補についてのレコードで、ホップ数hを、ハローヘッダのホップ数+1として更新する。そしてステップS1732で、このハローフレームに関する経路品質重みdを算出し、宛先LD候補に関する経路品質重みdを更新する。それから図18の記号(III)へフローを進める。ステップS1834では、宛先LD候補に関する受信電力を、このハローフレームを受信した際の受信電力として更新する。ステップS1836では、このハローフレームに関する評価値Eを上述したように算出して、宛先LD候補に関する評価値Eを更新する。それからステップS1838にて、宛先LD候補に関するエージングカウンタをリセットする。そしてフローはステップS1840に進み、宛先LD候補を評価値の順にソートし、ステップS1710’にて1つのくりかえしサイクルが完了する。
 くりかえし処理S1710~S1710’が一通り完了したところで、フローはステップS1850へ進む。
 ステップS1850では、くりかえし処理S1710~S1710’における処理にてハローヘッダを用いた宛先LD候補の更新があったか、すなわちステップS1714からS1716へ一度でも進んだかどうかを確認する。更新があった場合には、フローは図19の記号(VII)へ飛び、ステップS1700’にて1つのくりかえしサイクルを了える。更新が無かった場合には、フローはステップS1852へ進む。ステップS1852では、ハローフレームの送信元であるノード装置(LS)にあたる値が、(図15に示したような)重み付けテーブルのGDにあたるかどうかを判定する。 この実施形態ではこのようにして、ルーティングの評価を行っている。
 ハローフレームの送信元であるノード装置(LS)が、重み付けテーブルのGDと一致しなかった場合には、フローは図19の記号(VI)へ飛び、ステップS1930で宛先LD候補を評価値順にソートする。そしてステップS1700’にて1つのくりかえしサイクルを了える。
 ハローフレームの送信元であるノード装置(LS)が、重み付けテーブルのGDと一致した場合には、フローはステップS1854へ進む。そして、ハローフレームの送信元(LS)に対応する重み付けテーブルに、隣接ノードの候補が存在するかどうかを検索する。そして図19の記号(V)を挟んでステップS1900にて、宛先LD候補が有る場合にはフローはステップS1910へ進む。ステップS1910では、このハローフレームに関する経路品質重みdを計算して、その宛先LD候補に関する経路品質重みdを更新する。ステップS1912では、宛先LD候補に関する受信電力を、このハローフレームを受信した際の受信電力として更新する。ステップS1914では、このハローフレームに関する評価値Eを上述したように算出して、宛先LD候補に関する評価値Eを更新する。それからステップS1916にて、宛先LD候補に関するエージングカウンタをリセットする。なお紙幅の関係で省略したが、宛先LD候補が複数存在する場合にはステップS1910からステップS1916をその個数分くりかえすこともできる。そしてフローはステップS1930に進み、宛先LD候補を評価値の順にソートし、ステップS1700’にて1つのくりかえしサイクルが完了する。
 一方、ステップS1900にて宛先LD候補が無い場合にはフローはステップS1920へ進む。ステップS1920では、新たな宛先LD候補のホップ数を初期値(ここでは1)に設定する。ステップS1922では、宛先LD候補のリンク間到達 重みwに初期値(例えば0.5)を設定する。ステップS1924では、このハローフレームに関する経路品質重みdを計算して、その宛先LD候補に関する経路品質重みdを更新する。ステップS1926では、宛先LD候補に関する受信電力を、このハローフレームを受信した際の受信電力として更新する。ステップS1928では、このハローフレームに関する評価値Eを上述したように算出して、宛先LD候補に関する評価値Eを更新する。それからステップS1929にて、宛先LD候補に関するエージングカウンタをリセットする。そしてフローはステップS1930に進み、宛先LD候補を評価値の順にソートし、ステップS1700’にて1つのくりかえしサイクルが完了する。
 くりかえし処理S1700~S1700’が一通り完了したところで、フローは記号(VIII)を挟んで図20のステップS2000へ進む。
 ステップS2000では、ハローフレームの送信元であるノード装置(LS)に対応する(そのLSがGDとなっている)エントリが、自ノード装置の持つ重み付けテーブル(群)のうちに存在するかどうかを確認する。重み付けテーブルに該当エントリが存在した場合には、フローはステップS2010へ飛ぶ。重み付けテーブルに該当エントリが存在しなかった場合には、フローはステップS2001へ進む。
 ステップS2001では、そのLSをGDとした新たな重み付けテーブルを作成する。ステップS2002では、新たな宛先LD候補のホップ数を初期値(ここでは1)に設定する。ステップS2003では、宛先LD候補のリンク間到達 重みwに初期値(例えば0.5)を設定する。ステップS2004では、このハローフレームに関する経路品質重みdを計算して、その宛先LD候補に関する経路品質重みdを更新する。ステップS2005では、宛先LD候補に関する受信電力を、このハローフレームを受信した際の受信電力として更新する。ステップS2006では、このハローフレームに関する評価値Eを上述したように算出して、宛先LD候補に関する評価値Eを更新する。それからステップS2007にて、宛先LD候補に関するエージングカウンタをリセットする。それからフローはステップS2010に進む。
 ステップS2010では、ハローフレームに含まれるハローヘッダ一個ごとのくりかえし処理を開始する。
 記号(IX)を挟んで図21のステップS2100では、ハローヘッダのGDが、自ノード装置の持つ重み付けテーブルに存在するかどうかを確認する。重み付けテーブルに該当エントリが存在した場合には、フローはステップS2010’へ飛び、1つのくりかえしサイクルが完了する。重み付けテーブルに該当エントリが存在しなかった場合には、フローはステップS2101へ進む。
 ステップS2101では、そのハローヘッダのGDに対応した新たな重み付けテーブルを作成するとともに、そのテーブルに、ハローフレームの持つアドホックヘッダのLSをフィールドLDの値として持つようなエントリを作成する 。ステップS2102では、新たな宛先LD候補のホップ数hを、ハローヘッダのホップ数+1として設定する。ステップS2103では、宛先LD候補のリンク間到達 重みwに初期値(例えば0.5)を設定する。ステップS2104では、このハローヘッダに関する経路品質重みdを使って経路品質重みdを再計算して、その宛先LD候補に関する経路品質重みdを初期化する。ステップS2105では、宛先LD候補に関する受信電力を、このハローフレームを受信した際の受信電力として更新する。ステップS2106では、このハローヘッダに関する評価値Eを算出して、宛先LD候補に関する評価値Eを更新する。それからステップS2107にて、宛先LD候補に関するエージングカウンタをリセットする。それからフローはステップS2010’に進み、1つのくりかえしサイクルが完了する。
 そしてくりかえし処理S2010~S2010’が一通り完了すると、一連のフローは終了する。
 図22は、ハローフレームの交換シーケンスを示す図である。各ノード装置は、ハローフレームを近隣のノード装置に向けてブロードキャスト送信する。ハローフレームには、各ノードまでの経路の中で最適と判定されたリンク情報が含まれている。各ノード装置は、ハローフレームを受信すると、保有する隣接ノード管理テーブル6もしくは6aおよび重み付けテーブル7もしくは7aと比較して、各ノード装置についての重みに関する情報の作成及び更新を行っていく。また、隣接ノード管理テーブル6もしくは6aを参照して、ハローフレームのリンク情報の更新を行う。この動作を各ノード装置が複数回繰り返すことで、ノード装置は、他のノード装置のそれぞれまでのルーティングを可能とするリンク先情報を複数個持つことが可能となる。
 或る実施形態においては、ノード装置1もしくは1aが、特定のノード装置からそれまで受信できていたハローフレームを所定の期間内(例えば30分以内)に受信できなくなった場合に、その特定のノード装置を、通信不能状態にあると見做して 、その旨をゲートウェイ装置に通知することができる。また、受信したハローフレームの内容から判断を行ったうえで、異常が検出されればその旨をゲートウェイ装置へ通知することもできる。更には、隣接ノード管理テーブル6もしくは6aを参照して、あるノード装置について異常が検出された場合には、上記重み付けテーブル7もしくは7aの対応する重みを更新して、そのノード装置についての優先度を低くしてもよい。
 更に或る実施形態では、図22に示すとおり、ゲートウェイ装置との間でハローフレームを送受することにより、ゲートウェイ装置の死活監視を行うこともできる。
 ノード装置間での状態監視については、所定の時間内に相手のノード装置からハローフレームを受信しない場合には、相手のノード装置に対してハローフレーム発生要求を送信し、相手のノード装置からハローフレームを受信するか否かにより、相手のノード装置の状態を監視するような構造をとってもよい。
 或る実施形態では、上記のようにして各ノード装置においてネットワークを監視し、ハローフレームにそのハローフレームが通過した経路上のノード装置についての情報を付加してゆき、さらにサーバで集計することにより、ネットワークの監視を行うこともできる。
 本発明の実施形態に応じて、ハローフレームを用いて各ノード装置がネットワークの監視を行うことで、ネットワーク監視用のフレームを別途流通させる必要がなく、流通フレーム数を抑制することができる。また、隣接ノード装置とで送受するハローフレームを用いてネットワーク監視を行うことにより、センターからネットワーク監視用のフレームを送信してその応答により状態を監視する場合と比較して、ターンアラウンドを小さく抑えたリアルタイムに近い監視が可能となる。
 図23は、本発明の実施形態にかかるノード装置もしくはプログラムを実施可能なハードウェアを示す概要図である。
 図23にはまず、各種計算処理を担うマイクロプロセッサユニット(MPU)2300が示されている。マイクロプロセッサユニット2300は、有線物理層処理部(PHY)2312とMII(Media Independent Interface)/MDIO(Management Data Input/Output)インターフェイス2310を介して通信可能に接続されている(なお"MII/MDIO"とは、「MIIまたはMDIO」を意味する)。MIIとMDIOはいずれも、物理層とMAC副層(Media Access Control sublayer)との間のインターフェイスである。またマイクロプロセッサ2300は、時刻の計測などを担うタイマIC2322と、I2C(Inter-Integrated Circuit)/PIO(Parallel Input/Output)バス2320を介して通信可能に接続されている(なお"I2C/PIO"とは、「I2CまたはPIO」を意味する)。さらにマイクロプロセッサ2300は、記憶手段であるダイナミックランダムアクセスメモリ(DRAM)2332およびフラッシュメモリ2334、ならびにネットワークインターフェイスである無線LAN処理部2336と、PCI(Peripheral Component Interconnect)バス2330を介して通信可能に接続されている。当然のことながら、当該技術分野の常識に照らし、ここに例示した規格・種類以外の装置を適宜使用してもかまわない。
 MPU2300は、不揮発性記憶装置の一種であるフラッシュメモリ2334上に格納されたファームウェアなどの種々のプログラムを、DRAM2332上にロードして実行することで、様々な処理を実行できる。MPU2300は例えば、上述した各種処理をノード装置1に実行させるためのファームウェアプログラムなど、種々のプログラムを実行できる。
 なお、DRAM2332は、フレームの送信バッファ及び受信バッファとしても使用可能である。フラッシュメモリ2334は、上述したようにファームウェアプログラムなどを格納できる。また、フラッシュメモリ2334には、ノード装置1もしくは1a自身に固有の情報(例えば、ノードIDやMACアドレス)も格納できる。
 有線PHY処理部2312は、有線接続における物理層の処理を行う回路である。また、無線LAN処理部2336は、無線LAN接続における物理層の処理を行うハードウェアである。無線LAN処理部2336は、例えばアンテナ、ADC(Analog-to-Digital Converter)、DAC(Digital-to-Analog Converter)、変調器、復調器などを含むことができ、物理層とMAC副層の処理を行う。したがって、本実施形態では、ノード装置1もしくは1aが、有線通信と無線通信の双方を行うことができる。当然ながらノード装置1もしくは1aが、有線通信又は無線通信の一方のみを行う実施形態も可能である。
 タイマIC2322は、設定された時間が経過するまでカウントアップ動作を行い、設定された時間が経過すると割り込み信号を出力する回路である。
 なお、上記の実施形態においては、ノード装置について主に説明したが、上記の方法をコンピュータに実行させる制御プログラムも、本発明の実施形態の一例に含まれる。当該制御プログラムは、磁気ディスク、光磁気ディスク、不揮発性の半導体メモリ、光ディスクなどの、コンピュータ読み取り可能な記憶媒体に格納されて提供され、コンピュータにロードされ、コンピュータにより実行されてもよい。
 当該制御プログラムを実行するコンピュータは、不図示のノード装置に内蔵又は接続され、上記不図示のノード装置が上記実施形態のノード装置1もしくは1aと同様に動作するように、当該制御プログラムにしたがって上記不図示のノード装置を制御する。例えば、上記実施形態を別の観点から見れば、ノード装置1もしくは1aの内蔵コンピュータであるMPU2300は、フラッシュメモリ2334に格納された制御プログラムにしたがってノード装置1もしくは1aを制御し、上記各処理をノード装置1もしくは1aに行わせている、とも見做せる。
 以上説明したように、上記の実施形態に係るノード装置によれば、大規模の通信ネットワークに適用する場合であっても、各ノード装置が隣接ノード装置から受信した情報により経路の最適化を行うことやネットワークの監視を行うことが可能となる。
 また、本実施形態では各種のデータについて、理解しやすいようにテーブル形式の例を開示したが、この例に限らず、データを対応付けて管理可能なXMLやツリー構造など他の管理形式を採用してもよい。

Claims (7)

  1.  複数のノード装置を含むネットワークの中の、ノード装置において、
     自ノードが送信したフレームの情報として、フレームを一意に識別するための識別情報と該フレームの送出先ノードに関する情報とを格納する識別情報管理テーブルと、
     フレームの最終宛先ノードごとに、フレームを中継するため送出先とする他ノードについての重み付け情報を格納する宛先ノード別重み付けテーブルと、
     他ノードから自ノードに宛てて送信されたフレームを受信するフレーム受信手段と、
     前記フレーム受信手段により受信した前記フレームの識別情報が、前記識別情報管理テーブルに格納されている場合に、該識別情報と対応付けて格納されている前記送出先ノードについて、該フレームの最終宛先に対応する前記宛先ノード別重み付けテーブルのデータを更新する宛先ノード別重み付けテーブル更新手段と、
     前記フレーム受信手段により受信した前記フレームの識別情報が、前記識別情報管理テーブルに格納されていない場合に、前記フレームの最終宛先ノードに該当する前記宛先ノード別重み付けテーブルを参照して、該フレームを中継するための送出先とする他ノードを決定するフレーム送出先決定手段と、
     を有することを特徴とするノード装置。
  2.  前記宛先ノード別重み付けテーブル更新手段は、前記フレーム受信手段により受信した前記フレームの識別情報が、前記識別情報管理テーブルに格納されている場合に、該識別情報と対応付けて格納されている前記送出先ノードについて、該フレームの最終宛先に対応する前記宛先ノード別重み付けテーブルの該送出先ノードに対する重み付けを、優先度が低くなるように更新する
     ことを特徴とする請求項1記載のノード装置。
  3.  自ノードの周囲に存在する他ノードに関する情報を格納する隣接ノード管理テーブルと、
     ハローメッセージとして、自ノードの存在を知らせる情報と、前記隣接ノード管理テーブルから読み出した情報であって、周囲の経路に関する情報とを送信するハローメッセージ送信手段と、
     他ノードからの送信されたハローメッセージを受信するハローメッセージ受信手段と、
     前記ハローメッセージ受信手段により受信したハローメッセージの送出元ノードに関する情報に基づき、前記隣接ノード管理テーブルを更新する隣接ノード管理テーブル更新手段と、
     を更に備え、
     前記隣接ノード管理テーブルにおいて、所定の状態になった第1のノードを検出した場合には、前記宛先ノード別重み付けテーブル更新手段は、前記宛先ノード別重み付けテーブルの送出先ノードが該第1のノードであるデータを優先度が低くなるように更新する
     ことを特徴とする請求項2記載のノード装置。
  4.  前記隣接ノード管理テーブル更新手段は、前記ハローメッセージ受信手段が受信する送信元ノードごとのハローメッセージの受信間隔に基づいて決定した、前記送出元ノードに関する状態によって、前記隣接ノード管理テーブルを更新する
     ことを特徴とする請求項3記載のノード装置。
  5.  複数のノード装置を含むネットワークの中の、ノード装置において使用されるプログラムであって、
     自ノードが送信したフレームの情報として、フレームを一意に識別するための識別情報と該フレームの送出先ノードに関する情報とを識別情報管理テーブルに格納し、
     フレームの最終宛先ノードごとに、フレームを中継するため送出先とする他ノードについての重み付け情報を宛先ノード別重み付けテーブルに格納し、
     他ノードから自ノードに宛てて送信されたフレームを受信し、
     前記受信した前記フレームの識別情報が、前記識別情報管理テーブルに格納されている場合に、該識別情報と対応付けて格納されている前記送出先ノードについて、該フレームの最終宛先に対応する前記宛先ノード別重み付けテーブルのデータを更新し、
     前記受信した前記フレームの識別情報が、前記識別情報管理テーブルに格納されていない場合に、前記フレームの最終宛先ノードに該当する前記宛先ノード別重み付けテーブルを参照して、該フレームを中継するための送出先とする他ノードを決定する、
     処理をコンピュータに実行させることを特徴とするプログラム。
  6.  複数のノード装置を含んだネットワークの中の、ノード装置において、
     ひとつ以上の相手ノードから自ノードに宛てて送信されたフレームを受信する、フレーム受信手段と、
      前記自ノードから前記ひとつ以上の相手ノードの各々へと送信するフレームの通信品質に関する、第一の情報、
      前記ひとつ以上の相手ノードの各々から前記自ノードへと送信されるフレームの通信品質に関する、第二の情報、および
      前記第一の情報と前記第二の情報とから算出される、双方向の通信品質に関する第三の情報
    を含んだテーブルを格納する、記憶手段と、
     前記テーブルに基づいて、前記ひとつ以上の相手ノードの各々に関する優先度を示す評価値を定める、優先度判定手段と、
     前記評価値を用いて、前記ひとつ以上の相手ノードのうちのもっとも優先度の高いノードへフレームを送信する、フレーム送信手段と
    を含むことを特徴とするノード装置。
  7.  前記フレーム受信手段が受信した、前記ひとつ以上の相手ノードから前記自ノードに宛てて送信されたハローフレームに基づいて、前記優先度判定手段が前記評価値を定め、
     前記ひとつ以上の相手ノードのいずれかから前記自ノードに宛てて送られたデータフレームを、前記フレーム受信手段が受信し、
     前記フレーム送信手段が、前記評価値を用いて、前記データフレームを前記ひとつ以上の相手ノードのうちの適切なノードへ送信する
    ことを特徴とする、請求項6記載のノード装置。
PCT/JP2009/001924 2008-04-25 2009-04-27 ノード装置及びプログラム WO2009130918A1 (ja)

Priority Applications (7)

Application Number Priority Date Filing Date Title
CA2721911A CA2721911C (en) 2008-04-25 2009-04-27 Node device and program
EP09734953.4A EP2273732B1 (en) 2008-04-25 2009-04-27 Node device and program
BRPI0911155A BRPI0911155A2 (pt) 2008-04-25 2009-04-27 dispositivo de nodo e programa
CN200980113894.2A CN102017543B (zh) 2008-04-25 2009-04-27 节点装置及程序
JP2010509093A JP4888598B2 (ja) 2008-04-25 2009-04-27 ノード装置及びプログラム
AU2009239253A AU2009239253B2 (en) 2008-04-25 2009-04-27 Node device and program
US12/908,169 US8817616B2 (en) 2008-04-25 2010-10-20 Node device and computer readable storage medium storing program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2008-115023 2008-04-25
JP2008115023 2008-04-25

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/908,169 Continuation US8817616B2 (en) 2008-04-25 2010-10-20 Node device and computer readable storage medium storing program

Publications (1)

Publication Number Publication Date
WO2009130918A1 true WO2009130918A1 (ja) 2009-10-29

Family

ID=41216659

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2009/001924 WO2009130918A1 (ja) 2008-04-25 2009-04-27 ノード装置及びプログラム

Country Status (10)

Country Link
US (1) US8817616B2 (ja)
EP (1) EP2273732B1 (ja)
JP (3) JP4888598B2 (ja)
KR (1) KR101212838B1 (ja)
CN (2) CN102017543B (ja)
AU (1) AU2009239253B2 (ja)
BR (1) BRPI0911155A2 (ja)
CA (1) CA2721911C (ja)
RU (1) RU2457627C2 (ja)
WO (1) WO2009130918A1 (ja)

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2453641A1 (en) * 2010-07-07 2012-05-16 Panasonic Corporation Repeater, automated wireless meter reading system provided with same, and relay method
WO2012133521A1 (ja) * 2011-03-29 2012-10-04 富士通株式会社 通信方法および通信装置
JP5477462B2 (ja) * 2010-03-31 2014-04-23 富士通株式会社 ノード装置およびデータ送信方法
JP5500246B2 (ja) * 2010-03-31 2014-05-21 富士通株式会社 データ通信装置および方法
JP2014096812A (ja) * 2013-12-12 2014-05-22 Intel Corp 群知能を利用する大規模分散型システムにおける情報ルーティングのために枠組みを利用するシステムおよび方法
US20140226566A1 (en) * 2011-11-01 2014-08-14 Fujitsu Limited Transmission control method and transmission control apparatus
JP2015095722A (ja) * 2013-11-11 2015-05-18 富士通株式会社 ノード装置、経路入れ替え方法、及び、プログラム
US9439128B2 (en) 2011-10-13 2016-09-06 Fujitsu Limited Node device and communication method for generating cluster
JP2017028442A (ja) * 2015-07-21 2017-02-02 矢崎総業株式会社 車両用通信システム
US9730140B2 (en) 2011-12-12 2017-08-08 Fujitsu Limited Transmission control method, node, and non-transitory computer-readable recording medium
WO2017145390A1 (ja) * 2016-02-26 2017-08-31 富士通株式会社 データ転送プログラム、データ転送装置およびデータ転送方法
US9768917B2 (en) 2012-10-31 2017-09-19 Fujitsu Limited Communication control method, network system, and communication device
JP2022514910A (ja) * 2018-12-18 2022-02-16 ソニーグループ株式会社 Wlanネットワークにおけるバックアップルートを伴うマルチホップルーティングプロトコル

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5777112B2 (ja) * 2010-02-23 2015-09-09 国立大学法人九州大学 通信システム、スレーブノード、ルート構築方法及びプログラム
US11026169B2 (en) 2010-11-09 2021-06-01 Qualcomm Incorporated Physical layer power save facility
US9992738B2 (en) * 2010-11-17 2018-06-05 Qualcomm Incorporated Physical layer power save facility with random offset
WO2012131960A1 (ja) * 2011-03-30 2012-10-04 富士通株式会社 通信装置、経路探索方法および経路探索プログラム
JP5884919B2 (ja) * 2012-11-06 2016-03-15 富士通株式会社 ネットワーク装置および送信プログラム
JP5958293B2 (ja) * 2012-11-14 2016-07-27 富士通株式会社 通信方法、通信プログラム、および、ノード装置
US9170969B2 (en) 2013-01-20 2015-10-27 Lenovo Enterprise Solutions (Singapore) Pte. Ltd. Cached PHY register data access
JP2016136651A (ja) * 2013-05-20 2016-07-28 パナソニック株式会社 無線通信機器および無線通信方法
KR101465138B1 (ko) * 2013-05-22 2014-11-26 한국과학기술원 온디멘드 방식의 모바일 애드혹 네트워크 라우팅에서의 헬로 패킷 스케줄링 방법 및 연결 제어 방법
US9553710B2 (en) * 2013-10-31 2017-01-24 Electronics And Telecommunications Research Institute Methods and an apparatus for carrier aggregation
CN104243549A (zh) * 2014-07-24 2014-12-24 北京天公瑞丰科技有限公司 基于TG-Inwicos的配电自动化通信方法与装置
US9553829B2 (en) * 2014-11-13 2017-01-24 Cavium, Inc. Apparatus and method for fast search table update in a network switch
CN104486809B (zh) * 2014-12-26 2018-05-18 陈晨 一种无线局域网路由方法
JP6459558B2 (ja) * 2015-01-27 2019-01-30 富士通株式会社 無線通信装置、無線通信方法、および無線通信プログラム
CN105357744B (zh) * 2015-08-31 2017-03-01 厦门纵行信息科技有限公司 一种随机接入中继器、中继系统及其中继方法
CN106603404A (zh) * 2015-10-15 2017-04-26 富士通株式会社 无线体域网中2跳扩展转发节点的选举装置、方法和系统
US10516606B2 (en) 2017-07-12 2019-12-24 Micron Technology, Inc. System for optimizing routing of communication between devices and resource reallocation in a network
US10511353B2 (en) 2017-07-12 2019-12-17 Micron Technology, Inc. System for optimizing routing of communication between devices and resource reallocation in a network
US20190253357A1 (en) * 2018-10-15 2019-08-15 Intel Corporation Load balancing based on packet processing loads
CN109275171B (zh) * 2018-10-17 2022-07-12 珠海云洲智能科技股份有限公司 无线自组网通信方法和装置
WO2020150349A1 (en) * 2019-01-15 2020-07-23 Loud-Hailer, Inc. Device presence method and system for mesh network management

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005260299A (ja) * 2004-03-09 2005-09-22 Thinktube Ltd 移動通信装置及び移動通信プログラム
WO2006104185A1 (ja) * 2005-03-31 2006-10-05 Advanced Telecommunications Research Institute International 無線装置
JP2006526937A (ja) 2003-06-05 2006-11-24 メッシュネットワークス インコーポレイテッド アドホック無線通信ネットワークにおける最適なルーティング

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH02109445A (ja) 1988-10-19 1990-04-23 Nippon Telegr & Teleph Corp <Ntt> パケット識別方法
US7327683B2 (en) * 2000-03-16 2008-02-05 Sri International Method and apparatus for disseminating topology information and for discovering new neighboring nodes
JP2002171283A (ja) * 2000-11-14 2002-06-14 Lucent Technol Inc パケットネットワークのノードで使用される方法と装置
RU2233473C2 (ru) * 2000-12-22 2004-07-27 Самсунг Электроникс Ко., Лтд. Устройство и способ выполнения высокоскоростного поиска маршрутов протокола интернет и управления таблицами маршрутизации/пересылки
JP3575435B2 (ja) 2001-03-09 2004-10-13 日本電気株式会社 電話システム及び電話接続監視方法
JP2003273964A (ja) 2002-03-15 2003-09-26 Ntt Docomo Inc 通信システム、通信制御方法及びルータ
US7515600B1 (en) * 2003-01-28 2009-04-07 Cisco Technology, Inc. Synchronizing portions of a database with different databases on different nodes of a network
US7701858B2 (en) 2003-07-17 2010-04-20 Sensicast Systems Method and apparatus for wireless communication in a mesh network
EP1718004B1 (en) * 2004-02-18 2017-06-21 Ntt Docomo, Inc. Packet transmission system, wireless base station and route optimization for packet transmission
JP4201270B2 (ja) 2004-02-19 2008-12-24 日本電信電話株式会社 ブリッジ装置とループ検出方法およびプログラム
JP4378192B2 (ja) * 2004-03-05 2009-12-02 富士通株式会社 通信端末、通信プログラムおよび通信プログラムを記録したコンピュータ読み取り可能な記録媒体
JP4312655B2 (ja) * 2004-05-11 2009-08-12 株式会社神戸製鋼所 無線ネットワーク通信システム,及びこのシステムに用いられる発信元の無線端末,及び無線通信経路のルーティング方法
US7475158B2 (en) 2004-05-28 2009-01-06 International Business Machines Corporation Method for enabling a wireless sensor network by mote communication
JP4010341B2 (ja) 2004-07-27 2007-11-21 松下電工株式会社 通信ルートの構築方法及び通信端末
JP2006340165A (ja) 2005-06-03 2006-12-14 Hitachi Communication Technologies Ltd 通信経路切替制御システム及びルータ装置
JP4656310B2 (ja) 2005-07-07 2011-03-23 日本電気株式会社 スケジューリング方法及び移動通信システム
JP4635840B2 (ja) * 2005-11-16 2011-02-23 横河電機株式会社 無線機器及びネットワークシステム
US7633882B2 (en) * 2006-02-02 2009-12-15 Eaton Corporation Ad-hoc network and method employing globally optimized routes for packets
US9043487B2 (en) * 2006-04-18 2015-05-26 Cisco Technology, Inc. Dynamically configuring and verifying routing information of broadcast networks using link state protocols in a computer network
US7756017B2 (en) * 2006-09-08 2010-07-13 The Uwm Research Foundation, Inc. System and method for scheduling routing table calculation in link state routing protocols
JP4853869B2 (ja) * 2006-09-29 2012-01-11 株式会社国際電気通信基礎技術研究所 無線装置、それにおける隠れ端末の検出方法および通信制御方法
US7940776B2 (en) * 2007-06-13 2011-05-10 Cisco Technology, Inc. Fast re-routing in distance vector routing protocol networks
US8089884B2 (en) * 2008-04-07 2012-01-03 Itt Manufacturing Enterprises, Inc. Method and apparatus for early warning of congestion in Ad-Hoc wireless networks

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006526937A (ja) 2003-06-05 2006-11-24 メッシュネットワークス インコーポレイテッド アドホック無線通信ネットワークにおける最適なルーティング
JP2005260299A (ja) * 2004-03-09 2005-09-22 Thinktube Ltd 移動通信装置及び移動通信プログラム
WO2006104185A1 (ja) * 2005-03-31 2006-10-05 Advanced Telecommunications Research Institute International 無線装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2273732A4

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5477462B2 (ja) * 2010-03-31 2014-04-23 富士通株式会社 ノード装置およびデータ送信方法
JP5500246B2 (ja) * 2010-03-31 2014-05-21 富士通株式会社 データ通信装置および方法
EP2453641A4 (en) * 2010-07-07 2012-06-06 Panasonic Corp REPEATER, AUTOMATED WIRELESS COUNTER READING SYSTEM HAVING IT, AND RELAY METHOD
CN102972017A (zh) * 2010-07-07 2013-03-13 松下电器产业株式会社 中继器、具备该中继器的自动无线抄表系统以及中继方法
EP2453641A1 (en) * 2010-07-07 2012-05-16 Panasonic Corporation Repeater, automated wireless meter reading system provided with same, and relay method
WO2012133521A1 (ja) * 2011-03-29 2012-10-04 富士通株式会社 通信方法および通信装置
JP2012209741A (ja) * 2011-03-29 2012-10-25 Fujitsu Ltd 通信方法および通信装置
US10003532B2 (en) 2011-03-29 2018-06-19 Fujitsu Limited Communication method and communication apparatus
US9439128B2 (en) 2011-10-13 2016-09-06 Fujitsu Limited Node device and communication method for generating cluster
US20140226566A1 (en) * 2011-11-01 2014-08-14 Fujitsu Limited Transmission control method and transmission control apparatus
US9485705B2 (en) * 2011-11-01 2016-11-01 Fujitsu Limited Transmission control method and transmission control apparatus
US9730140B2 (en) 2011-12-12 2017-08-08 Fujitsu Limited Transmission control method, node, and non-transitory computer-readable recording medium
US9768917B2 (en) 2012-10-31 2017-09-19 Fujitsu Limited Communication control method, network system, and communication device
JP2015095722A (ja) * 2013-11-11 2015-05-18 富士通株式会社 ノード装置、経路入れ替え方法、及び、プログラム
JP2014096812A (ja) * 2013-12-12 2014-05-22 Intel Corp 群知能を利用する大規模分散型システムにおける情報ルーティングのために枠組みを利用するシステムおよび方法
JP2017028442A (ja) * 2015-07-21 2017-02-02 矢崎総業株式会社 車両用通信システム
WO2017145390A1 (ja) * 2016-02-26 2017-08-31 富士通株式会社 データ転送プログラム、データ転送装置およびデータ転送方法
JP2022514910A (ja) * 2018-12-18 2022-02-16 ソニーグループ株式会社 Wlanネットワークにおけるバックアップルートを伴うマルチホップルーティングプロトコル
JP7345735B2 (ja) 2018-12-18 2023-09-19 ソニーグループ株式会社 Wlanネットワークにおけるバックアップルートを伴うマルチホップルーティングプロトコル

Also Published As

Publication number Publication date
CN103457849A (zh) 2013-12-18
CN102017543A (zh) 2011-04-13
KR20100137546A (ko) 2010-12-30
AU2009239253A1 (en) 2009-10-29
AU2009239253B2 (en) 2014-05-29
EP2273732A4 (en) 2013-01-23
EP2273732B1 (en) 2018-03-21
RU2457627C2 (ru) 2012-07-27
US8817616B2 (en) 2014-08-26
CN102017543B (zh) 2015-11-25
CN103457849B (zh) 2016-08-24
JP5182409B2 (ja) 2013-04-17
JP2012050128A (ja) 2012-03-08
CA2721911A1 (en) 2009-10-29
US20110141932A1 (en) 2011-06-16
JPWO2009130918A1 (ja) 2011-08-11
RU2010144792A (ru) 2012-05-27
EP2273732A1 (en) 2011-01-12
JP4888598B2 (ja) 2012-02-29
JP2013085295A (ja) 2013-05-09
BRPI0911155A2 (pt) 2015-10-06
KR101212838B1 (ko) 2012-12-14
CA2721911C (en) 2015-11-24
JP5569604B2 (ja) 2014-08-13

Similar Documents

Publication Publication Date Title
JP4888598B2 (ja) ノード装置及びプログラム
US20090296704A1 (en) Method for multi-path source routing in sensor network
US7856001B2 (en) Wireless mesh routing protocol utilizing hybrid link state algorithms
US20130250754A1 (en) Proactive timer-based local repair path communication in reactive routing networks
KR20100051693A (ko) 유틸리티 스마트-그리드 네트워크 내의 라우팅 방법 및 시스템
KR20080075151A (ko) 무선 통신 루트 개선 방법 및 시스템
TW200915788A (en) Method and system of routing in a utility smart-grid network
US20080076461A1 (en) Radio device for preventing isolated radio devices in network
US20100020740A1 (en) Wireless Communication System, Wireless Communication Device, Wireless Communication Method, and Program
Okazaki et al. Ant-based dynamic hop optimization protocol: A routing algorithm for mobile wireless sensor networks
JP4605428B2 (ja) 通信システム、通信端末装置、通信方法及びプログラム
JP4627465B2 (ja) 無線通信端末およびQoS情報収集方法
JP5958293B2 (ja) 通信方法、通信プログラム、および、ノード装置
JP4696314B2 (ja) 無線装置およびそれを備えた無線ネットワークシステム
CN104053208B (zh) 无线自组网中基于信道分配的路由方法、装置
JP6191411B2 (ja) ノード装置、制御プログラム、及びノード装置の動作方法
US20130201970A1 (en) Wireless communication system, wireless communication control method, and wireless communication device
JP7326230B2 (ja) 通信システム、ノード、通信方法及びプログラム
WO2014087138A1 (en) Wireless node
AU2013204999B2 (en) Node device and program
KR20080037509A (ko) 데이터 경로 설정 방법 및 데이터 경로 설정 장치
KR20100039774A (ko) 애드혹 네트워크에서 링크 신뢰 지역에 기반한 라우팅 방법및 장치
Chung et al. Performance analysis of WMPLS signaling and control in ad hoc networks

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200980113894.2

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09734953

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2010509093

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 12010502359

Country of ref document: PH

WWE Wipo information: entry into national phase

Ref document number: 2721911

Country of ref document: CA

ENP Entry into the national phase

Ref document number: 20107023884

Country of ref document: KR

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2009734953

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2009239253

Country of ref document: AU

Ref document number: 4104/KOLNP/2010

Country of ref document: IN

ENP Entry into the national phase

Ref document number: 2009239253

Country of ref document: AU

Date of ref document: 20090427

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2010144792

Country of ref document: RU

ENP Entry into the national phase

Ref document number: PI0911155

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20101019