Technical Field

The invention relates generally to mobile communication networks. More particularly, the invention relates to optimizing feedback for a multicast/broadcast of data.

Background

It is known that a source may transmit data to multiple targets simultaneously. Such data transmission may be referred to as multicasting or broadcasting. The targets may need to inform the source whether or not the data was received successfully, e.g. to acknowledge the reception via an ACK or NACK. In case of several targets, this may cause collisions and contention of the network and, thus, decrease the efficiency of the data transfer.

Summary

According to an embodiment of the invention there is provided a method comprising the steps of:

causing, by a source device, transmission of data to a plurality of destination devices, wherein at least one data unit is to be transmitted by the source device to the plurality of destination devices;

causing reception of feedback from at least one of the plurality of destination devices, wherein each feedback comprises an indication of the progress of data reception corresponding to the destination device which transmitted the feedback, the progress being measured in the number of data units received or not received; and

determining whether or not to change the data transmission characteristics on the basis of the lowest progress among the indicated at least one progress. In a preferred arrangement, this embodiment is performed by a user equipment or a base station.

In an alternative embodiment there is provided a method comprising: causing, by a destination device, reception of data from a source device, wherein at least one data unit is to be transmitted by the source device to a plurality of destination devices;

determining the progress of data reception, wherein the progress is measured in the number of data units received or not received;

determining whether or not to transmit a feedback of data reception to the source device on the basis of predetermined criteria; and

upon detecting that the feedback is to be transmitted, including an indication of the determined progress in the feedback and causing transmission of the feedback to the source device. In a preferred arrangement this embodiment is performed by a user equipment.

According to a further embodiment, there is provided an apparatus comprising a processing system, which may be embodied by processing circuitry and/or a computer program and memory, configured to cause the apparatus at least to:

cause transmission of data to a plurality of destination devices, wherein at least one data unit is to be transmitted to the plurality of destination devices;

cause reception of feedback from at least one of the plurality of destination devices, wherein each feedback comprises an indication of the progress of data reception corresponding to the destination device which transmitted the feedback, the progress being measured in the number of data units received or not received; and

determine whether or not to change the data transmission characteristics on the basis of the lowest progress among the indicated at least one progress. In a preferred arrangement, this embodiment is performed by a user equipment or a base station.

According to a further embodiment, there is provided an apparatus comprising a processing system, which may be embodied by processing circuitry and/or a computer program and memory, configured to cause the apparatus at least to:

cause reception of data from a source device, wherein at least one data unit is to be transmitted by the source device to a plurality of destination devices;

determine the progress of data reception, wherein the progress is measured in the number of data units received or not received;

determine whether or not to transmit a feedback of data reception to the source device on the basis of predetermined criteria; and upon detecting that the feedback is to be transmitted, include an indication of the determined progress in the feedback and cause transmission of the feedback to the source device. In a preferred arrangement the apparatus is embodied by a user equipment.

According to an aspect of the invention, there is provided a computer program comprising a set of instructions, which, when executed by a computing system, causes the computing system to perform the steps of:

causing, by a source device, transmission of data to a plurality of destination devices, wherein at least one data unit is to be transmitted by the source device to the plurality of destination devices;

causing reception of feedback from at least one of the plurality of destination devices, wherein each feedback comprises an indication of the progress of data reception corresponding to the destination device which transmitted the feedback, the progress being measured in the number of data units received or not received; and determining whether or not to change the data transmission characteristics on the basis of the lowest progress among the indicated at least one progress.

Preferred features of embodiments of the invention are defined in the dependent claims. Brief Description of the Drawings

In the following, the invention will be described in greater detail with reference to the embodiments and the accompanying drawings, in which

Figure 1 presents a communication scenario applying ACK/NACKS;

Figures 2 and 4 present communication scenarios applying multicasting/broadcasting, according to some embodiments;

Figures 3A and 3B show methods according to some embodiments;

Figures 5A and 5B depict how the progress of data reception is used in determining the point of time for transmitting the feedback, according to some embodiments;

Figures 6 and 8 depict flow diagrams according to some embodiments;

Figure 7 illustrates a time line with respect to an embodiment; and

Figures 9 A and 9B show apparatuses according to some embodiments. Detailed Description

The following embodiments are exemplary. Although the specification may refer to "an", "one", or "some" embodiment(s) in several locations of the text, this does not necessarily mean that each reference is made to the same embodiment(s), or that a particular feature only applies to a single embodiment. Single features of different embodiments may also be combined to provide other embodiments.

In a communication of data from a source 100 to a plurality of destinations devices 102A to 102N, as shown in Figure 1, each of the destination devices (DD) may be required to acknowledge the reception of the data by transmitting a feedback to the source 100. The transmission of data is shown with solid arrows in Figure 1, whereas the feedback is marked with dashed arrows. The feedback may typically apply acknowledgements (ACK) or negative ACKs (NACK) via which the source 100 may determine whether the DDs 102A, 102N have received the transmitted data unit, such as a packet, successfully or not. In case the packet is not received successfully, a retransmission of the data packet may be in order. As known by a skilled person, for example, automatic repeat request (ARQ) is a retransmission scheme that is based on these acknowledgements. The ARQ may be seen as an error-control method for data transmission.

