Patent Description:
3GPP document R2-<NUM> discusses NR multicast DRX, and 3GPP document R2-<NUM> discusses MBS MAC Layer and Group scheduling.

The embodiments of <FIG>, <FIG> and <FIG> as well as their associated text are part of the invention and covered by the claims. All other exemplary embodiments disclosed below are merely explanatory and are not part of this invention.

The exemplary wireless communication systems and devices described below employ a wireless communication system, supporting a broadcast service. Wireless communication systems are widely deployed to provide various types of communication such as voice, data, and so on. These systems may be based on code division multiple access (CDMA), time division multiple access (TDMA), orthogonal frequency division multiple access (OFDMA), <NUM>rd Generation Partnership Project (3GPP) LTE (Long Term Evolution) wireless access, 3GPP LTE-A or LTE-Advanced (Long Term Evolution Advanced), 3GPP2 UMB (Ultra Mobile Broadband), WiMax, 3GPP NR (New Radio) wireless access for <NUM>, or some other modulation techniques.

<FIG> presents a multiple access wireless communication system in accordance with one or more embodiments of the disclosure. An access network <NUM> (AN) includes multiple antenna groups, one including <NUM> and <NUM>, another including <NUM> and <NUM>, and an additional including <NUM> and <NUM>. In <FIG>, only two antennas are shown for each antenna group, however, more or fewer antennas may be utilized for each antenna group. Access terminal <NUM> (AT) is in communication with antennas <NUM> and <NUM>, where antennas <NUM> and <NUM> transmit information to access terminal <NUM> over forward link <NUM> and receive information from access terminal <NUM> over reverse link <NUM>. AT <NUM> is in communication with antennas <NUM> and <NUM>, where antennas <NUM> and <NUM> transmit information to AT <NUM> over forward link <NUM> and receive information from AT <NUM> over reverse link <NUM>. In a frequency-division duplexing (FDD) system, communication links <NUM>, <NUM>, <NUM> and <NUM> may use different frequencies for communication. For example, forward link <NUM> may use a different frequency than that used by reverse link <NUM>.

In the embodiment, antenna groups each may be designed to communicate to access terminals in a sector of the areas covered by access network <NUM>.

In communication over forward links <NUM> and <NUM>, the transmitting antennas of access network <NUM> may utilize beamforming in order to improve the signal-to-noise ratio of forward links for the different access terminals <NUM> and <NUM>. Also, an access network using beamforming to transmit to access terminals scattered randomly through its coverage may normally cause less interference to access terminals in neighboring cells than an access network transmitting through a single antenna to its access terminals.

An access network (AN) may be a fixed station or base station used for communicating with the terminals and may also be referred to as an access point, a Node B, a base station, an enhanced base station, an eNodeB (eNB), a Next Generation NodeB (gNB), or some other terminology. An access terminal (AT) may also be called user equipment (UE), a wireless communication device, terminal, access terminal or some other terminology.

<FIG> presents an embodiment of a transmitter system <NUM> (also known as the access network) and a receiver system <NUM> (also known as access terminal (AT) or user equipment (UE)) in a multiple-input and multiple-output (MIMO) system <NUM>. At the transmitter system <NUM>, traffic data for a number of data streams may be provided from a data source <NUM> to a transmit (TX) data processor <NUM>.

Preferably, each data stream is transmitted over a respective transmit antenna. TX data processor <NUM> formats, codes, and interleaves the traffic data for each data stream based on a particular coding scheme selected for that data stream to provide coded data.

The coded data for each data stream may be multiplexed with pilot data using orthogonal frequency-division multiplexing (OFDM) techniques. The pilot data may typically be a known data pattern that is processed in a known manner and may be used at the receiver system to estimate the channel response. The multiplexed pilot and coded data for each data stream may then be modulated (i.e., symbol mapped) based on a particular modulation scheme (e.g., binary phase shift keying (BPSK), quadrature phase shift keying (QPSK), M-ary phase shift keying (M-PSK), or M-ary quadrature amplitude modulation (M-QAM)) selected for that data stream to provide modulation symbols. The data rate, coding, and/or modulation for each data stream may be determined by instructions performed by processor <NUM>.

The modulation symbols for data streams are then provided to a TX MIMO processor <NUM>, which may further process the modulation symbols (e.g., for OFDM). In certain embodiments, TX MIMO processor <NUM> may apply beamforming weights to the symbols of the data streams and to the antenna from which the symbol is being transmitted.

Each transmitter <NUM> receives and processes a respective symbol stream to provide one or more analog signals, and further conditions (e.g., amplifies, filters, and/or upconverts) the analog signals to provide a modulated signal suitable for transmission over the MIMO channel. NT modulated signals from transmitters 222a through 222t may then be transmitted from NT antennas 224a through 224t, respectively.

At receiver system <NUM>, the transmitted modulated signals are received by NR antennas 252a through 252r and the received signal from each antenna <NUM> may be provided to a respective receiver (RCVR) 254a through 254r. Each receiver <NUM> may condition (e.g., filters, amplifies, and downconverts) a respective received signal, digitize the conditioned signal to provide samples, and/or further process the samples to provide a corresponding "received" symbol stream.

An RX data processor <NUM> then receives and/or processes the NR received symbol streams from NR receivers <NUM> based on a particular receiver processing technique to provide NT "detected" symbol streams. The RX data processor <NUM> may then demodulate, deinterleave, and/or decode each detected symbol stream to recover the traffic data for the data stream. The processing by RX data processor <NUM> may be complementary to that performed by TX MIMO processor <NUM> and TX data processor <NUM> at transmitter system <NUM>.

A processor <NUM> may periodically determine which pre-coding matrix to use (discussed below).

The reverse link message may then be processed by a TX data processor <NUM>, which may also receive traffic data for a number of data streams from a data source <NUM>, modulated by a modulator <NUM>, conditioned by transmitters 254a through 254r, and/or transmitted back to transmitter system <NUM>.

Processor <NUM> may then determine which pre-coding matrix to use for determining the beamforming weights and may then process the extracted message.

<FIG> presents an alternative simplified functional block diagram of a communication device according to one embodiment of the disclosed subject matter. As shown in <FIG>, the communication device <NUM> in a wireless communication system can be utilized for realizing the UEs (or ATs) <NUM> and <NUM> in <FIG> or the base station (or AN) <NUM> in <FIG>, and the wireless communications system may be the LTE system or the NR system. The communication device <NUM> may include an input device <NUM>, an output device <NUM>, a control circuit <NUM>, a central processing unit (CPU) <NUM>, a memory <NUM>, a program code <NUM>, and a transceiver <NUM>. The control circuit <NUM> executes the program code <NUM> in the memory <NUM> through the CPU <NUM>, thereby controlling an operation of the communications device <NUM>. The communications device <NUM> can receive signals input by a user through the input device <NUM>, such as a keyboard or keypad, and can output images and sounds through the output device <NUM>, such as a monitor or speakers. The transceiver <NUM> is used to receive and transmit wireless signals, delivering received signals to the control circuit <NUM>, and outputting signals generated by the control circuit <NUM> wirelessly. The communication device <NUM> in a wireless communication system can also be utilized for realizing the AN <NUM> in <FIG>.

<FIG> is a simplified block diagram of the program code <NUM> shown in <FIG> in accordance with one embodiment of the disclosed subject matter. In this embodiment, the program code <NUM> includes an application layer <NUM>, a Layer <NUM> portion <NUM>, and a Layer <NUM> portion <NUM>, and is coupled to a Layer <NUM> portion <NUM>. The Layer <NUM> portion <NUM> may perform radio resource control. The Layer <NUM> portion <NUM> may perform link control. The Layer <NUM> portion <NUM> may perform and/or implement physical connections.

One or more parts of <NPL>) are quoted below:.

The IE SC-MTCH-InfoList provides the list of ongoing MBMS sessions transmitted via SC-MRB and for each MBMS session, the associated G-RNTI and scheduling information. <IMG>
<IMG>
<IMG>.

One or more parts of <NPL>) are quoted below.

The MAC entity may be configured by RRC with a DRX functionality that controls the UE's PDCCH monitoring activity for the MAC entity's C-RNTI, TPC-PUCCH-RNTI, TPC-PUSCH-RNTI, Semi-Persistent Scheduling C-RNTI (if configured), UL Semi-Persistent Scheduling V-RNTI (if configured), eIMTA-RNTI (if configured), SL-RNTI (if configured), SL-V-RNTI (if configured), CC-RNTI (if configured), SRS-TPC-RNTI (if configured), and AUL C-RNTI (if configured). When in RRC _CONNECTED, if DRX is configured, the MAC entity is allowed to monitor the PDCCH discontinuously using the DRX operation specified in this clause; otherwise the MAC entity monitors the PDCCH continuously. When using DRX operation, the MAC entity shall also monitor PDCCH according to requirements found in other clauses of this specification. RRC controls DRX operation by configuring the timers onDurationTimer, drx-InactivityTimer, drx-RetransmissionTimer (for HARQ processes scheduled using <NUM> TTI, one per DL HARQ process except for the broadcast process), drx-RetransmissionTimerShorttTI (for HARQ processes scheduled using short TTI, one per DL HARQ process), drx-ULRetransmissionTimer (for HARQ processes scheduled using <NUM> TTI, one per asynchronous UL HARQ process), drx-ULRetransmissionTimerShorttTI (for HARQ processes scheduled using short TTI, one per asynchronous UL HARQ process), the longDRX-Cycle, the value of the drxStartOffset and optionally the drxShortCycleTimer and shortDRX-Cycle. A HARQ RTT timer per DL HARQ process (except for the broadcast process) and UL HARQ RTT Timer per asynchronous UL HARQ process is also defined (see clause <NUM>).

