Patent Description:
Current wireless communication networks, e.g., based on the LTE (Long Term Evolution) or NR technology as specified by 3GPP, also support D2D communication modes to enable direct communication between UEs (user equipments). Such D2D communication modes may for example be used for vehicle communications, e.g., including communication between vehicles, between vehicles and roadside communication infrastructure and, possibly, between vehicles and cellular networks. Due to wide range of different types of devices that might be involved in the communication with the vehicles, vehicle-to-everything (V2X) communications is another term used to refer to this class of communication. Vehicle communications have the potential to increase traffic safety, reduce energy consumption and enable new services related to intelligent transportation systems.

In some scenarios where vehicles and the other involved communication entities are equipped with multiple transmit and receive antennas communication may be performed over what is known as a multiple input multiple output (MIMO) interference broadcast channel (IBC). Such scenarios may also involve that multiple transmitting nodes attempt to transmit to possibly multiple intended receiving nodes on a given time-frequency resource.

User scheduling techniques may be used for access coordination when multiple communication links are competing for resources in a shared wireless medium. One of the main responsibilities of scheduling techniques is to decide which users can transmit on each time slot as well as how much bandwidth should be assigned to each scheduled user. In MIMO systems, transmitting and receiving nodes utilize multiple antennas in order to spatially multiplex data streams on a given frequency-time resource. In this case, user scheduling in such systems may aim at simultaneously accommodating multiple users with some reasonable quality of service (QoS) within the same frequency-time resource by means of spatial-division multiplexing.

In some MIMO systems, a previous centralized or distributed mechanism (e.g., a mechanism executed by the cellular infrastructure) may be used to pre-schedule the frequency-time resources on which each node should transmit or receive data. Then, a MIMO scheduling method is executed for optimizing the transceiver vectors targeting a certain objective and attempting to ensure some reasonable QoS. The computation of the transceiver vectors may be carried out in a distributed manner, i.e., each involved node performed its own computations based on some information received from other nodes. However, such optimization of link parameters may be difficult to handle in D2D communication scenarios, where multiple links coexist on the same time-frequency resources and may be subject to frequent changes due to mobility of the involved D2D communication devices, e.g., due to moving vehicles in a V2X communication scenario, where a central coordinating entity is not available. For example, it may be difficult to decide when a D2D communication device should transmit and when it should rather refrain from transmission and wait for a suitable transmission opportunity. Further, it may be difficult to decide what transmit power and precoder should be used. Further, it may be difficult to implement QoS constraints and to handle violations of such QoS constraints.

<CIT> describes V2X services in cellular networks and that a V2X device can derive geolocation information from a plurality of V2X communication nodes. <CIT> describes that a peer-to-peer (P2P) communication device may discover other P2P communication devices and negotiate which device shall become a group owner and a group client in a P2P group. The negotiation may involve exchanging IP (Internet Protocol) addresses,.

Accordingly, there is a need for techniques which allow for efficiently controlling D2D communication.

The aspects of the present invention are defined in the appended independent claims.

According to claim <NUM>, a method of controlling D2D communication is provided.

According to the method a first D2D communication device receives first information from one or more second D2D communication devices. The first information indicates control information for one or more links from the respective second D2D communication device. Based on the indicated control information, the first D2D communication device determines control information for one or more links from the first D2D communication device. Further, the first D2D communication device sends second information to one or more third D2D communication devices. The second information indicates whether the first D2D communication device intends to perform a transmission on one or more of the links from the first D2D communication device, using the determined control information for the one or more of the links from the first D2D communication device.

According to independent claim <NUM>, a first D2D communication device is provided. The first D2D communication device is configured to receive first information from one or more second D2D communication devices. The first information indicates control information for one or more links from the respective second D2D communication device. Further, the first D2D communication device is configured to, based on the indicated control information, determine control information for one or more links from the first D2D communication device. Further, the first D2D communication device is configured to send second information to one or more third D2D communication devices. The second information indicates whether the first D2D communication device intends to perform a transmission on one or more of the links from the first D2D communication device, using the determined control information for the one or more of the links from the first D2D communication device.

According to independent claim <NUM>, a computer program or computer program product is provided, e.g., in the form of a non-transitory storage medium, which comprises program code to be executed by at least one processor of a first D2D communication device. Execution of the program code causes the first D2D communication device to receive first information from one or more second D2D communication devices. The first information indicates control information for one or more links from the respective second D2D communication device.

Further, execution of the program code causes the first D2D communication device to, based on the indicated control information, determine control information for one or more links from the first D2D communication device. Further, execution of the program code causes the first D2D communication device to send second information to one or more third D2D communication devices. The second information indicates whether the first D2D communication device intends to perform a transmission on one or more of the links from the first D2D communication device, using the determined control information for the one or more of the links from the first D2D communication device.

In the following, concepts in accordance with exemplary embodiments of the invention will be explained in more detail and with reference to the accompanying drawings. The illustrated embodiments relate to controlling of D2D communication between UEs. The D2D communication may for example be based on the LTE radio technology or the NR radio technology as specified by 3GPP (<NUM>rd Generation Partnership Project). However, it is noted that the illustrated concepts could also be applied to other technologies, e.g., a WLAN (Wireless Local Area Network) technology.

The illustrated concepts may use a joint user scheduling mechanism and a transceiver design for sum-rate maximization and QoS assurance considering MIMO devices. If a wireless communication network is available, i.e., for devices in network coverage, the illustrated mechanism can take advantage of network assistance. When devices are out of network coverage, the illustrated mechanism may provide QoS, e.g., bit-rate, guarantees if QoS requirements can be met. When the QoS requirements cannot be met due to high QoS requirements relative to available resources or in view of prevailing interference situation, the illustrated mechanism reduce the QoS requirements in a controlled manner such that they can be fulfilled with a minimum deviation from the original QoS requirements.