In addition to conventional infrastructure-based networks (e.g. networks where a base station communicates with a plurality of user equipments (UEs)), the multicasting/broadcasting feature is possible for non-infrastructure based device-to- device (D2D) communication. Moreover, 802.11 technologies support device-to- device communication by offering ad-hoc communication mode via an independent basic service set (IBBS) function. Also, the D2D communication is a potential new feature supported by the future cellular technologies, such as the long term evolution - advanced (LTE-A). In general the D2D support is not limited only to the LTE and its advanced evolution but may also be implemented, e.g., in the Global System for Mobile communications (GSM, 2G), in the Universal Mobile Telecommunication System (UMTS, 3G) based on basic wideband-code division multiple access (W- CDMA), and in the Worldwide Interoperability for Microwave Access (WiMAX). In future networks, the direct device-to-device multicasting may be a network controlled operation mode or a standalone feature supported by the D2D devices.

To achieve reliable multicast/broadcast may be a cumbersome operation. One of the main difficulties in such multicasting/broadcasting of a file to a set of destinations 102A to 102N is the overhead introduced when the set of destinations 102 A, 102N needs to provide feedback to the source 100 regarding the outcome of the transmission. Given that the multicast/broadcast content is typically destined to a large set of destinations 102 A to 102N, the existing back-off mechanism may fail to scale efficiently. It should be noted that, although two destination terminals are explicitly shown in Figure 1 , the number N of destination terminals may be large, such as tens or hundreds, for example. In particular, when the number of destination terminals 102A to 102N is large, the probability of a collision of random access methods in the uplink for the destinations 102A to 102N to acknowledge the transmission to the source 100 increases. Subsequently, if a random access protocol, such as carrier sense multiple access (CSMA) is used, the contention windows at the destination terminals will increase which will introduce long delays as nodes remain longer in back-off and will create contention because all the destination terminals 102A to 102N will need to send their feedback. Thus, the collisions and subsequent retransmissions from destinations 102A to 102N will consume the bandwidth in an excessive manner. Given the significant role of multicast/broadcast content in future networks, alternative methods need to be introduced to provide multicast reliability.

Therefore in the proposed scheme shown in Figures 2, 3A, and 3B, the source device 200 transmits in step 300 of Figure 3 A, data to a plurality of destination devices (DD) 202 to 206. The data transmission may denote that at least one data unit is to be transmitted by the source device 200 to the plurality of destination devices 202 to 206. In Figure 2, the solid lines represent the transmission of data to the DDs 202 to 206. From the point of view of the DDs 202 to 206 with respect to Figure 3B, in step 310, the DD 202 to 206 may receive the transmitted data from the source device 200. However, it is clear to a skilled person, that the receiver may not benefit from the received data properly such, as e.g., in the case where the received data are erroneous. The data transmitted to the different DDs 202 to 206 may be or comprise the same data. For example, let us assume that the source 200 broadcasts the same content to all destinations 202 to 206. This situation can arise in several cases. For instance, this may be the case when the source 200 uses network coding to multicast the content. E.g., the source 200 may multicast the content encoded through some rateless code, such as raptor codes in Multimedia Broadcast/Multicast Service (MBMS). Also, this situation may arise when all users of the multicast group have paid for a particular service and, thus, the service should be guaranteed. In such a situation, the rate of the multicast transmission may be restricted by the destination 202 to 206 facing the worst channel conditions, for example.

The source 200 in such multicast or broadcast of data to a plurality of DDs 202 to 206 may be a user equipment or user terminal (UE, UT) communicating directly with the set of destinations 202 to 206. Alternatively, the source 200 may be a cellular base station multicasting/broadcasting data to the DDs 202 to 206. In this case, the DDs 202 to 206 may feedback in the uplink. The cellular base station, as the source 200, applicable to the embodiments may be configured to provide communication services according to at least one of the following radio access technologies (RATs): WiMAX, GSM, GSM EDGE radio access Network (GERAN), General Packet Radio Service (GRPS), UMTS, high-speed packet access (HSPA), LTE, and/or LTE-A. The present embodiments are not, however, limited to these protocols. The base station may thus be, for example, a node B (NB) as in the LTE, an evolved node B (eNB) as in the LTE-A, a radio network controller (RNC) as in the UMTS, a base station controller (BSC) as in the GSM/GERAN, or any other apparatus capable of controlling radio communication and managing radio resources within the cell. Further, the source 200 may be seen as a wireless local area network (WLAN) (or any other broadband communication technique network) base station transmitting data to a set of DDs 202 to 206.

Figure 2 further depicts with reference numeral 208 a set of data units. In an embodiment, the data unit may be seen as data packets which are to be transmitted to the DDs 202 to 206. The P packets may make up one file, such as video file, and the DD 202 to 206 may need to obtain all P packets before it may appropriately build up the file. This may be the case, for example, when the data is uncoded at the source 200. In another embodiment, the P data units at the source may be encoded together by using some form of network coding e.g., random linear network coding and the encoded packets may be transmitted by the source. Therefore, those P packets may comprise the whole file. For a destination to decode the data successfully it must receive at least P linearly independent vectors, i.e. as many as the number of packets comprising the file that have been encoded together at the source 200. Alternatively, those P packets may be parts of the file that are commonly called "generations" in network coding literature. In that case, for a destination to decode the data it must receive all the generations comprising the file, where a generation is received successfully when a destination receives at least P linearly independent vectors, i.e., as many as the packets comprising the generation. Equivalently, the P data units may be seen as the number of linearly independent vectors required to be acquired by the DD 202 to 206 before the destination 202 to 206 may decode the original content which the source 200 transmitted, e.g. the packets that were encoded together at the source 200. In the case that P data units comprise a generation, the discussions that follow apply per generation. These latter two cases may be seen to represent a case of coded transmission. The data may be coded by random linear network coding (RLNC), raptor codes, or other forms of rateless codes in general, for example. It should be noted that the successfully received vectors by a receiving destination device 202, 204, or 206 need to be linearly independent. This means that even though the transmission may successfully go through, in the sense that the required signal to noise ratio is satisfied, it is possible that the corresponding DD does not gain any information from the received dependent vector when the received vectors are dependent with other vectors that the DD has received so far.

In an embodiment, the source 200 may transmit information indicating the maximum number of data units that are meant to be delivered to the plurality of destination devices 202 to 206. I.e. it may be advantageous for the DDs 202 to 206 to know how many packets are encoded together or how many packets belong to a specific file. The information may be sent as a separate message or it may be piggybacked to the first transmission (encoded or uncoded). In the encoded case, such indication may be provided explicitly by saying P packets are encoded or implicitly by observing that P coefficients are sent, each corresponding to one uncoded packet residing at the source 200. The implicit way of decoding may be used when the coefficients are sent along with the payload. The destination 202 to 206 may need those coefficients to start building a matrix that will be inverted later on to obtain the transmitted P packets. However, in another embodiment, the coefficients need not be sent with the data payload in cases where the source 200 and the destinations 202 to 206 are synchronized with a common seed and, thus, may create the same pseudorandom sequence of coefficients. This approach may advantageously have less overhead at the cost of being more sensitive to transmission errors and to the chance that the source 200 and the destinations 202 to 206 may eventually get out of synchrony. In this case, it may be mentioned explicitly how many (=P) packets are encoded together or are to be transmitted.

In step 312 of Figure 3B, the receiving DD 202 to 206 may determine the progress of data reception, wherein the progress is measured with respect to how close a given destination is in receiving the data from the source, namely in terms of the number of data units received or not received. The meaning of progress depends on the context but is always defined per destination. In an embodiment related to the uncoded case, the progress at a destination 202 to 206 may be the number of packets that the corresponding destination has received so far while in an embodiment related to the case of network coding, the progress at a destination 202 to 206 may be the number of linearly independent vectors the corresponding DD has received so far. In an embodiment, the progress may start by an initial value of 0 (zero) and in this case is a non-decreasing function of time per destination. The maximum progress is the number of packets that have been encoded together at the source 200 or the number of uncoded packets sent by the source 200. As the DDs 202 to 206 may receive the number of data units to be transmitted by the source 200 (i.e. receivable by the DDs 202 to 206), either implicitly or explicitly, the DDs 202 to 206 may obtain knowledge of the maximum progress achievable. When the maximum progress is reached at a destination 202 to 206, then the corresponding DD may be able to decode the original content the source 200 transmitted.

In another embodiment, the progress is a non-increasing parameter in time per destination device and measurable in the number of data units yet to be received or not received. In the uncoded case this corresponds to the number of packets yet to be received by a destination DD and in the encoded case to the number of the remaining linearly independent vectors needed before the uncoded transmitted packets can be recovered. In other words, as the DD 202 to 206 may acquire knowledge that P packets are to be sent from the source 200 (i.e. receivable by the DD), the destination device 202 to 206 may determine the progress as X data units are not received or are yet to be received. For example, in the uncoded case after a first transmission, there may be 5 packets not received, whereas after a second transmission, there may be only 4 packets not received. A few transmissions may eventually lead to reception of all the P packets by the corresponding DD. In this case, the progress is a non-increasing function of time, e.g. in the above case [5, 4,..., 0]. The same example would apply in the coded case if the numbers above correspond to linearly independent vectors needed before the uncoded transmitted packets can be recovered.

In an embodiment related to the uncoded multicast/broadcast, the progress may be the number of packets from a given file or video that each destination 202 to 206 has received successfully. Again, in this context, the minimum progress may be equal to 0 (zero), e.g. no packets have been received by a destination, and the maximum value of the progress may equal to the number of packets in the file that the source 200 transmitted. As the DDs 202 to 206 may receive the number of data units to be received (implicitly or explicitly), the DDs 202 to 206 may obtain knowledge of the maximum progress achievable. When the progress at each destination takes its maximum value, then each destination is able to decode the file successfully. It is to be noted that, in both cases, the progress may as well be a non-increasing function of time. This may be a valid case when progress does not explicitly indicate the number of packets received but rather the number of packets not received, i.e. still to be received.

A destination 202, 204 or 206 may experience the worst or lowest progress because the corresponding DD faces the worst channel conditions, or, e.g., when network coding is used, when the encoded vectors the DD received are linearly dependent. For example, in Figure 2, the progress, in the case of P=6, may vary between 0 and 6.

In steps 314 and 316 of Figure 3B, the receiving DD 202 to 206 may determine whether or not to transmit a feedback of data reception to the source device on the basis of predetermined criteria and, upon detecting that the feedback is to be transmitted, include an indication of the determined progress in the feedback and cause transmission of the feedback to the source device, respectively. Correspondingly, the source 200 may, in step 302, receive feedback from at least one of the plurality of destination devices 202 to 206, wherein each feedback comprises an indication of the progress of data reception. The source 200 may then, in step 304, determine whether or not to change the data transmission characteristics on the basis of the lowest progress among the indicated at least one progress.

Under a traditional feedback scheme, such as the ACK/NACK scheme depicted in Figure 1 , the source would expect a feedback from each destination before it makes an adaptive decision, for example, in terms of changing the rate or the transmit power, or before it stops transmitting the content. This may create a lot of contention and delays in the uplink of the random access scheme (e.g., CSMA) applied for sending the feedback when the number of destinations is large. However, in the proposed manner, the DD 202 to 206 may not all send the feedback as will be explained. However, in the case of multicast/broadcast, where the same content may need to be received by each destination, effectively what matters to the source 200 may be the worst (i.e. the lowest) progress in the reception measured among all the destinations 202 to 206. I.e. in the case of Figure 2, from the point of view of the source 200, it may be enough to receive the feedback from the DD 204, which encountered the lowest progress (=3). This may be enough for the source 200 because the lowest progress may be the one that will determine what the source 200 should do subsequently, e.g. whether or not to adapt its rate or transmission power. It should be noted that multicast may intend to get the data transmitted to each and every destination 202 to 206.

Regarding step 314 of Figure 3B, the DD 202 to 206 may determine whether or not to transmit the feedback to the source 200 according to the predetermined criteria. These criteria may comprise, for example, that no transmission is needed when the DD 202 to 206 receives a re-transmission of a set of at least one data unit from the source device prior to transmission of the feedback for the previously received same set of at least one data unit. This may be the case depicted in Figure 4. Let us assume the uncoded case and that the source 200 has transmitted P packets to the DDS 202 and 204. The progress of the DD 202 is at least three, whereas the progress determined by the DD 204 for the DD 204 is three. Now it may be that the DD 204 has transmitted feedback to the source 200 and, thus, indicated the progress=3 to the source 200. As the source 200 knows that the number of achievable packets P is larger than three (such as six, in the case of Figure 2), the source knows that it needs to change (or adapt) the characteristics of data transmission and transmit the same data again (i.e. retransmit the previous at least one data packet). It may decide to do so even before the DD 202 has transmitted its feedback. Thus, the DD 202 may receive the retransmission of data and from that, acquire knowledge that it need not transmit any feedback for the previous set of data, as indicated by the cross 400. The progress of the DD 202 may have been anything between 4 and P.

In an embodiment, when any of the DDs receive a new set of data before transmitting the feedback, the corresponding DD may decide that it need not transmit the feedback to the source 200. This is because the source 200 has already determined that each DD has correctly received the previously transmitted data set (i.e. all P packets of the previous data set were successfully received by each DD 202 to 206). In an embodiment, the members 202 to 206 of the multicast group are in proximity of each other and may overhear each other's feedback transmissions, such overheard information may be incorporated in the back-off mechanism to design deterministic back-off schemes with smaller delays. Such overhearing may be possible and advantageous, for example, in networks with a large number of terminals 202 to 206 in proximity of each other. More particularly, the predetermined criteria may in this case comprise that whenever a DD acquires knowledge of the progress corresponding to another destination device 202 to 206 by detecting a feedback sent by the other destination device 202 to 206 and detects that the progress corresponding to the other destination device 202 to 206 is lower than or the same as the progress of the present destination device, the latter may defer from the feedback transmission (i.e. it does not transmit the feedback to the source 200). Thus, looking again at Figure 4, in one embodiment, if the DD 204 sends a feedback to the source 200 in which its progress (=3) is worse than or the same as the progress of the destination device 202 which overheard the feedback, then the DD 202 may defer the feedback transmission. The overhearing may be possible because the feedback may not be a coded transmission and because the DDs 202 to 206 may know that there are other DDs in the proximity which may be overheard. Alternatively, it may be possible if the feedback is sent in a broadcast address. The proximity information may be obtained from the source 200 or from any device-to-device discovery protocol known to a skilled person, for example. Such avoidance of transmitting the feedbacks from each DD 202 to 206 may be advantageous as then the network may not become congested due to each DD 202 to 206 transmitting feedbacks. For example, if the destination 204 with the worst progress signals the source 200 first, this may save unnecessary subsequent contention and feedback transmissions. In a network with D destinations, the savings may correspond to D-1 transmissions in the best case. The gains are even higher if one considers that these D-1 transmissions may result in several collisions and subsequent increases of the contention window. Ideally speaking, the system should not receive feedbacks from the rest of the destinations, except the one with the lowest progress, since the other DD's feedback would just waste the bandwidth and create unnecessary contention. Thus, avoiding excessive feedbacks or at least controlling the order of feedback transmissions (such as by controlling the maximum back-off window size of the destinations, as will be described) may provide an ordering in the times in which the DDs 202 to 206 access the channel and hence an ordering in receiving the feedback from the different destinations 202 to 206 by the source 200. Let us next take a look at the ordering.

In an embodiment, there is proposed a random back-off implementation that is parameterized by the destination's reception "progress" so that the destination with the worst progress has the smallest maximum back-off window size. This would allow the worst destination 204 (i.e. the DD with the worst/lowest progress) to feedback the source first, on average, before the rest of the destinations 202 and 206 send their feedback. By preventing unnecessary contention due to feedbacks from the other destinations 202 and 206, this embodiment may increase the system efficiency and in a sense tackle the feedback implosion problem.

Thus, in an embodiment, the plurality of destination devices transmits the feedback according to an order which is at least partly based on the progress. The DDs 202 to 206 may apply a function of the progress in at least partly determining the point of time for transmitting the feedback. In a more particular embodiment, any DD 202 to 206 may determine the maximum back-off window size on the basis of the function, wherein the maximum back-off window (BW) size for a destination device with a lower progress is smaller than for a destination device with a higher progress. This is shown in Figure 5A, where the maximum BW for a DD 204 with the progress=3 has a duration marked with reference numeral 500. The maximum BW for a DD 202 with the progress being at least 4 has a duration marked with reference numeral 502. It may be seen that the duration 502 is longer than the duration 500. The corresponding DD 204/202 may then select the point of time (i.e. the back-off time) for transmitting the feedback within the back-off window 500/502, respectively. This way the maximum back-off window size 500/502 is given, in an embodiment, by an increasing function of the progress. This is in the case that progress is defined in terms of the number of packets (or linearly independent vectors) received.

Alternatively, in another embodiment, if the progress is defined as the number of packets (or linearly independent vectors) still needed at a destination, then the maximum back-off window is still an increasing function of the negative progress. In both cases, this means that the closer a destination is at receiving all the packets from the source, the larger the maximum window size is and the vice versa. For example, if a destination's progress is poor in terms of not having received much data from the source, the applied function may take a small value (meaning that the maximum back- off window 500/502 for this destination 204/202 is small) and, subsequently, so is the back-off time value chosen within the interval 500/502. Hence, the corresponding destination device may access the channel sooner on the average than another destination with a better progress (which has a larger back-off window on the basis of the applied function). This may advantageously enable the "worst destination 204" to signal the source 200 first in the expected sense.

However, this may take place on average only as the actual back-off time is a time that is chosen randomly and uniformly within the BW interval [0, maximum back-off window size 500/502]. In any case, this may further enable the source 200 to adapt its transmission scheme accordingly before all of the destinations 202 and 206 send their feedbacks.

In an embodiment, the DD may not select its back-off time randomly and uniformly within the interval 500/502 but apply a bias towards the maximum back-off window size (MAX BW in Figure 5A), when selecting the point of time for transmitting the feedback within the back-off window. This may additionally imply that the destination 204 with the lowest progress transmits the feedback first.

In an embodiment, the function to be applied is a linear, increasing function. Even though these embodiments applying the function of the progress may in general use any arbitrary increasing functions of the progress, in an embodiment convex functions are proposed. Example convex functions are shown in Figure 5B with reference numerals 510 and 512. Convex functions may be beneficial as they may have better performance than linear functions. A convex function may be characterized by having a steeper slope for higher inputs than for lower inputs. This means that such functions assign small maximum back-off windows 500 when the progress is poor and proportionally much larger maximum back-off windows 502 when the progress is good.

In an embodiment, the applied (any arbitrary selected) increasing function is scaled by the number of destinations 202 to 206. The source 200, having the knowledge of the number of destinations 202 to 206, at least in the multicasting case, may select a function of the progress at least partly on the basis of the number of the plurality of destinations devices 202 to 206. Then the source 200 may cause transmission of information indicating the function to the plurality of destination devices 202 to 206. For example, the source 200 may have several possible functions to signal to the DDs 202 to 206 depending on the configuration and the number of destinations 202 to 206. Figure 5B shows two different convex functions 510 and 512. For example, as the number of destinations decreases the maximum back-off window 500/502 for a given progress decreases. I.e. the source may select the function 512 rather than the function 510 when the number of DDs 202 to 206 is small, and vice versa. When the number is low or when it is high, may be known based on empirical derivation or mathematical modeling, for example. Further, it may be noted that the maximum slope of the applied convex function decreases as the number of destinations decrease.

In an embodiment, as long as the functions are common among destinations

202 to 206, the destinations 202 to 206 may operate independently without the need to know what the other destinations 202 to 206 are doing and what is their progress. This may provide an increase in efficiency and reduce the protocol overhead. The function to be applied (or functions, out of which one is selected by the DD) may be, for example, preconfigured to the destination devices 202 to 206.

An embodiment proposes a non-random back-off implementation in which destinations 202 to 206 are placed in an order. The order may be either an increasing or a decreasing order on the basis of the identifier, wherein the identifier is at least one of the following: medium access control (MAC) address, Association Identifier (AID), and radio network temporary identifier (RNTI). Even though ordering can be in ascending or descending order, in the following we discuss the case where order is increasing, for simplicity reasons.

Let us take a closer look at this embodiment with reference to Figure 6. In step 600, the source 200 may determine the identifiers of the plurality of destination devices 202 to 206. As known by a skilled person, the source 200 may have the knowledge regarding the identities of the destinations 202 to 206. Thereafter, the source 200 may in step 602 transmit information to the plurality of destination devices 202 to 206 (out of which only 202 and 204 are shown in Figure 6), wherein the information indicates the order based on the determined identifiers. The sent information may be the explicit order, or it may be that the identifiers of the destination devices 202 to 206 are indicated. In other words, the source 200 may multicast/broadcast a sequence of AIDs/MAC addresses/RNTIs to the DDS 202 to 206. Such info may need to be sent once at the beginning of the broadcast/multicast. In case the identifiers of the devices 202 to 206 (i.e. the members of the multicast) are consecutive, (e.g., AIDs are 1 ,2,3... , N) only the lowest (or largest) value may need to be sent depending on whether the ordering considered is ascending or descending.

In steps 604A and 604B, each DD 202, 204 may check, or determine, its own identifier. For example, the let us assume that the identifiers of the device 202 and 206 are #5 and #19, respectively. The source 200 may transmit a sequence [5, 19]. In such case, each station 202, 204 may first need to check what is the own identifier of the DD before the DD may determine is it supposed to transmit first or second. In other words, each destination may check its position in the order. If its position is the next in order from the last transmission, then the back-off for this device expires and it moves to the next step and sends its feedback. In this way, the stations 202 and 204 may acquire knowledge on the order in which they are supposed to transmit.

In step 606, the destination 204, with the example identifier X, is transmitting its feedback to the source 200. In an embodiment, in step 608, the other devices 202 may detect (overhear) the feedback transmitted by the destination device 204, which precedes the present destination device 202 according to the order. When the DD 202 detects that the progress of the DD 204 is worse than that of the DD 202, the latter may decide not to transmit at all. In this case, the step 610 may be omitted. In other words, if a "preceding" destination 204 sends a feedback to the source in which its progress is worse than or the same as the destination 202 who is supposed to transmit next, then the latter (DD 202) defers transmission. In the random back-off case, the "preceding" DD is the DD that transmitted earlier (which has a worse performance because its back-off window 500 given by the function is smaller). In the non-random back-off case, the "preceding" DD is the DD which is of lower/higher order, as the case may be. It may be worth noting that the rest of the destinations may also defer their feedback transmissions when they detect that their preceding destination did not transmit the feedback.

However, upon the DD 202 detecting the feedback from the DD 204 and detecting that the progress is better than that of the DD 202, the DD 202 may cause transmission of the feedback to the source in step 610. It should also be noted that when such overhearing is not possible (due to large distances between the DDs 202 to 206) or otherwise not performed, the step 608 may be omitted and step 610 may be performed.

It should be noted that each destination 202 that hears the transmission of another destination device with a smaller order, may be required to wait for a time margin used for robustness to capture potential delays, potential non-response of the preceding destination, etc., and then transmit its own feedback message. Thus, in this embodiment, all the targets may transmit the feedback but in a controlled manner which may thus decrease system delay by preventing multiple-access collisions and the associated increases of the window-size 500/502 of the back-off schemes. Thereafter, the source 200 may in step 612 determine whether adaptation of transmission characteristics, such as change of coding parameters (rate, applied codes) or increase of transmission power, is needed.

It is possible that at least one DD 202 to 206 leaves the group of multicast/broadcast members. For managing such cases, each destination may wait until an expiry of predetermined time duration before transmitting their feedback. In other words, even though the device 202 would not detect the feedback from the DD 204 (which may have left the multicast group), the DD 202 may, after expiry of the predetermined time duration, transmit its feedback to the source 200. This may also contribute in reducing delays in the system.

Further, at least one DD leaving the multicast group may be detected by the source 200, for example, by updates of the tracking area. In such scenario, the source 200 may transmit information to the plurality of destination devices 202 to 206, wherein the information indicates the updated order based on the determined identifiers. I.e. if the original order based on the identifiers is [1, 4, 7, 9, 10], and a device with an identifier #7 leaves the group, the updated order may be sent to the DDs, wherein the updated order may be [1, 4, 9, 10]. The DDs receiving the updated order may thus act correspondingly without the device with identifier #9 waiting for the predetermined time duration prior to the feedback transmission. Thus, the order setting may be controlled by the source 200 according to past transmissions.

In an embodiment, a destination 206, which have reached the maximum progress, feedbacks only once. This may further increase the efficiency as there is no point for destinations which have already obtained all the packets to constantly let the source 200 know this. It is enough to let the source 200 know once. This may be especially beneficial when there are several retransmissions due to some DDs not receiving all the transmitted packets, but where some other DDs received all the packets already in the first transmission, for example.

The source 200 may also broadcast the identifiers, such as AIDs, of DDS 206 that have reached the maximum progress to the other DDs 202 to 204. Thereby indicating the other DDs that the devices 206 having those AIDs are not transmitting the feedback anymore. This may simplify the establishment of the order in which the feedbacks are transmitted. Figure 7 shows an example where the source 200 applies a timer 700A, 700B for determining a maximum duration for listening to feedbacks from the plurality of destination devices. Let us assume that the source 200 has transmitted data as shown with solid arrow 702. The feedbacks received are illustrated with dashed arrows 704 and 706. After the timer 700 A has expired, the source 200 may possibly adapt the transmission characteristics and retransmit data in step 708. Let us now assume that the device corresponding to the previous feedback 706 has left the multicast group and feedback for the data transmitted in step 708 is received only from one device corresponding to feedback 710. In such case, the timer may be advantageous to use, as then the source may, after the expiry of the timer 700B, transmit new data in step 712. Thus, in an embodiment, upon detecting that the channel has been idle for a predetermined duration of time 700B, the source 200 may determine that no more feedback is to be received for the previously transmitted at least one data unit 708. Thus, the source 200 may apply a timer to determine whether or not to quit the message transmission. This may prevent the source 200 from waiting any feedback from the destinations when they are not available anymore.

In an embodiment, upon the source 200 observing the channel to be idle for more than a given duration, it may seize the channel in order to avoid excessive delays.

Regarding step 304 of Figure 3 A, the source 200 may determine whether or not there is at least one destination device 202 to 206 which has not received all the transmitted data units. In Figure 2, the DDs 202 and 204 have not received all the data packets as the progress indicated by those devices is less than P (=6). As a consequence, the source 200 may determine that adaptation (or change/variation) of at least one data transmission characteristics needs to be made. As an example it may be said that the data transmission characteristics to be changed may comprise at least one of the following: a transmission power, a rate of the coding, applied codes. For example, the amount of change of the transmission characteristics may be proportional to the difference of the indicated lowest progress and the known maximum progress.

As an example, in the case of RLNC, the source 200 may send all the P packets again by encoding them with different parameters. Assume that the source encodes together P packets, after adaptation the source 200 may keep on transmitting encoded combinations of the P packets (e.g. alpha_il *pl + alpha_i2*p2 + ... + alpha_iP*pP) for different choices of alphas. The first transmitted encoded packet corresponds to i=l . It may be that some generation of packets corresponding to certain i may lead to an encoded packet that is innovative for a certain DD, but for another DD the encoded packet is not innovative (i.e. the two vectors may be linearly dependent). However, due to the rateless property of the code, the source may only need to know how many linearly independent combinations of packets a destination has received (this gives an indication of the progress and eventually gives an indication of how many packets it can decode). When a DD has received P such "encoded" packets which are linearly independent, the corresponding DD may decode the generation. When all destinations receive P linearly independent destinations, the source may encode a new generation of data units.

Owing to the proposed order of sending the feedbacks, the source may receive feedback from only one destination device, such as the DD 204, when it is known, on the basis of the order for example, that the first feedback corresponds to the lowest progress among the plurality of destination devices 202 to 206. Thereafter, the source may determine whether or not to adapt the data transmission characteristics on the basis of the received single feedback.

In an embodiment, the source 200 may request a feedback from the plurality of destinations 202 to 206. Alternatively each destination device knows that it needs to feedback the progress without any specific request.

In an embodiment, the communication between the source 200 and the destination device 202, 204, or 206 applies a single-hop communication scenario and the source device 200 is one of the following: a user equipment applying device-to- device (D2D) communication scheme, a base station applying cellular downlink transmission, a base station applying 802.11 communication scheme, for example.

Figure 8 provides an example flow diagram regarding the proposed solution. In step 800, the source 200 transmits data to destinations 202 and 204. In steps 802A and 802B, the destinations 202 and 204 determine their progress. As the progress of the DD 204 is lower (e.g. 3) than that of the DD 204 (e.g. 4), the back-off window for the DD 204, based on the function, is shorter. As a consequence, it is likely that DD 204 selects a shorter back-off time than the DD 202 and thus transmits the feedback first in step 804. The source 200, receiving the feedback and knowing that it is the feedback corresponding to the lowest progress, may immediately decide to adapt the transmission characteristics in step 808. As a result, the source 200 may retransmit the data to the destinations 202 and 204 in step 810. The DD 202 receiving the retransmission before transmitting its feedback for the earlier data, may decide not to transmit the feedback, which would otherwise been transmitted in step 806 as shown with a dotted arrow. This may be advantageous as it may decrease the contention of the system and decrease delays.

Embodiments, as shown in Figures 9 A and 9B, provide apparatuses 900 and 920, each comprising a control circuitry (CTRL) 902, 922, such as at least one processor, and at least one memory 904, 924 including a computer program code (PROG), wherein the at least one memory 904, 924 and the computer program code (PROG), are configured, with the at least one processor 902, 922, to cause the apparatus 900, 920 to carry out any one of the described embodiment. It should be noted that Figures 9A and 9B show only the elements and functional entities required for understanding a processing systems. Other components have been omitted for reasons of simplicity. It is apparent to a person skilled in the art that the apparatuses may also comprise other functions and structures.

In an embodiment, the apparatus 900 may be or be comprised in a base station (also called a base transceiver station, a Node B, a radio network controller, or an evolved Node B, for example) of a cellular radio communication network or of a IEEE 802.11 network. In another embodiment, the apparatus 900 may comprise the terminal device of a cellular communication system, e.g. a computer (PC), a laptop, a tabloid computer, a cellular phone, a communicator, a smart phone, a palm computer, or any other communication apparatus, such as user equipment (UE), capable of device to device communication. Alternatively, the apparatus 900 is comprised in such a terminal device. Further, the apparatus 900 may be or comprise a module (to be attached to the UE) providing connectivity, such as a plug-in unit, an "USB dongle", or any other kind of unit. The unit may be installed either inside the UE or attached to the UE with a connector or even wirelessly.

In an embodiment, the apparatus 920 may comprise the terminal device of a cellular communication system, e.g. a computer (PC), a laptop, a tabloid computer, a cellular phone, a communicator, a smart phone, a palm computer, or any other communication apparatus, such as user equipment (UE). Alternatively, the apparatus 920 is comprised in such a terminal device. Further, the apparatus 920 may be or comprise a module (to be attached to the UE) providing connectivity, such as a plug-in unit, an "USB dongle", or any other kind of unit. The unit may be installed either inside the UE or attached to the UE with a connector or even wirelessly.

In an embodiment the apparatus 900 is or is comprised in the source 200. In an embodiment, the apparatus 920 is or is comprised in the destination device 202, 204, or 206.

As said, the apparatuses 900, 920 may comprise a control circuitry 902, 922, respectively, e.g. a chip, a processor, a micro controller, or a combination of such circuitries causing the apparatus to perform any of the embodiments of the invention. The control circuitry may be implemented with a separate digital signal processor provided with suitable software embedded on a computer readable medium, or with a separate logic circuit, such as an application specific integrated circuit (ASIC). The control circuitry X may comprise an interface, such as computer port, for providing communication capabilities. The memory 904, 924 may store software (PROG) executable by the at least one control circuitry 902, 922, respectively.

The control circuitry 902 of the apparatus 900 (e.g. the source) may comprise a multicast/broadcast circuitry 910 responsible of causing the multicast/broadcast of at least one data unit to the DDs according to any of the embodiments. The circuitry 910 may also take care of adaptation of the transmission characteristics according to any of the embodiment. The control circuitry 902 may also comprise a feedback managing circuitry 912 for determining, for example, the order in which the feedbacks are to be received. The circuitry 912 may also select the function to be applied by the DDs, for example.

The control circuitry 922 of the apparatus 920 (e.g. the destination device) may comprise a progress determination circuitry 930 for determining the progress corresponding to the destination device. A feedback managing circuitry 932 may be responsible of detecting or determining a point of time for transmitting the feedback to the source 200 and the generation of the feedback, for example.

The apparatuses 900, 920 may further comprise radio interface components (TRX) 906, 926 providing the apparatus with radio communication capabilities with the radio access network. The radio interface components may comprise standard well-known components such as amplifier, filter, frequency-converter, (de)modulator, and encoder/decoder circuitries and one or more antennas.

The apparatus 900, 920 may also comprise a user interface 908, 928 comprising, for example, at least one keypad, a microphone, a touch display, a display, a speaker, etc. The user interface may be used to control the corresponding apparatus by the user.

As said, the apparatus 900, 920 may comprise the memory 904, 924 connected to the corresponding control circuitry. However, memory may also be integrated to the control circuitry and, thus, no memory 904, 924 may be required. The memory may be implemented using any suitable data storage technology, such as semiconductor based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The memory 904 may be for storing data related to applicable functions and identifiers of the multicast group members, for example. The memory 924 may be for storing data related to applicable functions, for example.

As used in this application, the term 'circuitry' refers to all of the following: (a) hardware-only circuit implementations, such as implementations in only analog and/or digital circuitry, and (b) combinations of circuits and software (and/or firmware), such as (as applicable): (i) a combination of processor(s) or (ii) portions of processor(s)/software including digital signal processor(s), software, and memory(ies) that work together to cause an apparatus to perform various functions, and (c) circuits, such as a microprocessor(s) or a portion of a microprocessor(s), that require software or firmware for operation, even if the software or firmware is not physically present. This definition of 'circuitry' applies to all uses of this term in this application. As a further example, as used in this application, the term 'circuitry' would also cover an implementation of merely a processor (or multiple processors) or a portion of a processor and its (or their) accompanying software and/or firmware. The term 'circuitry' would also cover, for example and if applicable to the particular element, a baseband integrated circuit or applications processor integrated circuit for a mobile phone or a similar integrated circuit in a server, a cellular network device, or another network device. The techniques and methods described herein may be implemented by various means. For example, these techniques may be implemented in hardware (one or more devices), firmware (one or more devices), software (one or more modules), or combinations thereof. For a hardware implementation, the apparatus(es) of embodiments may be implemented within one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, micro-controllers, microprocessors, other electronic units designed to perform the functions described herein, or a combination thereof. For firmware or software, the implementation can be carried out through modules of at least one chip set (e.g. procedures, functions, and so on) that perform the functions described herein. The software codes may be stored in a memory unit and executed by processors. The memory unit may be implemented within the processor or externally to the processor. In the latter case, it can be communicatively coupled to the processor via various means, as is known in the art. Additionally, the components of the systems described herein may be rearranged and/or complemented by additional components in order to facilitate the achievements of the various aspects, etc., described with regard thereto, and they are not limited to the precise configurations set forth in the given figures, as will be appreciated by one skilled in the art.

Thus, according to an embodiment, the apparatus comprises processing means configure to carry out embodiments of any of the Figures 1 to 9B. In an embodiment, the at least one processor 902, the memory 904, and the computer program code form an embodiment of processing means for carrying out the embodiments of the invention. In an embodiment, the at least one processor 922, the memory 924, and the computer program code form an embodiment of processing means for carrying out the embodiments of the invention.

Embodiments as described may also be carried out in the form of a computer process defined by a computer program. The computer program may be in source code form, object code form, or in some intermediate form, and it may be stored in some sort of carrier, which may be any entity or device capable of carrying the program. For example, the computer program may be stored on a computer program distribution medium readable by a computer or a processor. The computer program medium may be, for example but not limited to, a record medium, computer memory, read-only memory, electrical carrier signal, telecommunications signal, and software distribution package, for example.

Even though the invention has been described above with reference to an example according to the accompanying drawings, it is clear that the invention is not restricted thereto but can be modified in several ways within the scope of the appended claims. Therefore, all words and expressions should be interpreted broadly and they are intended to illustrate, not to restrict, the embodiment. It will be obvious to a person skilled in the art that, as technology advances, the inventive concept can be implemented in various ways. Further, it is clear to a person skilled in the art that the described embodiments may, but are not required to, be combined with other embodiments in various ways.