When a DRX cycle is configured, the Active Time includes the time while:
[.

Each G-RNTI and, for NB-IoT UEs, BL UEs or UEs in enhanced coverage, each SC-RNTI of the MAC entity may be configured by RRC with a DRX functionality that controls the UE's PDCCH monitoring activity for this G-RNTI and SC-RNTI as specified in TS <NUM> [<NUM>]. When in RRC_IDLE or RRC_CONNECTED, if DRX is configured, the MAC entity is allowed to monitor the PDCCH for this G-RNTI or SC-RNTI discontinuously using the DRX operation specified in this clause; otherwise the MAC entity monitors the PDCCH for this G-RNTI or SC-RNTI continuously. For each G-RNTI or SC-RNTI of the MAC entity, RRC controls its DRX operation by configuring the timers onDurationTimerSCPTM, drx-InactivityTimerSCPTM, the SCPTM-SchedulingCycle and the value of the SCPTM-SchedulingOffset for G-RNTI and for SC-RNTI. The DRX operation specified in this clause is performed independently for each G-RNTI and SC-RNTI and independently from the DRX operation specified in subcaluse <NUM>.

When DRX is configured for a G-RNTI or for SC-RNTI, the Active Time includes the time while:.

When DRX is configured for a G-RNTI or for SC-RNTI as specified in TS <NUM> [<NUM>], the MAC entity shall for each subframe for this G-RNTI or SC-RNTI:.

For the purposes of the present document, the terms and definitions given in TR <NUM> [<NUM>] and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR <NUM> [<NUM>].

DRX group: A group of Serving Cells that is configured by RRC and that have the same DRX Active Time.

The MAC entity may be configured by RRC with a DRX functionality that controls the UE's PDCCH monitoring activity for the MAC entity's C-RNTI, CI-RNTI, CS-RNTI, INT-RNTI, SFI-RNTI, SP-CSI-RNTI, TPC-PUCCH-RNTI, TPC-PUSCH-RNTI, TPC-SRS-RNTI, and AI-RNTI. When using DRX operation, the MAC entity shall also monitor PDCCH according to requirements found in other clauses of this specification. When in RRC_CONNECTED, if DRX is configured, for all the activated Serving Cells, the MAC entity may monitor the PDCCH discontinuously using the DRX operation specified in this clause; otherwise the MAC entity shall monitor the PDCCH as specified in TS <NUM> [<NUM>].

NOTE <NUM>: If Sidelink resource allocation mode <NUM> is configured by RRC, a DRX functionality is not configured.

RRC controls DRX operation by configuring the following parameters:.

Serving Cells of a MAC entity may be configured by RRC in two DRX groups with separate DRX parameters. When RRC does not configure a secondary DRX group, there is only one DRX group and all Serving Cells belong to that one DRX group. When two DRX groups are configured, each Serving Cell is uniquely assigned to either of the two groups. The DRX parameters that are separately configured for each DRX group are: drx-onDurationTimer, drx-InactivityTimer. The DRX parameters that are common to the DRX groups are: drx-SlotOffset, drx-RetransmissionTimerDL, drx-RetransmissionTimerUL, drx-LongCycleStartOffset, drx-ShortCycle (optional), drx-ShortCycleTimer (optional), drx-HARQ-RTT-TimerDL, and drx-HARQ-RTT-TimerUL.

When a DRX cycle is configured, the Active Time for Serving Cells in a DRX group includes the time while:.

When DRX is configured, the MAC entity shall:.

NOTE <NUM>: If a UE multiplexes a CSI configured on PUCCH with other overlapping UCI(s) according to the procedure specified in TS <NUM> [<NUM>] clause <NUM>. <NUM> and this CSI multiplexed with other UCI(s) would be reported on a PUCCH resource outside DRX Active Time of the DRX group in which this PUCCH is configured, it is up to UE implementation whether to report this CSI multiplexed with other UCI(s).

Regardless of whether the MAC entity is monitoring PDCCH or not on the Serving Cells in a DRX group, the MAC entity transmits HARQ feedback, aperiodic CSI on PUSCH, and aperiodic SRS defined in TS <NUM> [<NUM>] on the Serving Cells in the DRX group when such is expected.

The MAC entity needs not to monitor the PDCCH if it is not a complete PDCCH occasion (e.g. the Active Time starts or ends in the middle of a PDCCH occasion).

One or more parts of R2-<NUM> are quoted below. Notably, Figure <NUM>. <NUM>-<NUM> of Section <NUM>. <NUM> of R2-<NUM>, entitled "Downlink Layer <NUM> Architecture for Multicast Session", is reproduced herein as <FIG>. Figure <NUM>. <NUM>-<NUM> of Section <NUM>. <NUM> of R2-<NUM>, entitled "Downlink Layer <NUM> Architecture for Broadcast Session", is reproduced herein as <FIG>.

For the purposes of the present document, the abbreviations given in TR <NUM> [<NUM>], in TS <NUM> [<NUM>] and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR <NUM> [<NUM>] and TS <NUM> [<NUM>].

Editor's Note: General aspects to be covered here.

NR system enables resource efficient delivery of multicast/broadcast services (MBS).

For broadcast communication service, the same service and the same specific content data are provided simultaneously to all UEs in a geographical area (i.e., all UEs in the MBS service area are authorized to receive the data). A broadcast communication service is delivered to the UEs using a broadcast session. A UE can receive a broadcast communication service in RRC_IDLE, RRC_INACTIVE and RRC_CONNECTED state.

For multicast communication service, the same service and the same specific content data are provided simultaneously to a dedicated set of UEs (i.e., not all UEs in the MBS service area are authorized to receive the data). A multicast communication service is delivered to the UEs using a multicast session. A UE can receive a multicast communication service in RRC_CONNECTED state with mechanisms such as PTP and/or PTM delivery, as defined in section <NUM>. HARQ feedback/retransmission can be applied to both PTP and PTM transmission.

Editor's Note: RAN3 to provide architecture aspects here.

Editor's Note: User plane and control plane protocol architecture to be covered here.

Figure <NUM>. <NUM>-1and <NUM>. <NUM>-<NUM> depict the Downlink Layer <NUM> architecture for multicast session and broadcast session respectively, where MBS protocol stack comprises the same layer <NUM> sublayers as described in section <NUM> with the following differences:.

Editor's Note: Whether to support security in PDCP requires progress and input from other WG, i.e. SA3.

Figure <NUM>. <NUM>-<NUM>: Downlink Layer <NUM> Architecture for Broadcast Session.

Editor's Note: Group scheduling related aspects to be covered here.

The following logical channels are used in MBS delivey:.

The following connections between logical channels and transport channels for group transmission exist:.

The following decipts the usage of RNTI for group transmission:.

Editor's Note: RAN3 to provide Session management aspects here.

Editor's Note: FFS how multicast configuration is provided for supporting multicast reception in RRC_CONNECTED state.

If the UE which joined the multicast session is in RRC_CONNECTED state, the gNB sends RRC Reconfiguration message with relevant MBS configuration for multicast session to the UE and there is no need for separate session activation notification for this UE.

MBS supporting gNBs notify the UEs in RRC IDLE/INACTIVE state about a multicast session activation using a group notification mechanism. The group notification is addressed with P-RNTI on PDCCH, and the paging channels are monitored by the UE as described in section <NUM>. And each UE is not paged individually, and the same group notification identity, i.e., MBS session ID, is used for UEs with the same multicast session in both RRC IDLE and RRC INACTIVE states.

gNBs not supporting MBS may notify the UEs in RRC IDLE/INACTIVE state about a multicast session activation through Paging messages in the PO as described in section <NUM>. <NUM>, where each UE is paged individually.

Editor's Note: Dynamic switch related aspects to be covered here.

For multicast service, gNB may deliver MBS data packets using the following methods:.

Editor's Note: FFS that RAN1 inputs are needed for the definition of PTP/PTM transmission.

If a UE is configured with a split MRB, a gNB dynamically decides whether to deliver multicast data by PTM or PTP for a given UE based on the protocol stack defined in section16.

For a split MRB, the usage of the PTP leg cannot be deactivated, i.e. the UE needs to always monitor C-RNTI and the state of RLC entity for PTP delivery is always active, after the necessary split MRB configuration.

Editor's Note: When two RLC entities are configured for a MRB for PTP delivery and PTM delivery respectively by RRC, it is FFS whether the state of RLC entity for PTM delivery can be active or deactive and can be dynamically controlled.

No data: When there is no data ongoing for the multicast session, the UE can stay in RRC_CONNECTED. Other cases FFS.

It is up to SA2 to decide whether the multicast session activation/deactivation mechanism is supported or not, and RAN2 will discuss if there is any RAN2 impacts based on SA2 inputs.

It is up to SA2 to decide on the support of local MBS service, and RAN2 will discuss the RAN2 impacts based on SA2 inputs.

In general, Information of MBS services/groups subscribed by the UE (e.g. TMGI) and QOS requirements of a MBS service should be provided to RAN. Detail information e.g. for PTM PTP switch if any is FFS.

Both idle/inactive UEs and connected mode UEs can receive MBS services transmitted by NR MBS delivery mode <NUM> (Broadcast service as already agreed, TBD other). The ability for connected mode UEs to receive this may depend on the network provisioning of the service (e.g. which freq), UE connected mode configuration and UE capabilities.

The two-step based approach (i.e. BCCH and MCCH) as adopted by LTE SC-PTM is reused for the transmission of PTM configuration for NR MBS delivery mode <NUM>.

Assume it is possible to reuse LTE SC-PTM mechanism for the CONNECTED UEs to receive the PTM configuration for NR MBS delivery mode <NUM>, i.e. broadcast based manner.

Assume that MCCH change notification mechanism is used to notify the changes of MCCH configuration due to session start for delivery mode <NUM> of NR MBS (other cases FFS, if any).

Assume that MBS Interest Indication is supported for UEs in connected mode for Broadcast service (assume that as usual there is no mandatory network requirement, network action is up to network).

MBS Interest Indication is NOT supported for UEs in idle/inactive mode for NR MBS delivery mode <NUM>.

Assume that some information for purpose of service continuity can be provided for NR MBS delivery mode <NUM>. (FFS what - need to be revisited, e.g. based on progress in other groups, e.g. USD, SAI/TMGI etc).

FFS whether support UE awareness of MBS services on frequency basis for service continuity for NR MBS delivery mode <NUM> (i.e. Reuse LTE SC-PTM mechanism).

FFS Support frequency prioritization during cell reselection for service continuity for NR MBS delivery mode <NUM> (i.e. Reuse LTE SC-PTM mechanism).

P2: Whether UEs that receive Multicast can be released to RRC Inactive / Idle and continue receiving Multicast is Postponed. Should limit to RRC inactive in future discussions.

One-to-one mapping between G-RNTI and MBS session is supported in NR MBS. Other mappings FFS.

One-to-one mapping between G-CS-RNTI and MBS session is supported in NR MBS. Other mappings FFS.

A UE can support multiple G-RNTIs/G-CS-RNTIs, It is FFS whether this depends on UE capability. Inform RAN1 of this agreement.

Multiple MBS QoS flows corresponding to the same MBS session can be mapped to one or more than one MBS radio bearers.

MCCH is mapped to the DL-SCH for NR MBS delivery mode <NUM>.

MTCH is specified for PTM transmission of NR MBS.

DTCH is reused for PTP transmission of NR MBS.

FFS if there is a need to have specific LCID spaces for the used channels.

Multiplexing/de-multiplexing of different logical channels associated with the same G-RNTI is supported for NR MBS.

FFS if Multiplexing/de-multiplexing of different logical channels associated with the same G-CS-RNTI is supported for NR MBS.

Multiplexing/de-multiplexing of different logical channels associated with the C-RNTI is supported for NR MBS.

For NR MBS delivery mode <NUM>, LTE SC-PTM DRX scheme is used as baseline.

FFS whether For PTM transmission of NR MBS, DRX scheme is independent of DRX for unicast transmission, e.g. supported on a per G-RNTI basis.

FFS whether For PTP transmission, DRX operation for unicast transmission is reused.

One or more parts of R2-<NUM> are quoted below:.

In LTE SC-PTM, there is a one-to-one mapping between MBMS session, which is identified by the TMGI, and MBMS traffic logical channel (e.g. SC-MTCH). Further, the transmissions of an SC-MTCH are associated with a G-RNTI. Hence, there is a one-to-one mapping between TMGI and G-RNTI.

For NR MBS, considering that each MBS session can support one or multiple QoS flows according to the SA2 agreement, it is worthy to reconsider the mapping relation between G-RNTI and MBS session. Further, as agreed in RAN1#104bis-e meeting, G-CS-RNTI was defined for both the activation/deactivation of SPS group-common PDSCH and PTM scheme <NUM> based dynamic retransmission. Then, it seems a spontaneous logic that the mapping relation between G-CS-RNTI and MBS session needs to be also considered.

Contributions [<NUM>][<NUM>][<NUM>][<NUM>][<NUM>][<NUM>][<NUM>][<NUM>][<NUM>][<NUM>][<NUM>][<NUM>][<NUM>] proposed that there could be one-to-one mapping between G-RNTI and MBS session, the same as LTE SC-PTM. The intention is to avoid UE from receiving/processing MBS services in which the UE is not interested. With this, both UE complexity and power consumption on blind PDCCH detection can be largely reduced.

Furthermore, contributions [<NUM>][<NUM>][<NUM>][<NUM>][<NUM>] proposed that the mapping between G-RNTI and MBS session can be extended to one-to-multiple mapping (based on network configuration and UE capability). The main reason supporting this mapping relation is that the mandate LTE one-to-one mapping rule makes it difficult for the network to efficiently satisfy the service requirements of various UEs interested in multiple MBS services (e.g. configured with different numbers of G-RNTIs). In practice, the gNB should be allowed to schedule multiple multicast services to a given UE via the same G-RNTI (also considering the limited UE capability on simultaneous PDCCH detection with different RNTIs).

Similar to the G-RNTI case, contributions [<NUM>][<NUM>][<NUM>][<NUM>][<NUM>] proposed that the mapping between G-CS-RNTI and MBS session/service can be one-to-one mapping or one-to-multiple mapping. Specifically, (<NUM>/<NUM>) companies proposed one-to-one mapping only while the other (<NUM>/<NUM>) companies proposed one-to-multiple mapping can be additionally supported.

On the other hand, contributions [<NUM>] proposed that the multiple-to-one mapping between G-RNTI and MBS session should be considered so that one-to-one mapping between G-RNTI and MBS radio bearer can be achieved. With this mapping, separate QoS treatments (i.e. different MRBs within the same MBS session may need different handling over Uu) for a specific MBS radio bearer can be provided by gNB.

(<NUM>/<NUM>) contributions have provided proposals on the mapping relation between G-RNTI/G-CS-RNTI and MBS session. Based on these contributions, the most majority of companies (<NUM>/<NUM>) agree that using a one-to-one mapping between G-RNTI/G-CS-RNTI and MBS session can help to UE power saving. Specifically,.

Based on P1 and P2, next, we can review the questions asked by RAN1 in the LS R2-<NUM> regarding the support of multiple G-RNTIs and G-CS-RNTIs. Specifically,.

Companies in contributions [<NUM>][<NUM>][<NUM>][<NUM>][<NUM>][<NUM>][<NUM>][<NUM>][<NUM>][<NUM>] all agreed that multiple G-RNTIs/G-CS-RNTIs can be supported based on network configuration/UE capability/UE implementation. On the contrary, the company in contribution [<NUM>] thinks only one G-CS-RNTI is supposed to be used for PTM transmission, which is similar to the legacy NR mechanism with multiple CG configurations.

(<NUM>/<NUM>) contributions have provided proposals on the question in the RAN1 LS. It seems a majority view (<NUM>/<NUM>) that multiple G-RNTIs/G-CS-RNTI can be supported by UE for both NR MBS broadcast and multicast. Therefore, the following is proposed,.

Proposal <NUM>: A UE can support multiple G-RNTIs/G-CS-RNTIs. Inform RAN1 of this agreement.

In LTE SC-PTM, group DRX is introduced for UE power saving. In NR MBS, similar DRX mechanism needs to be considered as well. Contributions [<NUM>][<NUM>][<NUM>][<NUM>][<NUM>][<NUM>][<NUM>][<NUM>][<NUM>][<NUM>][<NUM>] all proposed supporting DRX for NR MBS and had further discussed DRX related detailed operation. Overall, the majority view can be concluded as follows,.

Furthermore, contributions [<NUM>][<NUM>] would RAN2 to consider whether a common DRX configuration can be used for CONNECTED UE with both multicast (including PTM and/or PTP) and unicast transmission. Contribution [<NUM>] considered to configure DRX configuration for each MCCH.

(<NUM>/<NUM>) contributions have provided proposals on DRX for NR MBS. Obviously, it is a majority view that DRX operation is supported in NR MBS. Then, rapporteur thinks all three conclusions mentioned above with the majority company supporting can be considered as baseline for the future detailed design of NR MBS DRX mechanism. Therefore, the following proposals are made,.

Adhering to SCPTM principle, each MBS session can have a service specific DRX for reception with PTM mode and is associated with a specific G-RNTI. Whereas, PTP mode is closely related to legacy unicast and UE specific unicast C-DRX is suitable. There are two important aspects that need to be considered.

One or more parts of R2-<NUM> are quoted below. Notably, <FIG> of Section <NUM> of R2-<NUM>, entitled "DRX cycle for LTE MTCH", is reproduced herein as <FIG>.

DRX is a key feature for power saving in the UE. It allows the UE to stop monitoring PDCCH during periods of time when there is no data activity, thereby saving power. The DRX function consists of two parts. The static part consists of known durations the UE will monitor PDCCH in order for the network to schedule it. On top of this a dynamic part is added which adapts the UE's monitoring of PDCCH depending on the traffic. As DRX is a fundamental component to save UE power, it should also be supported for monitoring of the G-RNTI:
Proposal <NUM>: DRX is supported for monitoring of G-RNTI on PDCCH.

In LTE the MTCH traffic channel is used to carry the multicast/broadcast data. The UE in idle/inactive mode is monitoring the MTCH when the onDurationTimer or drx-InactivityTimer are running configured for the G-RNTI, i.e. during the Active Time of the G-RNTI (<NUM>) as shown in <FIG>.

The drx-InactivityTimer is restarted when DL data scheduled with the G-RNTI is received. Up to <NUM> SC-MTCHs can be configured in the cell for each MBMS session (G-RNTI) with its own DRX parameters. This means there is one DRX operation for unicast traffic and one DRX operation for each G-RNTI/SC-MTCH. There is a difference in the unicast DRX operation and the SC-PTM DRX operation in that the latter applies both for RRC_IDLE and RRC_CONNECTED and it lacks DRX short cycle functionality and functionality related to HARQ timers and retransmission timers. SC-PTM was designed for services with predictable characteristics (inter-arrival time, packet sizes etc) so this simplification compared to unicast DRX operation was justified. The UE simply receives the transmissions and there is no HARQ feedback for example.

The first question for DRX support for NR MBS should be if the existing DRX operation is sufficient or if there is need to introduce another DRX operation for monitoring of the G-RNTI(s). NR MBS will have some support for HARQ, so it is not possible to copy the LTE SC-PTM solution. If the UE can only be configured with a single DRX configuration, then the on duration for all UEs interested configured with an MRB have to be aligned. This is not wanted behaviour as the corresponding DRBs of the UEs have to be handled during the same duration. Thus, having DRX configurations specifically for MRBs is appropriate:
Proposal <NUM>: Introduce MBS-specific DRX configuration, one per G-RNTI.

Secondly the question arises about the properties of the MBS-specific DRX configuration. Unicast DRX is controlled by the following parameters and MAC CEs. The table includes the usefulness to MBS DRX.

Proposal <NUM>: The MBS DRX operation supports the parameters listed in Table <NUM> and the baseline is that they operate (actions for start/stop/expiry etc) similar to Unicast DRX operation.

For NR MBS, the gNB should inform the UE where the MBS services might be scheduled, otherwise the UE has to monitor PDCCH all the time, which is not beneficial for the UE's power consumption. In order to minimize the UE power consumption, in LTE, the DRX mechanism for SC-PTM was used. Therefore, NR should follow the same principle for MBS service to achieve the same benefits.

According to RAN1#<NUM> e-meeting agreements and RAN1#<NUM> e-meeting agreements, there may be three transmission schemes for MBS, including PTM transmission scheme <NUM>, PTM transmission scheme <NUM> and PTP transmission, while PTM transmission scheme <NUM> and PTP transmission have been agreed, but PTM transmission scheme <NUM> is not agreed yet. At the same time, MBS SPS has also be supported. For these three agreed transmission including PTM transmission scheme <NUM>, PTP transmission and MBS SPS transmission, the impact for DRX can be discussed separately.

In NR MBS, there are multiple UEs who are interested in the same MBS service and different UEs have different DRX configurations for unicast. For PTM transmission scheme <NUM>, the UEs which are interested in the same MBS service need to receive the same DCI. However, it seems difficult to align DRX for unicast of the UEs who are interested in the same MBS service. Furthermore, considering that a UE may be interested in multiple MBS services, such kind of alignment will be even harder.

Hence, we believe DRX for PTM transmission scheme <NUM> should be in parallel with DRX for unicast, which is a simple approach and allows to avoid impacts on the DRX configurations for unicast.

In existing DRX for unicast, UE needs to monitor DCI scrambled by C-RNTI during Active Time.

For multicast PTP transmission, UE also needs to monitor DCI scrambled by C-RNTI. If proposal 3b is agreed, obviously, DRX for unicast should be reused for PTP transmission for multicast.

In existing DRX for unicast, the UE needs to control DRX timers for unicast DRX after a MAC PDU is received in unicast SPS. In NR MBS, similarly, the UE needs to control DRX timers for PTM DRX after a MAC PDU is received in MBS SPS.

Considering that the MAC PDU transmitted in MBS SPS is common for UEs who are interested in the same MBS service, the DRX for PTM transmission should also take into account MBS SPS transmission.

Proposal 9a: DRX for PTM transmission of broadcast and multicast shall be independent from DRX for unicast.

Proposal 9b: DRX for unicast is reused for PTP transmission for multicast.

Considering different MBS services may have different service characteristic, for PTM transmission, it should be possible to configure a different DRX configurations for each G-RNTI. Furthermore, for PTM transmission, UE should perform DRX operation for each G-RNTI to control the UE's PDCCH monitoring activity for the G-RNTI.

Proposal <NUM>: For broadcast and multicast, UE should perform DRX operation for each G-RNTI independently.

LTE SC-PTM does not support HARQ-ACK feedback and HARQ-based retransmission. So, there is not Retransmission Timer in DRX of LTE SC-PTM. And the Active Time for DRX of LTE SC-PTM only includes the time while onDurationTimerSCPTM or drx-InactivityTimerSCPTM is running.

In NR, broadcast also does not support HARQ-ACK feedback and HARQ-based retransmission. Obviously, LTE SC-PTM DRX mechanism can be reused in PTM transmission of broadcast.

In DRX for unicast, Active Time for unicast includes the time while drx-onDurationTimer or drx-InactivityTimer or drx-RetransmissionTimerDL is running. And during Active Time for unicast, the network can transmit new transmission or retransmission to UE.

Furthermore, according to the current specification, in unicast DRX, when UE receives a MAC PDU, UE starts the drx-HARQ-RTT-TimerDL for the corresponding HARQ process in the first symbol after the end of the corresponding transmission carrying the DL HARQ feedback, and UE only starts drx-RetransmissionTimerDL for the corresponding HARQ process in the first symbol after the expiry of drx-HARQ-RTT-TimerDL if the MAC PDU was not successfully decoded.

In NR MBS, multiple UEs interested in the same MBS service will receive the same DCI and MBS MAC PDU, which is different from unicast. If the DRX mechanism for unicast is directly reused in DRX for PTM transmission, Active Time of different UEs receiving the same MBS service may be not aligned in some case:.

Considering the differences between unicast and MBS, it is not possible to directly reuse DRX mechanism in unicast for PTM transmission. Otherwise, for PTM transmission, some UEs may fail to receive new transmission transmitted during the running of Retransmission Timer.

In order to avoid some UEs missing new PTM transmissions during the running of Retransmission Timer, for multicast PTM transmission, if neither onDuration Timer nor Inactivity Timer is running, and Retransmission Timer of only some UEs is running, the network should not transmit new transmissions.

Proposal <NUM>: For DRX operation for multicast PTM, if neither onDuration Timer nor Inactivity Timer is running, and Retransmission Timer of only some UEs is running, the network should not schedule new transmissions.

According to RAN1#<NUM> e-meeting agreement [<NUM>], when ACK/NACK based HARQ-ACK feedback is enabled for multicast, after the network performs initial transmission by PTM transmission for a MAC PDU, the network may perform retransmission of the MAC PDU by PTP transmission for a specific UE or perform retransmission of the MAC PDU by PTM transmission. Furthermore, according to RAN1#104bis e-meeting agreement [<NUM>], after the network performs initial transmission by MBS SPS transmission for a MAC PDU, the network may perform retransmission of the MAC PDU by PTP transmission for a specific UE or perform retransmission of the MAC PDU by PTM transmission.

Hence, when ACK/NACK based HARQ-ACK feedback is enabled for multicast, in order to ensure that UE can receive the DCI scheduling retransmission by PTP transmission, after UE fails to receive PDSCH for PTM scheduling/MBS SPS transmission, DRX for unicast should also allow the UE to monitor the retransmission scheduled by PTP.

Proposal <NUM>: For multicast, when the UE fails to receive PDSCH for PTM transmission, DRX for unicast should be adapted to allow the UE to monitor the retransmission scheduled by PTP.

In NR ,Unicast DRX is supported to enable UE to sleep when there is no data traffic to send and receive. Contributions [<NUM>][<NUM>][<NUM>][<NUM>][<NUM>][<NUM>][<NUM>][<NUM>][<NUM>][<NUM>][<NUM>][<NUM>][<NUM>][<NUM>][<NUM>][<NUM>][<NUM>][<NUM>] all proposed to support Multicast DRX, which is different from Unicast DRX. These contributaions discussed multiple proposals related to Multicast DRX configuration for PTM and PTP transmission. Overall, it can be concluded from the contributions that,.

All contributions agree that Multicast DRX operation is supported and is independent of Unicast DRX.

Therefore, the following proposals need to be discussed,.

Proposal <NUM>: For multicast PTM transmission, Multicast DRX pattern is configured on a per G-RNTI basis (i.e. independent of legacy UE-specific DRX for unicast transmission).

Proposal <NUM>: As network configuration, multiple Multicast services can be associated with one Multicast DRX pattern.

Proposal <NUM>: Legacy UE-specific DRX pattern for unicast is reused for PTP transmission of NR MBS, which means the UE specific DRX pattern are for both unicast services and the MBS PTP bearer of UE.

Proposal <NUM>: Multicast long DRX support is baseline. FFS whether to support optional short DRX for Multicast or not.

Proposal <NUM>: The Multicast Long DRX operation has to support the following parameters which are similar to the UE-specific DRX for unicast, where the last two parameters are needed if the HARQfeedback is enabled:.

Proposal <NUM>: During PTM Multicast DRX active period, UE monitors both G-RNTI and C-RNTI (for receiving C-RNTI based unicast HARQ re-transmissions assuming gNB can use configured Multicast Search Space to schedule either by G-RNTI or C-RNTI).

Proposal <NUM>. For Multicast HARQ ACK/NACK feedback using UE specific PUCCH resources, RAN2 to discuss following <NUM> options.

Proposal <NUM>. For group common PTM Multicast HARQ PUCCH resources (NACK only feedback), the same group of UEs have aligned HRAQ RTT and DL Re-Tx timer configuration. HARQ RTT timer counting starts from end of common PUCCH resource based NACK transmission (i.e. same as Unicast DRX behaviour).

Contributions [<NUM>] [<NUM>] [<NUM>] [<NUM>] [<NUM>] [<NUM>] [<NUM>] discussed about Broadcast DRX configuration aspects. Based on these papers, below are summary proposals:.

Contribution [<NUM>] discussed about WUS aspects for Multicast PTP reception.

PTP is expected to re-use Unicast DRX and it is reasonable to to use PDCCH WUS for Multicast PTP reception. For PTM WUS requires additional work and can be discussed later if time permits.

Contribution [<NUM>] proposed not to support R16 power saving mechanisms.

Proposal <NUM>: PDCCH WUS is applicable for Multicast data reception via PTP RLC (i.e. assuming Unicast DRX is used for PTP).

One or more parts of RP-<NUM> are quoted below:.

A first Discontinuous Reception (DRX) (e.g., a first DRX pattern and/or a first DRX configuration) may be associated with a Group Radio Network Temporary Identifier (G-RNTI) that may correspond to a multicast service. A network (e.g., a gNB) may transmit data (e.g., a transport block (TB) and/or a Medium Access Control Protocol Data Unit (MAC PDU)) to a plurality of UEs by multicast (e.g., using the multicast service associated with the G-RNTI). For example, the transmission of the data may be an initial transmission of the data (e.g., the initial transmission of the data may be a new transmission of the data and/or may not be a retransmission of the data). The transmission of the data (and/or the data in the transmission of the data) may be addressed to the G-RNTI associated with the first DRX. In some examples, if the data is not successfully decoded by a UE (e.g., a UE of the plurality of UEs), such as where the UE does not successfully decode the data carried by the transmission of the data (e.g., multicast transmission of data) from the network, the network may retransmit the data to the UE. The retransmission of the data (and/or the data in the retransmission of the data) may be addressed to a Cell Radio Network Temporary Identifier (C-RNTI) (e.g., a C-RNTI associated with the UE that did not successfully decode the initial transmission of the data). The UE (that did not successfully decode the initial transmission of the data, for example) may be configured with a second DRX associated with the C-RNTI (to which the retransmission of the data is addressed, for example), wherein the second DRX associated with the C-RNTI is different than the first DRX associated with the G-RNTI (e.g., the second DRX may correspond to a second DRX pattern and/or a second DRX configuration different than the first DRX pattern and/or the first DRX configuration, respectively). Accordingly, coordination between the two DRXs (e.g., the first DRX, associated with the G-RNTI to which the initial transmission of the data is addressed, and the second DRX associated with the C-RNTI to which the retransmission of the data is addressed) may be required for data reception.

When a UE receives/detects data (e.g., a TB and/or a MAC PDU), addressed to a G-RNTI for a Hybrid Automatic Repeat Request (HARQ) process, from a network (e.g., a gNB) and the UE does not decode the data successfully (e.g., the UE may transmit HARQ feedback indicative of Negative Acknowledgment (NACK) based on not successfully decoding the data, wherein the HARQ feedback be associated with the HARQ process), the UE may start a G-RNTI DRX retransmission timer associated with the G-RNTI for the HARQ process (e.g., the G-RNTI DRX retransmission timer may be drx-RetransmissionTimerDLPTM) and the UE may or may not start a C-RNTI DRX retransmission timer associated with a C-RNTI for the HARQ process (e.g., the C-RNTI DRX retransmission timer may be drx-RetransmissionTimerDL). In the present disclosure, the term "receives/detects" may refer to "receives and/or detects". For example, the UE may start the C-RNTI retransmission timer upon expiry of a HARQ Round Trip Time (RTT) timer associated with the G-RNTI for the HARQ process. In some examples, the HARQ RTT timer (associated with the G-RNTI for the HARQ process) is started (by the UE, for example) upon transmission of HARQ feedback (e.g., Acknowledgment (ACK)/NACK feedback) after reception/detection of the data from the network. The HARQ feedback may be indicative of whether or not the data is decoded successfully by the UE. In some examples, the UE may determine to start the C-RNTI retransmission timer based on information (e.g., one or more indications) of a Physical Downlink Control Channel (PDCCH) and/or a Radio Resource Control (RRC) configuration. The information of the PDCCH and/or the RRC configuration indicates that C-RNTI transmission may occur for the multicast transmission (e.g., the transmission of the data addressed to the G-RNTI) for the same data (e.g., the same TB and/or MAC PDU). For example, the C-RNTI transmission may correspond to a retransmission of the data that is transmitted (e.g., initially transmitted) via the multicast transmission addressed to the G-RNTI for the HARQ process.

When a UE receives/detects data (e.g., a TB and/or a MAC PDU), addressed to a C-RNTI for a HARQ process, from a network (e.g., a gNB) and the UE does not decode the data successfully (e.g., the UE may transmit HARQ feedback indicative of NACK based on not successfully decoding the data, wherein the HARQ feedback be associated with the HARQ process), the UE may start a C-RNTI DRX retransmission timer associated with the C-RNTI for the HARQ process (e.g., the C-RNTI DRX retransmission timer may be drx-RetransmissionTimerDL) and the UE may or may not start a G-RNTI DRX retransmission timer associated with a G-RNTI for the HARQ process (e.g., the G-RNTI DRX retransmission timer may be drx-RetransmissionTimerDLPTM). For example, the UE may start the G-RNTI retransmission timer upon expiry of a HARQ RTT timer associated with the G-RNTI for the HARQ process. In some examples, the HARQ RTT timer (associated with the G-RNTI for the HARQ process) is started (by the UE, for example) upon transmission of HARQ feedback (e.g., ACK/NACK feedback) after reception/detection of the data from the network. The HARQ feedback may be indicative of whether or not the data is decoded successfully by the UE.

In the present disclosure, the terms "multicast retransmission timer", "group retransmission timer", "G-RNTI retransmission timer", and/or "G-RNTI DRX retransmission timer" may be used interchangeably. Alternatively and/or additionally, the terms "unicast retransmission timer", "C-RNTI retransmission timer", and/or "C-RNTI DRX retransmission timer" may be used interchangeably.

If a network (e.g., a gNB) receives a NACK (e.g., any NACK) associated with multicast transmission of data to UEs (and/or if the network does not receive all ACK from UEs associated with the multicast transmission), the network may retransmit the data through multicast (associated with G-RNTI, for example) and unicast (associated with C-RNTI, for example) for different UEs, wherein the retransmissions of the data to the UEs (through multicast and unicast) may be performed at the same time and/or within a window of time that is smaller than a threshold duration of time. For example, the retransmissions of the data for the different UEs may comprise a retransmission of the data (addressed to the G-RNTI, for example) through multicast for one or more first UEs and one or more retransmissions of the data (addressed to one or more C-RNTIs, for example) through unicast for one or more second UEs. When a UE receives/detects a retransmission (of the retransmissions of the data, for example), addressed to a G-RNTI for the HARQ process, the UE may stop both a G-RNTI retransmission timer and a C-RNTI retransmission timer. The UE may not continue to monitor PDCCH for C-RNTI retransmission and may lose (e.g., miss and/or not detect) a retransmission addressed to C-RNTI.

In an example scenario, a network (e.g., a gNB) may perform a multicast transmission of data (e.g., a TB and/or a MAC PDU), addressed to a G-RNTI for a HARQ process, to a plurality of UEs. The network may perform retransmissions of the data if (i) the network receives a NACK (e.g., any NACK) associated with the multicast transmission of the data from a UE of the plurality of UEs (such as where the NACK is indicative of the data not being decoded successfully by a UE of the plurality of UEs), and/or (ii) the network does not receive, from every UE of the plurality of UEs, an ACK indicating successful reception and/or successful decoding of the data. The retransmissions of the data may comprise a first multicast retransmission of the data (addressed to the G-RNTI for the HARQ process, for example) and one or more first unicast retransmissions of the data (addressed to one or more C-RNTIs for the HARQ process, for example). The retransmissions of the data may be performed for different UEs, such as UEs (of the plurality of UEs, for example) that did not successfully decode the data via the multicast transmission of the data. For example, the first multicast retransmission of the data may be performed for one or more first UEs (of the plurality of UEs, for example) and the one or more first unicast retransmissions of the data (addressed to one or more C-RNTIs, for example) may be performed for one or more second UEs (of the plurality of UEs, for example). In some examples, the retransmissions of the data may be performed at the same time or within a window of time that is smaller than a threshold duration of time. When a UE (of the plurality of UEs, for example) receives/detects a retransmission (of the retransmissions of the data, for example), addressed to the G-RNTI for the HARQ process (e.g., when the UE receives the first multicast retransmission of the data), the UE may stop both a G-RNTI retransmission timer associated with the G-RNTI and a C-RNTI retransmission timer associated with a C-RNTI for the HARQ process. The UE may not continue to monitor PDCCH for C-RNTI retransmission (addressed to the C-RNTI, for example) and may lose (e.g., miss and/or not detect) a retransmission addressed to the C-RNTI. For example, the UE may stop monitoring PDCCH for C-RNTI retransmission when the UE stops the C-RNTI retransmission timer associated with the C-RNTI. Alternatively and/or additionally, in some examples, the UE does not monitor PDCCH for C-RNTI retransmission when the C-RNTI retransmission timer associated with the C-RNTI is not running.

In some examples, if the network (e.g., the gNB) decides to retransmit the data through multicast (e.g., associated with the G-RNTI) and unicast (e.g., associated with the C-RNTI) for different UEs, network (e.g., a gNB) should ensure that unicast retransmissions (e.g., all unicast retransmissions, such as all unicast retransmissions of the one or more first unicast retransmissions of the data) are performed earlier than the multicast retransmission (e.g., the first multicast retransmission of the data). In this way, the network may ensure that multicast UEs (e.g., all multicast UEs) are still awake for retransmission reception (e.g., reception of retransmissions of the data) and/or that DRX retransmission timers (of the multicast UEs, for example) for multicast are still running.

In some examples, if a UE receives/detects a transmission (e.g., a retransmission) addressed to a C-RNTI for a HARQ process, the UE stops a C-RNTI retransmission timer for the HARQ process and does not stop a G-RNTI retransmission timer for the same HARQ process (e.g., the UE does not stop the G-RNTI retransmission timer in response to receiving/detecting the transmission addressed to the C-RNTI, such as where the UE keeps the G-RNTI retransmission timer running if the timer is running when the UE receives/detects the transmission addressed to the C-RNTI). For example, the UE may receive/detect a G-RNTI retransmission later than the C-RNTI transmission (e.g., the transmission addressed to the C-RNTI) for the HARQ process. The UE may perform HARQ combining and decoding for the C-RNTI and G-RNTI transmissions. In some examples, if the UE transmits an ACK and/or if the UE decodes the data successfully for the transmission (e.g., the retransmission) addressed to C-RNTI for the HARQ process, the UE may stop the corresponding G-RNTI retransmission timer and/or G-RNTI HARQ RTT timer.

In an example scenario, a UE may receive/detect a transmission (e.g., a retransmission) addressed to a C-RNTI for a HARQ process. In response to (e.g., upon) receiving the transmission (e.g., the retransmission) addressed to the C-RNTI for the HARQ process, the UE stops a C-RNTI retransmission timer (associated with the C-RNTI) for the HARQ process and does not stop a G-RNTI retransmission timer associated with a G-RNTI for the HARQ process (e.g., the UE does not stop the G-RNTI retransmission timer in response to receiving/detecting the transmission addressed to the C-RNTI, such as where the UE keeps the G-RNTI retransmission timer running if the timer is running when the UE receives/detects the transmission addressed to the C-RNTI). The UE may receive/detect a G-RNTI retransmission later than the C-RNTI transmission (e.g., the transmission addressed to the C-RNTI) for the HARQ process. The G-RNTI retransmission may be addressed to the G-RNTI for the HARQ process. The UE may perform HARQ combining and decoding for the C-RNTI transmission and the G-RNTI retransmission. In some examples, if the UE transmits an ACK (e.g., the ACK may be indicative of the UE having successfully received and/or decoded data via the C-RNTI transmission) and/or if the UE successfully decodes data received via the C-RNTI transmission (e.g., the retransmission) addressed to the C-RNTI for the HARQ process, the UE may stop the G-RNTI retransmission timer associated with the G-RNTI for the HARQ process and/or the UE may stop a G-RNTI HARQ RTT timer associated with the G-RNTI for the HARQ process. For example, the UE may stop the G-RNTI retransmission timer and/or the G-RNTI HARQ RTT timer in response to (e.g., upon) transmission of the ACK and/or successfully decoding the data received via the C-RNTI transmission (e.g., the retransmission) addressed to the C-RNTI.

In some examples, if a UE receives/detects a transmission (e.g., a retransmission) addressed to a G-RNTI for a HARQ process, the UE stops a G-RNTI retransmission timer (if the G-RNTI retransmission timer is running, for example) for the HARQ process and does not stop a C-RNTI retransmission timer for the same HARQ process (e.g., the UE does not stop the C-RNTI retransmission timer in response to receiving/detecting the transmission to the G-RNTI, such as where the UE keeps the C-RNTI retransmission timer running if the C-RNTI retransmission timer is running when the UE receives/detects the transmission addressed to the G-RNTI). For example, the UE may receive/detect a C-RNTI retransmission later than the G-RNTI transmission (e.g., the transmission addressed to the G-RNTI) for the HARQ process.

Alternatively and/or additionally, whether or not the UE stops the C-RNTI retransmission timer (and/or keeps the C-RNTI retransmission timer) running may be based on whether or not an earlier transmission for the HARQ process (e.g., a most recent transmission for the HARQ process earlier than the transmission addressed to the G-RNTI and/or any transmission for the HARQ process that is earlier than the transmission addressed to the G-RNTI) is addressed to C-RNTI.

In a first example, the UE may determine that an earlier transmission for the HARQ process is addressed to the C-RNTI. The earlier transmission may correspond to a transmission that was received/detected by the UE via the HARQ process prior to reception/detection of the transmission addressed to the G-RNTI. For example, the earlier transmission may correspond to a most recently received/detected transmission of the HARQ process prior to the transmission addressed to the G-RNTI. Based on the determination that the earlier transmission for the HARQ process is addressed to the C-RNTI, the UE may not stop the C-RNTI retransmission timer and/or may keep the C-RNTI retransmission timer running (if the C-RNTI retransmission timer is running, for example). For example, based on the determination that the earlier transmission for the HARQ process is addressed to the C-RNTI, the UE may not stop the C-RNTI retransmission timer in response to receiving/detecting the transmission addressed to the G-RNTI.

In a second example, the UE may determine that (i) an earlier transmission for the HARQ process is not addressed to the C-RNTI (e.g., the earlier transmission may correspond to a transmission that was received/detected by the UE via the HARQ process prior to reception/detection of the transmission addressed to the G-RNTI, such as a most recently received/detected transmission of the HARQ process prior to the transmission addressed to the G-RNTI) and/or (ii) there is no earlier transmission for the HARQ process that is addressed to the C-RNTI (e.g., there is no transmission that (i) was addressed to the C-RNTI, and (ii) was received/detected by the UE via the HARQ process prior to reception/detection of the transmission addressed to the G-RNTI). Based on the determination that the earlier transmission for the HARQ process is not addressed to the C-RNTI and/or that there is no earlier transmission for the HARQ process that is addressed to the C-RNTI, the UE may stop the C-RNTI retransmission timer (and/or a C-RNTI HARQ RTT timer associated with the C-RNTI). For example, based on the determination that the earlier transmission for the HARQ process is not addressed to the C-RNTI and/or that there is no earlier transmission for the HARQ process that is addressed to the C-RNTI, the UE may stop the C-RNTI retransmission timer (and/or the C-RNTI HARQ RTT timer) in response to receiving/detecting the transmission to the G-RNTI. For example, in response to the receiving/detecting the transmission addressed to the G-RNTI, the UE may stop the C-RNTI retransmission timer (and/or the C-RNTI HARQ RTT timer) in addition to stopping the G-RNTI retransmission timer.

In some examples, if the UE transmits an ACK and/or if the UE decodes the data successfully for the transmission (e.g., the retransmission) addressed to G-RNTI for the HARQ process, the UE may stop the corresponding C-RNTI retransmission timer and/or the C-RNTI HARQ RTT timer. In an example, if the UE transmits an ACK (e.g., the ACK may be indicative of the UE having successfully received and/or decoded data via the G-RNTI transmission) and/or if the UE successfully decodes data received via the G-RNTI transmission (e.g., the retransmission) addressed to the G-RNTI for the HARQ process, the UE may stop the C-RNTI retransmission timer associated with the C-RNTI for the HARQ process and/or the UE may stop the C-RNTI HARQ RTT timer associated with the C-RNTI for the HARQ process. For example, the UE may stop the C-RNTI retransmission timer and/or the C-RNTI HARQ RTT timer in response to (e.g., upon) transmission of the ACK and/or successfully decoding the data received via the G-RNTI transmission (e.g., the retransmission) addressed to the G-RNTI.

<FIG> illustrate timing diagrams of example scenarios associated with handling retransmission timers and/or HARQ RTT timers. In <FIG>, a UE has an inactivity timer <NUM>, a group RTT timer <NUM> (e.g., a G-RNTI HARQ RTT timer associated with multicast transmission and/or a G-RNTI), a unicast RTT timer <NUM> (e.g., a C-RNTI HARQ RTT timer associated with unicast transmission and/or a C-RNTI), a group retransmission timer <NUM> (e.g., a multicast retransmission timer, a G-RNTI retransmission timer) and/or a unicast retransmission timer <NUM> (e.g., a C-RNTI retransmission timer). In some examples, the group RTT timer <NUM>, the unicast RTT timer <NUM>, the group retransmission timer <NUM> and/or the unicast retransmission timer <NUM> are associated with (e.g., used for) a HARQ process (e.g., the same HARQ process). In some examples, the group RTT timer <NUM> is the same as the unicast RTT timer <NUM>. Alternatively and/or additionally, the group RTT timer <NUM> may be different than the unicast RTT timer <NUM>.

In a first example scenario <NUM> illustrated in <FIG>, the UE may receive/detect a first group transmission <NUM> at time t1 from a network (e.g., a gNB). The first group transmission <NUM> may comprise a multicast transmission and/or may be addressed to the G-RNTI. At or after the time t1, the UE may start the inactivity timer <NUM>. For example, the inactivity timer <NUM> may be utilized to keep the UE active for monitoring PDCCH based upon receiving/detecting the first group transmission <NUM> (e.g., the UE may monitor PDCCH while the inactivity timer <NUM> is running). The UE may transmit a NACK <NUM> at time t2 (e.g., the NACK <NUM> may be transmitted in response to the first group transmission <NUM>). The NACK <NUM> may be transmitted based on the UE not successfully decoding the data carried by the first group transmission <NUM>. The NACK <NUM> may be indicative of the UE not successfully decoding the data carried by the first group transmission <NUM>. In some examples, in response to transmitting the NACK <NUM>, the UE may start the group RTT timer <NUM> and the unicast RTT timer <NUM>. For example, the UE may start the group RTT timer <NUM> and the unicast RTT timer <NUM> at or after time t2. In the first example scenario <NUM>, the group RTT timer <NUM> and the unicast RTT Timer <NUM> expire at time t3 (e.g., the group RTT timer <NUM> and the unicast RTT Timer <NUM> both expire at time t3 if the group RTT timer <NUM> and the unicast RTT Timer <NUM> are the same timer, for example). Alternatively and/or additionally, the group RTT timer <NUM> and the unicast RTT Timer <NUM> may expire at different times (if the group RTT timer <NUM> and the unicast RTT Timer <NUM> are different timers, for example). The UE may start (at time t3, for example) the group retransmission timer <NUM> in response to (e.g., upon) expiry of the group RTT timer <NUM>. The UE may start (at time t3, for example) the unicast retransmission timer <NUM> in response to (e.g., upon) expiry of the unicast RTT timer <NUM>. At time t4, the UE may receive/detect a second group transmission <NUM> from the network. The second group transmission <NUM> may be a multicast transmission and/or may be addressed to the G-RNTI. The second group transmission <NUM> may be a transmission of the same data transmitted via the first group transmission <NUM>. The UE may stop (at time t4, for example) the group retransmission timer <NUM> and the unicast retransmission timer <NUM> in response to receiving/detecting the second group transmission <NUM>.

In a second example scenario <NUM> illustrated in <FIG>, the UE may receive/detect a first unicast retransmission <NUM> at time t4 (rather than or in addition to receiving/detecting the second group transmission <NUM> of the first example scenario <NUM> shown in <FIG>). The first unicast retransmission <NUM> may be addressed to the C-RNTI. The first unicast retransmission <NUM> may be a transmission of the same data transmitted via the first group transmission <NUM>. The UE may stop (at time t4, for example) the group retransmission timer <NUM> and the unicast retransmission timer <NUM> in response to receiving/detecting the first unicast retransmission <NUM>.

In a third example scenario <NUM> illustrated in <FIG>, the UE may transmit a NACK <NUM> at time t5 (e.g., the NACK <NUM> may be transmitted in response to the first unicast retransmission <NUM>). The NACK <NUM> may be transmitted based on the UE not successfully decoding the data carried by the first unicast retransmission <NUM>. The NACK <NUM> may be indicative of the UE not successfully decoding the data carried by the first unicast retransmission <NUM>. In some examples, in response to transmitting the NACK <NUM>, the UE may not start the group RTT timer <NUM> and may start the unicast RTT timer <NUM>. For example, the UE may not start the group RTT timer <NUM> and may start the unicast RTT timer <NUM> at or after time t5 (e.g., only the unicast RTT timer <NUM> may be started by the UE, at or after time t5, in response to transmitting the NACK <NUM>). The unicast RTT Timer <NUM> may expire at time t6. The UE may start (at time t6, for example) the unicast retransmission timer <NUM> in response to (e.g., upon) expiry of the unicast RTT timer <NUM>. At time t7, the UE may receive/detect a third group transmission <NUM> from the network. The third group transmission <NUM> may be a multicast transmission and/or may be addressed to the G-RNTI. The third group transmission <NUM> may be a transmission of the same data transmitted via the first group transmission <NUM> and the first unicast retransmission <NUM>. In some examples, the UE does not stop the unicast retransmission timer <NUM> (e.g., the UE does not stop the unicast retransmission timer <NUM> in response to receiving/detecting the third group transmission <NUM>). For example, the UE may keep the unicast retransmission timer <NUM> running when the third group transmission <NUM> is received/detected.

In some examples, the UE does not stop the unicast retransmission timer <NUM> in response to receiving/detecting the third group transmission <NUM> based upon a determination that an earlier transmission for the HARQ process (e.g., a most recent transmission for the HARQ process earlier than the third group transmission <NUM> and/or any transmission for the HARQ process that is earlier than the third group transmission <NUM>) is addressed to the C-RNTI. For example, the UE may not stop the unicast retransmission timer <NUM> in response to receiving/detecting the third group transmission <NUM> based upon the earlier transmission being the first unicast retransmission <NUM> (addressed to the C-RNTI, for example).

As shown in <FIG>, the UE may receive/detect a second unicast retransmission <NUM> at time t8. The second unicast retransmission <NUM> may be addressed to the C-RNTI. The second unicast retransmission <NUM> may be a transmission of the same data transmitted via the first group transmission <NUM>, the first unicast retransmission <NUM> and the third group transmission <NUM>. The UE may stop (at time t8, for example) the unicast retransmission timer <NUM> in response to receiving/detecting the second unicast retransmission <NUM>.

Alternatively and/or additionally, the UE may transmit a NACK (not shown in <FIG>) to the network between time t7 (associated with the third group transmission <NUM>) and time t8 (associated with the second unicast retransmission <NUM>). For example, the NACK may be transmitted in response to the third group transmission <NUM>. The NACK may be transmitted based on the UE not successfully decoding the data carried by the third group transmission <NUM>. The NACK may be indicative of the UE not successfully decoding the data carried by the third group transmission <NUM>. In some examples, the UE does not start the group retransmission timer <NUM> in response to transmitting the NACK. In some examples, the UE does not stop the unicast retransmission timer <NUM> in response to transmitting the NACK. In some examples, the group retransmission timer <NUM> is not running during a period of time between time t7 and time t8, while the UE may keep the unicast retransmission timer <NUM> running from time t6 to time t8 (e.g., the UE may keep the unicast retransmission timer <NUM> at least until time t8 when the UE receives/detects the second unicast retransmission <NUM>). Accordingly, in some examples, the UE receives/detects the data (associated with the HARQ process, for example) via the second unicast retransmission <NUM> without having to monitor for multicast transmissions of the data during the period of time in which the group retransmission timer <NUM> is not running.

Embodiments are contemplated in which the UE starts the group retransmission timer <NUM> in response to transmitting the NACK (and/or in response to not successfully decoding the data carried by the third group transmission <NUM>, for example).

Alternatively and/or additionally, the UE may transmit an ACK (not shown in <FIG>) to the network between time t7 (associated with the third group transmission <NUM>) and time t8. For example, the ACK may be transmitted in response to the third group transmission <NUM>. The ACK may be transmitted based on the UE successfully decoding the data carried by the third group transmission <NUM>. The ACK may be indicative of the UE successfully decoding the data carried by the third group transmission <NUM>. In some examples, the UE stops the unicast retransmission timer <NUM> in response to transmitting the ACK and/or in response to successfully decoding the data carried by the third group transmission <NUM>. In this example, the UE may not receive/detect the second unicast retransmission <NUM> at time t8.

In some examples, a UE receives/detects a G-RNTI transmission addressed to a G-RNTI for a HARQ process. In some examples, if an earlier transmission for the HARQ process (e.g., a most recent transmission for the HARQ process earlier than the G-RNTI transmission and/or any transmission for the HARQ process that is earlier than the G-RNTI transmission) was addressed to a C-RNTI and/or if the earlier transmission (received/detected by the UE, for example) was a transmission of the same data transmitted via the G-RNTI transmission (e.g., the earlier transmission and the G-RNTI transmission both comprise transmission of the same data, such as the same TB and/or MAC PDU), the UE may not start a HARQ RTT timer for the G-RNTI (e.g., the HARQ RTT timer for the G-RNTI may be drx-HARQ-RTT-TimerDLPTM) for the HARQ process in response to (e.g., upon) reception/detection of the G-RNTI transmission (e.g., the UE may not start the HARQ RTT timer at a timing associated with transmitting HARQ feedback, such as HARQ feedback associated with the G-RNTI transmission).

In some examples, the UE determines whether or not to stop a C-RNTI retransmission timer for a HARQ process based on whether a received/detected transmission of data is an initial transmission of the data (e.g., a new transmission of the data) or a retransmission of the data (e.g., whether or not the UE stops the C-RNTI retransmission timer in response to receiving/detecting the transmission of the data depends on whether or not the transmission of the data is an initial transmission of the data or a retransmission of the data).

In an example, if the transmission of the data is an initial transmission of the data (e.g., a new transmission of the data), the UE may stop both a G-RNTI retransmission timer (if the G-RNTI retransmission timer is running, for example) and the C-RNTI retransmission timer for the HARQ process. For example, the UE may stop the G-RNTI retransmission timer and the C-RNTI retransmission timer for the HARQ process in response to receiving/detecting the transmission of the data if the transmission of the data is an initial transmission of the data (e.g., the transmission of the data may be addressed to C-RNTI or to G-RNTI).

In an example, if the transmission of the data is a retransmission of the data and the transmission of the data is addressed to G-RNTI for the HARQ process, the UE stops the G-RNTI retransmission timer (if the G-RNTI retransmission timer is running, for example) for the HARQ process and does not stop the C-RNTI retransmission timer (e.g., the UE keeps the C-RNTI retransmission timer for the same HARQ process running). For example, the UE may stop the G-RNTI retransmission timer and may keep the C-RNTI retransmission timer running in response to receiving/detecting the transmission of the data if the transmission of the data is a retransmission of the data and is addressed to G-RNTI for the HARQ process.

In an example, if the transmission of the data is a retransmission of the data and the transmission of the data is addressed to C-RNTI for the HARQ process, the UE stops the C-RNTI retransmission timer (if the C-RNTI retransmission timer is running, for example) for the HARQ process and does not stop the G-RNTI retransmission timer (e.g., the UE keeps the G-RNTI retransmission timer for the same HARQ process running). For example, the UE may stop the C-RNTI retransmission timer and may keep the G-RNTI retransmission timer running in response to receiving/detecting the transmission of the data if the transmission of the data is a retransmission of the data and is addressed to C-RNTI for the HARQ process.

In some examples, if the UE receives/detects an initial transmission (e.g., a new transmission) addressed to C-RNTI or G-RNTI for the HARQ process, the UE stops both G-RNTI retransmission timer (if running, for example) and C-RNTI retransmission timer for the HARQ process. In an example, if UE receives/detects a retransmission addressed to G-RNTI for the HARQ process, the UE stops G-RNTI retransmission timer (if running, for example) for the HARQ process and keeps C-RNTI retransmission timer for the same HARQ process running (e.g., the UE does not stop the C-RNTI retransmission timer if the C-RNTI retransmission timer is running). In an example, if UE receives/detects a retransmission addressed to C-RNTI for the HARQ process, the UE stops C-RNTI retransmission timer (if running, for example) for the HARQ process and keeps G-RNTI retransmission timer for the same HARQ process running (e.g., the UE does not stop the G-RNTI retransmission timer if the G-RNTI retransmission timer is running).

In some examples, if a UE receives/detects a transmission (e.g., retransmission) of data addressed to G-RNTI for a HARQ process and the data (e.g., the data carried by the transmission) has been decoded successfully before reception of the transmission (e.g., the retransmission), the UE may not transmit ACK for the data (e.g., the UE may not transmit an ACK in response to the transmission, such as the retransmission, of the data). In some examples, the UE previously sent ACK for an earlier transmission of the same data addressed to C-RNTI or G-RNTI for the same HARQ process.

In an example scenario, the UE receives/detects a first transmission of data addressed to C-RNTI or G-RNTI for a HARQ process. The UE transmits ACK for the first transmission of the data based on successfully decoding the data (e.g., the data that is carried by the first transmission of the data). For example, the ACK may indicate that the UE successfully decoded the data using the first transmission of the data. If the UE receives/detects a second transmission of the data (e.g., a retransmission of the data) addressed to G-RNTI for the HARQ process, the UE may not transmit ACK for the second transmission of the data (e.g., the UE may not transmit ACK for the second transmission of the data based on the data already having been decoded successfully by the UE using the first transmission of the data).

In some examples, if a UE receives/detects a transmission (e.g., retransmission) of data addressed to C-RNTI for a HARQ process and the data (e.g., the data carried by the transmission) has been decoded successfully before reception of the transmission (e.g., the retransmission), the UE may transmit ACK for the data (e.g., the UE may transmit an ACK in response to the transmission, such as the retransmission, of the data). For example, the UE may transmit the ACK for the data in response to successfully decoding the data using the transmission (e.g., the retransmission) of the data. Embodiments are contemplated in which the UE does not transmit ACK for the data in response to the transmission (e.g., the retransmission) of the data (such as where the UE does not transmit ACK in response to successfully decoding the data using the transmission, such as the retransmission, of the data). In some examples, the UE previously sent ACK for an earlier transmission of the same data addressed to C-RNTI or G-RNTI for the same HARQ process.

In an example scenario, the UE receives/detects a first transmission of data addressed to C-RNTI or G-RNTI for a HARQ process. The UE transmits ACK for the first transmission of the data based on successfully decoding the data (e.g., the data that is carried by the first transmission of the data). For example, the ACK may indicate that the UE successfully decoded the data using the first transmission of the data. If the UE receives/detects a second transmission of the data (e.g., a retransmission of the data) addressed to C-RNTI for the HARQ process, the UE may transmit ACK for the second transmission of the data (e.g., the UE may transmit ACK based on successfully decoding the data using the second transmission of the data). Embodiments are contemplated in which the UE does not transmit ACK for the second transmission of the data (such as where the UE does not transmit ACK in response to successfully decoding the data using the transmission).

In some examples, if a UE receives/detects a transmission (e.g., retransmission) of data addressed to G-RNTI for a HARQ process, the UE may stop the G-RNTI retransmission timer. For example, the UE may stop the G-RNTI retransmission timer in response to receiving/detecting the transmission (e.g., the retransmission) of the data addressed to the G-RNTI for the HARQ process. If the data (e.g., the data carried by the transmission) is decoded successfully, the UE may stop a C-RNTI retransmission timer (e.g., C-RNTI retransmission timer associated with the HARQ process) and/or a C-RNTI HARQ RTT timer (e.g., C-RNTI HARQ RTT timer associated with the HARQ process). For example, the UE may stop the C-RNTI retransmission timer and/or the C-RNTI HARQ RTT timer in response to receiving/detecting the transmission (e.g., the retransmission) of the data addressed to the G-RNTI for the HARQ process. In some examples, the UE may transmit ACK for the data. For example, the UE may transmit the ACK in response to receiving/detecting the transmission (e.g., the retransmission) of the data addressed to the G-RNTI for the HARQ process and/or in response to successfully decoding the data (e.g., the data carried by the transmission of the data).

In some examples, if a UE receives/detects a transmission (e.g., retransmission) of data for addressed to G-RNTI for a HARQ process and the data (e.g., the data carried by the transmission) is not decoded successfully, the UE may or may not send NACK for the data (e.g., the UE may or may not send NACK in response to the transmission, such as the retransmission, of the data). In some examples, in a scenario in which the UE transmits NACK for the data (e.g., the UE transmits the NACK in response to the transmission, such as the retransmission, of the data), the UE may not start a corresponding HARQ RTT timer for the G-RNTI in response to (e.g., upon) the transmission of the NACK. In some examples, in a scenario in which the UE transmits NACK for the data (e.g., the UE transmits the NACK in response to the transmission, such as the retransmission, of the data), the UE starts the corresponding HARQ RTT timer for the G-RNTI in response to (e.g., upon) the transmission of the NACK but may not start a retransmission timer for the G-RNTI (e.g., G-RNTI retransmission timer). In some examples, a C-RNTI retransmission timer (e.g., drx-RetransmissionTimerDL) is running (e.g., the C-RNTI retransmission timer is running when and/or after the UE receives/detects the transmission of the data addressed to the G-RNTI and/or the UE transmits the NACK). Considering that the C-RNTI retransmission timer is still running (e.g., the C-RNTI retransmission timer is still running when and/or after the UE receives/detects the transmission of the data addressed to the G-RNTI and/or the UE transmits the NACK), the network (e.g., gNB) may schedule a unicast retransmission (e.g., a specific unicast retransmission) for the data so the corresponding HARQ RTT timer for the G-RNTI or the retransmission timer for the G-RNTI do not need to start additionally for potential retransmission scheduling through multicast (e.g., since the C-RNTI retransmission timer is still running, the network is able to schedule a unicast retransmission of the data for the UE to deliver the data to the UE, and it is not necessary for the network to perform a multicast retransmission of the data to deliver the data to the UE).

In some examples, a RNTI, such as a G-RNTI, a C-RNTI, etc., associated with a UE may be used to identify the UE in communications with the UE. In an example in which the RNTI is a C-RNTI, a transmission (e.g., a unicast transmission) may be addressed to the RNTI (e.g., C-RNTI) of the UE if the UE is the intended recipient of the transmission. In an example in which the RNTI is a G-RNTI, a transmission (e.g., a multicast transmission) may be addressed to the RNTI (e.g., G-RNTI) associated with a plurality of UEs (e.g., a group of UEs) comprising the UE if the plurality of UEs, comprising the UE, are intended recipients of the transmission.

The UE may receive/detect a first transmission (and/or control channel, such as PDCCH, comprising the first transmission) using the RNTI. The first transmission that is addressed to the RNTI may comprise an indication of the RNTI. In some examples, in response to receiving/detecting the first transmission (and/or the control channel) addressed to the RNTI, the UE may attempt to receive/detect one or more second transmissions on a data channel (e.g., PDSCH) using information carried by the first transmission. The information carried by the first transmission may comprise information indicative of (i) HARQ process information associated with the one or more second transmissions, (ii) whether a transmission of the one or more second transmissions is a new transmission or a retransmission, and/or (iii) other information associated with the one or more second transmissions and/or the data channel. The HARQ process information carried by the first transmission may identify a HARQ process (e.g., the HARQ process information may comprise a HARQ process ID of the HARQ process). In some examples, the UE receives/detects the one or more second transmissions and/or communicates (e.g., performs monitoring, reception/detection and/or transmission) on the data channel in accordance with the HARQ process.

One, some and/or all of the foregoing examples, concepts, techniques and/or embodiments can be formed and/or combined to a new embodiment.

Various techniques, embodiments, methods and/or alternatives of the present disclosure may be performed independently and/or separately from one another. Alternatively and/or additionally, various techniques, embodiments, methods and/or alternatives of the present disclosure may be combined and/or implemented using a single system. Alternatively and/or additionally, various techniques, embodiments, methods and/or alternatives of the present disclosure may be implemented concurrently and/or simultaneously.

<FIG> is a flow chart <NUM> according to one exemplary embodiment from the perspective of a UE. In step <NUM>, the UE receives/detects a transmission of data (e.g., downlink data) from a network, wherein the transmission of the data is addressed to a G-RNTI for a HARQ process. In an example, the transmission of the data is associated with (e.g., performed using and/or performed as part of) the HARQ process. In step <NUM>, in response to receiving/detecting the transmission of the data, the UE (i) starts a first HARQ RTT timer associated with the G-RNTI for the HARQ process, and (ii) starts a second HARQ RTT timer associated with a C-RNTI for the HARQ process. In an example, the UE concurrently (e.g., simultaneously) starts the first HARQ RTT timer and the second HARQ RTT timer. In an example, the first HARQ RTT timer and/or the second HARQ RTT timer are associated with (e.g., used by) the HARQ process. In step <NUM>, the UE starts a multicast retransmission timer for the HARQ process in response to (e.g., upon) expiry of the first HARQ RTT timer. In an example, the multicast retransmission timer is associated with (e.g., used by) the HARQ process. In step <NUM>, the UE starts a unicast retransmission timer for the HARQ process in response to (e.g., upon) expiry of the second HARQ RTT timer. In an example, the unicast retransmission timer is associated with (e.g., used by) the HARQ process. In step <NUM>, the UE receives/detects a first retransmission of the data addressed to the G-RNTI for the HARQ process. In an example, the first retransmission of the data is associated with (e.g., performed using and/or performed as part of) the HARQ process. In an example, the first retransmission of the data is a multicast transmission from the network. In step <NUM>, in response to receiving/detecting the first retransmission of the data, the UE (i) stops the multicast retransmission timer, and (ii) stops the unicast retransmission timer. In an example, the UE concurrently (e.g., simultaneously) stops the multicast retransmission timer and the unicast retransmission timer.

Preferably, the first HARQ RTT timer (associated with the G-RNTI) is the same as the second HARQ RTT timer (associated with the C-RNTI).

Preferably, the first HARQ RTT timer (associated with the G-RNTI) is different than the second HARQ RTT timer (associated with the C-RNTI).

Preferably, the UE starts the first HARQ RTT timer (associated with the G-RNTI) and the second HARQ RTT timer (associated with the C-RNTI) in response to transmission of NACK information. In an example, the UE transmits the NACK information (to the network, for example) in response to receiving/detecting the transmission of the data (e.g., the NACK information may indicate that the UE did not successfully decode the data carried by the transmission of the data). In an example, the UE transmits the NACK information based on the UE not having successfully decoded the data carried by the transmission of the data.

Preferably, the UE receives/detects a second retransmission of the data addressed to the C-RNTI for the HARQ process. In an example, the second retransmission of the data is associated with (e.g., performed using and/or performed as part of) the HARQ process. In an example, the second retransmission of the data is a unicast transmission from the network. In response to receiving/detecting the second retransmission of the data, the UE (i) stops the multicast retransmission timer, and (ii) stops the unicast retransmission timer.

Preferably, the UE does not start the multicast retransmission timer in response to receiving/detecting the second retransmission of the data.

Preferably, the UE monitors PDCCH when the multicast retransmission timer is running and/or the unicast retransmission timer is running.

Preferably, the G-RNTI is used by the UE for receiving services (e.g., different services) from the network.

Preferably, the G-RNTI is associated with a group of UEs, comprising the UE, that receive services (e.g., different services) from the network. In an example, the group of UEs use the G-RNTI to receive services (e.g., different services) from the network.

Preferably, the UE transmits, to the network, NACK information for the HARQ process if the data is not successfully decoded. For example, in response to receiving/detecting the transmission of the data, the UE may transmit NACK information (e.g., the NACK information may indicate that the UE did not successfully decode the data transmitted via the transmission) if the UE does not successfully decode the data transmitted via the transmission. Alternatively and/or additionally, in response to receiving/detecting the first retransmission of the data, the UE may transmit NACK information (e.g., the NACK information may indicate that the UE did not successfully decode the data transmitted via the first retransmission) if the UE does not successfully decode the data transmitted via the first retransmission. Alternatively and/or additionally, in response to receiving/detecting the second retransmission of the data, the UE may transmit NACK information (e.g., the NACK information may indicate that the UE did not successfully decode the data transmitted via the second retransmission) if the UE does not successfully decode the data transmitted via the first retransmission.

Preferably, the network comprises a gNB.

Preferably, the data comprises a TB and/or a MAC PDU.

Referring back to <FIG> and <FIG>, in one exemplary embodiment of a UE, the device <NUM> includes a program code <NUM> stored in the memory <NUM>. The CPU <NUM> could execute program code <NUM> to enable the UE (i) to receive/detect a transmission of data (e.g., downlink data) from a network, wherein the transmission of the data is addressed to a G-RNTI for a HARQ process, (ii) in response to receiving/detecting the transmission of the data, to (A) start a first HARQ RTT timer associated with the G-RNTI for the HARQ process, and (B) start a second HARQ RTT timer associated with a C-RNTI for the HARQ process, (iii) to start a multicast retransmission timer for the HARQ process in response to (e.g., upon) expiry of the first HARQ RTT timer, (iv) to start a unicast retransmission timer for the HARQ process in response to (e.g., upon) expiry of the second HARQ RTT timer, (v) to receive/detect a first retransmission of the DL data addressed to the G-RNTI for the HARQ process, and (vi) in response to receiving/detecting the first retransmission of the data, to (A) stop the multicast retransmission timer, and (B) stop the unicast retransmission timer. Furthermore, the CPU <NUM> can execute the program code <NUM> to perform one, some and/or all of the above-described actions and steps and/or others described herein.

<FIG> is a flow chart <NUM> according to one exemplary embodiment from the perspective of a UE. In step <NUM>, the UE receives/detects a transmission of data (e.g., downlink data), associated with a HARQ process, from a network. In an example, the transmission of the data is associated with (e.g., performed using and/or performed as part of) the HARQ process. In step <NUM>, in response to receiving/detecting the transmission of the data, the UE (i) starts a first HARQ RTT timer associated with a G-RNTI for the HARQ process if the transmission of the data is addressed to the G-RNTI, and/or (ii) starts a second HARQ RTT timer associated with a C-RNTI for the HARQ process if the transmission of the data is addressed to the G-RNTI or the C-RNTI. For example, if the transmission of the data is addressed to the G-RNTI, the UE starts the first HARQ RTT timer and the second HARQ RTT timer in response to receiving/detecting the transmission of the data (e.g., the UE may concurrently, such as simultaneously, start the first HARQ RTT timer and the second HARQ RTT timer). If the transmission of the data is addressed to the C-RNTI, the UE starts the second HARQ RTT timer (and does not start the first HARQ RTT timer, for example) in response to receiving/detecting the transmission of the data. In an example, the first HARQ RTT timer and/or the second HARQ RTT timer are associated with (e.g., used by) the HARQ process. In step <NUM>, the UE starts a multicast retransmission timer for the HARQ process in response to (e.g., upon) expiry of the first HARQ RTT timer. In an example, the multicast retransmission timer is associated with (e.g., used by) the HARQ process. In step <NUM>, the UE starts a unicast retransmission timer for the HARQ process in response to (e.g., upon) expiry of the second HARQ RTT timer. In an example, the unicast retransmission timer is associated with (e.g., used by) the HARQ process. In step <NUM>, the UE receives/detects a first retransmission of the data addressed to the G-RNTI or the C-RNTI for the HARQ process. In an example, the first retransmission of the data is associated with (e.g., performed using and/or performed as part of) the HARQ process. In an example, the first retransmission of the data is from the network. In step <NUM>, in response to receiving/detecting the first retransmission of the data, the UE (i) stops the multicast retransmission timer, and (ii) stops the unicast retransmission timer.

Preferably, the UE transmits, to the network, NACK information for the HARQ process if the data is not successfully decoded. For example, in response to receiving/detecting the transmission of the data, the UE may transmit NACK information (e.g., the NACK information may indicate that the UE did not successfully decode the data transmitted via the transmission) if the UE does not successfully decode the data transmitted via the transmission. Alternatively and/or additionally, in response to receiving/detecting the first retransmission of the data, the UE may transmit NACK information (e.g., the NACK information may indicate that the UE did not successfully decode the data transmitted via the first retransmission) if the UE does not successfully decode the data transmitted via the first retransmission.

Referring back to <FIG> and <FIG>, in one exemplary embodiment of a UE, the device <NUM> includes a program code <NUM> stored in the memory <NUM>. The CPU <NUM> could execute program code <NUM> to enable the UE (i) to receive/detect a transmission of data (e.g., downlink data), associated with a HARQ process, from a network, (ii) in response to receiving/detecting the transmission of the data, to (A) start a first HARQ RTT timer associated with a G-RNTI for the HARQ process if the transmission of the data is addressed to the G-RNTI, and/or (B) start a second HARQ RTT timer associated with a C-RNTI for the HARQ process if the transmission of the data is addressed to the G-RNTI or the C-RNTI, (iii) to start a multicast retransmission timer for the HARQ process in response to (e.g., upon) expiry of the first HARQ RTT timer, (iv) to start a unicast retransmission timer for the HARQ process in response to (e.g., upon) expiry of the second HARQ RTT timer, (v) to receive/detect a first retransmission of the DL data addressed to the G-RNTI or the C-RNTI for the HARQ process, and (vi) in response to receiving/detecting the first retransmission of the data, to (A) stop the multicast retransmission timer, and (B) stop the unicast retransmission timer. Furthermore, the CPU <NUM> can execute the program code <NUM> to perform one, some and/or all of the above-described actions and steps and/or others described herein.

<FIG> is a flow chart <NUM> according to one exemplary embodiment from the perspective of a UE. In step <NUM>, the UE receives/detects a transmission of data (e.g., downlink data) from a network, wherein the transmission of the data is addressed to a G-RNTI for a HARQ process. In an example, the transmission of the data is associated with (e.g., performed using and/or performed as part of) the HARQ process. In step <NUM>, in response to receiving/detecting the transmission of the data, the UE (i) starts a first HARQ RTT timer associated with the G-RNTI for the HARQ process, and (ii) starts a second HARQ RTT timer associated with a C-RNTI for the HARQ process. In an example, the UE concurrently (e.g., simultaneously) starts the first HARQ RTT timer and the second HARQ RTT timer. In an example, the first HARQ RTT timer and/or the second HARQ RTT timer are associated with (e.g., used by) the HARQ process. In step <NUM>, the UE starts a multicast retransmission timer for the HARQ process in response to (e.g., upon) expiry of the first HARQ RTT timer. In an example, the multicast retransmission timer is associated with (e.g., used by) the HARQ process. In step <NUM>, the UE starts a unicast retransmission timer for the HARQ process in response to (e.g., upon) expiry of the second HARQ RTT timer. In an example, the unicast retransmission timer is associated with (e.g., used by) the HARQ process. In step <NUM>, the UE receives/detects a first retransmission of the data addressed to the C-RNTI for the HARQ process. In an example, the first retransmission of the data is associated with (e.g., performed using and/or performed as part of) the HARQ process. In an example, the first retransmission of the data is a unicast transmission from the network. In step <NUM>, in response to receiving/detecting the first retransmission of the data, the UE (i) stops the multicast retransmission timer, and (ii) stops the unicast retransmission timer. In an example, the UE concurrently (e.g., simultaneously) stops the multicast retransmission timer and the unicast retransmission timer.

Preferably, the UE does not start the multicast retransmission timer in response to receiving/detecting the first retransmission of the data.

Referring back to <FIG> and <FIG>, in one exemplary embodiment of a UE, the device <NUM> includes a program code <NUM> stored in the memory <NUM>. The CPU <NUM> could execute program code <NUM> to enable the UE (i) to receive/detect a transmission of data (e.g., downlink data) from a network, wherein the transmission of the data is addressed to a G-RNTI for a HARQ process, (ii) in response to receiving/detecting the transmission of the data, to (A) start a first HARQ RTT timer associated with the G-RNTI for the HARQ process, and (B) start a second HARQ RTT timer associated with a C-RNTI for the HARQ process, (iii) to start a multicast retransmission timer for the HARQ process in response to (e.g., upon) expiry of the first HARQ RTT timer, (iv) to start a unicast retransmission timer for the HARQ process in response to (e.g., upon) expiry of the second HARQ RTT timer, (v) to receive/detect a first retransmission of the DL data addressed to the C-RNTI for the HARQ process, and (vi) in response to receiving/detecting the first retransmission of the data, to (A) stop the multicast retransmission timer, and (B) stop the unicast retransmission timer. Furthermore, the CPU <NUM> can execute the program code <NUM> to perform one, some and/or all of the above-described actions and steps and/or others described herein.

A communication device (e.g., a UE, a network such as a gNB and/or a base station, etc.) may be provided, wherein the communication device may comprise a control circuit, a processor installed in the control circuit and/or a memory installed in the control circuit and coupled to the processor. The processor may be configured to execute a program code stored in the memory to perform method steps illustrated in <FIG>. Furthermore, the processor may execute the program code to perform one, some and/or all of the above-described actions and steps and/or others described herein.

A computer-readable medium may be provided. The computer-readable medium may be a non-transitory computer-readable medium. The computer-readable medium may comprise a flash memory device, a hard disk drive, a disc (e.g., a magnetic disc and/or an optical disc, such as at least one of a digital versatile disc (DVD), a compact disc (CD), etc.), and/or a memory semiconductor, such as at least one of static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), etc. The computer-readable medium may comprise processor-executable instructions, that when executed cause performance of one, some and/or all method steps illustrated in <FIG>, and/or one, some and/or all of the above-described actions and steps and/or others described herein.