The illustrated concepts may rely on an iterative procedure and on a low-demanding signaling exchange. The transmitting nodes and receiving nodes may compute their respective beamforming vectors aiming at optimizing a network key performance indicator (KPI) while ensuring some predetermined, e.g. by network configuration, QoS for each link. Relevant KPIs may include a system sum-rate or network throughput, network coverage, experienced user latency, or the like.

In the following, it will be further described how multi-antenna transmitting and multi-antenna receiving nodes may compute their respective beamforming vectors, aiming at maximizing the network sum-rate subject to per link QoS requirements. Here, the illustrated concepts enable treating the scheduling, e.g., by link activation, and transmitter side and receiver side parameter setting jointly at each node, such that a system-wide objective, e.g., high communication throughput and sum-rate, can be achieved while maintaining per-user QoS constraints.

As part of the illustrated concepts, per-link QoS-relaxation variables may be used for QoS-violation detection and control in order to ensure minimum QoS demands when possible, while relaxing the initial QoS demands if it is not feasible to meet the desired QoS requirements.

Procedures executed by the transmitting node and the receiving node may be summarized as follows:
A transmitting node, communicating with a receiving node via a communication link, that.

A receiving node, where the receiving node can be a UE or a network node, communicating with a transmitting node via a communication link, that.

<FIG> illustrates an exemplary scenario involving V2X communications. In particular, <FIG> shows various UEs <NUM>, which may engage in V2X communication, illustrated by solid arrows. Further, <FIG> shows an access node <NUM> of a wireless communication network, e.g., an eNB of the LTE technology or a gNB of the NR technology, or an access point of a WLAN (Wireless Local Area Network). At least some of the UEs <NUM> may also be capable of communicating by using DL radio transmissions and/or UL radio transmissions, illustrated by broken arrows.

The UEs illustrated in <FIG> comprise vehicles, a mobile phone, and a person, e.g., a pedestrian, a cyclist, a driver of a vehicle, or a passenger of a vehicle. Here, it is noted that in the case of the vehicles the radio transmissions may be performed by a communication module installed in the vehicle, and that in the case of the person the radio transmissions may be performed by a radio device carried or worn by the person, e.g., a wristband device or similar wearable device. Furthermore, it is noted that the UEs shown in <FIG> are merely exemplary and that in the illustrated concepts other types of V2X communication device or D2D communication device could be utilized as well, e.g., RSUs (roadside units) or other infrastructure based V2X communication devices, V2X communication devices based in an aircraft, like an airplane, helicopter, drone, in a spacecraft, in a train or car of a train, in a ship, in a motorcycles, in a bicycle, in a mobility scooter, or in any other kind of mobility or transportation device.

The involved communication entities, i.e., the UEs <NUM>, may be equipped with multiple transmit and receive antennas in order to enable the special multiplexing of data streams on a given frequency-time resource.

<FIG> illustrates an exemplary D2D communication scenario. In particular, <FIG> shows multiple UEs <NUM>, which are connected to each other by radio links (illustrated by double-headed arrows). Further, one of the UEs <NUM> is connected by a radio link to an access node <NUM> of a wireless communication network <NUM>, e.g., to an eNB of the LTE technology, or a gNB of the NR technology.

The radio links may be used for D2D communication between the UEs <NUM>. Further, the radio link to the wireless communication network <NUM> may be used for controlling or otherwise assisting the D2D communication. Further, the D2D communication and/or data communication with the wireless communication network <NUM> may be used for providing various kinds of services to the UEs <NUM>, e.g., a voice service, a multimedia service, a data service, and/or an intelligent transportation system (ITS) or similar vehicular management or coordination service. Such services may be based on applications which are executed on the UE <NUM> and/or on a device linked to the UE <NUM>. Further, <FIG> illustrates an application service platform <NUM> in the wireless communication network <NUM>. Further, <FIG> illustrates one or more application servers <NUM> provided outside the wireless communication network. The application(s) executed on the UE <NUM> and/or on one or more other devices linked to the UE <NUM> may use the radio links with one or more other UEs <NUM>, the application service platform <NUM>, and/or the application server(s) <NUM>, thereby enabling the corresponding service(s) on the UE <NUM>.

In the example of <FIG>, the UEs <NUM> are assumed to be vehicles or vehicle-based communication devices, e.g., a vehicle-mounted or vehicle-integrated communication module, or a smartphone or other user device linked to vehicle systems. However, it is noted that other types of UE could be used as well, e.g., a device carried by a pedestrian, or an infrastructure-based device, such as a roadside unit.

The illustrated concepts may for example be applied in vehicle communication scenarios in which vehicles, roadside communication infrastructure, a cellular network, and/or any other communication entities compete to transmit over a given frequency-time resource. An example of such a scenario is illustrated in <FIG>. The illustrated concepts may also be applied in a scenario where only vehicles are attempting to transmit, such as illustrated in <FIG>. In <FIG>, arrows indicate which nodes are transmitting data and which nodes are receiving data. As illustrated in the example of <FIG>, a transmitting node might also have more than one intended receiving node.

In the following, the control of D2D communication according to the illustrated concepts will be explained in more detail by referring to specific examples illustrated in <FIG>.

As mentioned above, the illustrated concepts are applicable in infrastructure-based (i.e. cellular network assisted, in-coverage) and infrastructure-less or outside the coverage (OoC) of a network scenarios. In the OoC case, according to the invention, the UE may be preconfigured, either when it is inside the network coverage, e.g., prior to moving out of coverage, or using manual preconfiguration, for a communication link.

In the following, the term communication link is used to refer to the communication of data packets between a transmitting node (which has data packets awaiting to be transmitted) and a receiving node (which awaits to receive data packets) on a given set of frequency-time resources. As such, example of communication links are radio bearers of the 3GPP LTE or NR systems. The communication link can be either between UEs in the communication network, such as mobile terminals, handsets, vehicles, etc., or between UE and network equipment, such as radio base stations or other access nodes. Therefore, both the transmitting node and the receiving node can be any type of node, such as mobile devices, vehicles, cellular base stations or road-side infrastructure.

The illustrated concepts may consider multiple communication links, i.e., multiple pairs of transmitting node and receiving node, competing for transmission of data on a certain set of frequency-time resources. A maximum transmit power budget is associated with each transmitting node (e.g. done by the network or by manual preconfiguration in a vehicle or user device) and is denoted by Pb, which is a value known at each transmitting node.

In one embodiment of the method, each communication link between a transmitting node and receiving node has an associated minimum non-negative data rate requirement, indicated by <MAT>. The minimum data rate requirement for a communication link may be pre-configured by the network while the corresponding pair of transmitting node and receiving node is in network coverage, or it may be preconfigured in the device, by way of example associated with an application installed in the device.

Each communication link between a transmitting node and a receiving node may have associated a non-negative priority weight <MAT> and/or a non-negative penalty weight Θu ∈ <MAT>. In the illustrated concepts, the values of the priority weights may be used for prioritizing communication links with higher priority weight values, i.e., the higher is the priority weight, the lesser the assigned rate is reduced. The values of the penalty weights may be used for identifying which communication links can have their QoS requirements reduced first, i.e., communication links with higher values of the penalty weight can have their QoS requirements reduced first as compared to the other communication links. The values of the priority and/or penalty weights are either determined by the a centralized control entity in the network, such as a orchestration and management (OAM) node, and then communicated to the transmitting and receiving nodes of the link, or are determined by the transmitting/receiving nodes prior to performing the illustrated method. As an alternative, the values of the priority and/or penalty weights can be application dependent and pre-configured at the transmitting node and receiving node of a communication link.

A previous centralized or distributed mechanism, e.g., a mechanism executed by wireless communication network infrastructure, such as the above-mentioned access node <NUM>, has pre-scheduled time-frequency resources. Further, a channel estimation process may have been performed, where, for example, the transmitting/receiving nodes transmit reference signals to the receiving/transmitting nodes in a period or non-periodic manner, when transmitting data or when requested by the receiving or transmitting node. A number of data streams to be used on each communication link may have been previously defined. The illustrated method can then be employed for computing the beamforming vectors for the group of transmitting/receiving nodes selected to transmit/receive data on the time-frequency resource. This illustrated method may also allow for deciding that a potential transmitting node does not send data at a particular time instant.

<FIG> shows a flowchart for illustrating a method to implement the illustrated concepts at a transmitting node. The transmitting node may correspond to any of the above-mentioned UEs <NUM>.

On the transmitting node side the method involves computation of a first set of control parameters, in particular including a transmit power and precoder, that is to be used for transmitting the data, e.g., data packets, waiting for transmission. Using these parameters, the method may maximize a system sum-rate while meeting a minimum rate requirement when possible. Otherwise, the method may find a minimum possible QoS violation for each communication link while still maximizing the system sum-rate.

At step <NUM>, the transmitting node may receive a second set of control parameters from the receiving node. The receiving node may provide the second set of control parameters in accordance with a method as described below in connection with <FIG>.

At step <NUM>, the transmitting node may receive a third set of control parameters from one or more other transmitting nodes. The other transmitting node(s) may provide the third set of control parameters in accordance with a method as described below in connection with <FIG>.

At step <NUM>, may forward at least a part of the set of control parameters received at step <NUM> and/or at step <NUM> to another transmitting node or to another receiving node.

At step <NUM>, the transmitting node computes the first set of control parameters for the communication link. In this computation, the transmitting node may consider the second set of control parameters received at step <NUM> and/or the third set of control parameters received at step <NUM>. Accordingly, upon receiving the control parameters from other transmitting nodes, the transmitting node may update the values of one or more control parameters computed for the communication link from the transmitting node to the receiving node. For example, the third set of control parameters may include one or more weights associated to one or more data streams of a communication link from the other transmitting node, which are then used by the transmitting node to compute one or more transmit beamforming vector associated to one or more data streams of the communication link from the transmitting node to the receiving node.

The first set of control parameters associated to the communication link with the receiving node may include one or more of:.

The control flag for closed loop control may be set to "FALSE" or to "TRUE". The transmitting node may set the control flag for closed loop control to TRUE in order to configure the receiving node to perform closed loop optimization of control parameters associated to the communication link with the transmitting node for a number of T≥<NUM> times.

In one possible implementation, for instance, the first set of control parameters may include only one or more transmit beamforming vector associated to one or more data streams of the communication link and one or more scalar parameters for controlling the power allocation of the transmit beamforming vectors.

The control flag for data reception may be set to "FALSE" or to "TRUE". The transmitter node shall set the control flag for data reception to TRUE in order to configure the receiving node to receive a data transmission after one or more iterations of closed loop optimization of control parameters for the communication link.

