Re-transmission of a transmitted concatenation packet by a sending device, especially a base station device or a terminal device of a telecommunication network

A base station, a terminal device, a network and a method for re-transmission of a transmitted original concatenation packet by a sending device station, especially a base station device or a terminal device of a telecommunication network, especially a cellular telecommunication network, wherein an original concatenation packet includes several sub-packets, wherein re-transmission of a full or partial concatenation packet by a base station or terminal sending device to at least one receiving terminal device is done after the sending device receiving a transmission failure indicating signal representing at least one failed transmission of an original concatenation packet to at least one receiving terminal device, wherein the sending device decides on re-transmission modes representing how to transmit a re-transmission concatenation packet, based on re-transmission criteria.

BACKGROUND

The invention relates to a base station, a terminal and a method for re-transmission of a transmitted original concatenation packet by a sending device, especially a base station device or a terminal device of a telecommunication network, especially a cellular telecommunication network.

Telecommunication networks and devices for of packet re-transmission for different applications/scenarios are e.g. known from:

BRIEF SUMMARY

An object of the invention is to allow improved re-transmission in a telecommunication network, especially cellular telecommunication network by addressing a new BS behavior with metrics of re-transmission criteria for concatenation packets. This object is respectively achieved by the teaching of the independent patent claims.

Embodiments of the invention allow an improved concatenation packet re-transmission handling especially in a cellular telecommunication network, The dependent patent claims describe some advantageous embodiments of the invention.

DETAILED DESCRIPTION

Regarding “concatenation” packets and transmissions, a concatenated transmission of concatenation packets is e.g. known from 3GPP, e.g. 3.2.1 or 3.2.2, definitions and examples of concatenation can be found there online. A “concatenated” transmission of concatenation packets can e.g. comprise sending in respectively one of the so called concatenation packets (of a concatenation transmission) sub-packets intended for different user terminal devices (e.g. mobile phones, smartphones, metering device, car TCUs, wearables, modules etc).

A concatenated transmission of concatenation packets can e.g. used for a ultra-reliable (which can e.g. also mean high QoS required) and/or a low-latency communication etc.

For DL (downlink; base station to terminal equipment) transmissions, multiple packets intended for a group of UEs can be concatenated as well as single UE based multi-packet concatenation.

Ultra-reliable and low-latency communication (URLLC) (i.e. e.g. communication with low latency budget and/or allowing few latency) is one of key service areas introduced in 5G along with other major ones such as enhanced mobile broadband (eMBB) and machine-type communication (MTC).

To reduce latency, short packet size has been introduced for URLLC since support of URLLC services needs the stringent requirement for high reliability and/or low latency. However, it could cause a few critical problems such as high signaling traffic overhead, reliability performance degradation, and inefficient radio resource use due to short packet transmissions.

Therefore, packet concatenation concept has been introduced to improve those problems for URLLC.

Packet concatenation also provides another challenging problem about how to re-transmit (meaning especially here: re-send) a concatenation packet (that was already unsuccessfully sent at least once) efficiently when any packet reception fails on receiver side.

When one single or several (multiple) terminal devices UE1, UE2, . . . , UEk receive a concatenation packet, there is a possibility that it cannot be decoded successfully (i.e. e.g. it cannot be received successfully due to e.g. bad air interface connection etc.) by at least one or several of the receiving terminal devices UE1, UE2, . . . , UEk.

In such case, the terminal device(s) UE1, UE2, . . . , UEk or HARQ can send or need(s) to send a request for re-transmission of the packet (and/or sub packets) in e.g. a message e.g. representing a failed receipt (non-acknowledgement) known as NACK to e.g. a base station BS, gNB (and/or a sending UE if the concatenation packet is from that UE). Or alternatively if a positive receipt confirmation ACK is expected according to a protocol etc, it sends no ACK to a base station gNB which detects the missing ACK and thus detects a transmission failure.

Requests for re-transmissions as such (of not successfully received packets, i.e. not decoded packets), e.g. in HARQ procedures or otherwise, are known to the expert, e.g. from 3GPP where details can be found online with those search terms online.

FIG. 1 shows a so called concatenated transmission (indicated by an arrow) of a concatenated packet 1 containing several sub-packets 11, 12, 13 etc from a base station device BS (in the following also as a simplification named a gNB) over a telecommunication network, especially cellular network (as e.g. 2G, 3G, 4G, 5G, 6G), to at least one, here a group of terminal devices UE1, UE2, . . . , UEk.

In the concatenated packet 1 in FIG. 1, at least one sub-packet 11 is (meant) for a terminal device UE1 (whereas all other UEs can ignore it), at least one sub-packet 12 is for terminal device UE2 (whereas all other UEs can ignore it), and at least one sub-packet 13 is for terminal device UE3 (whereas all other UEs can ignore it).

One or several of the terminal devices UE1, UE2, . . . , UEk can inform the base station device BS with a signaled message NACK that a packet or at least one sub-packet 12 was not successfully received.

In the concatenated packet 1 in FIG. 1, at least one sub-packet 11 is for terminal device UE1 (whereas all other UEs can ignore 11), at least one sub-packet 12 is for terminal device UE2 (whereas all other UEs can ignore 12), and at least one sub-packet 13 is for terminal device UE3 (whereas all other UEs can ignore 13).

In the concatenated packet 2 in FIG. 2, at least one sub-packet 21 is for terminal device UE1 (whereas all other UEs can ignore 21), at least one sub-packet 22 is for terminal device UE2 (whereas all other UEs can ignore 22), and at least one sub-packet 23 is for terminal device UE3 (whereas all other UEs can ignore 23).

In the concatenated packet 3 in FIG. 2, at least one sub-packet 31 is for terminal device UE1 (whereas all other UEs can ignore 31), at least one sub-packet 32 is for terminal device UE2 (whereas all other UEs can ignore 32), and at least one sub-packet 33 is for terminal device UE3 (whereas all other UEs can ignore 33).

Here transmission of a sub-packet 22 to one of the terminal devices UE2 fails, i.e. it is not successfully received (=decoded), indicated by a cross in sub-packet 22.

Moreover, here transmission of a sub-packet 13 to one of the terminal devices UE1 fails, i.e. it is not successfully received (=decoded), indicated by a cross in sub-packet 13.

One or several of the terminal devices UEs can inform the base station device BS with a signaled message NACK (or by not sending an expected Ack) that a sub-packet 22, 13 for that terminal devices UE2, UE3 was not successfully received by it.

The base station device BS or a terminal device UE1, UE2, . . . , UEk can then re-transmit (send again) one or more (full or partial) concatenated packets 1, 2 containing a failed sub-packet 13, 22 to all UEs for which the original concatenated packet transmission is intended.

In packet concatenation transmission, re-transmission signaling (e.g. HARQ re-transmission signaling) can be heavily loaded if concatenated packet re-transmission requests are high or too numerous among or from different UEs whose sub-packets 11-13, 21-23, 31-33 e.g. can be concatenated with others (i.e. e.g. transmitted (transmitted meaning especially sent) in the same concatenation packets).

If a base station BS, gNB re-transmits a whole concatenated packet (e.g. 1, 2, 3) to all UEs UE1, UE2, . . . , UEk, for those UE that have had a decoding failure (not received/decoded packets or sub-packets), a significant radio resource waste could be problematic and re-transmission signaling traffic between gNB and UEs could be quite heavily loaded depending on link quality conditions.

Therefore, in the following some embodiments of gNB/UE behaviors will be proposed for concatenated packet re-transmission(s), so that radio resource waste and re-transmission signaling traffic can be improved.

After a re-transmission one or more than one re-retransmissions are possible, i.e. e.g. re-transmitting packets or sub-packets more than one time, e.g. for higher or ultra-high transmission reliability or due to further (re-) transmission errors or NACKs (or missing ACKs).

Embodiments of the invention may comprise key ideas as one or more of:

A device (as a base station gNB, BS or a terminal equipment UE1, UE2, . . . , UEk) can be configured to trigger a re-transmission of an already transmitted original concatenation packet 1; 2; 3, (i.e. triggering a transmission of a re-transmission concatenation packet 5; 6; 7; 8):

FIG. 3 shows a so called concatenated transmission (indicated by an arrow) of a concatenated packet 1 containing several sub-packets 11, 12, 13 etc from a base station device BS, gNB to a group of terminal devices UE1, UE2, . . . , UEk as in FIG. 1, over a base station-terminal equipment interface Uu (e.g. downlink DL transmission for URLLC application based data packets).

Here after a failed transmission of (only or at least) a sub-packet 12 to UE2, at least one of the (group) terminal devices UE1 (which received the sub-packet 12, that the UE2 did not receive but should get) re-transmits the full or part (e.g. only the failed sub-packet 12) concatenated packet 1 to one or more (group) terminal devices UE2, . . . , UEk, here over a (data and/or signaling) link called PC5 and/or called sidelink.

Here at least more than one UE in the downlink cluster can reach each other using a sidelink, e.g. here at least one UE1 of (group) terminal devices UE1, UE2, . . . , UEk can reach one or several or all (group) terminal devices UEs for data packet (and/or signaling) transmission, which is called sidelink transmission (as it is not via a base station but e.g. directly UE1 to UE2, . . . , UEk).

Target UE packets for concatenation can be selected based on packet concatenation scheduling in a base station BS, gNB. E.g. HARQ for any undecoded (e.g. not successfully received) concatenation packet can be supported and re-transmission mechanism can e.g. be based on gNB behavior criteria.

According to some embodiments of the invention, new base station device gNB and/or terminal device UE1-k behaviors can be proposed where concatenation packets can be associated with one of the following metrics for re-transmission criteria: UE priority (priority level, e.g. high or low priority or in between; e.g. high priority for streaming low priority for less urgent data and/or high priority for police and/or users with high priority contract etc) 201, UE latency budget, base station (BS/gNB overload status (e.g. how much re-transmission load/overload the base station has), and more according to target concatenation packet QoS profile category, and generally network conditions and/or base station conditions and or terminal device conditions and/or air interface conditions.

A re-transmission method can then be determined based on a base station BS, gNB (e.g. base station controller) re-transmission policy.

Potential key advantages with this idea can especially e.g. include one or more of:

A proposed embodiment is e.g. based on work scope of one or two aspects as:

A possible main idea for this solution can be focused on a base station gNB behavior with re-transmission criteria, e.g. when HARQ is needed FIG. 14 shows (simplified) some embodiments of a so called concatenated transmission (indicated respectively by a flash) of at least one concatenated packet 1, 2, 3 (and as well of retransmitted concatenation packets) respectively containing one or several sub-packets 11, 12, 13 etc,

In FIG. 4, a (simplified) flow chart shows an example of an inventive embodiment of a base station BS, gNB and or terminal behavior for different concatenation packet re-transmission types and/or re-transmission modes.

A new gNB behavior, especially a selected re-transmission mode, is proposed as an embodiment of the invention, where e.g. concatenation packets 1, 2, 3 (and/or the sub-packets 1-13, 21-23, 31-33) are associated with (and/or evaluated under) one of the (e.g. in a step S1 earlier and/or generally generated/defined) metric for re-transmission criteria, which here especially are one or more of UE priority (priority level, e.g. high or low or between) 201, UE latency budget, gNB overload status, and more according to target concatenation packet QoS profile category.

E.g. regarding a suggested new BS, gNB behavior, in case of a re-transmission request (in a step S2) concerning a (unsuccessfully) transmitted concatenation packet 1, and in case of UE with a high(er) priority (priority level, e.g. high or low or between) 201 and/or with a high(er) latency requirement, a base station BS, gNB and/or terminal can (as in FIG. 7, for a group UE1, UE2, . . . , UEk or to a single UE1) re-transmit the whole (originally sent) concatenation packet 1 as a full re-transmitted concatenation packet 6 (with same sub-packets 61=11, 62 =12, 63=13), e.g. in order to avoid delay in re-transmission.

E.g. in case of a low(er) priority (201) UE, a base station BS, gNB can (after unsuccessful transmission of originally transmitted concatenation packet 1) transmit a UE specific (e.g. partial) re-transmitted packet (5 or 7 in FIG. 8, 9), e.g. comprising only one or some sub-packets 52 (identical to 12), 53 (identical to 13) of the originally sent packet 1 (as explained in more detail for FIG. 8)—with (5) or without (7) additional sub-packets (sub-packets 54, 55 transmitted now the first time and added to re-transmitted sub-packets 52 (=12), 53 (=13) in a packet 5).

If (as here) a gNB MAC layer doesn't buffer UE specific (sub-)packets, it can take re-transmission (sub-)packets from the RLC buffer (in a step S2) of the network or base station. To receive such (sub-)packet(s), e.g. MAC provides an indication to RLC.

On the other hand, if a base station BS, gNB is (fully, i.e. e.g. but not only, too overloaded to retransmit full packets in all cases etc) overloaded, then it e.g. will re-transmit to a UE with a transmitted UE specific (e.g. partial) packet. For example, overload indication can be specified as one bit use for overload status such that gNB is fully or not overloaded.

A base station's BS, gNB overload status can be broadcast through a system information message and a terminal device UE can expect a UE specific (re-transmission) packet from a (first/originally transmitted) full concatenation packet if bit 0 in system information (from a base station BS) is received (at the terminal device UE).

FIG. 5 shows a table of a base station BS, gNB and/or terminal behavior

policy, which provides concatenation packet re-transmission modes for different implementation scenarios.

In the table in FIG. 5, for each re-transmission mode, a re-transmission operation is defined by one or a combination of at least two or a combination of three alternatives of the following three modes:

Also different combinations of re-transmission mode selection are offered for different concatenation packet profile indexes with key metrics such as UE priority (priority level, e.g. high or low or between) 201 and gNB overload status level. Priority (priority level, e.g. high or low or between) 201 level as key metric e.g. reflects specific applications QoS profile for packet data characteristics (e.g., 5QI-5G QoS Identifier). Key metrics for a re-transmission mode selection can be flexibly configured e.g. according to applications QoS requirements. Re-transmission mode selection options can also be re-configurable based on prioritized selection and mode 2 for radio access re-transmission schemes (i.e., mTRP, duplication) can be selectively combined with mode 1 and mode 3 selections.

A re-transmission mode selection (of here only Mode 1 and Mode 3, possibly combined with Mode 2) can e.g. be based on a re-transmission mode operation table as e.g. the table in FIG. 6.

In FIG. 6 the table indicates an example of combination of re-transmission mode selection according to e.g. a concatenation packet profile index

A concatenation packet profile index CPP #1 can e.g. be set by a base station or other mobile network entity.

Re-transmission mode selection for modes 1 and 3 here is based on re-transmission mode operation table.

Re-transmission mode selection options can be also re-configurable based on prioritized selection.

For a re-transmission mode, Mode 2 (e.g. either mode 2-1 or mode 2-2 of FIG. 5) for radio access re-transmission schemes (e.g. mTRP or duplication) can be selectively combined with mode 1 and mode 3 selections chosen as e.g. in the table in FIG. 6.

So to choose a transmission mode, e.g. Mode 1 and 3 can be chosen as in FIG. 6 and Mode 2 can be chosen as additionally desired or possible in the network.

In FIG. 6, e.g. in case of a (e.g. UE and/or BS, gN, gMB detected) a concatenation packet profile index CPP #1 representing

In FIG. 6, e.g. in case of a (e.g. UE and/or BS, gN, gMB detected and/or in concatenation packet context or concatenation packet signaling or concatenation packets) a concatenation packet profile index CPP #2 representing

In FIG. 6, e.g. in case of a (e.g. UE and/or BS, gN, gMB detected) a concatenation packet profile index CPP #3 representing

In FIG. 6, e.g. in case of a (e.g. UE and/or BS, gN, gMB detected) a concatenation packet profile index CPP #4 representing

FIG. 10 shows details of an embodiment of a re-transmission in a groupcast of one or more concatenation packets:

Initially, a base station BS, gNB schedules for a downlink DL a concatenation packet transmission for a group and/or set of UEs (UE1, UE2, . . . , UEk).

A subset of terminal devices UE (UE1, UE2, . . . , UEk) for one or more DL (downlink) concatenation packet(s) 1, 6, are candidate UEs for a sidelink groupcast, especially in a re-transmission.

For a sidelink groupcast signaling of re-transmission (of 7), a base station BS, gNB receives (receipt strength/quality/error rate etc) measurement reports from terminal devices UE1, UE2, . . . . UEk, and it determines to use for a re-transmission case a sidelink groupcast and/or to use for a re-transmission case a re-transmission to be sent from one (or at least two) of the terminal devices UE1, UE2, . . . . UEk, e.g. from the one (UE) with the best measurement report-i.e. in case of a necessary re-transmission case terminal device UE shall send (as a sidelink) to other terminal devices UEs for the re-transmission packets.

A sidelink (=UE to UE instead of BS to UE) groupcast based re-transmission can be prioritized by default when it is available. Otherwise, gNB based re-transmission is chosen.

For the representing (re-transmitting) terminal device Uk (=“TX UE”=aka “RepUE”) in a sidelink groupcast, a base station BS, gNB e.g. initially assigns it to support (e.g. sidelink) re-transmissions for other groupcast terminal devices UE1, UE2, . . . in case that there is any UE that reports NACK feedback to the “RepUE” terminal device (e.g. Uk).

The representing (re-transmitting) terminal device Uk (aka “RepUE”) for a sidelink groupcast is initially determined by a base station BS, gNB e.g. based on DL (won link) link quality condition (e.g., UE with best CQI among UEs).

The representing (re-transmitting) terminal device Uk (aka “RepUE”) can be re-assigned to other terminal devices UE1, UE2, . . . in sidelink groupcast after initial setup based on sidelink feedback and a RepUE candidate list information transmission.

FIG. 11 shows details of an embodiment of signaling for a re-transmission in a cast or groupcast of one or more concatenation packets especially via a sideliink.

E.g. in a phase #1 (with communication between a base station BS and terminal devices UE (UE1, UE2, . . . , UEk)), a base station BS sends to terminal devices UE (UE1, UE2, . . . , UEk) RRC connection setup signaling information.

a base station BS UE capability information report representing capabilities of several terminal devices UE (UE1, UE2, . . . , UEk).

The base station BS starts a DL (downlink) concatenation packets transmission to terminal devices UE (UE1, UE2, . . . , UEk), i.e. the base station BS transmits via a downlink concatenation packet to terminal devices UE (UE1, UE2, . . . , UEk).

The representing terminal device RepUE (e.g. former Uk) determines whether the current terminal device RepUE (is kept as RepUE or whether a further terminal device is used/switched for another re-transmission. A representing terminal device RepUE (e.g. former Uk) transmits to sidelink UEs (=further terminal devices UE (UE1, UE2, . . . , UEk)) Groupcast RepUE update information via e.g. a PSSCH channel.

A representing terminal device RepUE (e.g. former Uk) transmits to a base station BS Sidelink Feedback information update via e.g. a PUCCH channel.

Generally it is also possible to (at a receiving terminal device) combine a sub-packet (or a packet) from sub-packets (or packets) fragments (parts/bits/bytes) each only partially decoded/received in two or more transmissions/re-transmissions, e.g. if two times at least one same sub-packet (or packet) is transmitted more than one time. E.g. sub-packets and whole packets 1, 6 (10) are fully re-transmitted in FIG. 7,10.

E.g. sub-packets 51, 52 or 71, 72 are re-transmitted in FIG. 8 or 9. Combining of sub-packets or packets can e.g. be done be soft combining, e.g. by FIR or PIR or CC as already standardized in 3GPP for LTE, or otherwise.

FIG. 12 shows an embodiment of steps S11-S18 of a re-transmission in a groupcast (of originally a base station to more than one i.e. a group of terminal devices), representing what FIG. 11 also shows.

Sidelink groupcast UEs are served for re-transmission of concatenation packet by RepUE that is initially assigned by gNB based on link quality condition.

After groupcast re-transmission to sidelink UEs, a representing terminal device RepUE is determined to be kept or switched to other UE based on sidelink feedback and RepUE candidate list information.

When a representing terminal device RepUE is switched to other UE in groupcast re-transmission, re-transmission mode selection is updated for further re-transmissions.

One or more specific threshold values can be configured such as

Some preferred main embodiments can also e.g. be as follows.

E.g. a new RNTI is proposed to be added for sidelink groupcast based concatenation packet and it is defined as SCG-RNTI (Sidelink Concatenation Groupcast RNTI).

It is a unique identifier used for identifying sidelink groupcast terminal devices UEs served for concatenation packet transmission and reception. A base station (node) BS, gNB can assign SCG-RNTI values to each terminal device UEs or to those that belong to a sidelink groupcast of a concatenation packet 1.

E.g. initially, a base station gNB schedules DL concatenation packet transmission for a set of terminal devices UEs. A subset of terminal devices UEs for a DL concatenation packet can be candidate terminal devices UEs for at least one sidelink groupcast.

For sidelink groupcast signaling, a base station gNB receives measurement reports from terminal devices UEs and determines sidelink groupcast terminal devices UEs for a re-transmission case. Sidelink groupcast based re-transmission can be prioritized by default when it is available.

Otherwise, a base station gNB based re-transmission is chosen. For a sending terminal device (aka TX UE, especially aka RepUE) in a sidelink groupcast, a base station gNB initially assigns it to support re-transmissions for other groupcast terminal devices UEs in case that there is any terminal device UE(s) that report e.g. a NACK feedback to the terminal device RepUE that for sidelink groupcast is initially determined by base station gNB based on DL link quality condition (e.g., best CQI among UEs).

A terminal devices RepUE can be re-assigned to other terminal devices UE in a sidelink groupcast after initial setup based on sidelink feedback and a terminal devices RepUE candidate list information can be configured by a base station gNB. A block diagram for a DL concatenation packet transmission for a set of terminal devices UEs in sidelink groupcast is described as in FIG. 11.

As FIG. 11 shows, the signaling flows for the proposed concatenation packet transmission for a set of terminal devices UEs in a sidelink groupcast are shown in two phases as follows.

For a Phase 1, a base station gNB and a set of terminal devices (receiving=RX) Rx UEs are formed or determined to transmit a concatenation packet with determination of a sidelink groupcast use. During this phase, a terminal devices RepUE candidate list is also provided to sidelink groupcast UEs terminal devices, so that a terminal devices RepUE role can be transferred to one of UEs in the groupcast.

For a Phase 2, concatenation packet re-transmission is signaled between (representing and or retransmitting) terminal device(s) RepUE and (Rx=receiving re-transmission(s)) terminal devices Rx UEs. During this phase, sidelink feedback transmissions are used for a RepUE change and sidelink feedback information is also updated to the base station gNB.

E.g. sidelink groupcast terminal devices UEs are served for re-transmission of concatenation packet by a terminal device RepUE that is initially assigned by a base station gNB based on channel link quality condition. After groupcast re-transmission to sidelink (receiving) terminal devices UEs, a (representing) terminal device RepUE is determined to be kept or switched to other terminal devices UE based on sidelink feedback(s) and a RepUE candidate list information configured by a base station gNB. When a terminal devices RepUE is switched to other terminal devices UE in groupcast re-transmission, re-transmission mode selection is updated for further re-transmissions. A specific threshold values can be configured such as:

The flow chart for an embodiment of a RepUE assignment and of a sidelink groupcast re-transmission is shown in FIG. 11.

E.g. a sidelink groupcast RepUE change process is described as follows. First, a list of Rx terminal devices UEs for concatenation packet reception in sidelink groupcast is defined as {UE1, UE2, . . . , UEK}.

Sidelink groupcast terminal devices RepUE candidates are also set as {UEa, UEb, UEc, . . . } from a list of Rx UEs.

The number of terminal devices RepUE candidates is pre-configured by the base station gNB and RepUE selection is based on e.g. link quality feedback information.

Each step of sidelink groupcast RepUE change is e.g. processed as follows:

Criteria of RepUE change is based on key configuration parameter set such as

To reduce RepUE terminal devices change process complexity, an alternative approach is also proposed. For a downlink DL concatenation packet, all Rx UEs can be RepUE candidates and RepUE can be autonomously changed to next RepUE candidate when a NACK feedback is received in a sidelink groupcast mode.

Therefore, every Rx UE can then be rotated to be RepUE and NACK feedback transmission to RepUE among Rx UEs triggers RepUE change. The order of a RepUE candidate list can be pre-configured by a base station gNB based on link quality condition comparison between each Rx UE and gNB. The flow chart for this operation about reducing RepUE change process complexity is shown as in FIG. 13

Since sidelink groupcast configurations can vary for concatenation packet re-transmission scenarios, a base station gNB can schedule a concatenation packet with multiple sub-packets for

How to schedule a concatenation packet for the above scenarios depends on base station gNB implementation and this should be flexibly configurable based on concatenation packet criteria. However, the proposed re-transmission modes for concatenation packet re-transmission can be applied to all different scenarios. In case of multiple clustered terminal devices UE groups, different terminal devices UE clusters can exchange concatenation packet re-transmissions as well.

(In FIG. 14 the diagrams show the three different scenarios for concatenation packet transmission as described above.)

Also, based on the above three different concatenation packet transmission scenarios, a high-level concatenation packet format is described below for each scenarios.

FIG. 15 shows some exemplary structure of concatenation packets for single UE, multiple UEs and multiple UE cluster concatenation packet transmission/re-transmission as in FIG. 14,

In FIG. 15 on top a single terminal equipment (UE) concatenation packet only comprises sub-packets 11, 12, 13 intended for one single terminal equipment UE1.

In FIG. 15 in the middle a multiple terminal equipment (UE) concatenation packet comprises sub-packets 11, 12, 21, 31 intended more than one single terminal equipment (UE), i.e. e.g. a group of terminal equipments UE1, UE2, . . . , UEk.

In FIG. 15 at the bottom a multiple cluster terminal equipment (UE) concatenation packet comprises sub-packets 11, 12, 13, 21, 31 intended for more than one cluster of single terminal equipments (UE), i.e. e.g. for at least two groups 9, 10, 19 of terminal equipments UE1, UE2, . . . , UEk.

REFERENCE SIGNS