It may be appreciated that applying one or more of the techniques presented herein may result in one or more benefits including, but not limited to, increased efficiency of communication between devices (e.g., a UE and/or a network, such as a gNB), such as due, at least in part, to reducing active time for G-RNTI monitoring (and/or reducing the amount of time the UE spends performing G-RNTI monitoring, such as monitoring for multicast retransmissions). For example, in some systems, the UE may monitor for and/or receive multicast retransmissions of data even when the network has decided to schedule unicast retransmissions for the data (thereby wasting power of the UE, for example). However, using one or more of the techniques herein, the UE may be enabled to receive a unicast retransmission of data without having to monitor for multicast retransmissions of the same data, thereby providing for reduction of power consumption of the UE.

Various aspects of the disclosure have been described above. It should be apparent that the teachings herein may be embodied in a wide variety of forms and that any specific structure, function, or both being disclosed herein is merely representative. Based on the teachings herein one skilled in the art should appreciate that an aspect disclosed herein may be implemented independently of any other aspects and that two or more of these aspects may be combined in various ways. As an example of some of the above concepts, in some aspects concurrent channels may be established based on pulse repetition frequencies. In some aspects concurrent channels may be established based on pulse position or offsets. In some aspects concurrent channels may be established based on time hopping sequences. In some aspects concurrent channels may be established based on pulse repetition frequencies, pulse positions or offsets, and time hopping sequences.

Those of skill would further appreciate that the various illustrative logical blocks, modules, processors, means, circuits, and algorithm steps described in connection with the aspects disclosed herein may be implemented as electronic hardware (e.g., a digital implementation, an analog implementation, or a combination of the two, which may be designed using source coding or some other technique), various forms of program or design code incorporating instructions (which may be referred to herein, for convenience, as "software" or a "software module"), or combinations of both.

It is understood that any specific order or hierarchy of steps in any disclosed process is an example of a sample approach. Based on design preferences, it is understood that the specific order or hierarchy of steps in the processes may be rearranged while remaining within the scope of the present disclosure. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented.

The steps of a method or algorithm described in connection with the aspects disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module (e.g., including executable instructions and related data) and other data may reside in a data memory such as RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of computer-readable storage medium known in the art. A sample storage medium may be coupled to a machine such as, for example, a computer/processor (which may be referred to herein, for convenience, as a "processor") such the processor can read information (e.g., code) from and write information to the storage medium. A sample storage medium may be integral to the processor. The ASIC may reside in user equipment. In the alternative, the processor and the storage medium may reside as discrete components in user equipment. Alternatively and/or additionally, in some aspects any suitable computer-program product may comprise a computer-readable medium comprising codes relating to one or more of the aspects of the disclosure. In some aspects a computer program product may comprise packaging materials.

Claim 1:
A method of a User Equipment, UE, the method comprising:
at least one of receiving or detecting a first Physical Downlink Control Channel, PDCCH, of a transmission of data from a network, wherein the transmission of the data is addressed to a Group Radio Network Temporary Identifier, G-RNTI, for a Hybrid Automatic Repeat Request, HARQ, process (<NUM>);
in response to at least one of receiving or detecting the first PDCCH of the transmission of the data:
starting a multicast HARQ Round Trip Time, RTT, timer for the HARQ process; and
starting a unicast HARQ RTT timer for the HARQ process (<NUM>);
in response to expiry of the multicast HARQ RTT timer, starting a multicast retransmission timer for the HARQ process (<NUM>);
in response to expiry of the unicast HARQ RTT timer, starting a unicast retransmission timer for the HARQ process (<NUM>);
at least one of receiving or detecting a second PDCCH of a first retransmission of the data addressed to the G-RNTI for the HARQ process (<NUM>); and
in response to at least one of receiving or detecting the second PDCCH of the first retransmission of the data:
stopping the multicast retransmission timer; and
stopping the unicast retransmission timer (<NUM>).