At step <NUM>, the transmitting node may further send a fourth set of control parameters associated to the communication link with the receiving node to one or more other transmitting nodes, e.g., by broadcasting the fourth set of control parameters. The fourth set of control parameters may include one or more control parameters belonging to the first set of control parameters, i.e. the fourth set of control parameters may be a subset of or equal to the first set of control parameters. In one implementation of the invention, the transmitting node transmits the fourth set of control parameters to other transmitting nodes whose communication links may use the same set of time-frequency resources as the communication link with the receiving node. The one or more transmitting nodes in a surrounding region of the transmitting node may then receive and decode the fourth set of control parameters and utilize this information in computation of control parameters for their communication links.

As illustrated by a broken arrow in <FIG>, the transmitting nodes may iterate the steps of receiving information, sending information and computing the control parameters multiple times prior to transmitting data to the receiving node at step <NUM>. Therefore, in one case, before transmitting data to the receiving node over the communication link, the transmitting node repeats multiple times the steps of:.

<FIG> shows a flowchart for illustrating a method to implement the illustrated concepts at a receiving node. The receiving node may correspond to any of the above-mentioned UEs <NUM>.

On the receiving node side the method involves the computation of a decoder and a second set of control parameters in order to properly receive the data and to detect and control QoS violations.

At step <NUM> the receiving node receives a signal from the transmitting node. The signal can be a pilot signal or some other signal, e.g., a control channel. The signal indicates the first set of control parameters.

At step <NUM> the receiving node may receive a signal from another transmitting node and/or another receiving node. The signal can be a pilot signal or some other signal, e.g., a control channel. The signal indicates a further set of control parameters.

At step <NUM>, the receiving node may forward at least a part of the set of control parameters received at step <NUM> and/or at step <NUM> to another receiving node or to another transmitting node.

At step <NUM>, the receiving node computes the values of a second set of control parameters associated to the communication link with the transmitting node based on at least the signal received from the transmitting node.

At step <NUM>. the receiving node then sends the second set of control parameters to the transmitting node, e.g., a pilot signal, a control channel, or some other signal.

At step <NUM>, the receiving node uses one or more parameters in the second set of control parameters to receive and decode the information received from the transmitting node. For example, the receiving node may receive and decode a data transmission from the transmitting node based on one or more beamforming vectors computed at step <NUM>.

The first set of control parameters may include a control flag for closed loop control. For example, the control flag may be set to "FALSE" or "TRUE". In the latter case, as illustrated by a broken arrow in <FIG>, before receiving a data packet, the receiving node may iterate multiple times the steps of:.

After T≥<NUM> iterations, the receiving node may use one or more parameters from the first or second set of control parameters to receive and decode the information received from the transmitting node. In one embodiment, the number of iterations T≥<NUM> is signaled by the transmitting node as part of the first set of control parameters. In another embodiment, the value T≥<NUM> of iterations is preconfigured for the receiving node.

The first set of control parameters may include a control flag for data reception. When the control flag for data reception is set to TRUE, the receiving node is configured to receive data from the transmitting node according to the first or second set of control parameters. This flag indicates to the receiving node that after the current iteration of closed-loop control optimization of the control parameters associated to the communication link, the receiving node shall receive data transmission from the transmitting node.

The receiving nodes may compute the second set of control parameters associated to the communication link by.

In one example, the receiving node estimates the quality of the communication channel and the quality of the current communication parameters, measuring and estimating the symbol error, in terms of, for example, the mean squared error (MSE) of the received data symbols. For example, the estimation of the MSE might be performed using closed-form equations or from measuring errors from pilot symbols or data symbols that are detected erroneous over a given time window. In step <NUM>, the receiving node computes receive beamforming vectors for each of its data streams. The computation of such receive beamforming vectors is possible by acquiring channel state information at the receiver (CSIR) and employing multiuser receivers, such as minimum mean square error (MMSE) or interference rejection combining (IRC) receivers, successive interference cancellation (SIC) receivers and/or combinations of these type of receiver structures (which are known to the skilled person).

The second set of control parameters associated to the communication link with the transmitting node may include one or more of:.

In one possible implementation of the method, for instance, the second set of control parameters may comprise one or more receive beamforming vector associated to one or more data stream of the communication link. This information is used by the transmitting node to adapt the corresponding transmit beamforming vectors for optimizing the data transmission over the communication link.

In another possible implementation of the method, the second set of control parameters may comprise one or more receive beamforming vector associated to one or more data stream of the communication link and one or more QoS-relaxation variables associated to the communication link. This information is used by the transmitting node to adapt the corresponding transmit beamforming vectors for optimizing the data transmission over the communication link taking into account the QoS requirement of the communication link.

In another possible implementation of the method, the second set of control parameters may comprise one or more receive beamforming vector associated to one or more data stream of the communication link and one or more weights associated to one or more data streams of the communication link. This information is used by the transmitting node to adapt the corresponding transmit beamforming vectors for optimizing the data transmission over the communication link taking into account the weights associated to one or more data streams of the communication link.

<FIG> an example of processes based on the method of <FIG> and <FIG>. Specifically, <FIG> illustrates signaling between a transmitting node (TX-<NUM>) and a receiving node (RX-<NUM>:<NUM>) of a communication link (link <NUM>). <FIG> also shows further details concerning the steps from <FIG> and <FIG> which are executed by the transmitting node and receiving node. In <FIG>, the transmitting node and the receiving node may correspond to any pair of the above-mentioned UEs <NUM>.

At block <NUM>, the transmitting node initially computes the first set of control parameters. The transmitting node then sends a signal <NUM> to the receiving node. The signal <NUM> indicates at least a part of the computed first set of parameters. The signal <NUM> may be a pilot signal, a control channel signal, or some other type of signal.

The receiving node receives the signal and uses the indicated part of the first set of control parameters as a basis for computing the second set of control parameters, as indicated by block <NUM>. The receiving node then sends a signal <NUM> to the transmitting node. The signal <NUM> indicates at least a part of the computed second set of parameters. The signal <NUM> may be a pilot signal, a control channel signal, or some other type of signal.

The transmitting node further receives a signal <NUM>, e.g., from another transmitting node. The signal <NUM> indicates a third set of control parameters. The transmitting node then uses the control parameters indicated by the signals <NUM>, <NUM> to re-compute the first set of control parameters, as indicated by block <NUM>. The transmitting node then sends a signal <NUM> to the receiving node. The signal <NUM> indicates at least a part of the re-computed first set of parameters. The signal <NUM> may be a pilot signal, a control channel signal, or some other type of signal.

As further illustrated, the computation of parameters at blocks <NUM> and <NUM> and the exchange of information by signals <NUM>, <NUM>, and <NUM> may then be iterated for T times, until the transmitting node used the final re-computed set first set of control parameters to send data <NUM>.

<FIG> illustrates the signalling exchange which is similar to that of <FIG> but involves two transmitting nodes (TX-<NUM> and TX-<NUM>), with each transmitting node having two intended receiving nodes. In <FIG> RX-<NUM>:<NUM> denotes a first receiving node of TX-<NUM> and RX-<NUM>:<NUM> denotes a second receiving node of TX-<NUM>, while RX-<NUM>:<NUM> denotes a first the receiving node of TX-<NUM> and RX-<NUM>:<NUM> denotes a second receiving node of TX-<NUM>. In <FIG> dotted arrows illustrate the information signalled from the transmitting node to the receiving node (similar to signals <NUM> and <NUM> of <FIG>). This phase of signalling is denoted by T-R (transmitter-receiver). Broken arrows illustrate the information signalled from the receiving node to the transmitting node (similar to signal <NUM> of <FIG>). This phase of signalling is denoted by R-T (receiver-transmitter). Solid arrows illustrate the information signalled from transmitting node to transmitting node (similar to signal <NUM> of <FIG>). This phase of signalling is denoted by T-T (transmitter-transmitter).

<FIG> illustrates an example of a frame structure which may be used to support the illustrated method. As can be seen, the frame structure is divided into two main parts: a first part used for the beamforming setup, and a second part is used for the actual data transmission. In the beamforming setup phase, the signaling is split into three parts: <NUM>) `T-R', which denotes the forward signalling, which occurs from the transmitting nodes to the receiving nodes and includes at least the first set of control parameters; <NUM>) `R-T', which denotes the backward signalling, which happens from each receiving node to its associated transmitting node and includes at least the second set of control parameters; and <NUM>) '<NUM>-<NUM>', which denotes the signaling exchange between transmitting nodes and includes at least the third set of control parameters.

<FIG> illustrates an example of pseudocode of an iterative method based on the illustrated concepts. In the following, computation of parameters in the illustrated example will be described in more detail.

The illustrated example assumes a scenario composed of B transmitters equipped with NT antennas and U receivers equipped with NR antennas. It is worth noting that there is no assumption about the nature of the devices acting as transmitters and receivers. They can be cellular base stations, cellular devices, vehicles, road-side infrastructure, among others. Therefore, the method described can be used in scenarios where only vehicles are involved as well as in scenarios where there are cellular devices, BSs and vehicles, for example. The scenario considered herein is also known as the multiple-input multiple-output interference broadcast channel (MIMO IBC). Each transmitting node b serves a set of receiving nodes denoted by Ub with Ub = |Ub|. Each receiving node u is served by a single transmitting node bu. The number of spatial streams scheduled per user is fixed and computed prior to the executing of the proposed method, where the number of data streams allocated to receiving node u is Su. The s-th stream of receiving node u is denoted by (u, s).

In the illustrated example of the iterative method, the following parameters are considered: <MAT> denotes a channel matrix between transmitting node u and receiving node b serving the receiving node i. The channel matrix Hbi,u or an estimate of the channel matrix Hbi,u is maintained by each transmitting node with respect to its receiving node(s) and by each receiving node with respect to its transmitting node(s). The channel matrix Hbi,u may be acquired by estimation by the receiving node or the transmitting node using known and/or standardized methods, such as estimation based on a reference signal (RS). <MAT> denotes a transmit beamforming vector. Such transmit beamforming vector may be available at each transmitting node per data stream of each intended receiving node. The transmit beamforming vector mu,s may be computed by the transmitting node using the illustrated iterative method, based on information collected from the receiving node(s) and/or one or more other transmitting node(s). The transmit beamforming vector mu,s may then be used for transmitting data and/or pilot signals. The data and/or pilot signals may include parameters computed by the transmitting node. <MAT> denotes a receive beamforming vector. Such receive beamforming vector may be available at each receiving node per each of its received data streams. The receive beamforming vector wu,s may be computed by the receiving node using the illustrated iterative method, based on information collected from the transmitting node(s) and/or one or more other receiving node(s). The receive beamforming vector wu,s may then be used for receiving data and/or pilot signals. The data and/or pilot signals may include parameters computed by other nodes. <MAT> denotes an MSE (Mean Square Error) parameter. The parameter εu,s may be available at each receiving node and each transmitting node. Each receiving node may estimate the parameter εu,s for its own received data streams and may indicate the parameter εu,s or a value corresponding to the parameter εu,s to the corresponding transmitting node. <MAT> denotes a parameter used for approximation of the current estimation of the current communication link reliability and quality at iteration (i). The parameter <MAT> may be available at each receiving node. The parameter <MAT> may be computed by the receiving node using the illustrated iterative method, based on information collected from the transmitting node(s) and/or one or more other receiving node(s). <MAT> denotes a parameter for controlling rate violation with respect to rate requirements of the communication link, at iteration (j + <NUM>). The parameter <MAT> may be available at each receiving node. The parameter <MAT> may be computed by the receiving node using the illustrated iterative method, based on information collected from the transmitting node(s) and/or one or more other receiving node(s). <MAT> denotes a parameter for controlling violation of QoS-relaxation variables associated with the communication link, at iteration (i + <NUM>). The parameter <MAT> may be available at each receiving node. The parameter <MAT> may be computed by the receiving node using the illustrated iterative method, based on information collected from the transmitting node(s) and/or one or more other receiving node(s). <MAT> denotes a rate relaxation variable for receiving node u. The parameter du may be available at each receiving node. The parameter du may be computed by the receiving node using the illustrated iterative method, based on information collected from the transmitting node(s) and/or one or more other receiving node(s). <MAT> denotes weights assigned to one or more data streams of the communication link.

