WO2022138229A1 - 通信装置、及び通信方法 - Google Patents

通信装置、及び通信方法 Download PDF

Info

Publication number
WO2022138229A1
WO2022138229A1 PCT/JP2021/045491 JP2021045491W WO2022138229A1 WO 2022138229 A1 WO2022138229 A1 WO 2022138229A1 JP 2021045491 W JP2021045491 W JP 2021045491W WO 2022138229 A1 WO2022138229 A1 WO 2022138229A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
communication device
control unit
detector
communication
Prior art date
Application number
PCT/JP2021/045491
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 CN202180085031.XA priority Critical patent/CN116636306A/zh
Priority to US18/258,290 priority patent/US20240056936A1/en
Publication of WO2022138229A1 publication Critical patent/WO2022138229A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H04W40/04—Communication route or path selection, e.g. power-based or shortest path routing based on wireless node resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H04W40/12—Communication route or path selection, e.g. power-based or shortest path routing based on transmission quality or channel quality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H04W40/22—Communication route or path selection, e.g. power-based or shortest path routing using selective relaying for reaching a BTS [Base Transceiver Station] or an access point
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10—Small scale networks; Flat hierarchical networks
    • H04W84/12—WLAN [Wireless Local Area Networks]

Definitions

  • the present technology relates to a communication device and a communication method, and particularly to a communication device and a communication method capable of determining an optimum transmission route.
  • Joint Detection receives the uplink signal from the wireless terminal (STA: STAtion) at multiple access points, aggregates the received signals, and performs reception calculation at one of the access points.
  • STA STAtion
  • UL MU-MIMO Uplink Multiuser Multiple-Input and Multiple-Output
  • uplink (UL: Uplink) signals can be acquired from many wireless terminals at once, and throughput improvement and low delay transmission can be realized.
  • Patent Document 1 discloses a technique for setting a mesh path (communication path) by measuring or calculating a path metric value in a mesh network which is a network for performing multi-hop.
  • Pre-demodulated Data data in a state where demodulation processing has not been performed (hereinafter referred to as Pre-demodulated Data) to other access points.
  • Pre-demodulated Data is expected to have more information than the transmission data of the existing method, and the backhaul link between access points may be in a tight state.
  • This technology was made in view of such a situation, and makes it possible to determine the optimum transmission route.
  • the communication device of one aspect of the present technology exchanges information used for determining a multi-hop transmission route by using wireless communication with another communication device, and the transmission route is set based on the information. It is a communication device including a control unit that controls to determine an optimum transmission route based on an increase amount of transmission data when a plurality of communication devices cooperate to perform processing at the time of determination.
  • the communication device exchanges information used for determining the multi-hop transmission route with another communication device by using wireless communication, and is based on the above information.
  • This is a communication method for determining an optimum transmission route based on an increase in transmission data when a plurality of communication devices cooperate to perform processing when determining the transmission route.
  • information used for determining a multi-hop transmission route is exchanged with another communication device by using wireless communication, and the above information is used.
  • the optimum transmission route is determined based on the amount of increase in transmission data when a plurality of communication devices perform processing in cooperation with each other.
  • a communication device on one aspect of the present technology receives a trigger signal transmitted from another communication device included in a plurality of communication devices that perform cooperative processing in a multi-hop network, and a flag indicating the execution of cooperative processing.
  • a communication device including a control unit that controls transmission of an uplink signal including a PHY header in which node identification information is set according to the role of processing when performing cooperative processing.
  • a trigger signal transmitted from another communication device included in a plurality of communication devices that perform cooperative processing in a multi-hop network is received, and the implementation of the cooperative processing is shown.
  • An uplink signal including a flag and a PHY header set with node identification information according to the role of processing when performing cooperative processing is transmitted.
  • the communication device on one side of the present technology may be an independent device or an internal block constituting one device.
  • FIG. 1 is a diagram showing a configuration example of a wireless LAN system to which the present technology is applied.
  • Each access point AP constructs a mesh network as a network that performs multi-hop.
  • the access point AP connected to the backhaul is referred to as a source node (SourceNode), and the other access point AP is referred to as a relay node (RelayNode).
  • the access point AP5 becomes a source node
  • the access points AP1 to AP4 become relay nodes 1 to 4 (Relay 1 to Relay 4).
  • Each relay node is supposed to relay and transmit the acquired UL signal to the source node, and the existing method can be used for the transmission route at that time.
  • Both the source node and the relay node form cells, and the wireless terminal STA is connected under them.
  • the subordinate wireless terminal STA may perform UL signal transmission.
  • the target system configuration is not limited to the configuration shown in FIG. 1, and there are a plurality of communication devices for which a connection has been established, and a communication device exists as a peripheral terminal for each communication device. As long as the above conditions are satisfied, the positional relationship does not matter.
  • FIG. 2 is a diagram showing a configuration example of a communication device to which the present technology is applied.
  • the communication device 10 is configured as the access point AP shown in FIG.
  • the communication device 10 is composed of a control unit 100, a wireless communication unit 101, a wireless communication unit 102, a storage unit 103, and a WAN communication unit 104. Further, the antenna 117 and the antenna 127 are connected to the wireless communication unit 101 and the wireless communication unit 102, respectively.
  • the wireless communication unit 101 is a wireless communication unit for communication between access point APs (for communication between APs and APs).
  • the wireless communication unit 101 includes a communication control unit 111, a communication storage unit 112, a data processing unit 113, a signal processing unit 114, a wireless interface unit 115, and an amplification unit 116.
  • the communication control unit 111 controls the operation of each unit and the transmission of information between each unit. Further, the communication control unit 111 controls to pass control information and management information to be notified to other communication devices to each data processing unit 113.
  • the communication storage unit 112 holds the information used by the communication control unit 111. Further, the communication storage unit 112 holds a packet to be transmitted and a packet to be received. The transmission buffer for holding the packet to be transmitted is included in the communication storage unit 112.
  • the data processing unit 113 manages the sequence of the data held in the communication storage unit 112 and the control information and management information received from the communication control unit 111 at the time of transmission, performs encryption processing, and then performs MAC (Media). Access Control) Generates a packet by adding a header and an error detection code.
  • the data processing unit 113 performs a plurality of concatenation processing of the generated packets.
  • the data processing unit 113 performs reconnection processing, analysis and error detection of the MAC header of the received packet, and retransmission request operation reorder processing at the time of reception.
  • the signal processing unit 114 performs coding, interleaving, modulation, etc. on the packet, adds a PHY (Physical) header, and generates a symbol stream. Further, the signal processing unit 114 analyzes the PHY header at the time of reception, demodulates, deinterleaves, decodes, and the like with respect to the symbol stream, and generates a packet. The signal processing unit 114 estimates the complex channel characteristics and performs spatial separation processing as necessary.
  • PHY Physical
  • the wireless interface unit 115 performs digital-analog signal conversion, filtering, up-conversion, and phase control on the symbol stream to generate a transmission signal. Further, the wireless interface unit 115 performs down-conversion, filtering, and analog-digital signal conversion on the received signal at the time of reception to generate a symbol stream.
  • the amplification unit 116 amplifies the signal input from the wireless interface unit 115 or the antenna 117.
  • a part of the amplification unit 116 may be an external component of the wireless communication unit 101. Further, a part of the amplification unit 116 may be included in the wireless interface unit 115.
  • the wireless communication unit 102 is a wireless communication unit for communication (communication between AP and STA) between the access point AP and the wireless terminal STA.
  • the wireless communication unit 102 includes a communication control unit 121, a communication storage unit 122, a data processing unit 123, a signal processing unit 124, a wireless interface unit 125, and an amplification unit 126.
  • the wireless communication unit 102 for AP-STA communication is configured in the same manner as the wireless communication unit 101 for AP-AP communication. Therefore, regarding the internal configuration of the wireless communication unit 102, in the above description of the internal configuration of the wireless communication unit 101, the communication control unit 111 to the amplification unit 116 may be read as the communication control unit 121 to the amplification unit 126, respectively.
  • the configurations of the wireless communication unit 101 and the wireless communication unit 102 are exactly the same, the configurations of the two may be slightly different. Further, both transmission parameters (center frequency, bandwidth, maximum transmission power value, number of antennas, etc.) do not have to match.
  • the control unit 100 controls the wireless communication units 101 and 102 and the communication control units 111 and 121. Further, the control unit 100 may perform some operations of the communication control units 111 and 121 instead.
  • the control unit 100 and the communication control units 111 and 121 may be configured as one block.
  • the storage unit 103 holds information used by the control unit 100 and the wireless communication units 101 and 102. Further, the storage unit 103 may perform some operations of the communication storage units 112 and 122 instead.
  • the storage unit 103 and the communication storage units 112 and 122 may be configured as one block.
  • Pre-demodulated Data which is data in progress in the signal processing unit 124 of the wireless communication unit 102, to another access point AP. Therefore, as shown in FIG. 2, signal processing is performed. Information needs to be directly exchanged from the unit 124 to the control unit 100.
  • the Pre-demodulated Data received by the control unit 100 generates a transmission signal by the wireless communication unit 101 using processing according to the existing method, and transmits the quantized information to another access point AP.
  • the Pre-demodulated Data acquired from another access point AP is passed to the signal processing unit 124 of the wireless communication unit 102 via the control unit 100, and the reception processing is continued in consideration of the information. Details will be described later with reference to FIG.
  • Pre-demodulated Data may be temporarily stored in the storage unit 103 as needed. Further, data may be exchanged directly in the wireless communication units 101 and 102 without going through the control unit 100 or the storage unit 103.
  • the WAN communication unit 104 decodes the packet acquired from the backhaul and delivers it to the wireless communication units 101 and 102 through the control unit 100.
  • the format of the packet passed here may be a state in which the IP header is left as it is (access point mode) or a state in which the IP header is decoded and removed by the WAN communication unit 104 (router mode).
  • each of the wireless communication units 101 and 102 is configured as one IC (Integrated Circuit), but the configuration of the IC to which this technique is applied is not limited to this.
  • each of the wireless interface units 115 and 125 may be mounted as different ICs.
  • FIG. 3 is a diagram for explaining a reception operation in the signal processing unit 124 of the wireless communication unit 102 of FIG. 2.
  • processing units 151-1 to 151-N are provided in front of the MIMO detection unit 152, and processing units 153-1, 153 are provided in the subsequent stage. -2 and processing units 154-1 and 154-2 are provided.
  • the processing unit 151 includes a GI removing unit 161, an FFT unit 162, and a channel estimation unit 163.
  • the processing units 153 and 154 have an IDFT unit 171 and a demodulation unit 172, and a decoding unit 173, respectively.
  • the GI removing unit 161 GI Guard Interval
  • FFT Fast Fourier Transform
  • the channel estimation unit 163 estimates the frequency characteristics from the known symbols in the PHY header, and uses the Pre-demodulated Data (I / Q Data on the frequency axis) and the channel estimation results acquired from each receiving antenna to perform MIMO.
  • MIMO processing is performed by the detection unit 152 to separate the received signals of each stream.
  • IDFT Inverse Discrete Fourier Transform
  • the received signal acquired from each wireless terminal STA is Binary. Obtained in Data format.
  • the acquired data is supplied to the data processing unit 123.
  • the signal processing unit 124 is characterized in that a path for exchanging Pre-demodulated Data is added immediately before the MIMO detection unit 152 in order to perform Joint Detection. As described above, this path is connected to the control unit 100.
  • FIG. 4 is a diagram illustrating an outline of Joint Detection.
  • Joint Detection is a technology in which multiple access point APs cooperate to perform ULMU-MIMO processing as one access point AP.
  • Joint Detection will also be described as JD as appropriate.
  • the wireless terminals STA1 and STA2 can be connected to the access points AP1 and AP2
  • the received data of each access point AP is usually represented by the following equation (1).
  • W represents a reception weight.
  • the receiving antenna should be at least the total number of transmission streams of the wireless terminal STA that performs UL transmission.
  • the access point AP requires at least four receiving antennas. If the number is less than the number of receiving antennas, the access point AP cannot completely separate the stream from the wireless terminal STA, and the communication quality may be significantly deteriorated due to the decrease in received power and the increase in interference and noise power. Is high.
  • the number of simultaneous transmission terminals and the number of streams on the wireless terminal STA side are limited by the number of receiving antennas of the access point AP.
  • the number of receiving antennas is equivalent to the total number of receiving antennas possessed by the cooperating access point AP. That is, for example, when each wireless terminal STA transmits two streams, in Joint Detection by two access point APs, the transmission stream can be separated only by each access point AP having two receiving antennas. On the contrary, by increasing the total number of receiving antennas by Joint Detection, it is expected that the number of simultaneous transmission terminals and the number of streams that can be transmitted on the wireless terminal STA side will increase, and the wireless capacity will be significantly improved.
  • Pre-demodulated Data When Joint Detection is performed by two access point APs, one access point AP must transmit Pre-demodulated Data to the other access point AP.
  • the data must be transmitted in the form of quantized numerical values that can be expressed by I / Q on the frequency axis, and it is presumed that the amount of information to be transmitted will be larger than that of the existing Binary Data.
  • the quantization bit of Pre-demodulated Data can be changed depending on the transmission parameters of the UL signal (transmission bandwidth, MCS (Modulation and Coding Scheme), etc.).
  • the optimum transmission route at the time of Joint Detection implementation and its role must be determined by a method different from the path route determination by the existing method.
  • the roles of performing Joint Detection include a side that transmits Pre-demodulated Data (hereinafter referred to as a supplier) and a side that acquires Pre-demodulated Data (hereinafter referred to as a detector).
  • this technique provides a method for dynamically determining the path route when performing Joint Detection, and the roles of the detector and the supplier from the UL signal transmission parameters.
  • FIG. 5 is a sequence diagram showing the exchange between the devices according to the first embodiment along the time axis.
  • S1 Mesh Network Phase
  • S2 Path Discovery Phase
  • S3 Joint Detection Phase
  • mesh network construction is performed between the source node and each relay node, and the transmission route is determined during normal operation (when Joint Detection is not performed). Since the operation in the phase is the same as that of the existing method, detailed description thereof will be omitted.
  • Path Discovery Phase the transmission route is determined when Joint Detection is executed.
  • the Path Discovery Phase is started when a relay node sends a JD Path Discovery Request (S11).
  • the node that receives the JD Path Discovery Request calculates the metric value, updates the shortest route information, and then transmits the updated JD Path Discovery Request when the next transmission right is acquired (S12).
  • the path (Path) that is the minimum metric from the JD Path Discovery Request acquired by the destination node of Path Discovery (source node in FIG. 5) is started. It is determined as a route from the relay node to itself (or vice versa). After that, the JD Path Discovery Response is transmitted in order by following the route determined from the destination node in the reverse direction (S13, S14).
  • the node that starts this process is called the originator
  • the final destination for which the transmission route is to be determined is called the target.
  • the source node may be the originator, or the target may be the relay node.
  • the node that has acquired the transmission right is determined after receiving and decoding the UL signal from the subordinate wireless terminal STA using the cooperative operation (Joint Detection) with other nodes.
  • the acquired data is transmitted to the source node by the transmission route.
  • the relay node determines the coordinated access point AP and its respective roles (detector and supplier) from the route acquired by the wireless terminal STA that induces UL transmission and the Path Discovery Phase (S2) and its metric value. (S15). Details of this determination method will be described later.
  • JD UL DATA UL Data for Joint Detection is acquired from the wireless terminal STA by JD UL Trigger (S18, S19). .. Then, the supplier determined at the time of setup supplies the Pre-demodulated Data to the detector (S20), then the Joint Detection process is executed (S21), and the Demodulated data is transmitted to the source node (S22).
  • FIG. 5 shows a sequence diagram when the supplier acquires the transmission right, but when the detector acquires the transmission right, Path Determination (S15) is the process on the detector side, and Joint Detect Setup (S16). , S17) The arrows are reversed.
  • FIG. 6 is a diagram showing a configuration example of JDPathDiscoveryRequestFrame.
  • JDPathDiscoveryRequestFrame consists of FrameControl, Duration, RA, TA, FrameBody, and FCS.
  • FrameControl Duration
  • RA Duration
  • TA FrameBody
  • FCS FCS
  • the configuration based on the Mesh Action Frame and PREQ Element specified in IEEE (Institute of Electrical and Electronics Engineers) 802.11s is shown.
  • Frame Control contains information indicating the type of the frame.
  • the Duration contains information indicating the length of the frame.
  • RA Receiveiver Address
  • TA Transmitter Address
  • Frame Body contains the main body of information to be transmitted.
  • MeshActionFrame is included as the information of this main body.
  • FCS Fre Check Sequence
  • the MeshActionFrame contains fields that are Category, MeshAction, and JDPathDiscoveryRequestElement.
  • the Category contains information indicating that the Action Frame is a Mesh Action Frame.
  • the MeshAction includes information indicating that the MeshActionFrame is a JDPathDiscoveryRequestFrame.
  • the JDPathDiscoveryRequestElement contains a group of information used for path detection for Joint Detection.
  • the JDPathDiscoveryRequestElement contains fields that are ElementID, Length, OriginatorAddress, OriginatorSN, Lifetime, JDParameter, DetectorCount, and DetectorInfo.
  • the Element ID contains information indicating that the element is a JD Path Discovery Request Element.
  • Length includes information indicating the length of the element.
  • OriginatorAddress includes the address information of the originator that is the PathDiscovery request source.
  • the Originator SN contains the Sequence Number (SN) of the path managed by the originator that is the Path Discovery request source. Lifetime includes the remaining time information for collecting and transmitting PathDiscoveryRequestFrame.
  • JDParameter contains a group of information necessary for path search for Joint Detection.
  • the Detector Count contains information on the number of detector candidates that perform a path search for Joint Detection.
  • the Detector Info field that follows by the numerical value shown in the field is included.
  • DetectorInfo includes a path information group for each detector candidate node.
  • the DetectorInfo contains fields such as DetectorAddress, Metric, HopCount, ElementTTL, PathDiscoveryID, TargetCount, PerTargetFlags, TargetAddress, and TargetSN.
  • the Detector Address contains the address information of the detector candidate node.
  • Metric includes the path metric value from the originator to reach itself via the detector candidate node. The calculation method of this path metric value will be described later.
  • Hop Count includes the number of hops from the originator to reach itself via the detector candidate node.
  • Element TTL contains information on the number of remaining hops. When the value is 0, no further path search is performed.
  • the Path Discovery ID includes the identification information of the Path Discovery process. If the same ID is assigned to each detector, it may be notified in the upper row instead of in the field.
  • Target Count contains information indicating the number of targets to which Path Discovery is requested. Subsequent Per Target Flags, Target Address, and Target SN are included by the numerical value indicated by this Target Count.
  • Per Target Flags is a flag indicating detailed information of the target that is the Path Discovery request destination.
  • Target Address contains the address information of the target that is the Path Discovery request destination.
  • the Target SN includes the Sequence Number (SN) of the path that is the Path Discovery request destination but is managed. If the SN is unknown, the field may be skipped. In that case, the presence or absence of the field is notified by the flag in Per Target Flags.
  • the JD Path Discovery Request frame is not limited to the frame configuration shown in FIG. 6, and includes at least one JD Data Growth Rate, Detector Count, and one or more Detector Info including Detector Address and Metric in the figure. Just do it. Further, although the frame is described assuming MAC Frame, if the above information is described, it may be transmitted as TCP / IP Frame.
  • FIG. 7 is a diagram showing a configuration example of JD Path Discovery Response Frame.
  • JDPathDiscoveryResponseFrame consists of FrameControl, Duration, RA, TA, FrameBody, and FCS.
  • the configuration based on MeshActionFrame and PREPElement specified in IEEE802.11s is shown.
  • Frame Control contains information indicating the type of the frame.
  • the Duration contains information indicating the length of the frame.
  • the RA contains the destination address.
  • the TA contains the source address.
  • the Frame Body contains the body of the information to be transmitted.
  • MeshActionFrame is included as the information of this main body.
  • FCS is added as an error correction code.
  • the MeshActionFrame contains fields that are Category, MeshAction, and JDPathDiscoveryResponseElement.
  • the Action Frame is a Mesh Action Frame.
  • the MeshAction includes information indicating that the MeshActionFrame is a JDPathDiscoveryResponseframe.
  • the JD Path Discovery Response Element contains a group of information about the determined Joint Detection path.
  • the JD Path Discovery Response Element includes fields such as Element ID, Length, Target Address, Target SN, Lifetime, Detector Count, Detector Info, Originator Address, and Originator SN.
  • the Element ID contains information indicating that the element is a JD Path Discovery Response Element.
  • Length includes information indicating the length of the element.
  • Target Address contains the address information of the target that is the Path Discovery request destination.
  • the Target SN includes the Sequence Number (SN) of the path that is the Path Discovery request destination but is managed. Lifetime includes the remaining time information for collecting and transmitting the Path Discovery Response Frame.
  • the Detector Count contains information on the number of detector candidates that perform a path search for Joint Detection.
  • the Detector Info field that follows by the numerical value shown in the field is included.
  • DetectorInfo includes a group of path information for each detector candidate node.
  • the Detector Info contains fields such as Detector Address, Metric, Hop Count, Element TTL, Path Discovery ID, and Previous Node Address.
  • the Detector Address contains the address information of the detector candidate node.
  • Metric contains the path metric value from the target to itself. The calculation method of this path metric value will be described later.
  • Hop Count includes the number of hops from the target to reach itself.
  • Element TTL contains information on the number of remaining hops. When the value is 0, the frame is no longer transmitted.
  • the Path Discovery ID contains the same identification information as the Path Discovery Request. If the same ID is assigned to each detector, it may be notified in the upper row instead of in the field.
  • the Previous Node Address contains the destination address information for transmitting the frame next.
  • Originator Address contains the address information of the originator that is the Path Discovery request source.
  • the Originator SN includes the Sequence Number (SN) of the path managed by the originator that is the Path Discovery request source.
  • the JD Path Discovery Response Frame is not limited to the frame configuration shown in FIG. 7, and if at least one Detector Count including the Detector Count in the figure and one or more Detector Info including the Detector Address, Metric, and Previous Node Address are included. good. Further, although the frame is described assuming a MAC Frame, it may be transmitted as a TCP / IP Frame as long as the above information is described.
  • the relay node is when the Originator Address in the JD Path Discovery Request Element of the received JD Path Discovery Request Frame points to itself (Yes in S41 and S42), that is, when it is the Path Discovery request source. , End the process. On the other hand, if the Originator Address does not point to itself (No in S42), the Detector Info in the frame is checked one by one (S43).
  • the relay node calculates the path metric from the source of the frame to itself using the formula (2) described later, and describes the frame. Add to the metric value of (S45).
  • the relay node is the source of the frame using the formula (3) described later.
  • the path metric from to itself is calculated and added to the metric value described in the frame (S47).
  • step S45 or S47 When the process of step S45 or S47 is completed, the process proceeds to step S48.
  • the relay node compares the metric values stored for each detector candidate node, and if the numerical value calculated above is smaller (Yes in S48), the calculated metric value and the source of the frame (TA) are displayed. It is linked with the Detector Address and saved by overwriting in the managed route table (S49).
  • the processing for the confirmed Detector Info is terminated. This is because the first hop is always addressed to the detector. If there is another Detector Info (Yes in S50), the process returns to step S43, and the process for the other Detector Info is continued.
  • the formula for calculating the above-mentioned metric value will be described.
  • the metric calculation formula of the existing method that is, the metric calculation formula used in the process of step S45 of FIG. 8 is as shown in the following formula (2).
  • equation (2) the parameters used for the calculation are as follows.
  • ⁇ C a Link Metric
  • ⁇ O Varis depending on PHY It is an overhead value related to channel access including a frame header, a training signal (STF / LTF, etc.), and an access protocol frame (RTS / CTS, etc.), and is a fixed value.
  • ⁇ B t Test Payload The number of bytes in the frame. In IEEE802.11s, a fixed value (8192 bytes) is used.
  • ⁇ R Data Rate [Mbps] Test Payload (B t ) The data rate value expected to be used when sending. The choice of data rate is implementation dependent.
  • ⁇ E f Frame error rate This is the probability that the frame will be corrupted when the Test Payload (B t ) is sent at the Data Rate (r).
  • the estimation method is implementation-dependent.
  • the metric calculation formula from the supplier to the detector when Joint Detection is executed that is, the metric calculation formula used in the process of step S47 in FIG. 8 is as shown in the following formula (3).
  • JD Data Growth Rate It represents the rate of increase in the amount of information in the Pre-demodulated Data transmitted when Joint Detection is performed, as compared with the normally transmitted Demodulated data.
  • the parameter is stored in the JD Path Discovery Request Frame by the originator, and each relay node that receives the frame uses the numerical value stored in the frame.
  • JD Data Growth Rate There are several possible methods for determining the JD Data Growth Rate, but for example, it may be calculated according to the following equation (4).
  • ⁇ Q JDi Quantization Bit of Pre-demodulated Data ("I" domain)
  • Q JDq Quantization Bit of Pre-demodulated Data ("Q" domain)
  • the number of quantized bits may be implementation-dependent or standardized to use a value determined by the standard. The number of quantization bits may be different for each MCS of UL transmission. Quantization may be performed in amplitude or phase.
  • ⁇ N BPSCS Number of coded bits per single carrier for each spatial stream
  • ⁇ R Coding Rate Both N BPSCS and R are uniquely determined by MCS.
  • JDDataGrowthRate which is a parameter for calculating the path metric for Joint Detection, is a parameter determined by the number of quantization bits and ULMCS. After determining these parameters in advance, the originator stores and transmits the JDDataGrowthRate calculated by the above equation (4) in the JDPathDiscoveryRequestFrame.
  • the explanation is based on the metric calculation formula used in IEEE802.11s, this technique is not particularly limited to this, and at least JD Growth Rate is used when searching for a path for Joint Detection. If so, the metric may be calculated from RSSI (Received Signal Strength Indication), SNR (Signal-to-Noise-Ratio), etc. Further, instead of JDDataGrowthRate, each parameter used in the equation (4) may be stored in the frame, and JDDataGrowthRate may be calculated when the path metric value is calculated.
  • RSSI Receiveived Signal Strength Indication
  • SNR Signal-to-Noise-Ratio
  • Each node has received a JD Path Discovery Request Frame (No in S72) that is not the target or originator by itself at the time of acquiring the transmission right (S71), and the Lifetime in the frame has not elapsed (S73). No), if the Element TTL is not zero (No in S74), the process of step S75 is performed. That is, each node rewrites the acquired information such as Hop Count, Metric, Element TTL, etc. in the acquired Detector Info, and broadcasts the JD Path Discovery Request Frame (S75).
  • each node does not transmit JDPathDiscoveryRequestFrame when the transmission right is acquired.
  • the timing of acquiring the transmission right may be when the backoff of the user has expired or when transmission is permitted from another communication device.
  • FIG. 10 is a diagram showing a first example of a link between nodes.
  • FIG. 11 is a diagram showing an example of a route table of the relay node 3 (Relay 3) in the case of a link between the nodes shown in FIG.
  • the relay node 1 (Relay 1) is the originator and the source node (Source) is the target, and the transmission of the JD Path Discovery Request Frame is started from the relay node 1 (Relay 1).
  • the link metric value is described above each link, and Pre-demodulated Data is transmitted to all the links in the first hop from the relay node 1 (Relay 1) (that is, the destination is the detector candidate node).
  • the link metric value calculated by using a mathematical formula different from the existing method is described.
  • the relay node 3 (Relay 3) is the shortest route from the relay node 1 (Relay 1) to the path from the relay node 1 (Relay 1) to the source node (Source) (that is, “Relay 1 ⁇ ”. Only Relay3 ") is stored, and frames with higher metric values are discarded.
  • the path that becomes the minimum metric for each detector candidate node is continuously stored in the route table.
  • the relay node 3 (Relay 3) itself is a detector candidate node
  • the shortest path passing through the relay node 3 (Relay 3) is “Relay 1 ⁇ Relay 3”
  • the Previous Node is Relay 1
  • the metric value Is 8 (twice the normal metric value of 4), and the number of hops is 1.
  • the detector candidate node is relay node 2 (Relay 2)
  • the shortest path that the relay node 3 (Relay 3) passes through itself is "Relay 1 ⁇ Relay 2 ⁇ Relay 3”
  • the Previous Node is Relay 2.
  • the metric value is 12 (3 * 2 + 6) and the number of hops is 2.
  • the detector candidate node is the relay node 4 (Relay 4)
  • the same management is performed.
  • FIG. 12 is a diagram showing a second example of a link between nodes.
  • FIG. 13 is a diagram showing an example of a route table of a source node (Source) in the case of a link between the nodes shown in FIG.
  • the source node stores the minimum metric, Previous Node, and Hop Count for each detector candidate node from the received JD Path Discovery Request Frame in the route table. is doing.
  • the source node itself is a detector candidate node
  • the shortest path through it is "Relay 1 ⁇ Source”
  • the Previous Node is Relay 1
  • the metric value is 16 (8 * 2), and the number of hops. Is 1.
  • the detector candidate node is relay node 3 (Relay 3)
  • the shortest path through itself is "Relay 1 ⁇ Relay 3 ⁇ Source”
  • Previous Node is Relay 3
  • the metric value is 13. (4 * 2 + 5)
  • the number of hops is 2.
  • the detector candidate node is the relay node 2 (Relay 2) and the relay node 4 (Relay 4)
  • the same management is performed.
  • the node that received the JDPathDiscoveryRequestFrame is stored Previous when the Lifetime specified in the frame expires (S91) and if it is specified as the target in the frame (Yes in S92). Send JDPathDiscoveryResponseFrame to Node (S93).
  • JDPathDiscoveryResponseFrame As information indicating the destination of JDPathDiscoveryResponseFrame, it is assumed to be notified using the PreviousNodeAddress field in JDPathDiscoveryResponseElement, but if there is only one DetectorInfo, RA of the MAC header You may specify the destination with.
  • the node When the node receives the JDPathDiscoveryResponseFrame (S111), the node confirms the DetectorInfo in the Element of the frame one by one (S112).
  • the node When the PreviousNodeAddress in the DetectorInfo indicates its own address (Yes in S113), the node is used as the NextNode of the route table that manages the source address (TA) information in association with the DetectorAddress. Save (S114).
  • the node After that, if the node itself is not the originator (No in S115), after acquiring the next transmission right, the node transmits a JD Path Discovery Response Frame including the Detector Info that updated the Previous Node Address field (S116).
  • PreviousNodeAddress does not point to its own address (No in S113), or if it is the originator (Yes in S115), the processing for the confirmed DetectorInfo is terminated. If there is an unconfirmed Detector Info (Yes in S117), the process returns to step S112, and the processes up to this point are performed for the number of Detector Info.
  • FIG. 16 is a diagram showing a third example of a link between nodes.
  • FIG. 17 is a diagram showing an example of a route table of the relay node 3 (Relay 3) in the case of a link between the nodes shown in FIG.
  • the relay node 3 itself becomes the Previous Node in the frame transmitted from the source node (Source). Recognize that it is only when it becomes a detector candidate node.
  • the relay node 3 includes itself in the shortest path to the source node (Source) when the detector is managed as another relay node in the route table. Recognize that there is no. In this case, in the route table, the information that does not include itself may be deleted immediately or may be retained for a certain period of time.
  • the metric value may be calculated in JDPathDiscoveryResponseFrame as well, and the metric value of the reverse link from the source node (Source) to the relay node 3 (Relay3) may also be managed.
  • FIG. 18 is a diagram showing a fourth example of a link between nodes.
  • FIG. 19 is a diagram showing an example of a route table of the relay node 1 (Relay 1) in the case of a link between the nodes shown in FIG.
  • the relay node 1 (Relay 1), which is the originator, receives the JD Path Discovery Response Frame from each node and stores the optimum path and metric value when each node is set as a detector in the route table.
  • the Next Node, which is Relay 2 and the metric value, which is 14, are stored in association with the information managed as.
  • the Next Node, which is Relay 4 and the metric value, which is 21, are stored in association with the managed information.
  • the relay node 1 can use this information to select the optimum transmission route when Joint Detection is performed.
  • the metric value may be calculated in JDPathDiscoveryResponseFrame as well, and the metric value of the reverse link from the source node (Source) to the relay node 1 (Relay1) may also be managed.
  • FIG. 20 is a diagram showing a configuration example of JDSetupFrame.
  • JDSetupFrame consists of FrameControl, Duration, RA, TA, DialogToken, CoordinationType, CoordinationTypeVariant, and FCS.
  • Duration Duration
  • RA RA
  • TA DialogToken
  • CoordinationType CoordinationTypeVariant
  • FCS FCS
  • Frame Control contains information indicating the type of the frame.
  • the Duration contains information indicating the length of the frame.
  • the RA contains the destination address.
  • the TA contains the source address.
  • DialogToken contains information indicating the setup processing number.
  • Coordination Type contains information that specifies the cooperation method. As this designated information, it is described that Joint Detection is performed in the first embodiment.
  • the CoordinationTypeVariant contains a group of information specific to the cooperative method specified in the CoordinationType field. As this information group, in the first embodiment, information when performing Joint Detection is included. In addition, FCS is added as an error correction code.
  • the CoordinationTypeVariant contains fields that are JDRole, Metric, and CandidateNodeAddress.
  • JD Role contains information indicating whether the destination node is a detector or a supplier. You may leave JD Role as "Unknown" to determine the request destination. Metric contains the metric value for the role specified in JD Role. As Metric, it can be a numerical value stored in its own route table. Note that Metric may be used as information indicating "Unknow”.
  • CandidateNodeAddress includes the cooperation candidate node address of Joint Detection.
  • CandidateNodeAddress is an arbitrary field and is used only when the route table managed by the Joint Detection request source is not sufficient and the cooperative node or JD Role cannot be determined by itself.
  • the field is not required because the destination information is indicated by the RA of the frame.
  • RA can be a broadcast address or a multicast address.
  • JDSetupFrame is not limited to the frame configuration shown in FIG. 20, and may at least include information on CoordinationType, JDRole, and Metric in the figure. Further, although the frame is described assuming MAC Frame, if the above information is described, it may be transmitted as TCP / IP Frame.
  • FIG. 21 is a diagram showing a configuration example of JD UL Trigger.
  • JDULTrigger consists of FrameControl, Duration, RA, TA, CommonInfo, UserInfo, Padding, and FCS.
  • Duration Duration
  • RA RA
  • TA TA
  • CommonInfo UserInfo
  • Padding a resource provisioned by the JDULTrigger
  • FCS FCS
  • Frame Control contains information indicating the type of the frame.
  • the Duration contains information indicating the length of the frame.
  • the RA contains the destination address.
  • the TA contains the source address.
  • Common Info includes a group of information common to the wireless terminal STA for UL transmission.
  • UserInfo includes a group of information for each wireless terminal STA for UL transmission.
  • Padding is an additional bit provided for the wireless terminal STA to provide a preparation time for UL transmission.
  • FCS is an error correction code.
  • TriggerDependentCommonInfo includes a group of unique information for each Trigger Type. In this original information group, the information group necessary for performing Joint Detection in the first embodiment is described. For example, TriggerDependentCommonInfo includes DetectorNodeID and SupplierNodeID.
  • the DetectorNodeID contains the identification information of the node that acts as a detector. This identification information may be any information that can identify the MAC address, BSS Color, and other nodes.
  • the SupplierNodeID contains identification information of the node that acts as a supplier. This identification information may be any information that can identify the MAC address, BSS Color, and other nodes.
  • the JD UL Trigger is not limited to the frame configuration shown in FIG. 21, and may include at least the information of the Detector Node ID and the Supplier Node ID in the figure. Further, although the frame is described assuming that it is a MAC Frame, it may be transmitted as a TCP / IP Frame as long as the above information is described.
  • FIG. 22 is a diagram showing a configuration example of JDULDataFrame.
  • JDULDataFrame is composed of L-STF, L-LTF, L-SIG, RL-SIG, U-SIG, TypeDependentSIG, TypeDependentSTF, TypeDependentLTF, and DATA.
  • L-STF L-LTF
  • L-SIG L-SIG
  • RL-SIG U-SIG
  • TypeDependentSIG TypeDependentSTF
  • TypeDependentLTF TypeDependentLTF
  • L-STF is an abbreviation for non-HT (High Throughput) Short Training field and is used for signal detection.
  • L-LTF is an abbreviation for non-HT Long Training field and is used for frequency synchronization.
  • L-SIG is an abbreviation for non-HT SIGNAL field, and includes information groups (Length, etc.) for non-HT STA.
  • RL-SIG is an abbreviation for Reverse non-HT SIGNAL field, and is used to indicate that it is a data frame after HT.
  • U-SIG is an abbreviation for Universal SIGNAL field, and is a field that includes information groups common to standards since IEEE802.11be.
  • Type Dependent SIG is an abbreviation for Type Dependent SIGNAL field, and is a field that contains different information groups for each standard since IEEE802.11be. For example, in the case of IEEE802.11be, "EHT-SIG" is specified.
  • Type Dependent STF is an abbreviation for Type Dependent Short Training field, and has been used for synchronization of wideband signals that differ for each standard since IEEE802.11be.
  • Type Dependent LTF is an abbreviation for Type Dependent Long Training field, and has been used for channel estimation of MIMO signals that differ for each standard since IEEE802.11be.
  • DATA is a data part following the PHY header.
  • Type Dependent SIG includes fields that are Joint Detection Flag, Detector Node ID, and Supplier Node ID.
  • Joint Detection Flag is a flag indicating that it is a UL signal for Joint Detection.
  • the DetectorNodeID contains the identification information of the node that acts as a detector.
  • the SupplierNodeID contains identification information of the node that acts as a supplier. Information in JD UL Trigger is described in these identification information.
  • JDULDataFrame is not limited to the frame configuration shown in FIG. 22, and at least the information of the Joint Detection Flag, Detector Node ID, and Supplier Node ID in the figure may be included in the PHY header.
  • the node that has acquired the transmission right is called a sharing node.
  • the sharing node selects a cooperation candidate node when performing Joint Detection (Yes in S132) after acquiring the transmission right (S131).
  • the positional relationship of the wireless terminal STA that induces UL transmission that is, the link metric between the wireless terminal STA and each node
  • the sharing node is determined based on the acquired one).
  • the propagation loss with the wireless terminal STA that induces UL transmission may be taken into consideration.
  • JDULTrigger When the response of JDSetupFrame is received from the node (Yes in S137), JDULTrigger is transmitted to the wireless terminal STA (S143), and the UL signal is received. Subsequent processing will be described with reference to FIG.
  • the wireless terminal STA receives the JDULTrigger, the wireless terminal STA implements a flag indicating the execution of the cooperative processing (for example, Joint Detection Flag in FIG. 22) and the cooperative processing based on the information contained in the JDULTrigger. It is possible to transmit a UL signal (for example, JDULDataFrame in FIG. 22) including a PHY header in which node identification information (for example, DetectorNodeID, SupplierNodeID in FIG. 22) is set according to the role of processing at the time. can.
  • a UL signal for example, JDULDataFrame in FIG. 22
  • node identification information for example, DetectorNodeID, SupplierNodeID in FIG. 22
  • JD Setup Frame is sent to the node without specifying JD Role (S140). Then, when the response of the JD Setup Frame is received (Yes in S141), the detector and the supplier are determined by referring to the metric value in the response signal (S142), and the JD UL Trigger is transmitted to the wireless terminal STA (S143). Subsequent processing will be described with reference to FIG.
  • the sharing node uses UL Trigger as in the existing method. It transmits to the wireless terminal STA (S138), receives the UL signal, and then responds with Ack (S139). After that, if the transmittable period remains (Yes in S144), this process can be restarted. In this case, the sharing node itself may transmit a DL (Downlink) signal to the wireless terminal STA.
  • the number of cooperation candidate nodes is not limited to one, and a plurality of cooperation candidate nodes may be provided.
  • a plurality of Node Addresses are stored in the Candidate Node Address in the JD Setup Frame of FIG. 20.
  • the response JD Setup Frame may be transmitted in a time-division manner for each node, or may be scheduled and transmitted using OFDMA (Orthogonal Frequency Division Multiple Access) or the like.
  • OFDMA Orthogonal Frequency Division Multiple Access
  • the node that acquires JDSetupFrame from the sharing node and executes Joint Detection is called a shared node (SharedNode).
  • the shared node When the shared node acquires the JDSetupFrame (S161), it confirms whether RA is its own address or whether the identifier indicating itself is stored in the CandidateNodeAddress in the CoordinationTypeVariant field (S162). If either of them is applicable (Yes in S162), the process proceeds to the next process, but if neither of them is applicable (No in S162), the process is terminated as it is.
  • the shared node confirms whether or not the role is specified in the JD Role in the Coordination Type Variant field (S163).
  • JD Setup Frame responds to the sharing node (S165).
  • Joint Detection cannot be performed in the specified role (No in S164), the process ends as it is. Whether or not Joint Detection is feasible may be determined based on the Capability information, or may be independently determined based on the information based on its own performance.
  • the shared node determines the role. That is, when the supplier is the supplier in the route table, the metric value when the sharing node is the detector has been acquired, and Joint Detection can be executed (Yes in S166), the metric value is the smallest. The role is determined so as to be (S167). Then, after determining the role, the shared node responds to the sharing node with a JDSetupFrame including the role information of the determined sharing node (S165).
  • the UL signal is received after waiting for the JD UL Trigger to be transmitted from the sharing node. Subsequent processing will be described with reference to FIG.
  • each node receives the UL signal (S181)
  • the node as a detector waits for the processing in the PHY layer until the Pre-demodulated Data is transmitted from the supplier, and when the Pre-demodulated Data is acquired, the demodulation processing and the decoding processing by Joint Detection are started ( S185). After that, the node as a detector transmits ARQ (Automatic Repeat-Request) related information of UL signal data to the supplier (S186). If the DetectorNodeID in the PHY header does not point to itself (No in S184), the process ends as it is.
  • ARQ Automatic Repeat-Request
  • step S188 the node as a supplier transmits the received signal to the detector in the form of Pre-demodulated Data (S188). After that, the node as a supplier acquires the ARQ information from the detector (S189). Pre-demodulated Data is transmitted in quantized form. Communication between the nodes may be transmitted at the timing when the transmission right is acquired or at the scheduled timing. If the SupplierNodeID in the PHY header does not point to itself (No in S187), the process ends as it is.
  • step S186 or S189 the process proceeds to step S190.
  • Ack is transmitted to the wireless terminal STA (No. S191 in S190) based on the ARQ information, and then the process returns to the branch in step S144 in FIG.
  • FIG. 26 shows an example of a link between nodes at the time of normal data transmission
  • FIG. 27 shows an example of a link between nodes at the time of performing Joint Detection to which the present technology is applied. ..
  • the relay node 1 performs Joint Detection as a sharing node. The operation will be described.
  • the route "Relay 1 ⁇ Source" having the smallest metric value is selected. This transmission route is determined by the existing Path Discovery method.
  • the link metric value from the supplier to the detector is larger than that in the existing method, and the shortest route is different.
  • the route "Relay 1 ⁇ Relay 3 ⁇ Source" with the relay node 1 (Relay 1) as the supplier and the relay node 3 (Relay 3) as the detector is the transmission route with the smallest metric value (13). You can see that.
  • the relay node 1 (Relay 1) does not hold the shortest route information and the metric value when it is used as a detector
  • the relay node 3 (Relay 3) is stored in the route table, It is possible to determine the role of Joint Detection in JD Setup Frame.
  • the shortest route with the relay node 3 (Relay 3) as the supplier and the relay node 1 (Relay 1) as the detector is the route "Relay 3 ⁇ Relay 1 ⁇ Source”, and the metric value is 16.
  • "Relay 1 ⁇ Relay 3 ⁇ Source” with relay node 1 (Relay 1) as a supplier and relay node 3 (Relay 3) as a detector is a better route.
  • the candidates for cooperative nodes may be limited depending on the positional relationship of the wireless terminal STA.
  • the relay node 1 may determine the shortest transmission route and Joint Detection role after limiting the relay node 2 (Relay 2) or the relay node 3 (Relay 3) to the cooperation candidate nodes.
  • the configuration and processing when the UL transmission parameter is fixed in the mesh network have been described.
  • the following processing is performed by at least one control unit of the control unit 100, the communication control unit 111, and the communication control unit 121.
  • the exchange of information (information in each frame) used for determining the multi-hop transmission route is exchanged with another communication device (for example, another access point AP).
  • the supplier itself transmits the pre-demodulation data (for example, Pre-demodulated Data) that has not been demodulated to another communication device (detector).
  • the transmission route at that time can be used.
  • the quantization bit of the pre-demodulation data for example, the number of quantization bits of Pre-demodulated Data
  • the modulation method and coding rate of the uplink signal for example, MCS
  • a metric value for cooperative processing for example, a metric value for JD
  • a metric value for JD determined by the first parameter can be calculated (for example, calculated by equations (3) and (4)) and used.
  • the frame requesting the calculation of the metric value includes a value corresponding to the first parameter (for example, JDDataGrowthRate in FIG. 6) and a plurality of communications.
  • the address (for example, Detector Address in FIG. 6) and the metric value (for example, Metric in FIG. 6) for each detector candidate node that is a candidate for the node on the side for acquiring pre-demodulation data in the device are included.
  • the frame that responds to the calculation of the metric value for example, JDPathDiscoveryResponseFrame in FIG.
  • each detector candidate node that is a candidate of the node that acquires the pre-demodulation data among a plurality of communication devices. It includes an address (eg, Detector Address in FIG. 7), a metric value (eg, Metric in FIG. 7), and the address of the immediately preceding node (eg, Previous Node Address in FIG. 7).
  • the following effects can be expected. That is, in a multi-hop network environment in which multiple nodes exist, it is an optimum transmission route considering pre-demodulated Data transmission when performing Joint Detection, and it is possible to determine a transmission route including the role of Joint Detection. Will be.
  • the metric calculation is performed in consideration of the amount of data increase caused by Pre-demodulated Data transmission in Path Discovery in the mesh network, when Joint Detection is performed, Joint Detection is performed. It becomes possible to determine the optimum transmission route including the role.
  • the shortest route at the time of Joint Detection is searched by calculating the metric for Joint Detection at the time of Path Discovery Phase.
  • the metric value changes frequently. If Path Discovery Phase is implemented each time, it may lead to a decrease in wireless capacity due to an increase in overhead.
  • FIG. 28 is a diagram showing a configuration example of JDPathDiscoveryRequestFrame.
  • JDPathDiscoveryRequestFrame in the second embodiment and the JDPathDiscoveryRequestFrame (FIG. 6) in the first embodiment is that the JDPathDiscoveryRequestElement has no JDParameter and is in the DetectorInfo. , Hop # 1 Metric Parameters field is newly added.
  • the Detector Info includes fields such as Detector Address, Hop # 1 Metric Parameters, Metric, Hop Count, Element TTL, Path Discovery ID, Target Count, Per Target Flags, Target Address, and Target SN.
  • Hop # 1 Metric Parameters contains a set of parameters necessary for performing the metric calculation of the first hop.
  • the parameter type is not particularly limited. In the second embodiment, it is assumed that two parameters, r and e f , which have variable elements, are stored from the parameters of the metric calculation formula (2).
  • FIG. 29 is a diagram showing a configuration example of JD Path Discovery Response Frame.
  • the difference between the JD Path Discovery Response Frame in the second embodiment and the JD Path Discovery Response Frame (Fig. 7) in the first embodiment is that the Hop # 1 Metric Parameters field is newly added in the Detector Info. It is a point that was done.
  • the Detector Info includes fields such as Detector Address, Hop # 1 Metric Parameters, Metric, Hop Count, Element TTL, Path Discovery ID, and Previous Node Address.
  • Hop # 1 Metric Parameters contains a set of parameters necessary for performing the metric calculation of the first hop.
  • the parameter type is not particularly limited. In the second embodiment, it is assumed that two parameters, r and e f , which have variable elements, are stored from the parameters of the metric calculation formula (2).
  • step S217 in FIG. 30 and step S47 in FIG. 8 are particularly different.
  • HopCount is "1" and it is a detector candidate node (Yes in S214, Yes in S216) when JDPathDiscoveryRequestFrame is received, it is required for Hop # 1 Metric Parameters in the frame. All the information is stored (S217), and the path metric is calculated using the above-mentioned equation (2) (S215). Then, the Hop # 1 Metric Parameters saved here will continue to be stored in the JDPathDiscoveryRequestFrame transmitted after this, and the same information will be notified in the JDPathDiscoveryResponseFrame.
  • FIG. 31 is a diagram showing a fifth example of a link between nodes.
  • FIG. 32 is a diagram showing an example of a route table of the relay node 1 (Relay 1) in the case of a link between the nodes shown in FIG. 31.
  • the difference between the route table (FIG. 32) in the second embodiment and the route table (FIG. 11 and the like) in the first embodiment is that the metric value is the metric value according to the existing method, whereas it is new.
  • the point is that Hop # 1 Metric Parameters are stored and saved for each detector candidate node. The details will be described later, but when relay node 1 (Relay 1) performs Joint Detection, the path for Joint Detection is calculated from these metric values and Hop # 1 Metric Parameters, and the shortest path and the role of Joint Detection are determined. Can be done.
  • JD Path Metric is calculated (S243).
  • the following formula (5) is used.
  • the following “metric value of the first hop” is calculated from Hop # 1 Metric Parameters using the equation (2). Further, the “metric for JD in the first hop” is calculated from Hop # 1 Metric Parameters and ⁇ (JD Data Growth Rate) using the equation (3).
  • JD Path Metric (Saved metric)-(1st hop metric value) + (1st hop metric for JD) ⁇ ⁇ ⁇ (5)
  • FIGS. 34 and 36 show an example in which the relay node 1 (Relay 1) performs joint detection with another node when receiving a UL signal from the wireless terminals STA1 and STA2.
  • FIG. 34 shows a link between each node when the metric at the normal time is doubled when transmitting Pre-demodulated Data.
  • FIG. 36 shows a link between each node when the pre-demodulated data is transmitted, which is four times the normal metric.
  • the route table of FIG. 35 corresponds to the link between the nodes shown in FIG. 34.
  • the route table of FIG. 37 corresponds to the links between the nodes shown in FIG.
  • the upper table (A in FIG. 35, A in FIG. 37) represents the route table when oneself becomes a supplier (Supplier Node), and the lower table (B in FIG. 35, B in FIG. 37).
  • DetectorNode Represents the route table when it becomes a detector (DetectorNode).
  • all metric values are calculated using Eq. (3) before relay node 1 (Relay 1) induces a UL signal.
  • the above table can be calculated using the information obtained in the Path Discovery Phase requested by itself (Relay 1).
  • the table below can be calculated using the information obtained in the Path Discovery Phase requested by other nodes.
  • the optimum transmission route when Pre-demodulated Data transmission is twice the normal metric is “Relay 1 ⁇ Relay 3 ⁇ Source”, and the metric value is 13. Become.
  • the optimum transmission route when the pre-demodulated Data transmission is four times the normal metric is “Relay 1 ⁇ Relay 2 ⁇ Source”, and the metric. The value will be 20.
  • the relay node itself can determine the optimum transmission route and the role of Joint Detection without having to execute the Path Discovery Phase again. Become.
  • the configuration and processing when the UL transmission parameter fluctuates in the mesh network have been described.
  • the following processing is performed by at least one control unit of the control unit 100, the communication control unit 111, and the communication control unit 121.
  • the metric value calculated (for example, calculated by the equation (2)) without taking into account the increase amount of transmission data ( ⁇ : JDDataGrowthRate), and a plurality of communications.
  • a second parameter eg, Hop in FIGS. 28 and 29
  • Hop in FIGS. 28 and 29 that includes values required for metric calculation up to the detector candidate node, which is a candidate for the node that acquires pre-demodulated data (for example, Pre-demodulated Data) in the device.
  • Control is performed to determine the optimum transmission route based on the values corresponding to the # 1 Metric Parameters) and the first parameter (for example, the number of quantization bits of Pre-demodulated Data and MCS).
  • the address for each detector candidate node (for example, DetectorAddress in FIG. 28) and the metric value (for example, FIG. 28) are included.
  • Metric and the value corresponding to the second parameter (for example, Hop # 1 Metric Parameters in FIG. 28) are included.
  • the address for each detector candidate node (for example, DetectorAddress in FIG. 29), and the metric value (for example, Metric in FIG. 29). The value corresponding to the second parameter (for example, Hop # 1 Metric Parameters in FIG. 29), and the address of the immediately preceding node (for example, Previous Node Address in FIG. 29) are included.
  • the following effects can be expected. That is, in a multi-hop network environment in which multiple nodes exist, it is an optimum transmission route considering pre-demodulated Data transmission when performing Joint Detection, and it is possible to determine a transmission route including the role of Joint Detection. Will be.
  • the parameter information group for calculating the metric value of the link that may transmit Pre-demodulated Data in Path Discovery in the mesh network is stored and returned to the request node. Therefore, when the node performs Joint Detection, it is possible to flexibly determine the optimum transmission route including the role of Joint Detection in consideration of the amount of data increase that may fluctuate due to the transmission parameters of UL transmission. Become.
  • FIG. 38 is a diagram showing another configuration example of a wireless LAN system to which the present technology is applied.
  • the wireless LAN system has five access points AP1 to AP5 and four wireless terminals STA1 to STA4. Each access point AP constitutes a tree-type network.
  • the access point AP5 becomes a source node, and the access points AP1 to AP4 become relay nodes 1 to 4 (Relay 1 to Relay 4).
  • the wireless terminals STA1 and STA2 exist under the access point AP1, and the wireless terminals STA3 and STA4 exist under the access point AP2.
  • the difference between the wireless LAN system (FIG. 38) in the third embodiment and the wireless LAN system (FIG. 1) in the first embodiment is that the route between the nodes (structure of parent and child) is predetermined. There is a point. Therefore, in the wireless LAN system of FIG. 38, by measuring the metric value between the links with each node, it is possible to determine which node is best to cooperate with in performing Joint Detection, and further determine the role of Joint Detection. can.
  • FIG. 39 is a sequence diagram showing the exchange between the devices according to the third embodiment along the time axis.
  • the requesting node sends an Inter-NodeLinkMetricRequest to the surrounding node (S281) to calculate the metric value or the metric value measured from the surrounding node.
  • the parameter group required for this is answered by Inter-Node Link Metric Response (S282).
  • the same processing as the Joint Detection Phase (S3 in FIG. 5) is performed.
  • the Mesh Network Phase (S271) performs the same processing as the Mesh Network Phase (S1 in FIG. 5), and the Backhaul Link Measurement (S272) measures the backhaul link.
  • FIG. 40 is another example of a sequence diagram showing the exchange between devices in the third embodiment along the time axis.
  • a node (hereinafter referred to as a controller) that plays a role of centralized management of subordinate nodes is provided.
  • the source node is the controller.
  • the requesting node sends an Inter-NodeLinkMetricQuery to the controller (S331), so that the controller calculates the link metric value or the metric value from the surrounding node to the relay node 1 (Relay1).
  • the necessary parameter group is collected (S332, S333).
  • the node that wants to perform Joint Detection always sends a Joint Detection Setup Request to the controller (S334), and the Joint Detection Setup Response notifies the cooperative node and its role (S336), thereby processing the Joint Detection. Is carried out (S340).
  • FIG. 41 is a diagram showing a configuration example of Inter-Node Link Metric Request.
  • Inter-NodeLinkMetricRequest consists of tlvType, tlvLength, and tlvValue.
  • tlvType type-length-value
  • tlvValue type-length-value
  • the tlvType contains information indicating that the TLV is an Inter-Node Link Metric Request.
  • the tlvLength contains information indicating the length of the TLV.
  • the tlvValue contains a group of information to be notified by the TLV.
  • the tlvValue includes Number of Node ID and Node ID.
  • the Number of Node ID includes the number of nodes for which you want to request link metric measurement. You may specify all nodes by entering a specific numerical value (for example, 0).
  • the Node ID contains the identification information of the node for which the link metric measurement is requested. This identification information may be BSSID, BSSColor, or information uniquely allocated in the network.
  • Inter-NodeLinkMetricRequest is not limited to the frame configuration shown in FIG. 41, and at least the information of the NodeId in the figure may be included. Further, although the frame is assumed to be stored in TCP / IP Frame, it may be defined as MAC Frame as long as necessary information is described.
  • FIG. 42 is a diagram showing a configuration example of Inter-Node Link Metric Response.
  • Inter-NodeLinkMetricResponse consists of tlvType, tlvLength, and tlvValue.
  • tlvType type-length-value
  • tlvValue type-length-value
  • the tlvType contains information indicating that the TLV is an Inter-Node Link Metric Response.
  • the tlvLength contains information indicating the length of the TLV.
  • the tlvValue contains a group of information to be notified by the TLV. NodeID and MetricParameters are included in tlvValue.
  • the Node ID includes its own node identification information.
  • Metric Parameters includes the link metric value from itself to the request node, or a group of parameters necessary for calculating the metric value.
  • the parameter group may be the information required for the equation (3) or other information. For example, information such as RSSI and SNR may be used instead of the data rate value. In addition, information such as link usage rate and busy rate may be included.
  • Inter-NodeLinkMetricResponse is not limited to the frame configuration shown in FIG. 42, and at least the MetricParameters in the figure may be included. Further, although the frame is assumed to be stored in TCP / IP Frame, it may be defined as MAC Frame as long as necessary information is described.
  • FIG. 43 is a diagram showing a configuration example of Inter-Node Link Metric Query.
  • FIG. 44 is a diagram showing a configuration example of Joint Detection Setup Request.
  • Joint Detection SetupRequest consists of tlvType, tlvLength, and tlvValue.
  • tlvType type-length-value
  • tlvValue type-length-value
  • the tlvType contains information indicating that the TLV is a Joint Detection Setup Request.
  • the tlvLength contains information indicating the length of the TLV.
  • the tlvValue contains a group of information to be notified by the TLV. tlvValue includes JDDataGrowthRate, Number ofCandidateNode, and CandidateNodeID.
  • JDDataGrowthRate contains information indicating the data increase rate during Pre-demodulated Data transmission. Similar to the first embodiment, a numerical value determined by the MCS and the quantization bit of the UL signal is included.
  • the Number of Candidate Node contains the number of nodes that the Joint Detection request node wants to cooperate with. You may specify all nodes by entering a specific numerical value (for example, 0).
  • the Candidate Node ID contains the identification information of the node that the Joint Detection request node wants to cooperate with.
  • the identification information may be BSSID, BSSColor, or information uniquely allocated in the network.
  • the Joint Detection Setup Request is not limited to the frame configuration shown in FIG. 44, and may include at least the JD Data Growth Rate and the Candidate Node ID in the figure. Further, although the frame is assumed to be stored in TCP / IP Frame, it may be defined as MAC Frame as long as necessary information is described.
  • FIG. 45 is a diagram showing a configuration example of Joint Detection Setup Response.
  • Joint Detection Setup Response consists of tlvType, tlvLength, and tlvValue.
  • tlvType type-length-value
  • tlvValue type-length-value
  • the tlvType contains information indicating that the TLV is Joint Detection Setup Response.
  • the tlvLength contains information indicating the length of the TLV.
  • the tlvValue contains a group of information to be notified by the TLV.
  • the tlvValue includes the DetectorNodeID and SupplierNodeID.
  • the Detector Node ID includes the identification information of the node that plays the role of a detector when Joint Detection is executed.
  • the SupplierNodeID includes the identification information of the node that plays the role of the supplier when Joint Detection is executed. These identification information may be BSSID, BSSColor, or information uniquely assigned in the network.
  • the Joint Detection Setup Response is not limited to the frame configuration shown in FIG. 45, and may include at least the Detector Node ID and the Supplier Node ID in the figure. Further, although the frame is assumed to be stored in TCP / IP Frame, it may be defined as MAC Frame as long as necessary information is described.
  • the configuration and processing of the tree-type network have been described.
  • the following processing is performed by at least one control unit of the control unit 100, the communication control unit 111, and the communication control unit 121. That is, in the communication device 10 (for example, an access point AP), a third parameter (for example, Metric Parameters in FIG. 42) including a metric value with a surrounding node among a plurality of communication devices and a value necessary for calculating the metric value. ) Is used to control the optimum transmission route.
  • a third parameter for example, Metric Parameters in FIG. 42
  • the series of processes of the communication device 10 described above can be executed by hardware or software.
  • a program constituting the software is installed in the communication device 10.
  • the embodiment of the present technique is not limited to the above-described embodiment, and various changes can be made without departing from the gist of the present technique.
  • each embodiment has been described with reference to a sequence diagram, a frame configuration diagram, and a flowchart, but these embodiments are not necessarily limited to the illustrated configuration and may be used properly according to the situation. It doesn't matter.
  • the effects described herein are merely exemplary and not limited, and may have other effects.
  • Information used to determine a multi-hop transmission route is exchanged with other communication devices using wireless communication. It is provided with a control unit that controls to determine the optimum transmission route based on the amount of increase in transmission data when a plurality of communication devices cooperate to perform processing when the transmission route is determined based on the information.
  • Communication device (2) The communication according to (1) above, wherein the control unit determines a transmission route as an optimum transmission route when it is assumed that pre-demodulation data in a state where demodulation processing has not been performed is transmitted to another communication device.
  • Device (3) The control unit determines the optimum transmission route using the quantization bit of the pre-demodulation data and the first parameter including the modulation method and the coding rate of the uplink signal (1) or (2).
  • the communication device wherein the control unit calculates a metric value for cooperative processing determined by the first parameter, and determines an optimum transmission route based on the calculated metric value.
  • the control unit is a detector candidate that is a candidate for a node that acquires the value corresponding to the first parameter and the pre-demodulation data among the plurality of communication devices in the frame for requesting the calculation of the metric value.
  • the communication device which transmits an address including an address for each node and a metric value.
  • the control unit responds to the calculation of the metric value, the address, the metric value, and the immediately preceding address, the metric value, and the immediately preceding detector candidate node, which is a candidate of the node on the side for acquiring the pre-demodulation data among the plurality of communication devices.
  • the communication device according to (4) or (5) above, which transmits including the address of the node.
  • the control unit calculates a metric value calculated without considering the increase amount of the transmission data, and a metric calculation up to a detector candidate node which is a candidate of the node on the side for acquiring the pre-demodulation data among the plurality of communication devices.
  • the communication device according to (3) above, wherein the optimum transmission route is determined based on the second parameter including the value required for the above and the value corresponding to the first parameter.
  • the control unit transmits the frame requesting the calculation of the metric value including the address for each detector candidate node, the metric value, and the value corresponding to the second parameter.
  • the control unit transmits the frame in response to the calculation of the metric value, including the address for each detector candidate node, the metric value, the value corresponding to the second parameter, and the address of the immediately preceding node.
  • the communication device according to (8).
  • the control unit determines an optimum transmission route by using a third parameter including a metric value with surrounding nodes among the plurality of communication devices and a value necessary for calculating the metric value (1).
  • the communication device described in. (11) When the plurality of communication devices cooperate to perform processing, the control unit determines the role of the coordination processing based on the optimum transmission route determined for each cooperation candidate node included in the plurality of communication devices.
  • the communication device according to any one of (1) to (3) above.
  • (12) The communication device according to (11) above, wherein the cooperation candidate node is defined by a propagation loss or a positional relationship with another communication device that induces an uplink signal.
  • the communication device (13) The communication device according to (11) or (12) above, wherein the control unit determines the role of the cooperative processing so that the metric value is the smallest in the optimum transmission route for each cooperative candidate node. (14) The control unit determines, as the role of cooperative processing, a supplier that is a node that transmits the pre-demodulation data among the plurality of communication devices, or a detector that is a node that acquires the pre-demodulation data. The communication device according to (13). (15) The control unit receives a frame requesting cooperative processing transmitted from another communication device, and performs processing in cooperation with the other communication device in a role designated for the frame (11). The communication device according to any one of (14).
  • the communication device according to any one of (1) to (15) above, which is configured as an access point in a wireless LAN system.
  • the communication device Information used to determine a multi-hop transmission route is exchanged with other communication devices using wireless communication.
  • (18) Receives trigger signals transmitted from other communication devices included in multiple communication devices that perform processing in cooperation, Communication including a control unit that controls transmission of an uplink signal including a flag indicating the execution of cooperative processing in a multi-hop network and a PHY header in which node identification information is set according to the role of the processing when performing cooperative processing. Device.
  • the communication device (19)
  • (20) The communication device according to (18) or (19) above, which is configured as a wireless terminal in a wireless LAN system
  • 10 communication device 100 control unit, 101 wireless communication unit, 102 wireless communication unit, 103 storage unit, 104 WAN communication unit, 111 communication control unit, 112 communication storage unit, 113 data processing unit, 114 signal processing unit, 115 wireless interface.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本技術は、最適な伝送ルートを決定することができるようにする通信装置、及び通信方法に関する。 マルチホップの伝送ルートの決定に使用する情報のやり取りを、他の通信装置との間で無線通信を利用して行い、情報に基づいて伝送ルートを決定する際に、複数の通信装置が協調して処理を実施するときの伝送データの増加量に基づいて最適な伝送ルートを決定する制御を行う制御部を備える通信装置が提供される。本技術は、例えば、無線LANシステムを構成する機器に適用することができる。

Description

通信装置、及び通信方法
　本技術は、通信装置、及び通信方法に関し、特に、最適な伝送ルートを決定することができるようにした通信装置、及び通信方法に関する。
　近年、スタジアムや家庭内などに、無線LAN(Local Area Network)のアクセスポイント（AP：Access Point）が複数置かれる環境が増えており、アクセスポイント間で協調しシステムスループット向上や信頼性向上を目指すMulti-AP Coordination技術が注目を浴びている。
　その中の技術の１つであるJoint Detectionは、無線端末（STA：STAtion）からのアップリンク信号を複数のアクセスポイントで受信して受信信号を集約し、いずれか１台のアクセスポイントで受信演算処理を行うことで、協調したアクセスポイント分の受信アンテナを使用したUL MU-MIMO(Uplink Multiuser Multiple-Input and Multiple-Output)を実現する。これにより、一度に多くの無線端末からアップリンク（UL：Uplink）信号を取得してスループット向上及び低遅延伝送化が実現できる。
　また、複数のノードを経由（ホップ）することで目的地までデータを伝送するマルチホップ技術を用いたマルチホップネットワーク（Multi-Hop Network）が知られている。例えば、特許文献１には、マルチホップを行うネットワークであるメッシュネットワークにおいて、パスメトリック値を測定又は算出してメッシュパス（通信経路）を設定する技術が開示されている。
特開2015-046661号公報
　Joint Detectionを実現するためには、少なくとも１台のアクセスポイントは復調処理が行われていない状態のデータ（以下、Pre-demodulated Dataと呼ぶ）を、他のアクセスポイントに伝送しなければならない。通常、Pre-demodulated Dataは、既存方式の伝送データ以上の情報量となることが想定されており、アクセスポイント間のバックホールリンク（Backhaul Link）が逼迫しやすい状態となり得る。
　そのため、マルチホップネットワークにおいて、どのアクセスポイントがPre-demodulated Dataを集約し、受信演算処理を行って復調処理と復号処理を実施するか、各アクセスポイントの役割とバックホールリンクのルートを最適化し、バックホールリンクの実効レート最大化が重要となる。
　既存方式のマルチホップネットワークでは、例えば、特許文献１に開示されているように、各パスのメトリック値を測定又は算出し、最適なルーティングを決定するアルゴリズムを導入していることが一般的である。しかしながら、Joint Detectionにおけるルーティング制御では、一部のパスは情報量の多いPre-demodulated Dataを伝送しなくてはならないことから、ルーティングの決定方法は大きく異なる。
　本技術はこのような状況に鑑みてなされたものであり、最適な伝送ルートを決定することができるようにするものである。
　本技術の一側面の通信装置は、マルチホップの伝送ルートの決定に使用する情報のやり取りを、他の通信装置との間で無線通信を利用して行い、前記情報に基づいて前記伝送ルートを決定する際に、複数の通信装置が協調して処理を実施するときの伝送データの増加量に基づいて最適な伝送ルートを決定する制御を行う制御部を備える通信装置である。
　本技術の一側面の通信方法は、通信装置が、マルチホップの伝送ルートの決定に使用する情報のやり取りを、他の通信装置との間で無線通信を利用して行い、前記情報に基づいて前記伝送ルートを決定する際に、複数の通信装置が協調して処理を実施するときの伝送データの増加量に基づいて最適な伝送ルートを決定する通信方法である。
　本技術の一側面の通信装置、及び通信方法においては、マルチホップの伝送ルートの決定に使用する情報のやり取りが、他の通信装置との間で無線通信を利用して行われ、前記情報に基づいて前記伝送ルートを決定する際に、複数の通信装置が協調して処理を実施するときの伝送データの増加量に基づいて最適な伝送ルートが決定される。
　本技術の一側面の通信装置は、マルチホップネットワークにおいて協調して処理を実施する複数の通信装置に含まれる他の通信装置から送信されてくるトリガ信号を受信し、協調処理の実施を示すフラグ、及び協調処理を実施するときの処理の役割に応じたノード識別情報を設定したPHYヘッダを含むアップリンク信号を送信する制御を行う制御部を備える通信装置である。
　本技術の一側面の通信装置においては、マルチホップネットワークにおいて協調して処理を実施する複数の通信装置に含まれる他の通信装置から送信されてくるトリガ信号が受信され、協調処理の実施を示すフラグ、及び協調処理を実施するときの処理の役割に応じたノード識別情報を設定したPHYヘッダを含むアップリンク信号が送信される。
　なお、本技術の一側面の通信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。
本技術を適用した無線LANシステムの構成例を示す図である。 本技術を適用した通信装置の構成例を示すブロック図である。 図２の無線通信部の信号処理部内の受信動作を説明するための図である。 Joint Detectionの概要を説明する図である。 第１の実施の形態における装置間のやり取りを時間軸に沿って表したシーケンス図である。 JD Path Discovery Request Frameの構成例を示す図である。 JD Path Discovery Response Frameの構成例を示す図である。 JD Path Discovery Request Frame受信時の処理の流れを説明するフローチャートである。 JD Path Discovery Request Frame送信時の処理の流れを説明するフローチャートである。 ノード間のリンクの第１の例を示す図である。 図１０のノード間のリンクの場合におけるRelay3のルートテーブルの例を示す図である。 ノード間のリンクの第２の例を示す図である。 図１２のノード間のリンクの場合におけるSourceのルートテーブルの例を示す図である。 JD Path Discovery Response Frame送信時の処理の流れを説明するフローチャートである。 JD Path Discovery Response Frame受信時の処理の流れを説明するフローチャートである。 ノード間のリンクの第３の例を示す図である。 図１６のノード間のリンクの場合におけるRelay3のルートテーブルの例を示す図である。 ノード間のリンクの第４の例を示す図である。 図１８のノード間のリンクの場合におけるRelay1のルートテーブルの例を示す図である。 JD Setup Frameの構成例を示す図である。 JD UL Triggerの構成例を示す図である。 JD UL Data Frameの構成例を示す図である。 シェアリングノードにおける処理の流れを説明するフローチャートである。 シェアードノードにおける処理の流れを説明するフローチャートである。 Joint Detection実施時の処理の流れを説明するフローチャートである。 通常データ伝送時におけるノード間のリンクの例を示す図である。 Joint Detection実施時におけるノード間のリンクの例を示す図である。 JD Path Discovery Request Frameの構成例を示す図である。 JD Path Discovery Response Frameの構成例を示す図である。 JD Path Discovery Request Frame受信時の処理の流れを説明するフローチャートである。 ノード間のリンクの第５の例を示す図である。 図３１のノード間のリンクの場合におけるRelay1のルートテーブルの例を示す図である。 シェアリングノードにおける処理の流れを説明するフローチャートである。 他のノードとJoint Detectionを行う場合のノード間のリンクの第１の例を示す図である。 図３４のノード間のリンクの場合におけるルートテーブルの例を示す図である。 他のノードとJoint Detectionを行う場合のノード間のリンクの第２の例を示す図である。 図３６のノード間のリンクの場合におけるルートテーブルの例を示す図である。 本技術を適用した無線LANシステムの他の構成例を示す図である。 第３の実施の形態における装置間のやり取りを時間軸に沿って表したシーケンス図である。 第３の実施の形態における装置間のやり取りを時間軸に沿って表したシーケンス図である。 Inter-Node Link Metric Requestの構成例を示す図である。 Inter-Node Link Metric Responseの構成例を示す図である。 Inter-Node Link Metric Queryの構成例を示す図である。 Joint Detection Setup Requestの構成例を示す図である。 Joint Detection Setup Responseの構成例を示す図である。
（システム構成例）
　図１は、本技術を適用した無線LANシステムの構成例を示す図である。
　図１において、無線LANシステムには、５台のアクセスポイントＡＰ１乃至ＡＰ５と、２台の無線端末ＳＴＡ１，ＳＴＡ２が存在している。各アクセスポイントＡＰは、マルチホップを行うネットワークとしてメッシュネットワークを構築している。
　以下、バックホール（Backhaul）と接続しているアクセスポイントＡＰをソースノード（Source Node）、他のアクセスポイントＡＰをリレーノード（Relay Node）と呼ぶ。図１においては、アクセスポイントＡＰ５がソースノードとなり、アクセスポイントＡＰ１乃至ＡＰ４がリレーノード１乃至４（Relay 1乃至Relay 4）となる。
　各リレーノードは、取得したUL信号をソースノードへ中継伝送を行うことを想定しており、その際の伝送ルートに関しては既存方式を活用することができる。なお、ソースノードとリレーノードともセル形成を行い、配下に無線端末ＳＴＡが接続されている。以下、説明の簡略化のために、アクセスポイントＡＰ１（Relay 1）配下の無線端末ＳＴＡ１，ＳＴＡ２がUL信号伝送を行う際の動作について説明するが、本技術を適用した動作としてどのアクセスポイントＡＰの配下の無線端末ＳＴＡがUL信号伝送を行っても構わない。
　なお、対象となるシステム構成は、図１に示した構成に限定されるものではなく、接続が確立された複数の通信装置が存在し、それぞれの通信装置に対しに周囲端末として通信装置が存在していればよく、上述した条件が満たされていれば位置関係も問わない。
（装置の構成例）
　図２は、本技術を適用した通信装置の構成例を示す図である。
　通信装置１０は、図１のアクセスポイントＡＰとして構成される。通信装置１０は、制御部１００、無線通信部１０１、無線通信部１０２、記憶部１０３、及びWAN通信部１０４から構成される。また、無線通信部１０１と無線通信部１０２には、アンテナ１１７とアンテナ１２７がそれぞれ接続される。
　無線通信部１０１は、アクセスポイントＡＰの間における通信用（AP-AP間通信用）の無線通信部である。無線通信部１０１は、通信制御部１１１、通信記憶部１１２、データ処理部１１３、信号処理部１１４、無線インターフェース部１１５、及び増幅部１１６から構成される。
　通信制御部１１１は、各部の動作及び各部間の情報伝達の制御を行う。また、通信制御部１１１は、他の通信装置へ通知する制御情報及び管理情報を各データ処理部１１３へ受け渡す制御を行う。
　通信記憶部１１２は、通信制御部１１１で使用する情報を保持する。また、通信記憶部１１２は、送信するパケット及び受信したパケットを保持する。なお、送信するパケットを保持する送信バッファは、通信記憶部１１２内に含まれる。
　データ処理部１１３は、送信時に、通信記憶部１１２に保持されたデータ、並びに通信制御部１１１から受け取った制御情報及び管理情報のシーケンス管理を行い、暗号化処理等を行った後、MAC(Media Access Control)ヘッダ及び誤り検出符号を付加してパケットを生成する。データ処理部１１３は、生成したパケットの複数連結処理を行う。また、データ処理部１１３は、受信時に、受信したパケットのMACヘッダの連結解除処理、解析及び誤り検出、並びに再送要求動作リオーダ処理を行う。
　信号処理部１１４は、送信時に、パケットに対する符号化、インターリーブ及び変調等を行い、PHY(Physical)ヘッダを付加しシンボルストリームを生成する。また、信号処理部１１４は、受信時に、PHYヘッダを解析し、シンボルストリームに対する復調、デインターリーブ及び復号化等を行い、パケットを生成する。信号処理部１１４では、必要に応じて複素チャネル特性の推定及び空間分離処理が行われる。
　無線インターフェース部１１５は、送信時に、シンボルストリームに対するデジタル－アナログ信号変換、フィルタリング、アップコンバート、位相制御を行い、送信信号を生成する。また、無線インターフェース部１１５は、受信時に、受信信号に対しダウンコンバート、フィルタリング、アナログ－デジタル信号変換を行い、シンボルストリームを生成する。
　増幅部１１６は、無線インターフェース部１１５又はアンテナ１１７から入力された信号を増幅する。増幅部１１６は、一部が無線通信部１０１の外部の構成要素となってもよい。また、増幅部１１６の一部が無線インターフェース部１１５に内包されてもよい。
　無線通信部１０２は、アクセスポイントＡＰと無線端末ＳＴＡの間における通信用（AP-STA間通信用）の無線通信部である。無線通信部１０２は、通信制御部１２１、通信記憶部１２２、データ処理部１２３、信号処理部１２４、無線インターフェース部１２５、及び増幅部１２６から構成される。
　AP-STA間通信用の無線通信部１０２は、AP-AP間通信用の無線通信部１０１と同様に構成される。そのため、無線通信部１０２の内部構成については、上述した無線通信部１０１の内部構成の説明において、通信制御部１１１乃至増幅部１１６を、通信制御部１２１乃至増幅部１２６とそれぞれ読み替えればよい。
　ただし、無線通信部１０１と無線通信部１０２において、内部構成は全く同じであると想定しているが、両者の構成が多少異なっていても構わない。また、両者の送信パラメータ（中心周波数、帯域幅、最大送信電力値、アンテナ数等）は一致してなくてもよい。
　制御部１００は、無線通信部１０１，１０２及び通信制御部１１１，１２１の制御を行う。また、制御部１００は、通信制御部１１１，１２１の一部の動作を代わりに行ってもよい。なお、制御部１００と通信制御部１１１，１２１は、１つのブロックとして構成されてもよい。
　記憶部１０３は、制御部１００及び無線通信部１０１，１０２で使用する情報を保持する。また、記憶部１０３は、通信記憶部１１２，１２２の一部の動作を代わりに行ってもよい。記憶部１０３と通信記憶部１１２，１２２は、１つのブロックとして構成されてもよい。
　また、本技術では、無線通信部１０２における信号処理部１２４内の処理途中データであるPre-demodulated Dataを、他のアクセスポイントＡＰへ伝送する必要があるため、図２に示すように、信号処理部１２４から制御部１００に直接情報がやり取りされる必要がある。制御部１００が受け取ったPre-demodulated Dataは、量子化された情報を無線通信部１０１にて既存方式に応じた処理を用いて送信信号を生成し、他のアクセスポイントＡＰへ伝送される。また逆に、他のアクセスポイントＡＰから取得したPre-demodulated Dataを、制御部１００を介して無線通信部１０２の信号処理部１２４に受け渡され、当該情報を加味して受信処理を継続する。詳細については図３を参照して後述する。
　なお、必要に応じてPre-demodulated Dataが、記憶部１０３に一旦格納されても構わない。また、制御部１００や記憶部１０３を介さずとも、直接、無線通信部１０１，１０２内でデータ交換を行っても構わない。
　WAN通信部１０４は、バックホール（Backhaul）から取得したパケットを解読し、制御部１００を通じて無線通信部１０１，１０２へと受け渡す。ここで受け渡されるパケットの形式としては、IPヘッダがそのまま残された状態（アクセスポイントモード）でも、IPヘッダがWAN通信部１０４で解読され除去された状態（ルータモード）でも構わない。
　なお、図２において、無線通信部１０１，１０２のそれぞれは、１つのIC(Integrated Circuit)として構成されることを想定しているが、本技術を適用したICの構成はこれに限らない。例えば、無線インターフェース部１１５，１２５のそれぞれが、別のICとして搭載されても構わない。
　図３は、図２の無線通信部１０２の信号処理部１２４内の受信動作を説明するための図である。
　信号処理部１２４においては、MIMO検出部１５２に対し、その前段に、処理部１５１－１乃至１５１－Ｎ（Ｎは１以上の整数）が設けられ、その後段に、処理部１５３－１，１５３－２と、処理部１５４－１，１５４－２が設けられる。処理部１５１は、GI除去部１６１、FFT部１６２、及びチャネル推定部１６３を有する。処理部１５３，１５４は、IDFT部１７１、復調部１７２、及びデコード部１７３をそれぞれ有する。
　信号処理部１２４においては、まず、無線インターフェース部１２５からシンボルストリーム、すなわち、各受信アンテナにて取得したOFDM(Orthogonal Frequency Division Multiplexing)信号（時間軸上のI/Q Data）から、GI除去部１６１によりGI(Guard Interval)を除去し、FFT部１６２によるFFT(Fast Fourier Transform)処理にて周波数軸上の信号に変換する。
　その後、チャネル推定部１６３によりPHYヘッダ内の既知シンボルから周波数特性推定を行い、各受信アンテナから取得したPre-demodulated Data（周波数軸上のI/Q Data）とチャネル推定結果を使用して、MIMO検出部１５２によりMIMO処理を行い各ストリームの受信信号に分離する。その後、ストリームごとに、IDFT部１７１によるIDFT(Inverse Discrete Fourier Transform)処理と、復調部１７２による復調処理と、デコード部１７３による復号処理を施すことで、各無線端末ＳＴＡから取得した受信信号がBinary Data形式で取得される。取得されたデータは、データ処理部１２３に供給される。
　信号処理部１２４では、Joint Detectionを行うために、MIMO検出部１５２の直前に、Pre-demodulated Dataをやり取りするためのパスが追加されることを特徴としている。このパスは、上述した通り、制御部１００に繋がっている。
（Joint Detectionの概要）
　図４は、Joint Detectionの概要を説明する図である。
　Joint Detectionは、複数のアクセスポイントＡＰが協調し、１台のアクセスポイントＡＰとしてUL MU-MIMO処理を行う技術である。以下、適宜、Joint Detectionを、JDとも記述する。例えば、無線端末ＳＴＡ１，ＳＴＡ２がアクセスポイントＡＰ１，ＡＰ２に接続可能な場合、通常、各アクセスポイントＡＰの受信データは、下記の式（１）により表される。ただし、式（１）において、Wは受信ウェイトを表す。
Figure JPOXMLDOC01-appb-M000001
　既存方式のUL MU-MIMOでは、アクセスポイントＡＰが、無線端末ＳＴＡ１，ＳＴＡ２の両方のUL Dataを取得する場合、受信アンテナは、最低でもUL伝送を行う無線端末ＳＴＡの送信ストリームの合計数以上でなくてはならない。例えば、各無線端末ＳＴＡが２ストリームを伝送する場合、アクセスポイントＡＰは最低４本の受信アンテナが必要となる。受信アンテナ数未満の場合には、アクセスポイントＡＰは無線端末ＳＴＡからのストリームを完全に分離することができず、受信電力低下及び干渉や雑音電力増加に伴い、通信品質が大幅に悪化する可能性が高い。逆に、無線端末ＳＴＡ側の同時送信端末数及びストリーム数は、アクセスポイントＡＰの受信アンテナ数により限定されることとなる。
　一方、Joint Detectionを実施する際、受信アンテナ数は協調するアクセスポイントＡＰが持つ受信アンテナの合計数と等価となる。すなわち、例えば各無線端末ＳＴＡが２ストリームを伝送する場合、２台のアクセスポイントＡＰによるJoint Detectionでは、各アクセスポイントＡＰが受信アンテナ２本持つだけで伝送ストリームの分離を行うことが可能となる。逆に、Joint Detectionにより受信アンテナ総数が増加することで、無線端末ＳＴＡ側の同時送信端末可能数及びストリーム送信可能数が増加し、無線キャパシティを大幅に向上することが期待できる。
　上述した通り、２台のアクセスポイントＡＰでJoint Detectionを実施する場合、一方のアクセスポイントＡＰは他方のアクセスポイントＡＰにPre-demodulated Dataを伝送しなければならない。当該データは周波数軸上のI/Qで表せる数値を量子化した形で伝送しなくてはならず、既存方式のBinary Dataと比べ伝送すべき情報量は多くなることが推測される。さらに、Pre-demodulated Dataの量子化ビットは、UL信号の送信パラメータ（送信帯域幅やMCS(Modulation and Coding Scheme)等）により変わり得る。
　したがって、図１で示したようなマルチホップネットワークにおいて、Joint Detection実施時の最適な伝送ルート、及びその役割を既存方式でのパスルート決定と異なる方法にて判断しなければならない。Joint Detection実施時の役割としては、Pre-demodulated Dataを伝送する側（以下、サプライヤ（Supplier）と呼ぶ）と、Pre-demodulated Dataを取得する側（以下、ディテクタ（Detector）と呼ぶ）がある。
　そこで、本技術では、Joint Detectionを実施する際のパスルート、及びディテクタとサプライヤの役割を、UL信号の送信パラメータから動的に決定する手法を提供する。
＜１．第１の実施の形態＞
（全体シーケンス図）
　図５は、第１の実施の形態における装置間のやり取りを時間軸に沿って表したシーケンス図である。このシーケンス図では、Mesh Network Phase（Ｓ１），Path Discovery Phase（Ｓ２），Joint Detection Phase（Ｓ３）の３フェーズに分けて説明する。
　Mesh Network Phase（Ｓ１）では、ソースノード及び各リレーノード間でのメッシュネットワーク構築、及び通常時（Joint Detectionを実施しない時）の伝送ルート決定を行う。当該Phase内の動作については、既存方式と同様となるため、詳細な説明は省略する。
　Path Discovery Phase（Ｓ２）では、Joint Detection実施時の伝送ルート決定を行う。Path Discovery Phaseは、あるリレーノードがJD Path Discovery Requestを送信する（Ｓ１１）ことで処理が開始される。JD Path Discovery Requestを受信したノードは、メトリック値を計算し、最短ルート情報を更新した後、次の送信権獲得時に内容を更新したJD Path Discovery Requestを送信する（Ｓ１２）。
　これを事前に定められた期間内実施し、最後にPath Discoveryの宛先ノード（図５ではソースノード）が取得したJD Path Discovery Requestの中から最小メトリックとなるパス（Path）を、本処理を開始したリレーノードから自身まで（あるいはその逆も同様）のルートとして決定する。その後、宛先ノードから決定されたルートを逆に辿ってJD Path Discovery Responseが順に伝送されていく（Ｓ１３，Ｓ１４）。
　ここで、本処理を開始するノードをオリジネータ（Originator）、伝送ルートを決定したい最終宛先をターゲット（Target）と呼ぶ。なお、例えばソースノードがオリジネータとなってもよいし、ターゲットがリレーノードになってもよい。
　Joint Detectionを考慮したルート探索方法として既存方式と異なる点は、一部のメトリックの計算方法が異なることと、さらに自身がサプライヤとして動作した際のディテクタ候補ノードごとにメトリック計算及び最短ルートを計算する点である。これらの計算方法の詳細は後述する。
　Joint Detection Phase（Ｓ３）では、送信権を獲得したノードが、配下の無線端末ＳＴＡから他のノードとの協調動作（Joint Detection）を利用し、UL信号の受信と復号を行った後、定められた伝送ルートにてソースノードまで取得したデータを伝送する。
　まず、リレーノードは、UL送信を誘起する無線端末ＳＴＡ、及びPath Discovery Phase（Ｓ２）にて取得したルートとそのメトリック値から、協調するアクセスポイントＡＰと各々の役割（ディテクタとサプライヤ）を決定する（Ｓ１５）。この決定方法の詳細は後述する。
　次に、協調ノード間でJoint Detect Setupの交換を行った後（Ｓ１６，Ｓ１７）、JD UL Triggerによって、無線端末ＳＴＡからJoint Detection用のUL Data(JD UL DATA)を取得する（Ｓ１８，Ｓ１９）。そして、セットアップ時に決定したサプライヤが、Pre-demodulated Dataをディテクタに供給し（Ｓ２０）、その後にJoint Detection処理が実施され（Ｓ２１）、Demodulated dataがソースノードに伝送される（Ｓ２２）。
　なお、図５では、サプライヤが送信権を獲得した場合のシーケンス図を記載しているが、ディテクタが送信権を獲得した場合はPath Determination（Ｓ１５）がディテクタ側の処理となり、Joint Detect Setup（Ｓ１６，Ｓ１７）の矢印が逆になる。
（Ｓ２：Path Discovery Phase）
　全体シーケンス図におけるPath Discovery Phase（図５のＳ２）の詳細について説明する。ここでは、Path Discovery Phaseにて使用するフレームの構成例と、処理の流れを示すフローチャートについて説明する。
　図６は、JD Path Discovery Request Frameの構成例を示す図である。
　JD Path Discovery Request Frameは、Frame Control，Duration，RA，TA，Frame Body，FCSから構成される。ここでは、IEEE(Institute of Electrical and Electronics Engineers)802.11sに規定されたMesh Action FrameとPREQ Elementをベースした構成を示している。
　Frame Controlには、当該フレームの種類を示す情報が含まれる。Durationには、当該フレームの長さを示す情報が含まれる。RA(Receiver Address)には、送信先アドレスが含まれる。TA(Transmitter Address)には、送信元アドレスが含まれる。
　Frame Bodyには、送信する情報の本体が含まれる。この本体の情報として、第１の実施の形態では、Mesh Action Frameが含まれる。また、誤り訂正符号としてFCS(Frame Check Sequence)が付加される。Mesh Action Frame内には、Category，Mesh Action，JD Path Discovery Request Elementであるフィールドが含まれる。
　Categoryには、当該Action FrameがMesh Action Frameであることを示す情報が含まれる。Mesh Actionには、当該Mesh Action FrameがJD Path Discovery Request Frameであることを示す情報が含まれる。JD Path Discovery Request Elementには、Joint Detection用パス検出に使用する情報群が含まれる。
　JD Path Discovery Request Element内には、Element ID，Length，Originator Address，Originator SN，Lifetime，JD Parameter，Detector Count，Detector Infoであるフィールドが含まれる。
　Element IDには、当該エレメントがJD Path Discovery Request Elementであることを示す情報が含まれる。Lengthには、当該エレメントの長さを示す情報が含まれる。Originator Addressには、Path Discovery要求元であるオリジネータのアドレス情報が含まれる。Originator SNには、Path Discovery要求元であるオリジネータが管理するパスのSequence Number(SN)が含まれる。Lifetimeには、Path Discovery Request Frameを収集し伝送する残り時間情報が含まれる。
　JD Parameterには、Joint Detection用パス探索に必要な情報群が含まれる。この情報群として、第１の実施の形態では、少なくともメトリック値の計算に使用するJD Data Growth Rateが含まれる。Detector Countには、Joint Detection用パス探索を行うディテクタ候補数の情報が含まれる。当該フィールドに示される数値分だけ後続するDetector Infoフィールドが含まれる。Detector Infoには、ディテクタ候補ノードごとにパス情報群が含まれる。Detector Info内には、Detector Address，Metric，Hop Count，Element TTL，Path Discovery ID，Target Count，Per Target Flags，Target Address，Target SNであるフィールドが含まれる。
　Detector Addressには、ディテクタ候補ノードのアドレス情報が含まれる。Metricには、オリジネータからディテクタ候補ノードを経由して自身に届くまでのパスメトリック値が含まれる。このパスメトリック値の計算方法は後述する。Hop Countには、オリジネータからディテクタ候補ノードを経由して自身に届くまでのホップ数が含まれる。Element TTLには、残りホップ数の情報が含まれる。当該数値が0であるとき、これ以上のパス探索は行わない。
　Path Discovery IDには、当該Path Discovery処理の識別情報が含まれる。なお、ディテクタごとに同じIDが付与されるのであれば、当該フィールド内ではなく上段で通知されても構わない。Target Countには、Path Discovery要求先であるターゲットの個数を示す情報が含まれる。このTarget Countが示す数値分だけ、後続するPer Target Flags，Target Address，Target SNが含まれる。
　Per Target Flagsは、Path Discovery要求先であるターゲットの詳細情報を示すフラグである。Target Addressには、Path Discovery要求先であるターゲットのアドレス情報が含まれる。Target SNには、Path Discovery要求先であるが管理するパスのSequence Number (SN)が含まれる。なお、SNが不明である場合には、当該フィールドがスキップされてもよい。その場合には、Per Target Flags内のフラグにて当該フィールドの有無が通知される。
　なお、JD Path Discovery Request frameは、図６に示したフレーム構成に限定されず、少なくとも図中のJD Data Growth Rate，Detector Count，そしてDetector AddressとMetricを含むDetector Infoが１つ以上含まれていればよい。また、当該フレームはMAC Frameを想定して記載しているが、上記の情報が記載されていれば、TCP/IP Frameとして伝送されても構わない。
　図７は、JD Path Discovery Response Frameの構成例を示す図である。
　JD Path Discovery Response Frameは、Frame Control，Duration，RA，TA，Frame Body，FCSから構成される。ここでは、IEEE802.11sに規定されたMesh Action FrameとPREP Elementをベースにした構成を示している。
　Frame Controlには、当該フレームの種類を示す情報が含まれる。Durationには、当該フレームの長さを示す情報が含まれる。RAには、送信先アドレスが含まれる。TAには、送信元アドレスが含まれる。Frame Bodyには、送信する情報の本体が含まれる。この本体の情報として、第１の実施の形態では、Mesh Action Frameが含まれる。また、誤り訂正符号としてFCSが付加される。Mesh Action Frame内には、Category，Mesh Action，JD Path Discovery Response Elementであるフィールドが含まれる。
　Categoryには、当該Action FrameがMesh Action Frameであることを示す情報が含まれる。Mesh Actionには、当該Mesh Action FrameがJD Path Discovery Response frameであることを示す情報が含まれる。JD Path Discovery Response Elementには、決定したJoint Detection用パスに関する情報群が含まれる。
　JD Path Discovery Response Element内には、Element ID，Length，Target Address，Target SN，Lifetime，Detector Count，Detector Info，Originator Address，Originator SNであるフィールドが含まれる。
　Element IDには、当該エレメントがJD Path Discovery Response Elementであることを示す情報が含まれる。Lengthには、当該エレメントの長さを示す情報が含まれる。Target Addressには、Path Discovery要求先であるターゲットのアドレス情報が含まれる。Target SNには、Path Discovery要求先であるが管理するパスのSequence Number (SN)が含まれる。Lifetimeには、Path Discovery Response Frameを収集し伝送する残り時間情報が含まれる。
　Detector Countには、Joint Detection用パス探索を行うディテクタ候補数の情報が含まれる。当該フィールドに示される数値分だけ後続するDetector Infoフィールドが含まれる。Detector Infoには、ディテクタ候補ノードごとのパス情報群が含まれる。Detector Info内には、Detector Address，Metric，Hop Count，Element TTL，Path Discovery ID，Previous Node Addressであるフィールドが含まれる。
　Detector Addressには、ディテクタ候補ノードのアドレス情報が含まれている。Metricには、ターゲットから自身に届くまでのパスメトリック値が含まれる。このパスメトリック値の計算方法は後述する。Hop Countには、ターゲットから自身に届くまでのホップ数が含まれる。Element TTLには、残りホップ数の情報が含まれる。当該数値が0であるとき、これ以上当該フレームの伝送を行わない。
　Path Discovery ID には、Path Discovery Requestと同じ識別情報が含まれる。なお、ディテクタごとに同じIDが付与されるのであれば、当該フィールド内ではなく上段で通知されても構わない。Previous Node Addressには、次に当該フレームを伝送する宛先アドレス情報が含まれる。
　Originator Addressには、Path Discovery要求元であるオリジネータのアドレス情報が含まれる。Originator SNには、Path Discovery要求元であるオリジネータが管理するパスのSequence Number (SN)が含まれる。
　なお、JD Path Discovery Response Frameは、図７に示したフレーム構成に限定されず、少なくとも図中のDetector Count，そしてDetector Address，Metric，Previous Node Addressを含むDetector Infoが１つ以上含まれていればよい。また、当該フレームは、MAC Frameを想定し記載しているが、上記の情報が記載されていれば、TCP/IP Frameとして伝送されても構わない。
　次に、図８のフローチャートを参照して、JD Path Discovery Request Frame受信時の処理の流れを説明する。
　まず、リレーノードは、受信したJD Path Discovery Request FrameのJD Path Discovery Request Element内のOriginator Addressが自身を指していた場合（Ｓ４１，Ｓ４２のYes）、すなわち、自身がPath Discovery要求元であった場合、処理を終了する。一方で、Originator Addressが自身を指していなかった場合（Ｓ４２のNo）、フレーム内のDetector Infoを１つずつ確認していく（Ｓ４３）。
　リレーノードは、確認したDetector Infoについて、Hop Countが"1"でない場合（Ｓ４４のNo）、後述する式（２）を用いて当該フレームの送信元から自身までのパスメトリックを算出し、フレーム記載のメトリック値に加算する（Ｓ４５）。
　一方で、リレーノードは、Hop Countが"1"で、かつ、Detector Addressが自身を指している場合（Ｓ４４のYes，Ｓ４６のYes）、後述する式（３）を用いて当該フレームの送信元から自身までのパスメトリックを算出し、フレーム記載のメトリック値に加算する（Ｓ４７）。
　ステップＳ４５又はＳ４７の処理が終了すると、処理はステップＳ４８に進められる。リレーノードは、自身がディテクタ候補ノードごとに記憶しているメトリック値を比較し、上記で算出した数値の方が小さい場合（Ｓ４８のYes）、算出したメトリック値及びフレームの送信元（TA）をDetector Addressと紐づけて、管理するルートテーブルに上書き保存する（Ｓ４９）。
　なお、Hop Countが"1"で、かつ、Detector Addressが自身を指していない場合（Ｓ４４のYes，Ｓ４６のNo）、確認した当該Detector Infoに対する処理を終了する。これは、１ホップ目が必ずディテクタ宛となるためである。また、他のDetector Infoがある場合（Ｓ５０のYes）、処理はステップＳ４３に戻り、他のDetector Infoに対する処理が継続される。
　ここで、上述したメトリック値を算出する数式について説明する。まず、既存方式のメトリック計算式、すなわち、図８のステップＳ４５の処理で用いられるメトリック計算式は、下記の式（２）の通りである。
Figure JPOXMLDOC01-appb-M000002
　式（２）において、計算に使用されるパラメータは下記の通りである。
・ Ca：Link Metric
・ O：Varies depending on PHY
　　フレームヘッダ、トレーニング信号（STF/LTFなど）、アクセスプロトコルフレーム（RTS/CTSなど）を含むチャネルアクセスに関するオーバヘッド値であり、固定値である。
・ Bt：Test Payload
　　フレームのbyte数である。IEEE802.11sでは固定値（8192byte）を使用する。
・ r：Data Rate [Mbps]
　　Test Payload（Bt）送信時に使用されると想定されるデータレート値である。データレートの選択は実装依存である。
・ ef：Frame error rate
　　Test Payload（Bt）をData Rate（r）で送信する際にフレームが破損する確率である。推定方法は実装依存である。
　次に、Joint Detection実施時にサプライヤからディテクタまでのメトリック計算式、すなわち、図８のステップＳ４７の処理で用いられるメトリック計算式は、下記の式（３）の通りである。
Figure JPOXMLDOC01-appb-M000003
　ここで、式（３）において、上記の式（２）に対して追加されるパラメータは下記の通りである。
・ α：JD Data Growth Rate
　　通常伝送されるDemodulated dataと比較し、Joint Detection実施時に伝送されるPre-demodulated Dataの情報量増加率を表す。当該パラメータはオリジネータによってJD Path Discovery Request Frame内に格納され、当該フレームを受信した各リレーノードはフレーム内に格納された数値を使用する。なお、JD Data Growth Rateの決定方法はいくつか考えられるが、例えば、下記の式（４）の通り計算されても構わない。
Figure JPOXMLDOC01-appb-M000004
　ここで、式（４）において、計算に使用されるパラメータは下記の通りである。
・ QJDi：Quantization Bit of Pre-demodulated Data ("I" domain)
・ QJDq：Quantization Bit of Pre-demodulated Data ("Q" domain)
　　Pre-demodulated Dataの量子化ビット数
　　　量子化ビット数は実装依存でも、規格上決められた値を使用するよう規格化されても構わない。
　　　量子化ビット数はUL伝送のMCSごとに別の数値を使用されても構わない。
　　　量子化は振幅又は位相で行われても構わない。
・ NBPSCS：Number of coded bits per single carrier for each spatial stream
・ R：Coding Rate
　　NBPSCS，Rの両者ともMCSにより一意に決まる。
　例えば、無線端末ＳＴＡからMCS1 (NBPSCS=2, R=1/2)のUL信号が伝送されてきた場合、キャリアごとのDemodulated Dataは、2*1/2 = 1[bit]となる。一方、Joint Detectionのためにサプライヤが伝送するPre-demodulated Dataを、各キャリアの受信I/Q信号をI/Qとも5bitで量子化する場合、JD Data Growth Rateは、α = (5+5) / 1 = 10となる。
　一方、無線端末ＳＴＡからMCS7 (NBPSCS=5, R=5/6)のUL信号が伝送されてきた場合、キャリアごとのDemodulated Dataは、6*5/6 = 5[bit]となる。一方、Joint Detectionのためサプライヤが伝送するPre-demodulated Dataを、各キャリアの受信I/Q信号をI/Qとも5bitで量子化する場合、JD Data Growth Rateは、α = (5+5) / 5 = 2となる。
　従って、Joint Detection用のパスメトリックを算出するパラメータであるJD Data Growth Rateは、量子化ビット数とUL MCSにより決まるパラメータである。オリジネータは、予めこれらパラメータを決定した後に、上記の式（４）にて算出したJD Data Growth Rateを、JD Path Discovery Request Frame内に格納し送信する。
　なお、ここでは、IEEE802.11sで使用されているメトリック計算式を基に説明しているが、本技術は特にこれに限定されることはなく、Joint Detection用パス探索時に少なくともJD Growth Rateが使用されていれば、RSSI(Received Signal Strength Indication)，SNR(Signal-to-Noise-Ratio)等からメトリックを算出しても構わない。また、JD Data Growth Rateの代わりに、式（４）で用いる各パラメータがフレーム内に格納され、パスメトリック値の算出時にJD Data Growth Rateが計算されても構わない。
　次に、図９のフローチャートを参照して、JD Path Discovery Request Frame送信時の処理の流れを説明する。
　各ノードは、送信権獲得時（Ｓ７１）に、自身がターゲット又はオリジネータではないJD Path Discovery Request Frameを受信しており（Ｓ７２のNo）、かつ、当該フレーム内のLifetimeが未経過で（Ｓ７３のNo）、Element TTLがゼロでない場合（Ｓ７４のNo）、ステップＳ７５の処理を行う。すなわち、各ノードは、取得済みのDetector Info内のHop Count，Metric，Element TTL等の情報を書き替え、JD Path Discovery Request Frameをブロードキャスト送信する（Ｓ７５）。
　上記条件のいずれかを満足しない場合（Ｓ７２のYes，Ｓ７３のYes，又はＳ７４のYes）、各ノードは、送信権獲得時にJD Path Discovery Request Frame送信は行わない。なお、送信権獲得のタイミングとしては、自身のバックオフが満了した時でも、他の通信装置から送信を許可された時でも構わない。
（ルートテーブルの例）
　ここで、図１０，図１１を参照して、JD Path Discovery Request Frame送受信時におけるルートテーブルの例を説明する。図１０は、ノード間のリンクの第１の例を示す図である。図１１は、図１０に示したノード間のリンクとなる場合におけるリレーノード３（Relay 3）のルートテーブルの例を示す図である。
　図１０に示すように、リレーノード１（Relay 1）をオリジネータ，ソースノード（Source）をターゲットとし、リレーノード１（Relay 1）からJD Path Discovery Request Frameの送信が開始されたと仮定する。図１０では、各リンクの上にリンクメトリック値を記載しており、リレーノード１（Relay 1）から１ホップ目のリンクは全てPre-demodulated Dataが送信される（すなわち、宛先がディテクタ候補ノードとなる）として、上述した通り既存方式とは異なる数式を用いて算出したリンクメトリック値を記載している。
　ここでは簡単のため、Pre-demodulated Dataを伝送する場合、通常時のリンクメトリックの２倍になると仮定する。なお、以下特に説明がない限り、いずれも同様の仮定を立てているものとする。
　既存方式では、リレーノード３（Relay 3）は、リレーノード１（Relay 1）からソースノード（Source）までのパスに対し、リレーノード１（Relay 1）からの最短経路（すなわち、「Relay 1 → Relay 3」）のみを記憶し、それ以上のメトリック値を持つフレームは破棄する。一方で、本技術を適用した方式では、ディテクタ候補ノードごとに最小メトリックとなるパスをルートテーブルに記憶し続けることとなる。
　例えば、図１１に示すように、リレーノード３（Relay 3）は、自身がディテクタ候補ノードである場合、自身を通る最短経路が「Relay 1 → Relay 3」で、Previous NodeがRelay 1、メトリック値が8（4である通常時のメトリック値の２倍）、ホップ数が1となる。
　一方で、ディテクタ候補ノードがリレーノード２（Relay 2）の場合、リレーノード３（Relay 3）は、自身を通る最短経路が「Relay 1 → Relay 2 → Relay 3」で、Previous NodeがRelay 2、メトリック値が12（3*2+6）、ホップ数は2となる。また、ディテクタ候補ノードがリレーノード４（Relay 4）の場合も同様に管理することとなる。
　次に、図１２，図１３を参照して、JD Path Discovery Request Frame受信時におけるソースノード（Source）のルートテーブルの例を説明する。図１２は、ノード間のリンクの第２の例を示す図である。図１３は、図１２に示したノード間のリンクとなる場合におけるソースノード（Source）のルートテーブルの例を示す図である。
　ソースノード（Source）は、上述したリレーノード３（Relay 3）と同様に、受信したJD Path Discovery Request Frameの中からディテクタ候補ノードごとの最小メトリック、Previous Node、及びHop Countを、ルートテーブルに記憶している。
　例えば、ソースノード（Source）は、自身がディテクタ候補ノードである場合、自身を通る最短経路が「Relay 1 → Source」で、Previous NodeがRelay 1、メトリック値が16（8*2）、ホップ数は1となる。
　一方で、ディテクタ候補ノードがリレーノード３（Relay 3）の場合、ソースノード（Source）は、自身を通る最短経路が「Relay1 → Relay 3 → Source」で、Previous NodeがRelay 3、メトリック値は13（4*2+5）、ホップ数は2となる。また、ディテクタ候補ノードがリレーノード２（Relay 2），リレーノード４（Relay 4）の場合も同様に管理することとなる。
　図１４のフローチャートを参照して、JD Path Discovery Response Frame送信時の処理の流れを説明する。
　JD Path Discovery Request Frameを受信したノードは、当該フレームで指定されていたLifetimeが満了したとき（Ｓ９１）、当該フレームにて自身がターゲットと指定されていた場合（Ｓ９２のYes）、記憶済みのPrevious Nodeに、JD Path Discovery Response Frameを送信する（Ｓ９３）。
　JD Path Discovery Response Frameの宛先を示す情報として、JD Path Discovery Response Element内のPrevious Node Addressフィールドを使用して通知することを想定しているが、Detector Infoが１つのみの場合、MAC ヘッダのRAで宛先を指定しても構わない。
　次に、図１５のフローチャートを参照して、JD Path Discovery Response Frame受信時の処理の流れを説明する。
　ノードは、JD Path Discovery Response Frameを受信したとき（Ｓ１１１）、当該フレームのElement内のDetector Infoを１つずつ確認する（Ｓ１１２）。
　ノードは、Detector Info内のPrevious Node Addressが自身のアドレスを示している場合（Ｓ１１３のYes）、送信元アドレス（TA）の情報をDetector Addressと紐付けて管理しているルートテーブルのNext Nodeとして保存する（Ｓ１１４）。
　その後、ノードは、自身がオリジネータでない場合（Ｓ１１５のNo）、次の送信権を獲得した後に、Previous Node Addressフィールドを更新したDetector Infoを含むJD Path Discovery Response Frameを送信する（Ｓ１１６）。
　なお、Previous Node Addressが自身のアドレスを指していない場合（Ｓ１１３のNo）、あるいは自身がオリジネータである場合（Ｓ１１５のYes）、確認した当該Detector Infoに対する処理を終了する。また、未確認のDetector Infoがある場合（Ｓ１１７のYes）、処理はステップＳ１１２に戻り、ここまでの処理がDetector Infoの数だけ行われる。
（ルートテーブルの例）
　ここで、図１６，図１７を参照して、JD Path Discovery Response Frame受信時におけるルートテーブルの例を説明する。図１６は、ノード間のリンクの第３の例を示す図である。図１７は、図１６に示したノード間のリンクとなる場合におけるリレーノード３（Relay 3）のルートテーブルの例を示す図である。
　リレーノード３（Relay 3）は、JD Path Discovery Response Frame内のDetector Infoを１つずつ確認した結果、ソースノード（Source）から送信されてくるフレーム内で自身がPrevious Nodeとなるのが、自身がディテクタ候補ノードとなる時のみであることを認識する。
　そして、リレーノード３（Relay 3）は、「Detector Node = Relay 3」として管理している情報に紐づけて、Next NodeをSourceとしてルートテーブルに記憶する。このように、リレーノード３（Relay 3）は、リレーノード１（Relay 1）がサプライヤとなるJoint Detectionを実施するときに、自身がディテクタとなり、復調処理と復号処理を行った結果をソースノード（Source）に伝送することとなる。
　なお、リレーノード３（Relay 3）は、ルートテーブルで、ディテクタを他のリレーノードとして管理している情報について、それらをディテクタとした場合のソースノード（Source）までの最短経路に自身が含まれないことを認識する。この場合、ルートテーブルでは、自身を含まない情報をすぐに消去してもよいし、一定時間保持しても構わない。また、JD Path Discovery Response Frameでもメトリック値を計算し、ソースノード（Source）からリレーノード３（Relay 3）までの逆方向リンクのメトリック値を併せて管理しても構わない。
　次に、図１８，図１９を参照して、JD Path Discovery Response Frame受信時におけるリレーノード１（Relay 1）のルートテーブルの例を説明する。図１８は、ノード間のリンクの第４の例を示す図である。図１９は、図１８に示したノード間のリンクとなる場合におけるリレーノード１（Relay 1）のルートテーブルの例を示す図である。
　オリジネータであるリレーノード１（Relay 1）は、各ノードからのJD Path Discovery Response Frameを受け、各々のノードをディテクタと設定した際の最適なパス、及びメトリック値をルートテーブルに記憶する。
　具体的には、リレーノード１（Relay 1）では、「Detector Node = Source」として管理している情報に紐付けて、SourceであるNext Nodeと16であるメトリック値、「Detector Node = Relay 2」として管理している情報に紐付けて、Relay 2であるNext Nodeと14であるメトリック値をそれぞれ記憶する。また、リレーノード１（Relay 1）では、「Detector Node = Relay 3」として管理している情報に紐付けて、Relay 3であるNext Nodeと13であるメトリック値、「Detector Node = Relay 4」として管理している情報に紐付けて、Relay 4であるNext Nodeと21であるメトリック値をそれぞれ記憶する。
　後述する通り、リレーノード１（Relay 1）はこれら情報を用いて、Joint Detection実施時の最適な伝送ルートを選択することが可能となる。また、JD Path Discovery Response Frameでもメトリック値を計算し、ソースノード（Source）からリレーノード１（Relay 1）までの逆方向リンクのメトリック値を併せて管理しても構わない。
（Ｓ３：Joint Detection Phase）
　全体シーケンス図におけるJoint Detection Phase（図５のＳ３）の詳細について説明する。ここでは、Joint Detection Phaseにて使用するフレームの構成例と、処理の流れを示すフローチャートについて説明する。
　図２０は、JD Setup Frameの構成例を示す図である。
　JD Setup Frameは、Frame Control，Duration，RA，TA，Dialog Token，Coordination Type，Coordination Type Variant，FCSから構成される。ここでは、IEEE802.11-2016のAction Frameをベースにした構成を示している。
　Frame Controlには、当該フレームの種類を示す情報が含まれる。Durationには、当該フレームの長さを示す情報が含まれる。RAには、送信先アドレスが含まれる。TAには、送信元アドレスが含まれる。Dialog Tokenには、セットアップ処理番号を示す情報が含まれる。
　Coordination Typeには、協調方式を指定する情報が含まれる。この指定情報として、第１の実施の形態では、Joint Detectionを実施する旨が記載される。Coordination Type Variantには、Coordination Typeフィールドで指定した協調方式特有の情報群が含まれる。この情報群として、第１の実施の形態では、Joint Detectionを実施する際の情報が含まれる。また、誤り訂正符号としてFCSが付加される。Coordination Type Variant内には、JD Role，Metric，Candidate Node Addressであるフィールドが含まれる。
　JD Roleには、送信先ノードがディテクタか、又はサプライヤかを示す情報が含まれる。なお、JD Roleを"Unknown"として要求先の決定に委ねても構わない。Metricには、JD Roleで指定した役割におけるメトリック値が含まれる。Metricとしては、自身のルートテーブルに記憶されている数値とすることができる。なお、Metricを"Unknow"を示す情報としても構わない。
　Candidate Node Addressには、Joint Detectionの協調候補ノードアドレスが含まれる。Candidate Node Addressは、任意のフィールドであり、Joint Detection要求元の管理するルートテーブルが十分ではないなど、自身で協調ノードやJD Roleを決定できない場合のみ使用する。なお、協調ノードを指定する場合には、フレームのRAにて宛先情報を示すため、当該フィールドは不要となる。当該フィールドを使用する場合、RAは、ブロードキャストアドレス又はマルチキャストアドレスとなる。また、当該フィールドにブロードキャストアドレス又はマルチキャストアドレスを設定し、特定の候補ノードを指定しなくても構わない。
　なお、JD Setup Frameは、図２０に示したフレーム構成に限定されず、少なくとも図中のCoordination Type，JD Role，Metricの情報が含まれていればよい。また、当該フレームはMAC Frameを想定し記載しているが、上記の情報が記載されていれば、TCP/IP Frameとして伝送されても構わない。
　図２１は、JD UL Triggerの構成例を示す図である。
　JD UL Triggerは、Frame Control，Duration，RA，TA，Common Info，User Info，Padding，FCSから構成される。ここでは、IEEE802.11axのTrigger Frameをベースにした構成を示している。
　Frame Controlには、当該フレームの種類を示す情報が含まれる。Durationには、当該フレームの長さを示す情報が含まれる。RAには、送信先アドレスが含まれる。TAには、送信元アドレスが含まれる。
　Common Infoには、UL伝送に対し無線端末ＳＴＡに共通の情報群が含まれる。User Infoには、UL伝送に対し無線端末ＳＴＡごとの情報群が含まれる。Paddingは、無線端末ＳＴＡがUL伝送を行う準備時間を設けるために設けられる追加ビットである。FCSは、誤り訂正符号である。
　Common Infoには、Trigger Dependent Common Infoが含まれる。Trigger Dependent Common Infoには、Trigger Type別の独自情報群が含まれる。この独自情報群には、第１の実施の形態ではJoint Detectionを行うにあたり必要な情報群が記載される。例えば、Trigger Dependent Common Infoには、Detector Node ID，Supplier Node IDが含まれる。
　Detector Node IDには、ディテクタの役割を行うノードの識別情報が含まれる。この識別情報は、MACアドレス、BSS Color、その他各ノードを識別できる情報であれば構わない。Supplier Node IDには、サプライヤの役割を行うノードの識別情報が含まれる。この識別情報はMACアドレス、BSS Color、その他各ノードを識別できる情報であれば構わない。
　なお、JD UL Triggerは、図２１に示したフレーム構成に限定されず、少なくとも図中のDetector Node ID，Supplier Node IDの情報が含まれていればよい。また、当該フレームはMAC Frameと想定し記載しているが、上記の情報が記載されていれば、TCP/IP Frameとして伝送されても構わない。
　図２２は、JD UL Data Frameの構成例を示す図である。
　JD UL Data Frameは、L-STF，L-LTF，L-SIG，RL-SIG，U-SIG，Type Dependent SIG，Type Dependent STF，Type Dependent LTF，DATAから構成される。ここでは、IEEE802.11beで議論中のPHYヘッダをベースにした構成を示している。
　L-STFは、non-HT(High Throughput) Short Training fieldの略であり、信号検出に使用される。L-LTFは、non-HT Long Training fieldの略であり、周波数同期に使用される。L-SIGは、non-HT SIGNAL fieldの略であり、non-HT STA向けの情報群（Lengthなど）が含まれる。
　RL-SIGは、Reverse non-HT SIGNAL fieldの略であり、HT以降のデータフレームであることを表すために用いられる。U-SIGは、Universal SIGNAL fieldの略であり、IEEE802.11be以降、規格共通な情報群が含まれるフィールドである。
　Type Dependent SIGは、Type Dependent SIGNAL fieldの略であり、IEEE802.11be以降、規格ごとに異なる情報群が含まれるフィールドである。例えば、IEEE802.11beの場合、"EHT-SIG"が指定される。Type Dependent STFは、Type Dependent Short Training fieldの略であり、IEEE802.11be以降、規格ごとに異なる広帯域信号の同期のために使用される。Type Dependent LTFは、Type Dependent Long Training fieldの略であり、IEEE802.11be以降、規格ごとに異なるMIMO信号のチャネル推定に使用される。DATAは、PHYヘッダに続く、データ部である。
　Type Dependent SIGは、Joint Detection Flag，Detector Node ID，Supplier Node IDであるフィールドを含む。
　Joint Detection Flagは、Joint Detection用UL信号であることを示すフラグである。Detector Node IDには、ディテクタの役割を行うノードの識別情報が含まれる。Supplier Node IDには、サプライヤの役割を行うノードの識別情報が含まれる。これらの識別情報には、JD UL Trigger内の情報が記載される。
　なお、JD UL Data Frameは、図２２に示したフレーム構成に限定されず、少なくとも図中のJoint Detection Flag，Detector Node ID，Supplier Node IDの情報がPHYヘッダ内に含まれていればよい。
　次に、図２３のフローチャートを参照して、シェアリングノードにおける処理の流れを説明する。ここでは、送信権を獲得したノードを、シェアリングノード（Sharing Node）と呼んでいる。
　まず、シェアリングノードは、送信権獲得（Ｓ１３１）した後、Joint Detectionを実施する場合（Ｓ１３２のYes）、協調候補ノードを選択する（Ｓ１３３）。協調候補ノードの選択については、UL伝送を誘起する無線端末ＳＴＡの位置関係（すなわち、無線端末ＳＴＡと各ノード間のリンクメトリック）や、メッシュネットワークにおけるソースノードまでのメトリック値（Path Discovery Phaseにて取得したもの）に基づき、シェアリングノードが決定する。なお、協調候補ノードの選択に際しては、UL伝送を誘起する無線端末ＳＴＡとの伝搬損失を考慮してもよい。
　次に、Joint Detectionにおける役割を決定する。先ほど選択した協調候補ノードにおいて、自身が管理するルートテーブルに、自身がディテクタで当該ノードがサプライヤ時のメトリック値と、自身がサプライヤで当該ノードがディテクタ時のメトリック値を両方保持している場合（Ｓ１３４のYes）、処理は、ステップＳ１３５に進められる。そして、最小メトリックとなるように、ディテクタとサプライヤを決定し（Ｓ１３５）、JD Roleを指定したJD Setup Frameを当該ノードに送信する（Ｓ１３６）。
　当該ノードからJD Setup Frameの応答を受け取った場合（Ｓ１３７のYes）、JD UL Triggerを無線端末ＳＴＡ向けに送信し（Ｓ１４３）、UL信号を受信する。以降の処理は図２５にて説明する。なお、無線端末ＳＴＡは、JD UL Triggerを受信したとき、当該JD UL Triggerに含まれる情報に基づき、協調処理の実施を示すフラグ（例えば、図２２のJoint Detection Flag）、及び協調処理を実施するときの処理の役割に応じたノード識別情報（例えば、図２２のDetector Node ID，Supplier Node ID）を設定したPHYヘッダを含むUL信号（例えば、図２２のJD UL Data Frame）を送信することができる。
　一方で、自身がサプライヤで当該ノードがディテクタ時のメトリック値のみしか保持していない場合（Ｓ１３４のNo）、JD Roleを指定せずJD Setup Frameを当該ノードに送信する（Ｓ１４０）。そして、JD Setup Frameの応答を受け取った場合（Ｓ１４１のYes）、応答信号内のメトリック値を参照してディテクタとサプライヤを決定し（Ｓ１４２）、JD UL Triggerを無線端末ＳＴＡ向けに送信する（Ｓ１４３）。以降の処理は、図２５にて説明する。
　また、Joint Detectionを実施しない場合（Ｓ１３２のNo）、あるいは当該ノードからJD Setup Frameを一定時間取得できなかった場合（Ｓ１３７のNo，Ｓ１４１のNo）、シェアリングノードは、既存方式通りUL Triggerを無線端末ＳＴＡ宛に送信し（Ｓ１３８）、UL信号を受信した後、Ackを応答する（Ｓ１３９）。その後、送信可能期間が残っている場合（Ｓ１４４のYes）、本処理を再度開始することができる。またこの場合、シェアリングノード自らが無線端末ＳＴＡ宛にDL(Downlink)信号を送信しても構わない。
　ここで、協調候補ノードは１つに限定せず複数設けても構わない。この場合、図２０のJD Setup FrameにおけるCandidate Node Addressに、複数のNode Addressが格納されることになる。応答されるJD Setup Frameは、ノードごとに時分割で送信されても、OFDMA(Orthogonal Frequency Division Multiple Access)などを利用してスケジューリングされて送信されても構わない。
　次に、図２４のフローチャートを参照して、シェアードノードにおける処理の流れを説明する。ここでは、シェアリングノードからJD Setup Frameを取得して、Joint Detectionを実施するノードを、シェアードノード（Shared Node）と呼んでいる。
　シェアードノードは、JD Setup Frame取得時（Ｓ１６１）、RAが自分のアドレスである、あるいはCoordination Type Variantフィールド内のCandidate Node Addressに自身を示す識別子が格納されているかを確認する（Ｓ１６２）。両者のいずれかが該当する場合（Ｓ１６２のYes）、次の処理に進むが、両者のいずれも該当しない場合（Ｓ１６２のNo）、そのまま処理を終了する。
　次に、シェアードノードは、Coordination Type Variantフィールド内のJD Roleにて役割が指定されているか否かを確認する（Ｓ１６３）。JD Roleにて役割が指定されていた場合（Ｓ１６３のYes）、指定された役割でJoint Detectionが実施可能であるとき（Ｓ１６４のYes）、JD Setup Frameをシェアリングノードに応答する（Ｓ１６５）。
　また、指定された役割でJoint Detectionが実施可能ではない場合（Ｓ１６４のNo）、そのまま処理を終了する。なお、Joint Detectionが実施可能であるか否かは、Capability情報に基づき判断しても構わないし、あるいは自身のパフォーマンスに基づく情報によって独自で判断しても構わない。
　一方で、JD Roleにて役割が指定されていなかった場合（Ｓ１６３のNo）、シェアードノードが役割を決定する。すなわち、自身のルートテーブルにて自身がサプライヤで、シェアリングノードがディテクタの時のメトリック値を取得済みであり、かつ、Joint Detectionが実施可能である場合（Ｓ１６６のYes）、メトリック値が最も小さくなるよう役割を決定する（Ｓ１６７）。そして、シェアードノードは、役割を決定した後、決定したシェアリングノードの役割情報を含むJD Setup Frameをシェアリングノードに応答する（Ｓ１６５）。
　また、シェアードノードが該当するメトリック値を保持していない場合、あるいはJoint Detectionを実施可能でない場合（Ｓ１６６のNo）、そのまま処理を終了する。
　ステップＳ１６５の処理でJD Setup Frameを応答した後は、シェアリングノードからJD UL Triggerが送信されるのを待って、UL信号を受信する。以降の処理は、図２５にて説明する。
　次に、図２５のフローチャートを参照して、Joint Detection実施時の処理の流れを説明する。ここでは、シェアリングノードがJD UL Triggerを送信した後（図２３のＳ１４３，図２４のＳ１６５）、シェアリングノードとシェアードノード共通のフローチャートとなる。
　各々のノードは、UL信号を受信したとき（Ｓ１８１）、まず、PHYヘッダのみ復号して情報を確認する（Ｓ１８２）。自身がディテクタであり、かつ、PHYヘッダ内のDetector Node IDが自分を指している場合（Ｓ１８３のYes，Ｓ１８４のYes）、処理は、ステップＳ１８５に進められる。
　そして、ディテクタとしてのノードは、サプライヤからPre-demodulated Dataが伝送されてくるまでPHY層内の処理を待機し、Pre-demodulated Dataを取得した時点でJoint Detectionによる復調処理と復号処理を開始する（Ｓ１８５）。その後、ディテクタとしてのノードは、UL信号データのARQ(Automatic Repeat-Request)関連情報をサプライヤに送信する（Ｓ１８６）。また、PHYヘッダ内のDetector Node IDが自分を指していない場合（Ｓ１８４のNo）、そのまま処理を終了する。
　一方で、自身がサプライヤであり、かつ、PHYヘッダ内のSupplier Node IDが自分を指している場合（Ｓ１８３のNo，Ｓ１８７のYes）、処理は、ステップＳ１８８に進められる。そして、サプライヤとしてのノードは、受信した信号をPre-demodulated Dataの形でディテクタに送信する（Ｓ１８８）。その後、サプライヤとしてのノードは、ディテクタからARQ情報を取得する（Ｓ１８９）。Pre-demodulated Dataは量子化された形で伝送される。ノード間の通信は、送信権を獲得したタイミングでも、スケジューリングされたタイミングで伝送されても構わない。また、PHYヘッダ内のSupplier Node IDが自分を指していない場合（Ｓ１８７のNo）、そのまま処理を終了する。
　ステップＳ１８６又はＳ１８９の処理が終了すると、処理は、ステップＳ１９０に進められる。そして、最後に、自身がシェアードノードの時に限り、ARQ情報を基に、無線端末ＳＴＡにAckを送信し（Ｓ１９０のNo，Ｓ１９１）、その後、図２３のステップＳ１４４の分岐まで戻る。なお、Joint Detectionの結果次第では、Ackが送信されない無線端末ＳＴＡがあっても構わない。
（効果）
　最後に、図２６，図２７を参照しながら、第１の実施の形態におけるJoint Detection実施時の効果を説明する。
　ここでは、比較のために、図２６に、通常データ伝送時におけるノード間のリンクの例を示し、図２７に、本技術を適用したJoint Detection実施時におけるノード間のリンクの例を示している。また、ここでは、上述した図１８，図１９で説明したリレーノード１（Relay 1）が保有するルートテーブルにて、リレーノード１（Relay 1）がシェアリングノードとなるJoint Detectionを実施した際の動作について説明する。
　図２６の通常データの伝送時の伝送ルートでは、最もメトリック値が小さい「Relay 1 → Source」というルートが選択される。この伝送ルートは既存方式のPath Discoveryの方法で決定される。
　一方、図２７においては、第１の実施の形態におけるJoint Detection実施時、サプライヤからディテクタまでのリンクメトリック値が既存方式時よりも多くなり、最短ルートが異なる。この場合、リレーノード１（Relay 1）をサプライヤ、リレーノード３（Relay 3）をディテクタとした「Relay 1 → Relay 3 → Source」であるルートが、メトリック値（13）が最も小さい伝送ルートとなることが分かる。
　なお、特に言及はしていないが、リレーノード１（Relay 1）とリレーノード３（Relay 3）の役割については、リレーノード１（Relay 1）をオリジネータとするPath Discovery Phase、及びリレーノード３（Relay 3）をオリジネータとするPath Discovery Phaseの両方が完了していればよく、本技術を適用した方式を取れば、いずれのメトリック値もリレーノード１（Relay 1）が保持していることになる。
　仮にリレーノード１（Relay 1）が自身をディテクタとした際の最短ルート情報とメトリック値を保持していなくても、リレーノード３（Relay 3）がルートテーブルに保存している状態であれば、JD Setup FrameにてJoint Detectionの役割を決定することが可能となる。この場合、リレーノード３（Relay 3）をサプライヤ、リレーノード１（Relay 1）をディテクタとした最短ルートは、「Relay 3 → Relay 1 → Source」というルートであり、メトリック値は16となるため、やはりリレーノード１（Relay 1）をサプライヤ、リレーノード３（Relay 3）をディテクタとした「Relay 1 → Relay 3 → Source」がより良いルートであることが分かる。
　なお、無線端末ＳＴＡの位置関係次第では、協調ノードの候補が限られることもある。例えば、図２７の構成の場合、無線端末ＳＴＡ１，ＳＴＡ２からソースノード（Source）やリレーノード４（Relay 4）が遠く、UL信号を正しく取得できる可能性が乏しいと判断した場合、リレーノード１（Relay 1）は、リレーノード２（Relay 2）又はリレーノード３（Relay 3）を協調候補ノードに限定した後、最短となる伝送ルート及びJoint Detection役割を決定しても構わない。
　以上のように、第１の実施の形態では、メッシュネットワークでUL送信パラメータを固定したときの構成と処理を説明した。以上のような処理を実施する通信装置１０では、制御部１００、通信制御部１１１、及び通信制御部１２１の少なくとも１つの制御部によって、次のような処理が実施されている。
　すなわち、通信装置１０（例えばアクセスポイントＡＰ）においては、マルチホップの伝送ルートの決定に使用する情報（各フレーム内の情報）のやり取りを、他の通信装置（例えば他のアクセスポイントＡＰ）との間で無線通信を利用して行い、当該情報に基づいて伝送ルートを決定する際に、複数の通信装置が協調して処理を実施（Joint Detectionを実施）するときの伝送データの増加量（α：JD Data Growth Rate）に基づいて最適な伝送ルートを決定する制御が行われる。
　また、最適な伝送ルートを決定するに際しては、自身がサプライヤとして、復調処理を行っていない状態の復調前データ（例えばPre-demodulated Data）を、他の通信装置（ディテクタ）に伝送することを仮定した際の伝送ルートを用いることができる。さらに、最適な伝送ルートを決定する際には、復調前データの量子化ビット（例えばPre-demodulated Dataの量子化ビット数）、及びアップリンク信号の変調方式と符号化率（例えばMCS）を含む第１のパラメータにより定まる協調処理用のメトリック値（例えばJD用のメトリック値）を算出（例えば式（３）、式（４）により算出）して用いることができる。
　このとき、メトリック値の算出を要求するフレーム（例えば、図６のJD Path Discovery Request Frame）には、第１のパラメータに応じた値（例えば、図６のJD Data Growth Rate）、並びに複数の通信装置のうち復調前データを取得する側のノードの候補であるディテクタ候補ノードごとのアドレス（例えば、図６のDetector Address）、及びメトリック値（例えば、図６のMetric）が含まれる。また、メトリック値の算出を応答するフレーム（例えば、図７のJD Path Discovery Response Frame）内には、複数の通信装置のうち復調前データを取得する側のノードの候補であるディテクタ候補ノードごとのアドレス（例えば、図７のDetector Address）、メトリック値（例えば、図７のMetric）、及び直前のノードのアドレス（例えば、図７のPrevious Node Address）が含まれる。
　第１の実施の形態における構成を採用することで、例えば、次の効果が期待できる。すなわち、複数のノードが存在するマルチホップネットワーク環境において、Joint Detectionを行う際のPre-demodulated Data伝送を考慮した最適な伝送ルートであって、Joint Detectionの役割を含む伝送ルートを決定することが可能となる。
　また、第１の実施の形態においては、メッシュネットワークでのPath DiscoveryにてPre-demodulated Data伝送により生じるデータ増加量を考慮したメトリック計算が行われるため、Joint Detectionを実施する際に、Joint Detectionの役割を含む最適な伝送ルートを決定することが可能となる。
＜２．第２の実施の形態＞
　第１の実施の形態では、Path Discovery Phase時にJoint Detection用のメトリックを算出することで、Joint Detection実施時の最短ルートを検索していた。しかしながら、上述した通り、Pre-demodulated Dataの情報増加比はUL信号のMCSによって変わるため、メトリック値は頻繁に変わることとなる。その度にPath Discovery Phaseを実施するとオーバヘッド増加に伴う無線キャパシティの低下に繋がりかねない。
　そこで、第２の実施の形態では、Joint Detection実施時のメトリック値を直前に計算することで、Path Discovery Phaseを頻繁に実施しなくても最短パス及びJoint Detectionの役割を決定することができる方法を開示する。以下、第１の実施の形態との相違点のみを説明する。
　図２８は、JD Path Discovery Request Frameの構成例を示す図である。
　第２の実施の形態におけるJD Path Discovery Request Frameにおいて、第１の実施の形態におけるJD Path Discovery Request Frame（図６）との違いは、JD Path Discovery Request ElementからJD Parameterがなくなり、Detector Info内に、Hop#1 Metric Parametersフィールドが新たに追加された点である。
　すなわち、Detector Info内には、Detector Address，Hop#1 Metric Parameters，Metric，Hop Count，Element TTL，Path Discovery ID，Target Count，Per Target Flags，Target Address，Target SNであるフィールドが含まれる。
　Hop#1 Metric Parametersは、１ホップ目のメトリック計算を行うために必要なパラメータ群が含まれる。パラメータ種別は特に限定されるものではない。第２の実施の形態では、メトリック計算式である式（２）のパラメータの中から変動要素のある r と ef の２つが格納されることを想定する。
　図２９は、JD Path Discovery Response Frameの構成例を示す図である。
　第２の実施の形態におけるJD Path Discovery Response Frameにおいて、第１の実施の形態におけるJD Path Discovery Response Frame（図７）との違いは、Detector Info内に、Hop#1 Metric Parametersフィールドが新たに追加された点である。
　すなわち、Detector Info内には、Detector Address，Hop#1 Metric Parameters，Metric，Hop Count，Element TTL，Path Discovery ID，Previous Node Addressであるフィールドが含まれる。
　Hop#1 Metric Parametersには、１ホップ目のメトリック計算を行うために必要なパラメータ群が含まれる。パラメータ種別は特に限定されるものではない。第２の実施の形態では、メトリック計算式である式（２）のパラメータの中から変動要素のある r と ef の２つが格納されることを想定する。
　次に、図３０のフローチャートを参照して、JD Path Discovery Request Frame受信時の処理の流れを説明する。
　第２の実施の形態におけるJD Path Discovery Request Frame受信時の処理（図３０のＳ２１１乃至Ｓ２２０）において、第１の実施の形態におけるJD Path Discovery Request Frame受信時の処理（図８のＳ４１乃至Ｓ５０）との違いは、特に、図３０のステップＳ２１７と図８のステップＳ４７の処理内容が異なる点である。
　すなわち、JD Path Discovery Request Frame受信時に、Hop Countが"1"であり、かつ、自身がディテクタ候補ノードの場合（Ｓ２１４のYes，Ｓ２１６のYes）、当該フレーム内のHop#1 Metric Parametersに必要な情報を全て保存し（Ｓ２１７）、上述した式（２）を用いてパスメトリックを計算している（Ｓ２１５）。そして、この後に送信されるJD Path Discovery Request Frame内にも、ここで保存したHop#1 Metric Parametersが格納され続け、JD Path Discovery Response Frame内にも同様の情報が通知される。
（ルートテーブルの例）
　ここで、図３１，図３２を参照して、JD Path Discovery Response Frame受信時におけるルートテーブルの例を説明する。図３１は、ノード間のリンクの第５の例を示す図である。図３２は、図３１に示したノード間のリンクとなる場合におけるリレーノード１（Relay 1）のルートテーブルの例を示す図である。
　第２の実施の形態におけるルートテーブル（図３２）において、第１の実施の形態におけるルートテーブル（図１１等）との違いは、メトリック値は既存方式通りのメトリック値であるのに対し、新たにHop#1 Metric Parametersをディテクタ候補ノードごとに格納し保存している点である。詳細は後述するが、リレーノード１（Relay 1）はJoint Detectionを行うにあたり、これらメトリック値とHop#1 Metric Parametersから、Joint Detection用パスを算出し、最短パス及びJoint Detectionの役割を決定することができる。
　次に、図３３のフローチャートを参照して、シェアリングノードにおける処理の流れを説明する。
　第２の実施の形態におけるシェアリングノードの処理（図３３のＳ２４１乃至Ｓ２５５）において、第１の実施の形態におけるシェアリングノードの処理（図２３のＳ１３１乃至Ｓ１４４）との違いは、特に、図３３のステップＳ２４３の処理が追加されている点である。
　すなわち、Joint Detection実施時に、収集したメトリック値とHop#1 Metric Parameters、及び自身で定めたα（JD Data Growth Rate）から、ディテクタ候補ノードごと（及びサプライヤ候補ノードごと）のJD用のパスメトリック（JD Path Metric）を算出する（Ｓ２４３）。
　具体的な算出方法としては、下記の式（５）が用いられる。なお、下記の「１ホップ目のメトリック値」は、Hop#1 Metric Parametersから、式（２）を用いて算出される。また、「１ホップ目のJD用メトリック」は、Hop#1 Metric Parameters、及びα（JD Data Growth Rate）から、式（３）を用いて算出される。
　JD Path Metric = (保存済のメトリック) - (１ホップ目のメトリック値) + (１ホップ目のJD用メトリック) 　　　・・・（５）
（効果）
　最後に、図３４乃至図３７を参照しながら、第２の実施の形態におけるJoint Detection実施時の効果を説明する。
　図３４と図３６の両図とも、リレーノード１（Relay 1）が、無線端末ＳＴＡ１，ＳＴＡ２からUL信号を受信する際に、他のノードとJoint Detectionを行う例を図示している。図３４は、Pre-demodulated Dataを伝送する場合に、通常時のメトリックの２倍になった時の各ノード間のリンクを示している。図３６は、Pre-demodulated Dataを伝送する場合、通常時のメトリックの４倍になった時の各ノード間のリンクを示している。
　図３５のルートテーブルは、図３４に示したノード間のリンクに対応している。図３７のルートテーブルは、図３６に示したノード間のリンクに対応している。図３５と図３７において、上表（図３５のＡ，図３７のＡ）は自身がサプライヤ（Supplier Node）となった時のルートテーブルを表し、下表（図３５のＢ，図３７のＢ）は自身がディテクタ（Detector Node）となった時のルートテーブルを表している。これらの表において、メトリック値はいずれもリレーノード１（Relay 1）がUL信号を誘起する前に、式（３）を用いて計算される。
　なお、上表は自身（Relay 1）がリクエストしたPath Discovery Phase内で得られた情報を用いて計算することができる。また、下表は他のノードがリクエストしたPath Discovery Phase内で得られた情報を用いて計算することができる。
　図３４，図３５から分かる通り、Pre-demodulated Data伝送が通常時のメトリックの２倍になった時の最適な伝送ルートは、「Relay 1 → Relay 3 → Source」であり、メトリック値は13となる。それに対して、図３６，図３７から分かる通り、Pre-demodulated Data伝送が通常時のメトリックの４倍になった時の最適な伝送ルートは、「Relay 1 → Relay 2 → Source」であり、メトリック値は20となる。
　このように、UL伝送のパラメータが変わり、JD Growth Rateが頻繁に変わっても、再度Path Discovery Phase実施する必要なく、最適な伝送ルート及びJoint Detectionの役割をリレーノード自身が決定することが可能となる。
　以上のように、第２の実施の形態では、メッシュネットワークでUL送信パラメータが変動するときの構成と処理を説明した。以上のような処理を実施する通信装置１０では、制御部１００、通信制御部１１１、及び通信制御部１２１の少なくとも１つの制御部によって、次のような処理が実施されている。
　すなわち、通信装置１０（例えばアクセスポイントＡＰ）においては、伝送データの増加量（α：JD Data Growth Rate）を加味せずに算出（例えば式（２）により算出）されたメトリック値、複数の通信装置のうち復調前データ（例えばPre-demodulated Data）を取得する側のノードの候補であるディテクタ候補ノードまでのメトリック計算に必要な値を含む第２のパラメータ（例えば、図２８，図２９のHop#1 Metric Parameters）、及び第１のパラメータ（例えばPre-demodulated Dataの量子化ビット数やMCS）に応じた値に基づいて、最適な伝送ルートを決定する制御が行われる。
　このとき、メトリック値の算出を要求するフレーム（例えば、図２８のJD Path Discovery Request Frame）には、ディテクタ候補ノードごとのアドレス（例えば、図２８のDetector Address）、メトリック値（例えば、図２８のMetric）、及び第２のパラメータ（例えば、図２８のHop#1 Metric Parameters）に応じた値が含まれる。また、メトリック値の算出を応答するフレーム（例えば、図２９のJD Path Discovery Response Frame）に、ディテクタ候補ノードごとのアドレス（例えば、図２９のDetector Address）、メトリック値（例えば、図２９のMetric）、第２のパラメータ（例えば、図２９のHop#1 Metric Parameters）に応じた値、及び直前のノードのアドレス（例えば、図２９のPrevious Node Address）が含まれる。
　第２の実施の形態における構成を採用することで、例えば、次の効果が期待できる。すなわち、複数のノードが存在するマルチホップネットワーク環境において、Joint Detectionを行う際のPre-demodulated Data伝送を考慮した最適な伝送ルートであって、Joint Detectionの役割を含む伝送ルートを決定することが可能となる。
　また、第２の実施の形態においては、メッシュネットワークでのPath DiscoveryにてPre-demodulated Data伝送の可能性があるリンクのメトリック値を算出するためのパラメータ情報群を記憶し、要求ノードに返答することで、当該ノードはJoint Detectionを実施する際に、UL伝送の送信パラメータなどにより変動し得るデータ増加量を考慮し、柔軟にJoint Detectionの役割を含む最適な伝送ルートを決定することが可能となる。
＜３．第３の実施の形態＞
　第３の実施の形態では、ツリー型のマルチホップネットワーク構造したにおいてJoint Detectionを行う際の構成と処理について説明する。
（システム構成例）
　図３８は、本技術を適用した無線LANシステムの他の構成例を示す図である。
　図３８において、無線LANシステムには、５台のアクセスポイントＡＰ１乃至ＡＰ５と、４台の無線端末ＳＴＡ１乃至ＳＴＡ４が存在している。各アクセスポイントＡＰは、ツリー型のネットワークを構成している。図３８においては、アクセスポイントＡＰ５がソースノードとなり、アクセスポイントＡＰ１乃至ＡＰ４がリレーノード１乃至４（Relay 1乃至Relay 4）となる。アクセスポイントＡＰ１の配下に無線端末ＳＴＡ１，ＳＴＡ２が存在し、アクセスポイントＡＰ２の配下に無線端末ＳＴＡ３，ＳＴＡ４が存在する。
　第３の実施の形態における無線LANシステム（図３８）において、第１の実施の形態における無線LANシステム（図１）との違いは、ノード間のルート（親と子の構造）が予め決定されている点にある。そのため、図３８の無線LANシステムでは、各ノードとのリンク間のメトリック値を測定することで、Joint Detectionを行うにあたりどのノードと協調するのが最適か、さらにJoint Detectionの役割を決定することができる。
（全体シーケンス図）
　図３９は、第３の実施の形態における装置間のやり取りを時間軸に沿って表したシーケンス図である。
　第３の実施の形態における全体シーケンス図（図３９）において、第１の実施の形態における全体シーケンス図（図５）との違いは、Path Discovery Phase（図５のＳ２）ではなく、Inter-Node Link Metric Collection Phase（図３９のＳ２７３）が実施されている点である。
　すなわち、Inter-Node Link Metric Collection Phase（Ｓ２７３）では、要求元ノードがInter-Node Link Metric Requestを周囲ノードに送信する（Ｓ２８１）ことで、周囲ノードから測定したメトリック値、あるいはメトリック値を算出するために必要なパラメータ群をInter-Node Link Metric Responseにて返答してもらっている（Ｓ２８２）。
　Joint Detection Phase（Ｓ２７４）以降は、Joint Detection Phase（図５のＳ３）と同じ処理が行われる。なお、図３９において、Mesh Network Phase（Ｓ２７１）では、Mesh Network Phase（図５のＳ１）と同様の処理が行われ、Backhaul Link Measurement（Ｓ２７２）では、バックホールリンクの測定が行われる。
　図４０は、第３の実施の形態における装置間のやり取りを時間軸に沿って表したシーケンス図の他の例である。
　図４０の全体シーケンスにおいて、図３９の全体シーケンスとの違いは、配下ノードの集中管理の役割を担うノード（以下、コントローラ（Controller）と呼ぶ）が設けられる点である。図４０では、ソースノードがコントローラになっている。
　すなわち、要求元ノードが、Inter-Node Link Metric Queryをコントローラに送信する（Ｓ３３１）ことで、コントローラが、周囲ノードからリレーノード１（Relay 1）までのリンクメトリック値又はメトリック値を算出するために必要なパラメータ群を収集している（Ｓ３３２，Ｓ３３３）。さらに、Joint Detectionを行いたいノードは、必ずコントローラにJoint Detection Setup Requestを送信し（Ｓ３３４）、Joint Detection Setup Responseにて協調ノードとその役割を通知してもらう（Ｓ３３６）ことで、Joint Detectionの処理を実施する（Ｓ３４０）。
　図４１は、Inter-Node Link Metric Requestの構成例を示す図である。
　Inter-Node Link Metric Requestは、tlvType，tlvLength，tlvValueから構成される。ここでは、Wi-Fi Allianceで規格化されているEasyMeshで使用されているIEEE1905のtlv(type-length-value)をベースにした構成を示している。
　tlvTypeには、当該TLVがInter-Node Link Metric Requestであることを示す情報が含まれる。tlvLengthには、当該TLVの長さを示す情報が含まれる。tlvValueには、当該TLVが通知すべき情報群が含まれる。tlvValueには、Number of Node ID，Node IDが含まれる。
　Number of Node IDには、リンクメトリック測定を依頼したいノードの数が含まれる。特定の数値（例えば0）を入れて全ノードを指定しても構わない。Node IDには、リンクメトリック測定を依頼したいノードの識別情報が含まれる。この識別情報は、BSSIDでも、BSS Colorでも、ネットワーク内で独自に割り振られた情報でも構わない。
　なお、Inter-Node Link Metric Requestは、図４１に示したフレーム構成に限定されず、少なくとも図中のNode Idの情報が含まれていればよい。また、当該フレームは、TCP/IP Frame内に格納されることを想定しているが、必要な情報が記載されていればMAC Frameとして定義されても構わない。
　図４２は、Inter-Node Link Metric Responseの構成例を示す図である。
　Inter-Node Link Metric Responseは、tlvType，tlvLength，tlvValueから構成される。ここでは、Wi-Fi Allianceで規格化されているEasyMeshで使用されているIEEE1905のtlv(type-length-value)をベースにした構成を示している。
　tlvTypeには、当該TLVがInter-Node Link Metric Responseであることを示す情報が含まれる。tlvLengthには、当該TLVの長さを示す情報が含まれる。tlvValueには、当該TLVが通知すべき情報群が含まれる。tlvValueには、Node ID，Metric Parametersが含まれる。
　Node IDには、自身のノード識別情報が含まれる。Metric Parametersには、自身から要求ノードまでのリンクメトリック値、又はメトリック値を算出するために必要なパラメータ群が含まれる。パラメータ群は、式（３）に必要な情報でも、その他の情報でも構わない。例えばデータレート値ではなく、RSSIやSNR等の情報も構わない。さらに、リンク使用率やビジー率といった情報が含まれても構わない。
　なお、Inter-Node Link Metric Responseは、図４２に示したフレーム構成に限定されず、少なくとも図中のMetric Parametersが含まれていればよい。また、当該フレームは、TCP/IP Frame内に格納されることを想定しているが、必要な情報が記載されていればMAC Frameとして定義されても構わない。
　図４３は、Inter-Node Link Metric Queryの構成例を示す図である。
　図４３のInter-Node Link Metric Queryは、図４１のInter-Node Link Metric Requestと同様に構成されるため、説明は省略する。
　図４４は、Joint Detection Setup Requestの構成例を示す図である。
　Joint Detection Setup Requestは、tlvType，tlvLength，tlvValueから構成される。ここでは、Wi-Fi Allianceで規格化されているEasyMeshで使用されているIEEE1905のtlv(type-length-value)をベースにした構成を示している。
　tlvTypeには、当該TLVがJoint Detection Setup Requestであることを示す情報が含まれる。tlvLengthには、当該TLVの長さを示す情報が含まれる。tlvValueには、当該TLVが通知すべき情報群が含まれる。tlvValueには、JD Data Growth Rate，Number of Candidate Node，Candidate Node IDが含まれる。
　JD Data Growth Rateには、Pre-demodulated Data伝送時のデータ増加比率を示す情報が含まれる。第１の実施の形態と同様に、UL信号のMCSや量子化ビットによって決まる数値が含まれる。Number of Candidate Nodeには、Joint Detection要求ノードが協調依頼したいノード数が含まれる。特定の数値（例えば0）を入れて全ノードを指定しても構わない。
　Candidate Node IDには、Joint Detection要求ノードが協調依頼したいノードの識別情報が含まれる。識別情報は、BSSIDでも、BSS Colorでも、ネットワーク内で独自に割り振られた情報でも構わない。
　なお、Joint Detection Setup Requestは、図４４に示されたフレーム構成に限定されず、少なくとも図中のJD Data Growth RateとCandidate Node IDが含まれていればよい。また、当該フレームは、TCP/IP Frame内に格納されることを想定しているが、必要な情報が記載されていればMAC Frameとして定義されても構わない。
　図４５は、Joint Detection Setup Responseの構成例を示す図である。
　Joint Detection Setup Responseは、tlvType，tlvLength，tlvValueから構成される。ここでは、Wi-Fi Allianceで規格化されているEasyMeshで使用されているIEEE1905のtlv(type-length-value)をベースにした構成を示している。
　tlvTypeには、当該TLVがJoint Detection Setup Responseであることを示す情報が含まれる。tlvLengthには、当該TLVの長さを示す情報が含まれる。tlvValueには、当該TLVが通知すべき情報群が含まれる。tlvValueには、Detector Node ID，Supplier Node IDが含まれる。
　Detector Node IDには、Joint Detection実施時に、ディテクタの役割を担うノードの識別情報が含まれる。Supplier Node IDには、Joint Detection実施時に、サプライヤの役割を担うノードの識別情報が含まれる。これらの識別情報はBSSIDでも、BSS Colorでも、ネットワーク内で独自に割り振られた情報でも構わない。
　なお、Joint Detection Setup Responseは、図４５に示されたフレーム構成に限定されず、少なくとも図中のDetector Node IDとSupplier Node IDが含まれていればよい。また、当該フレームは、TCP/IP Frame内に格納されることを想定しているが、必要な情報が記載されていればMAC Frameとして定義されても構わない。
　以上のように、第３の実施の形態では、ツリー型ネットワークの構成と処理を説明した。以上のような処理を実施する通信装置１０では、制御部１００、通信制御部１１１、及び通信制御部１２１の少なくとも１つの制御部によって、次のような処理が実施されている。すなわち、通信装置１０（例えばアクセスポイントＡＰ）においては、複数の通信装置のうち周囲のノードとのメトリック値、及びメトリック値の算出に必要な値を含む第３のパラメータ（例えば図４２のMetric Parameters）を用いて、最適な伝送ルートを決定する制御が行われる。
　第３の実施の形態における構成を採用することで、例えば、次の効果が期待できる。すなわち、ツリー型ネットワークでも、ノード間のリンクメトリック値及びリンクメトリック算出に必要なパラメータ群を収集することで、Joint Detectionを実施する際に、協調ノード及びJoint Detectionの役割を決定することが可能となる。
　なお、上述した通信装置１０の一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、通信装置１０にインストールされる。
　また、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。例えば、上述した説明では、シーケンス図、フレーム構成図、及びフローチャートにより、各実施の形態を説明したが、これらの実施形態は必ずしも図示した構成に限定されることはなく、状況に応じて使い分けられても構わない。さらに、本明細書に記載された効果はあくまで例示であって限定されるものではなく、他の効果があってもよい。
　なお、本技術は、以下のような構成をとることができる。
（１）
　マルチホップの伝送ルートの決定に使用する情報のやり取りを、他の通信装置との間で無線通信を利用して行い、
　前記情報に基づいて前記伝送ルートを決定する際に、複数の通信装置が協調して処理を実施するときの伝送データの増加量に基づいて最適な伝送ルートを決定する
　制御を行う制御部を備える
　通信装置。
（２）
　前記制御部は、復調処理を行っていない状態の復調前データを、他の通信装置に伝送することを仮定した際の伝送ルートを、最適な伝送ルートとして決定する
　前記（１）に記載の通信装置。
（３）
　前記制御部は、前記復調前データの量子化ビット、及びアップリンク信号の変調方式と符号化率を含む第１のパラメータを用いて、最適な伝送ルートを決定する
　前記（１）又は（２）に記載の通信装置。
（４）
　前記制御部は、前記第１のパラメータにより定まる協調処理用のメトリック値を算出し、算出した前記メトリック値に基づいて最適な伝送ルートを決定する
　前記（３）に記載の通信装置。
（５）
　前記制御部は、前記メトリック値の算出を要求するフレームに、前記第１のパラメータに応じた値、並びに前記複数の通信装置のうち前記復調前データを取得する側のノードの候補であるディテクタ候補ノードごとのアドレス、及びメトリック値を含めて送信する
　前記（４）に記載の通信装置。
（６）
　前記制御部は、前記メトリック値の算出を応答するフレームに、前記複数の通信装置のうち前記復調前データを取得する側のノードの候補であるディテクタ候補ノードごとのアドレス、メトリック値、及び直前のノードのアドレスを含めて送信する
　前記（４）又は（５）に記載の通信装置。
（７）
　前記制御部は、前記伝送データの増加量を加味せずに算出されたメトリック値、前記複数の通信装置のうち前記復調前データを取得する側のノードの候補であるディテクタ候補ノードまでのメトリック計算に必要な値を含む第２のパラメータ、及び前記第１のパラメータに応じた値に基づいて、最適な伝送ルートを決定する
　前記（３）に記載の通信装置。
（８）
　前記制御部は、前記メトリック値の算出を要求するフレームに、前記ディテクタ候補ノードごとのアドレス、メトリック値、及び前記第２のパラメータに応じた値を含めて送信する
　前記（７）に記載の通信装置。
（９）
　前記制御部は、前記メトリック値の算出を応答するフレームに、前記ディテクタ候補ノードごとのアドレス、メトリック値、前記第２のパラメータに応じた値、及び直前のノードのアドレスを含めて送信する
　前記（７）又は（８）に記載の通信装置。
（１０）
　前記制御部は、前記複数の通信装置のうち周囲のノードとのメトリック値、及びメトリック値の算出に必要な値を含む第３のパラメータを用いて、最適な伝送ルートを決定する
　前記（１）に記載の通信装置。
（１１）
　前記制御部は、前記複数の通信装置が協調して処理を実施するとき、前記複数の通信装置に含まれる協調候補ノードごとに決定された最適な伝送ルートに基づいて、協調処理の役割を決定する
　前記（１）乃至（３）のいずれかに記載の通信装置。
（１２）
　前記協調候補ノードは、アップリンク信号を誘起する他の通信装置との伝搬損失又は位置関係により定められる
　前記（１１）に記載の通信装置。
（１３）
　前記制御部は、前記協調候補ノードごとの最適な伝送ルート内でメトリック値が最も小さくなるように、協調処理の役割を決定する
　前記（１１）又は（１２）に記載の通信装置。
（１４）
　前記制御部は、協調処理の役割として、前記複数の通信装置のうち前記復調前データを伝送する側のノードであるサプライヤ、又は前記復調前データを取得する側のノードであるディテクタを決定する
　前記（１３）に記載の通信装置。
（１５）
　前記制御部は、他の通信装置から伝送されてくる、協調処理を要求するフレームを受信し、当該フレームに指定された役割で、他の通信装置と協調して処理を実施する
　前記（１１）乃至（１４）のいずれかに記載の通信装置。
（１６）
　無線LANシステムにおけるアクセスポイントとして構成される
　前記（１）乃至（１５）のいずれかに記載の通信装置。
（１７）
　通信装置が、
　マルチホップの伝送ルートの決定に使用する情報のやり取りを、他の通信装置との間で無線通信を利用して行い、
　前記情報に基づいて前記伝送ルートを決定する際に、複数の通信装置が協調して処理を実施するときの伝送データの増加量に基づいて最適な伝送ルートを決定する
　通信方法。
（１８）
　協調して処理を実施する複数の通信装置に含まれる他の通信装置から送信されてくるトリガ信号を受信し、
　マルチホップネットワークにおいて協調処理の実施を示すフラグ、及び協調処理を実施するときの処理の役割に応じたノード識別情報を設定したPHYヘッダを含むアップリンク信号を送信する
　制御を行う制御部を備える
　通信装置。
（１９）
　前記制御部は、前記トリガ信号に含まれる情報に基づいて、前記PHYヘッダに含まれる情報を設定する
　前記（１８）に記載の通信装置。
（２０）
　無線LANシステムにおける無線端末として構成される
　前記（１８）又は（１９）に記載の通信装置。
　１０　通信装置，　１００　制御部，　１０１　無線通信部，　１０２　無線通信部，　１０３　記憶部，　１０４　WAN通信部，　１１１　通信制御部，　１１２　通信記憶部，　１１３　データ処理部，　１１４　信号処理部，　１１５　無線インターフェース部，　１１６　増幅部，　１１７　アンテナ，　１２１　通信制御部，　１２２　通信記憶部，　１２３　データ処理部，　１２４　信号処理部，　１２５　無線インターフェース部，　１２６　増幅部，　１２７　アンテナ

Claims (20)

  1. 　マルチホップの伝送ルートの決定に使用する情報のやり取りを、他の通信装置との間で無線通信を利用して行い、
    　前記情報に基づいて前記伝送ルートを決定する際に、複数の通信装置が協調して処理を実施するときの伝送データの増加量に基づいて最適な伝送ルートを決定する
    　制御を行う制御部を備える
    　通信装置。
  2. 　前記制御部は、復調処理を行っていない状態の復調前データを、他の通信装置に伝送することを仮定した際の伝送ルートを、最適な伝送ルートとして決定する
    　請求項１に記載の通信装置。
  3. 　前記制御部は、前記復調前データの量子化ビット、及びアップリンク信号の変調方式と符号化率を含む第１のパラメータを用いて、最適な伝送ルートを決定する
    　請求項２に記載の通信装置。
  4. 　前記制御部は、前記第１のパラメータにより定まる協調処理用のメトリック値を算出し、算出した前記メトリック値に基づいて最適な伝送ルートを決定する
    　請求項３に記載の通信装置。
  5. 　前記制御部は、前記メトリック値の算出を要求するフレームに、前記第１のパラメータに応じた値、並びに前記複数の通信装置のうち前記復調前データを取得する側のノードの候補であるディテクタ候補ノードごとのアドレス、及びメトリック値を含めて送信する
    　請求項４に記載の通信装置。
  6. 　前記制御部は、前記メトリック値の算出を応答するフレームに、前記複数の通信装置のうち前記復調前データを取得する側のノードの候補であるディテクタ候補ノードごとのアドレス、メトリック値、及び直前のノードのアドレスを含めて送信する
    　請求項４に記載の通信装置。
  7. 　前記制御部は、前記伝送データの増加量を加味せずに算出されたメトリック値、前記複数の通信装置のうち前記復調前データを取得する側のノードの候補であるディテクタ候補ノードまでのメトリック計算に必要な値を含む第２のパラメータ、及び前記第１のパラメータに応じた値に基づいて、最適な伝送ルートを決定する
    　請求項３に記載の通信装置。
  8. 　前記制御部は、前記メトリック値の算出を要求するフレームに、前記ディテクタ候補ノードごとのアドレス、メトリック値、及び前記第２のパラメータに応じた値を含めて送信する
    　請求項７に記載の通信装置。
  9. 　前記制御部は、前記メトリック値の算出を応答するフレームに、前記ディテクタ候補ノードごとのアドレス、メトリック値、前記第２のパラメータに応じた値、及び直前のノードのアドレスを含めて送信する
    　請求項７に記載の通信装置。
  10. 　前記制御部は、前記複数の通信装置のうち周囲のノードとのメトリック値、及びメトリック値の算出に必要な値を含む第３のパラメータを用いて、最適な伝送ルートを決定する
    　請求項１に記載の通信装置。
  11. 　前記制御部は、前記複数の通信装置が協調して処理を実施するとき、前記複数の通信装置に含まれる協調候補ノードごとに決定された最適な伝送ルートに基づいて、協調処理の役割を決定する
    　請求項３に記載の通信装置。
  12. 　前記協調候補ノードは、アップリンク信号を誘起する他の通信装置との伝搬損失又は位置関係により定められる
    　請求項１１に記載の通信装置。
  13. 　前記制御部は、前記協調候補ノードごとの最適な伝送ルート内でメトリック値が最も小さくなるように、協調処理の役割を決定する
    　請求項１１に記載の通信装置。
  14. 　前記制御部は、協調処理の役割として、前記複数の通信装置のうち前記復調前データを伝送する側のノードであるサプライヤ、又は前記復調前データを取得する側のノードであるディテクタを決定する
    　請求項１３に記載の通信装置。
  15. 　前記制御部は、他の通信装置から伝送されてくる、協調処理を要求するフレームを受信し、当該フレームに指定された役割で、他の通信装置と協調して処理を実施する
    　請求項１１に記載の通信装置。
  16. 　無線LANシステムにおけるアクセスポイントとして構成される
    　請求項１に記載の通信装置。
  17. 　通信装置が、
    　マルチホップの伝送ルートの決定に使用する情報のやり取りを、他の通信装置との間で無線通信を利用して行い、
    　前記情報に基づいて前記伝送ルートを決定する際に、複数の通信装置が協調して処理を実施するときの伝送データの増加量に基づいて最適な伝送ルートを決定する
    　通信方法。
  18. 　マルチホップネットワークにおいて協調して処理を実施する複数の通信装置に含まれる他の通信装置から送信されてくるトリガ信号を受信し、
    　協調処理の実施を示すフラグ、及び協調処理を実施するときの処理の役割に応じたノード識別情報を設定したPHYヘッダを含むアップリンク信号を送信する
    　制御を行う制御部を備える
    　通信装置。
  19. 　前記制御部は、前記トリガ信号に含まれる情報に基づいて、前記PHYヘッダに含まれる情報を設定する
    　請求項１８に記載の通信装置。
  20. 　無線LANシステムにおける無線端末として構成される
    　請求項１８に記載の通信装置。
PCT/JP2021/045491 2020-12-25 2021-12-10 通信装置、及び通信方法 WO2022138229A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202180085031.XA CN116636306A (zh) 2020-12-25 2021-12-10 通信设备和通信方法
US18/258,290 US20240056936A1 (en) 2020-12-25 2021-12-10 Communication device and communication method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2020216941 2020-12-25
JP2020-216941 2020-12-25

Publications (1)

Publication Number Publication Date
WO2022138229A1 true WO2022138229A1 (ja) 2022-06-30

Family

ID=82157824

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/045491 WO2022138229A1 (ja) 2020-12-25 2021-12-10 通信装置、及び通信方法

Country Status (3)

Country Link
US (1) US20240056936A1 (ja)
CN (1) CN116636306A (ja)
WO (1) WO2022138229A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002064550A (ja) * 2000-08-17 2002-02-28 Nippon Telegr & Teleph Corp <Ntt> 衛星／地上経路選択装置
JP2013055451A (ja) * 2011-09-02 2013-03-21 Hitachi Kokusai Electric Inc 無線センサーネットワークシステム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002064550A (ja) * 2000-08-17 2002-02-28 Nippon Telegr & Teleph Corp <Ntt> 衛星／地上経路選択装置
JP2013055451A (ja) * 2011-09-02 2013-03-21 Hitachi Kokusai Electric Inc 無線センサーネットワークシステム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
KOSUKE AIO (SONY CORPORATION): "Consideration on Multi-AP Home Mesh Scenario", IEEE DRAFT; 11-20-0032-00-00BE-CONSIDERATION-ON-MULTI-AP-HOME-MESH-SCENARIO, IEEE-SA MENTOR, PISCATAWAY, NJ USA, vol. 802.11 EHT; 802.11be, no. 0, 14 January 2020 (2020-01-14), pages 1 - 12, XP068165233 *

Also Published As

Publication number Publication date
CN116636306A (zh) 2023-08-22
US20240056936A1 (en) 2024-02-15

Similar Documents

Publication Publication Date Title
JP6644915B2 (ja) ブロック確認応答の生成および選択ルール
JP6564871B2 (ja) チャネル状態情報サウンディングおよびフィードバックのための方法および装置
JP4446770B2 (ja) 複数無線統一プロトコル
CN105493610B (zh) 用于多用户上行链路的方法和装置
JP5248674B2 (ja) ワイヤレスメッシュネットワークを通してデータを送信するための装置および方法
US9948367B2 (en) Methods and apparatus for acknowledging multiple user uplink transmissions
CN107148795A (zh) 用于无线网络中的多用户通信的方法和装置
CN107409012A (zh) 用于信道状态信息探通和反馈的方法和装置
US20110110273A1 (en) Waveform for use in mobile ad hoc networks
CN105493599A (zh) 用于多用户上行链路的方法和装置
CA2980467A1 (en) Block acknowledgement mechanism for acknowledging dl-mu data on ul-mu wireless communication system
JP2018512768A (ja) チャネル状態情報サウンディングおよびフィードバックのための方法および装置
US20160142122A1 (en) Methods and apparatus for channel state information feedback
WO2022138229A1 (ja) 通信装置、及び通信方法
JP2004015556A (ja) 通信方法、通信装置及び通信システム
JP6109184B2 (ja) 無線送受信機とのマルチチャネル、マルチ変調、マルチレート通信
CN113661723A (zh) 设备到设备通信互连局域网的方法和装置
Kosek-Szott et al. CLF-MAC: A coordinated MAC protocol supporting lossy forwarding in WLANs
WO2022196061A1 (ja) 通信装置
WO2022224315A1 (ja) 基地局
WO2024074343A1 (en) Communication devices and methods
WO2016111838A1 (en) Methods and apparatus for channel state information feedback

Legal Events

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

Ref document number: 21910378

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 202180085031.X

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 18258290

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21910378

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP