2.1. System Model of DTDBC-RC
Considering a delay-constrained transmission application with two sources (denoted by
and
) exchanging information with the aid of a relay (denoted by
R), one-round information exchange with maximum allowable transmission time
T consists of at most three time slots and each source’s message is transmitted for at most two time slots (i.e., one time slot for its own transmission and the other for the relay). The first and second time slots are with maximum allowable transmission time
, and the third time slot is with minimum transmission time
, where
if retransmission at the third time slot is possible. The message is transmitted in the form of codeword. For simplicity of analysis and without loss of generality, it is assumed that both sources transmit with the same rate and the same power (When the scenario with different data rates and/or different power is considered, the transmission lengths of each time slot in DTDBC-RC are different although with channel reciprocity assumption (see the system model in
Section 2). This is a general scenario which can be extended directly from the simple scenario with same data rates and same power in the paper. Moreover, the performance analysis in
Section 3 can be directly applied to the general scenario. Since the simple scenario captures the essence of utilizing the dynamics of the direct link transmission by rateless coding, we do not consider the general scenario here.). The channels keep unchanged in one-round information exchange and changes independently across different rounds. Moreover, the channels between any two nodes are assumed to be reciprocal.
The codeword lengths of and corresponding to the two-time-slot transmission are denoted by and , i.e., the transmitted codewords of and are denoted by and , respectively. The proposed DTDBC-RC protocol works in the following way.
In the first time slot (with given maximum allowable transmission time ), broadcasts its first part of codeword (i.e., ) continuously to and R in the rateless coding way. decodes the received message before or until . If decodes successfully, it feeds back one-bit acknowledgement (ACK). If cannot decode successfully until , it feeds back one-bit non-acknowledgement (NACK). In the second time slot (also with given maximum allowable transmission time ), works in the same way as in the first time slot, i.e., it broadcasts the first part of codeword (i.e., ) continuously to and R in the rateless coding way. Due to channel reciprocity, has the same decoding results as , and it feeds back NACK or ACK accordingly.
After the first two time slots, the following working process of DTDBC-RC depends on the decoding results of both and , and there are only two decoding states listed as follows.
State 1: both and cannot decode successfully. In this state, depending on the decoding result at
R, there are two cases. In
Case I,
R successfully decodes the messages from both
and
. It feeds backs an ACK to both
and
, re-encodes the received message from both sources and network-encodes the two sources’ message before retransmission (e.g., through bit-level XOR operation), and retransmits the network-encoded message to both
and
in the third time slot (i.e., until the transmission length
T is reached). In this case,
(
) decodes
’s (
’s) message by combining the message received from both
(
) in the first time slot and from
R in the third time slot. In
Case II, at least one source’s message (
or
) cannot be decoded successfully at
R. In this case,
R feeds back a NACK and there is no retransmission occurred at
,
, or
R. Thus, an outage event occurs and
and
begin a new round of information exchange as described above (In TWRC, outage probability is usually defined for the whole system, not for any single source (see [
2,
3] and the references therein). In the paper, we also define the system outage probability. Therefore, if
R cannot decode successfully any source’s message, there is no improvement in system outage probability if
or
retransmits in the third time slot. Thus, there is no need to assume retransmission in the third time slot if at least one source’s message cannot be decoded successfully at
R.).
State 2: both and decode successfully. In this state, and feed back ACKs to each other and begin a new round of information exchange, as described above.
The above two states are depicted in
Figure 1, where
is the transmission length of the first and second time slots (it will be calculated in
Section 3) due to the channel reciprocity assumption.
Note that (i) the one-bit ACK/NACK feedback is assumed to be received without delay or error, e.g., through a dedicated control channel; (ii) in one-round information exchange of DTDBC-RC, there are at most three time slots and two time slots for the whole system and for each source, respectively. Moreover, the transmission lengths of the first and second time slots are random depending on the channel quality of the direct link because the sources transmit in rateless coding way. Therefore, the transmission length of one-round information exchange is
when both
and
succeed in the first and second time slots (corresponding to State 2) or when
R cannot decode successfully at least one source’s message (corresponding to
Case II in State 1), or is
T when both
and
cannot decode successfully in the first and second time slots and
R successfully decodes both sources’ messages (corresponding to
Case I in State 1); and (iii) we extend the equal-length time slot assumption in [
7,
8] to the case with unequal-length time slot in the paper (see
Figure 1), i.e., both the first and second time slots are with length
in TDBC-IR like DTDBC-RC (The protocol in [
7,
8] corresponds to the case when
for TDBC-IR in the paper.). Thus, the outage probability, expected rate, and DMT analysis for TDBC-IR in
Section 3 is for the unequal-time length case.
2.2. System Model of Sub-DTDBC-RC
With the same assumptions as in DTDBC-RC, we present a subslot implementation scheme for DTDBC-RC (i.e., sub-DTDBC-RC) since its DMT cannot be derived directly based on conventional outage and expected rate analysis (this will be detailed in
Section 3). In sub-DTDBC-RC, the maximum allowable transmission time
at the first and second time slots is divided into
N equal-length subslots, each with length
. The sub-DTDBC-RC works in the same way as DTDBC-RC, with the exception that
(
) only decodes at one subslot before or at
in the former (i.e., at the
n-th subslot, where
), whereas it decodes at any time before or at
for the latter. The working process of sub-DTDBC-RC is shown in
Figure 2.
With the above description, it is intuitively and readily seen that when , the sub-DTDBC-RC becomes DTDBC-RC.
Remark 1: We note that the authors in [
11] proposed a similar protocol as TDBC. Their protocol works in the same way as TDBC protocol with direct link, but
,
, and
R transmit in the rateless coding way, where there are always three time slots and the lengths of three time slots are all random depending on the channels of direct and relaying links. The major differences between DTDBC-RC and the protocol in [
11] are that (i) only
R decodes in the first and second time slots while
and
keep silent (leading to three-time-slot transmission) in the latter, while in the former,
and
decode and
R only retransmits when possible (leading to possible two-time-slot transmission); (ii) DTDBC-RC applies in the delay-constrained scenarios with given maximum allowable transmission time for one round information exchange while the latter applies in the scenarios with no delay-constraint; and (iii) we investigate the performance in terms of outage probability, expected rate, and DMT in the paper, which is more comprehensive than the performance analysis in [
11] (The performance analysis method in
Section 3 can be directly extended to the protocol in [
11], where the two sources transmit with different data rates.).
From the above description, it is also intuitive that DTDBC-RC will be more efficient in throughput than the protocol in [
11]. We also point out that the protocol in [
11] will never have an outage event occurring since no time delay constraint is entailed, therefore its performance is not compared with the protocols presented in this paper.