The weights λu,s may be available at each receiving node and each transmitting node. Each receiving node may compute the weights λu,s for its own received data streams using the illustrated iterative method, based on information collected from the transmitting node(s) and/or one or more other receiving node(s). The receiving node may then indicate the weights λu,s to the corresponding transmitting node. In the illustrated iterative method, the weights λu,s may also be exchanged by transmitting nodes. <MAT> denotes a parameter used for approximation of the current estimation of the current communication link reliability and quality at iteration (i + <NUM>). The parameter <MAT> may be available at each receiving node. The parameter <MAT> may be computed by the receiving node using the illustrated iterative method, based on information collected from the transmitting node(s) and/or one or more other receiving node(s). <MAT> denotes a parameter used for approximation of the current estimation of the current communication link reliability and quality at iteration (i), with the parameter µ being a scalar value satisfying µ > <NUM>. These parameters may be pre-configured, e.g., based on network settings provided to each receiving node and each transmitting node. <MAT> denotes a step size at iteration (i). The step size δ(i) may be available at each receiving node and each transmitting node. The step size δ(i) may be configured before the beginning of the illustrated iterative method, e.g., by network settings or negotiation, and then updated in a decreasing manner with each iteration. <MAT> denote priority weight and penalty weight parameters which may vary for different time-frequency resources. These parameters may be available at each receiving node and each transmitting node and may be configured before the beginning of the illustrated iterative method, e.g., by network settings or negotiation. <MAT> denotes a rate requirement parameter which may vary for different time-frequency resources. The parameter Ru may be available at each receiving node and each transmitting node and may be configured before the beginning of the illustrated iterative method, e.g., by network settings or negotiation.

The SINR (Signal-to-Interference-and-Noise Ratio) for stream s of receiving node u can for example be expressed by <MAT> where <MAT> is the channel matrix between receiving node u and transmitting node b serving the receiving node i, <MAT> is the transmit beamforming vector, <MAT> is the receive beamforming vector and <MAT> is the noise variance at receiving node u.

The illustrated iterative method uses QoS relaxation variables to reduce the initial minimum rate requirements of some links in cases where the considered set of links cannot have their initial rate requirements met, i.e., in cases where there is an infeasible set of links with respect to the rate and power constraints and this is interrelated with the transceiver design. Therefore, using the relaxation variables, the illustrated iterative method performs a QoS-violation control in situations where it is not possible to meet the initial minimum rate requirements.

The rate relaxation variable for receiving node u is denoted by du. The range of possible values for each du is <NUM> ≤ du ≤ Ru. In cases when it is possible to meet the rate demands for every user, du should be equal to zero for all users. Otherwise, the values of du should be increased to the smallest possible values to not damage the system sum-rate. A penalty function is used to control the value of the relaxation variables, which is denoted by f(du). One suitable option of penalty function is the quadratic function <MAT>.

For a given receiving node u and stream s, the receiver beamforming vector (which is part of the second set of control parameters) is computed, for example, using the linear MMSE (Minimum Mean Square Error) receiver beamforming vector given by: <MAT>.

One option for estimating the MSE parameter (which is part of the second set of control parameters) for receiving node u and stream s is by using the following closed-form equation: <MAT>.

One example of equation used for computing the value of the parameter <MAT> (which is used for an approximation of the current estimation of the current communication link reliability and quality and is part of the second set of control parameters) at iteration i is: <MAT> where g(. ) can be given by <MAT>. The parameter µ is a scalar value satisfying µ > <NUM>.

The next step of the illustrated iterative method involves the computation of the parameters <MAT> (which is used for controlling the rate violation with respect to the rate requirements and is part of the second set of control parameters) and <MAT> (which is used for controlling the violation of the QoS-relaxation variables associated to the communication link and is part of the second set of control parameters), which can be computed, for example, by: <MAT> <MAT> where δ(i) denotes the step size of the current iteration and (·)+ denotes the operation max(<NUM>,·). The step size has an initial value know by each of the receiving nodes and its value is updated at each iteration of the proposed method using, for example, <MAT>.

The relaxation variables du (which are QoS-relaxation variables associated to the communication link and are part of the second set of control parameters) are computed, for instance, using: <MAT>.

Then, the values of the parameters λu,s (which are weights associated to one or more data streams of the communication link and are part of the second set of control parameters) can be computed, for example, using: <MAT>.

The next step of the proposed method involves the computation of the transmit beamforming vectors (which are part of the first set of control parameters) for each receiving node u and stream s, which is given by: <MAT> where <MAT> and vbu for all b and u comprises another set of parameters (which are scalar parameters for controlling the power allocation of the transmit beamforming vectors and are part of the first set of control parameters). Let us describe now one option for computing the values of vbu. If the power budget is fully used when solving (<NUM>) for vbu = <NUM>, then the computed values of transmit beamforming vectors are kept. Otherwise, the value of vbu can be found using one dimensional search techniques (e.g., bisection method) with respect to the power budget constraints. An eigenvalue decomposition of Qbu + Ivbu can be used to avoid the matrix inversion in (<NUM>). Alternatively, one can consider solving the linear system <MAT>. The use of such procedures makes the computational complexity of the algorithm very low.

Finally, the last step of the proposed method requires the computation of the parameters <MAT> (which is used for an approximation of the current estimation of the current communication link reliability and quality and is part of the second set of control parameters), which can be computed, for example, using: <MAT>.

<FIG> shows a flowchart for illustrating a method, which may be utilized for implementing the illustrated concepts. The method of <FIG> may be used for implementing the illustrated concepts in a first D2D communication device, e.g., corresponding to any of the above-mentioned UEs <NUM>.

If a processor-based implementation of the first D2D communication device is used, at least some of the steps of the method of <FIG> may be performed and/or controlled by one or more processors of the first D2D communication device. Such first D2D communication device may also include a memory storing program code for implementing at least some of the below described functionalities or steps of the method of <FIG>.

At step <NUM>, the first D2D communication device receives first information from one or more second D2D communication devices. The first information indicates control information for one or more links from the respective second D2D communication device.

At step <NUM>, the first D2D communication device determines control information for one or more links from the first D2D communication device. This is accomplished based on the indicated control information from step <NUM>.

At step <NUM>, determining the control information for one or more links from the first D2D communication device may be based on an optimization of quality and/or of reliability of the one or more links from the first D2D communication device, e.g., by using an MMSE optimization as described in connection with equation (<NUM>) to (<NUM>).

At step <NUM>, the first D2D communication device sends second information to one or more third D2D communication devices. The second information may indicate the determined control information of step <NUM> and/or the indicated control information of step <NUM>.

At step <NUM>, the first D2D communication device may control D2D communication on the one or more links from the first D2D communication device. The D2D communication may involve transmitting data and/or receiving data on the one or more links.

In some scenarios, as illustrated by a broken arrow in <FIG>, the method may be performed in an iterative manner. In this case, in response to sending the second information, the first D2D communication device may receive third information from the one or more second D2D communication devices, the third information indicating updated control information for the one or more links from the respective second D2D communication device. This may correspond to a further iteration of step <NUM>. Based on the indicated updated control information, the first D2D communication device may then determine updated control information for the one or more links from the first D2D communication device. This may correspond to a further iteration of step <NUM>. In such cases, step <NUM> may involve that the first D2D communication device controls communication on the one or more links from the first D2D communication device in accordance with the determined updated control information.

In some scenarios the first information may indicate whether the respective second D2D communication device intends to perform a transmission on one or more of the links from the second D2D communication device, using the indicated control information for the one or more links from the second D2D communication device, e.g., like the above-mentioned control flag for data reception.

The second information further indicates whether the first D2D communication device intends to perform a transmission on one or more of the links from the first D2D communication device, using the indicated control information for the one or more of the links from the first D2D communication device, e.g., like the above-mentioned control flag for data reception.

The one or more links from the first D2D communication device may include a link from the first D2D communication device to one of the one or more second D2D communication devices. On this link, the second D2D communication device can be the transmitting node, and the first D2D communication device the receiving node, or vice versa. Further, the one or more links from the respective second D2D communication device may include a link from the respective second D2D communication device to the first D2D communication device. On this link, the second D2D communication device can be the transmitting node, and the first D2D communication device the receiving node, or vice versa. <FIG> illustrates an example where the D2D communication device acts as the transmitting node, while <FIG> illustrates an example where the D2D communication device acts the receiving node.

The control information of step <NUM>, <NUM>, or <NUM> may include one or more beamforming parameters of the link, e.g., one or more beamforming vectors. Further, the control information of step <NUM>, <NUM>, or <NUM> may include one or more QoS parameters of the link, e.g., one or more QoS relaxation parameters and/or one or more parameters for controlling violation of one or more other QoS parameters. Further, the control information of step <NUM>, <NUM>, or <NUM> may include one or more weights for controlling distribution of transmit power to multiple data streams of the link. Further, the control information of step <NUM>, <NUM>, or <NUM> may include one or more parameters for controlling violation of one or more data rate requirements of the link. Further, the control information of step <NUM>, <NUM>, or <NUM> may include one or more parameters for estimation of quality of the link. Further, the control information of step <NUM>, <NUM>, or <NUM> may include one or more parameters for estimation of reliability of the link.

<FIG> shows a block diagram for illustrating functionalities of a D2D communication device <NUM> which operates according to the method of <FIG>. The D2D communication device <NUM> may for example correspond to any of the above-mentioned UEs <NUM>. As illustrated, the D2D communication device <NUM> may be provided with a module <NUM> configured to receive first information indicating control information for one or more links from second D2D communication devices, such as explained in connection with step <NUM>. Further, the D2D communication device <NUM> may be provided with a module <NUM> configured to determine control information for one or more links from the D2D communication device, such as explained in connection with step <NUM>. Further, the D2D communication device <NUM> may be provided with a module <NUM> configured to send information indicating control information for one or more links from the D2D communication device, such as explained in connection with step <NUM>. Further, the D2D communication device <NUM> may be provided with a module <NUM> configured to control D2D communication, such as explained in connection with step <NUM>.

It is noted that the D2D communication device <NUM> may include further modules for implementing other functionalities, such as known functionalities of a UE. Further, it is noted that the modules of the D2D communication device <NUM> do not necessarily represent a hardware structure of the D2D communication device <NUM>, but may also correspond to functional elements, e.g., implemented by hardware, software, or a combination thereof.

It is noted that the illustrated concepts could also be implemented in a system including at least multiple D2D communication devices, in particular at least one first D2D communication device operating as the first D2D communication device of the method of <FIG>. In addition to the at least one first D2D communication device, the system may include the above-mentioned one or more second D2D communication devices and/or the above-mentioned one or more third D2D communication devices.

<FIG> illustrates a processor-based implementation of a D2D communication device <NUM> which may be used for implementing the above-described concepts. For example, the structures as illustrated in <FIG> may be used for implementing the concepts in any of the above-mentioned UEs <NUM>.

As illustrated, the D2D communication device <NUM> includes one or more radio interfaces <NUM>. The radio interface(s) <NUM> may for example be based on the LTE technology or the NR technology.

Further, the D2D communication device <NUM> may include one or more processors <NUM> coupled to the radio interface(s) <NUM> and a memory <NUM> coupled to the processor(s) <NUM>. By way of example, the radio interface(s) <NUM>, the processor(s) <NUM>, and the memory <NUM> could be coupled by one or more internal bus systems of the D2D communication device <NUM>. The memory <NUM> may include a Read-Only-Memory (ROM), e.g., a flash ROM, a Random Access Memory (RAM), e.g., a Dynamic RAM (DRAM) or Static RAM (SRAM), a mass storage, e.g., a hard disk or solid state disk, or the like. As illustrated, the memory <NUM> may include software <NUM> and/or firmware <NUM>. The memory <NUM> may include suitably configured program code to be executed by the processor(s) <NUM> so as to implement the above-described functionalities for controlling D2D communication, such as explained in connection with <FIG> and <FIG>.

It is to be understood that the structures as illustrated in <FIG> are merely schematic and that the D2D communication device <NUM> may actually include further components which, for the sake of clarity, have not been illustrated, e.g., further interfaces or processors. Also, it is to be understood that the memory <NUM> may include further program code for implementing known functionalities of a UE. According to some embodiments, also a computer program may be provided for implementing functionalities of the D2D communication device <NUM>, e.g., in the form of a physical medium storing the program code and/or other data to be stored in the memory <NUM> or by making the program code available for download or by streaming.

As can be seen, the concepts as described above may be used for efficiently controlling D2D communication. Specifically, the concepts may be implemented based on per-node measurements and distributed decisions at participating nodes that guarantee the desired behavior, e.g., in terms of system-wide high throughput and per-user QoS. Further, the illustrated iterative method may offer a fast convergence of the method. The illustrated concepts may be implemented in a decentralized manner so that each involved node performs its own local computations in a completely distributed fashion upon reception of the control information associated to a communication link of another node. The illustrated concepts may be used for unicast and/or multicast transmissions, without requiring any significant modification. Further, the illustrated concepts may allow for maximizing a system sum-rate while still meeting minimum rates, e.g., corresponding to per-link QoS requirements. The illustrated concepts can additionally be used to optimize different network KPIs by means of different combinations of control parameters used to configure the communication links between network nodes. Further, the illustrated concepts may be applied in scenarios where communication links require a certain QoS, such as minimum rate requirements, as well as to the scenarios where communication links do not have QoS requirements, or a combination of such scenarios. For instance, some communication link could be required to support a minimum strictly positive communication rate (hence have a minimum data rate requirement), while other communication links could be required to support any non-negative data rate (hence have no minimum data rate requirement). The illustrated concepts may also be used to provide QoS-violation control, where the QoS requirements are met when feasible, while any occurring violation of the QoS requirements is minimized based on the optimized network KPI. This may be achieved, e.g., by deactivating links that cannot support the associated QoS requirement, thereby freeing radio resources for other communication links which are therefore enabled to meet the corresponding QoS requirement. Alternatively, the QoS requirements of one or more communication links may be reduced to optimize the network KPI while minimizing the QoS degradation for communication links that cannot meet the original QoS requirements. The illustrated concepts may enable optimizing the network KPI with limited low computational complexity and reduced signalling overhead as compared to centralized solutions.

Claim 1:
A method of controlling device-to-device, D2D, communication, the method comprising:
a first D2D communication device (<NUM>; <NUM>; <NUM>) receiving first information from one or more second D2D communication devices (<NUM>; <NUM>; <NUM>), the first information indicating control information for one or more links from the respective second D2D communication device (<NUM>; <NUM>; <NUM>);
based on the indicated control information, the first D2D communication device (<NUM>; <NUM>; <NUM>) determining control information for one or more links from the first D2D communication device (<NUM>; <NUM>; <NUM>); and
the first D2D communication device (<NUM>; <NUM>; <NUM>) sending second information to one or more third D2D communication devices (<NUM>; <NUM>; <NUM>), the second information indicating whether the first D2D communication device (<NUM>; <NUM>; <NUM>) intends to perform a transmission on one or more of the links from the first D2D communication device (<NUM>; <NUM>; <NUM>), using the determined control information for the one or more of the links from the first D2D communication device (<NUM>; <NUM>; <NUM>).