UE in RRC inactive / idle state for PTM retransmission reception using DRX

Abstract

Described herein is a user equipment, UE, comprising: at least one processor, and at least one memory storing instructions that, when executed by the at least one processor, cause the UE to at least: receive a configuration message from a network node during or prior to a multicast / broadcast service, MBS, session, the configuration message configuring at least one retransmission timer; when the UE is in an inactive state or an idle state, a physical downlink control channel (PDCCH) transmission is received, the PDCCH transmission is associated with the MBS session, and a transport block (TB) of the MBS session is scheduled with a group identifier identifying a UE group, the UE group comprising: a UE in an inactive state or an idle state, and one or more UEs in a connected state; receiving the scheduled TB in an inactive state or an idle state via a point-to-multipoint PTM physical downlink shared channel (PDSCH) transmission associated with the MBS session; and in the event of determining that decoding of the received TB fails: starting at least one retransmission timer based on the configuration message; and before the at least one retransmission timer expires, monitoring a PDCCH for at least one PTM retransmission for the failed TB, the at least one PTM retransmission being requested by the one or more UEs in the connected state via at least one Hybrid Automatic Repeat Request (HARQ) feedback to the network node.

Description

Technical Field

[0001] This disclosure relates to NR multicast / broadcast services and, in particular, to the reception of point-to-multipoint transmissions at a user equipment. Background Art

[0002] Any discussion of background art throughout the specification should not be construed as an admission that such art is well known or forms part of the common general knowledge in the field.

[0003] Rel-18 focuses on multicast reception by UEs in the RRC_INACTIVE state. It is expected that such UEs will receive the same PDSCH transmissions as UEs in the RRC_CONNECTED state that also receive the same multicast service.

[0004] However, it is currently unclear how an RRC_INACTIVE( / IDLE) UE can receive point-to-multipoint (PTM) retransmissions requested by an RRC_CONNECTED UE. Since a UE in the RRC_INACTIVE( / IDLE) state does not send any HARQ feedback, how does such a UE know when a potential retransmission (requested by a UE in the RRC_CONNECTED mode) might occur?

[0005] If DRX is configured for multicast, the DRX retransmission timer should also be configured for inactive ( / idle) UEs, as has been proposed for connected UEs with HARQ feedback disabled. Even if the UE is configured with a DRX retransmission timer, it is unclear when to start the DRX HARQ RTT timer because a UE in the inactive or idle state does not send HARQ feedback and, by definition, the HARQ RTT timer is started after sending HARQ feedback. Since an inactive ( / idle) UE is not configured with PUCCH resources and may therefore not be able to understand the HARQ feedback-related parameters in the DCI scheduling the PTM transmission and thus does not know when the DRX HARQ RTT timer should be started.

[0006] Related prior art is, for example:

[0007] - 3GPP Rel-15 / 16 / 17 / 18 specifications.

[0008] - Nokia's contribution R2-2306392 regarding Rel-17 amendments proposes that for UEs with HARQ feedback disabled, a DRX PTM retransmission timer can also be configured so that these UEs can receive PTM retransmissions requested by other UEs with HARQ feedback not disabled. It also proposes that if these UEs know when HARQ feedback should be sent (if enabled), they will start the DRX HARQ RTT timer. This disclosure focuses on another scenario where UEs in the RRC_INACTIVE state or RRC_IDLE state and not configured with PUCCH resources are intended to be able to receive retransmissions from UEs in the RRC_CONNECTED state.

[0009] Therefore, when a UE is configured with DRX, a means is needed to enable UEs in the RRC_INACTIVE( / IDLE) state to receive retransmissions originating from RRC_CONNECTED UEs. Summary of the Invention

[0010] According to a first aspect of the present disclosure, there is provided a user equipment UE, the UE comprising:

[0011] At least one processor, and

[0012] At least one memory storing instructions which, when executed by the at least one processor, cause the UE to at least: during or before a multicast / broadcast service MBS session:

[0013] Receive a configuration message from a network node, the configuration message configuring at least one retransmission timer;

[0014] When the UE is in an inactive state or an idle state, receive a physical downlink control channel PDCCH transmission associated with the MBS session and using a group identifier to schedule a transport block TB of the MBS session, the group identifier identifying a UE group comprising: UEs in an inactive state or an idle state, and one or more UEs in a connected state;

[0015] Receive the scheduled TB in the inactive state or the idle state via a point-to-multipoint PTM physical downlink shared channel PDSCH transmission associated with the MBS session; and

[0016] In the case of determining a failure in decoding the received TB:

[0017] Based on the configuration message, start at least one retransmission timer; and

[0018] Monitor a Physical Downlink Control Channel (PDCCH) for at least one Point-to-Multipoint (PTM) retransmission for a failed Transport Block (TB) before at least one retransmission timer expires, where the at least one PTM retransmission is requested by one or more User Equipments (UEs) in a connected state via at least one Hybrid Automatic Repeat reQuest (HARQ) feedback to a network node.

[0019] In some examples, the at least one retransmission timer includes at least one of a HARQ Round-Trip Time (RTT) timer and a Discontinuous Reception (DRX) retransmission timer.

[0020] Wherein the UE is configured in an inactive state or an idle state to:

[0021] Receive Downlink Control Information (DCI) via PDCCH transmission, the DCI including a timing indicator for indicating a time slot for at least one HARQ feedback.

[0022] After a predetermined symbol in the indicated time slot, start the HARQ RTT timer; and

[0023] After the HARQ RTT timer expires, start the DRX retransmission timer.

[0024] As described in more detail below, the HARQ RTT timer can be used to reduce unnecessary monitoring of PTM retransmissions. The duration of the HARQ RTT timer can be based on an estimate of the round-trip time between the UE and the network node, i.e., it can be understood as depicting the minimum time for receiving a PTM retransmission.

[0025] In some examples, the monitoring is stopped based on the expiration of the retransmission timer.

[0026] In some examples:

[0027] The indicated time slot includes a plurality of symbols.

[0028] The UE is pre-configured with a fixed number that indicates the corresponding symbol included in the indicated time slot as a default predetermined symbol for all Multimedia Broadcast Multicast Service (MBS) sessions, or

[0029] The configuration message also configures the UE with a specific number that indicates the corresponding symbol of the indicated time slot as a predetermined symbol for a specific MBS session or as a default for all MBS sessions.

[0030] In some examples, the UE is configured to:

[0031] When the predetermined symbol is the first symbol in the indicated time slot, extend the configured DRX retransmission timer by at least one additional time slot.

[0032] In some examples, the configuration message is per Temporary Mobile Group Identity (TMGI) or corresponding identifier that identifies a specific multicast service or all multicast services of a UE group.

[0033] In some examples, the configuration message includes information that is also used to configure a list of values for the UE, where the list of values is used to interpret a timing indicator by referring to a value included in the list, and where the UE is configured to determine a time slot based on a value in the list indicated by the received timing indicator.

[0034] In some examples:

[0035] The configuration message includes a complete PUCCH configuration for the UE, and

[0036] In addition to the timing indicator, the DCI also includes a PUCCH Resource Indicator (PRI) that indicates a predetermined symbol included in the time slot indicated by the timing indicator for transmitting at least one HARQ feedback.

[0037] In some examples, the timing indicator is a PDSCH-to-HARQ_feedback timing indicator, where the list is provided via the dl-DataToUL-ACK parameter or the dl-DataToUL-ACK-MulticastDCI-Format4-1 parameter, or the list includes the values {1, 2, 3, 4, 5, 6, 7, 8}. These parameters can be found in documents such as the 3GPP specifications for 5G New Radio.

[0038] In some examples, the UE is configured to receive the same PDCCH transmissions associated with an MBS session as one or more UEs in the connected state in the inactive state or the idle state.

[0039] In some examples:

[0040] The PTM PDSCH transmission for a failed transport block (TB) includes multiple symbols,

[0041] where the UE is also made to, in the inactive state or the idle state:

[0042] Start at least one retransmission timer after the last symbol included in the PTM PDSCH transmission for the failed TB.

[0043] In some examples:

[0044] The UE is configured in the inactive state or the idle state to receive downlink control information DCI for scheduling a failed TB transmission via PDCCH transmission, where the DCI includes: information for indicating a time slot in which HARQ feedback for the failed TB is sent by one or more UEs in the connected state.

[0045] wherein the UE is further caused to, in the inactive state or the idle state:

[0046] Determine to start at least one retransmission timer in the indicated time slot.

[0047] In some examples, the UE is further caused to:

[0048] Before receiving the configuration message, receive a signaling message from a network node, the signaling message particularly including an RRC release message, for being configured with a set of retransmission timers, each retransmission timer being configured for a corresponding cell serving the UE or for a corresponding MBS session;

[0049] Receive a configuration message indicating one retransmission timer from the set of indicated retransmission timers to the UE;

[0050] And start the indicated retransmission timer.

[0051] In some examples, the configuration message is a radio resource control RRC release message or an MBS control channel MCCH message.

[0052] According to a second aspect of the present disclosure, there is provided a network node of a radio access network, the network node being configured to establish communication with a UE group, the group being identified by a group identifier, the network node including:

[0053] At least one processor, and

[0054] At least one memory storing instructions that, when executed by the at least one processor, cause the network node to at least: during or before a multicast / broadcast service MBS session:

[0055] Send a configuration message to at least one UE among a plurality of UEs, the configuration message being used to configure at least one retransmission timer for at least one UE, where at least one UE is in the inactive state or the idle state, and at least one UE is in the connected state;

[0056] Schedule a transmission block TB to the UE group identified by the group identifier via transmission on one or more physical downlink control channels PDCCH associated with the MBS session;

[0057] Transmit the scheduled TB to a group of UEs identified by a group identifier via a point-to-multipoint PTM physical downlink shared channel PDSCH associated with an MBS session;

[0058] In response to receiving at least one hybrid automatic repeat request HARQ feedback indicating a failure to decode the TB from at least one UE in a connected state, determine resources for retransmission of the transmitted TB; and

[0059] Initiate retransmission of the failed TB at the determined resources and based on at least one retransmission timer configured for at least one UE in an inactive state or an idle state,

[0060] where the configuration message includes information for at least one UE in an inactive state or an idle state to determine when to start at least one retransmission timer based on the configuration message.

[0061] In some examples, the at least one retransmission timer includes at least one of a HARQ round-trip time RTT timer and a discontinuous reception DRX retransmission timer,

[0062] where the network node is further caused to:

[0063] Transmit downlink control information DCI to at least one UE in an inactive state or an idle state via PDCCH, the DCI including a timing indicator for indicating a time slot for at least one HARQ feedback,

[0064] where the configuration message further includes information for configuring at least one UE to determine to start a HARQ RTT timer after a predetermined symbol in the indicated time slot.

[0065] As described in more detail below, the HARQ RTT timer can be used to reduce unnecessary monitoring of PTM retransmissions. The duration of the HARQ RTT timer can be based on an estimate of the round-trip time between the UE and the network node, i.e., can be understood as depicting the minimum time for receiving a PTM retransmission.

[0066] In some examples, the configuration message further includes information for configuring at least one UE to stop monitoring based on the expiration of the retransmission timer.

[0067] In some examples, the indicated time slot includes multiple symbols, and

[0068] the network node is further caused to pre-configure a fixed number for at least one UE, the fixed number indicating a corresponding symbol included in the indicated time slot, the corresponding symbol being a default predetermined symbol for all MBS sessions; or

[0069] The configuration message also configures at least one UE with a specific number that indicates the corresponding symbol of the indicated time slot as: a predetermined symbol for a specific MBS session, or default for all MBS sessions.

[0070] In some examples, the network node is configured to:

[0071] When the predetermined symbol is the first symbol in the indicated time slot, indicate that at least one UE extends the configured DRX retransmission timer by at least one additional time slot.

[0072] In some examples, the network node is also made to:

[0073] Send the configuration message per Temporary Mobile Group Identity (TMGI) or corresponding identifier that identifies a specific multicast service or all multicast services being sent to a group of UEs.

[0074] In some examples, the configuration message includes information for also configuring at least one UE with a list of values used to interpret a timing indicator by referring to the values included in the list, and wherein at least one UE is configured to: determine a time slot based on one of the values of the list indicated by the received timing indicator.

[0075] In some examples:

[0076] The configuration message includes a complete PUCCH configuration, and

[0077] In addition to the timing indicator, the DCI also includes a PUCCH Resource Indicator (PRI) that indicates: a predetermined symbol included in the time slot indicated by the timing indicator for transmitting at least one negative HARQ feedback.

[0078] In some examples, the timing indicator is a PDSCH-to-HARQ_feedback timing indicator, where the list is provided via the dl-DataToUL-ACK parameter or the dl-DataToUL-ACK-MulticastDCI-Format4-1 parameter, or the list includes the values {1, 2, 3, 4, 5, 6, 7, 8}. These parameters can be found in documents such as the 3GPP specifications for 5G New Radio.

[0079] In some examples, the network node is configured to: provide at least one UE in an inactive state or idle state with the same PDCCH transmission associated with an MBS session as the remaining UEs in a connected state.

[0080] In some examples:

[0081] The PTM PDSCH transmission for a failed TB includes multiple symbols; and

[0082] A network node is caused to indicate to at least one UE in an inactive state or an idle state:

[0083] To start at least one retransmission timer after the last symbol included in the PTM PDSCH transmission for the failed TB.

[0084] In some examples, the network node is further caused to: transmit, via PDCCH, downlink control information DCI for scheduling the transmission of the failed TB to at least one UE in an inactive state or an idle state, where the DCI includes timing indicator information for indicating the time slot in which at least one HARQ feedback is sent by the remaining UEs in a connected state in response to the failed TB; and

[0085] A network node is caused to indicate to at least one UE in an inactive state or an idle state:

[0086] To determine to start at least one retransmission timer in the indicated time slot.

[0087] In some examples, the network node is further caused to:

[0088] Before sending a configuration message, send a signaling message to at least one UE, the signaling message particularly including an RRC release message for configuring a set of retransmission timers for at least one UE, each retransmission timer being configured for the corresponding cell of at least one UE or for a corresponding MBS session; and

[0089] To indicate to at least one UE to select one retransmission timer from the set.

[0090] In some examples, the configuration message is a radio resource control RRC release message or an MBS control channel MCCH message.

[0091] According to a third aspect of the present disclosure, there is provided a system configured to support multicast / broadcast service MBS, the system including:

[0092] A user equipment UE group including UEs according to the first aspect and its related examples, and one or more UEs in a connected state configured to support hybrid automatic repeat request HARQ procedures, the group being identified by a group identifier; and

[0093] A network node according to the second aspect and its related examples, the network node being configured to schedule and transmit data associated with MBS to the group.

[0094] According to a fourth aspect of the present disclosure, there is provided a method for a user equipment UE during or before a multicast / broadcast service MBS session:

[0095] Receive a configuration message from a network node, the configuration message configuring at least one retransmission timer;

[0096] When the UE is in an inactive state or an idle state, receive a physical downlink control channel PDCCH transmission, the PDCCH transmission being associated with the MBS session and using a group identifier to schedule a transport block TB of the MBS session, the group identifier identifying a UE group that includes: UEs in an inactive state or an idle state, and one or more UEs in a connected state;

[0097] Receive the scheduled TB in an inactive state or an idle state via a point-to-multipoint PTM physical downlink shared channel PDSCH associated with the MBS session; and

[0098] In case of determining a failure in decoding the received TB:

[0099] Based on the configuration message, start at least one retransmission timer; and

[0100] Before at least one retransmission timer expires, monitor the PDCCH for at least one PTM retransmission of the failed TB, wherein the at least one PTM retransmission is requested by one or more UEs in a connected state via at least one hybrid automatic repeat request HARQ feedback to the network node.

[0101] According to a fifth aspect of the present disclosure, there is provided a method for a network node of a radio access network, the network node being configured to establish communication with a UE group identified by a group identifier, the method including: during or before a multicast / broadcast service MBS session:

[0102] Send a configuration message to at least one UE among a plurality of UEs, the configuration message being for configuring at least one retransmission timer for at least one UE, wherein at least one UE is in an inactive state or an idle state and the remaining UEs are in a connected state;

[0103] Schedule a transport block TB for the UE group identified by the group identifier via one or more physical downlink control channels PDCCH associated with the MBS session;

[0104] Send the scheduled TB to the UE group identified by the group identifier via a point-to-multipoint PTM physical downlink shared channel PDSCH associated with the MBS session;

[0105] In response to receiving at least one hybrid automatic repeat request (HARQ) feedback indicating a failure to decode a transport block (TB) at a UE group from the remaining UEs in a connected state, determine resources for retransmitting the transmitted TB; and

[0106] Initiate a retransmission of the failed TB at the determined resources and based on at least one retransmission timer configured for at least one UE in an inactive state or an idle state,

[0107] where the configuration message includes information for at least one UE in an inactive state or an idle state to determine when to start the at least one retransmission timer based on the configuration message.

[0108] According to a sixth aspect of the present disclosure, there is provided a computer program comprising instructions for causing an apparatus to perform the method according to the fourth aspect or for causing an apparatus to perform the method according to the fifth aspect.

[0109] According to a seventh aspect of the present disclosure, there is provided a memory storing computer-readable instructions for causing an apparatus to perform the method according to the fourth aspect or for causing an apparatus to perform the method according to the fifth aspect.

[0110] Furthermore, according to some other example embodiments, for example, there is provided a computer program product for a wireless communication device, the product comprising at least one processor including a software code portion for performing the corresponding steps disclosed in the present disclosure when the above product runs on the device. The computer program product may include a computer-readable medium having the above software code portion stored thereon. Furthermore, the computer program product may be directly loadable into the internal memory of a computer and / or may be sendable via a network by means of at least one of uploading, downloading, and pushing processes.

[0111] Although some example embodiments will be described herein with particular reference to the above applications, it should be understood that the present disclosure is not limited to such fields of use and is applicable to a broader context.

[0112] It should be noted that it should be understood that the method according to the present disclosure relates to a method of operating an apparatus according to the above example embodiments and their variations, and the corresponding statements made with respect to the apparatus equally apply to the corresponding method, and vice versa. Therefore, for the sake of brevity, similar descriptions may be omitted. Furthermore, even if not explicitly disclosed, the above aspects may be combined in various ways. Those skilled in the art will understand that these aspects and combinations of features / steps are possible unless it results in an explicitly excluded contradiction.

[0113] Implementations of the disclosed apparatus may include, but are not limited to, one or more processors, one or more application specific integrated circuits (ASICs), and / or one or more field programmable gate arrays (FPGAs). Implementations of the apparatus may also include the use of other conventional and / or custom hardware, such as software programmable processors, such as graphics processing unit (GPU) processors.

[0114] In the following discussion, other and additional example embodiments of the present disclosure will become apparent with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0115] Example embodiments of the present disclosure will now be described by way of example only with reference to the accompanying drawings, in which:

[0116] Figure 1 Schematically illustrates an example of a signaling diagram of PTM transmission (retransmission) according to an example embodiment of the present disclosure;

[0117] Figure 2 Schematically illustrates an example of a signaling diagram of PTM transmission (retransmission) according to an example embodiment of the present disclosure;

[0118] Figure 3 Schematically illustrates an example of a signaling diagram of PTM transmission (retransmission) according to an example embodiment of the present disclosure; and

[0119] Figure 4 Schematically illustrates an example of a signaling diagram of PTM transmission (retransmission) according to an example embodiment of the present disclosure. DETAILED DESCRIPTION

[0120] In the following, different exemplary embodiments will be described using as an example of a communication network a communication network architecture based on 3GPP standards (such as 5G / NR) for communication networks, without limiting the embodiments to such an architecture. It will be clear to those skilled in the art that the embodiments can also be applied to other types of communication networks, where the mobile communication principle is integrated with D2D (device-to-device) or V2X (vehicle-to-everything) configurations, such as SL (side chain), for example Wi-Fi, Worldwide Interoperability for Microwave Access (WiMAX), Personal Communication Service (PCS), Wideband Code Division Multiple Access (WCDMA), systems using Ultra Wideband (UWB) technology, Mobile Ad-hoc Network (MANET), wired access, etc. Furthermore, without loss of generality, some examples of the embodiments are described in relation to mobile communication networks, but the principles of the present disclosure can be extended and applied to any other type of communication network, such as a wired communication network.

[0121] The following examples and embodiments should only be understood as illustrative examples. Although the specification may refer to "an", "one", or "some" examples or embodiments in several places, this does not necessarily mean that each such reference relates to the same example or embodiment, nor that the feature only applies to a single example or embodiment. Individual features of different embodiments can also be combined to provide other embodiments. In addition, terms such as "comprising" and "including" should be understood not to limit the described embodiments to only consisting of the features already mentioned; such examples and embodiments may also include features, structures, units, modules, etc. not specifically mentioned.

[0122] The basic system architecture of a communication (telecom) network including a mobile communication system (to which some examples of embodiments are applicable) may include the architecture of one or more communication networks, including (a) radio access network subsystem(s) and (a) core network(s). Such an architecture may include one or more communication network control elements or functions, access network elements, radio access network elements, access service network gateways, or base station transceivers (such as base stations (BSs), access points (APs), NodeBs (NBs), eNBs, or gNBs), distributed units (DUs), or centralized / central units (CUs), which control the corresponding coverage areas or (a) cell(s), and one or more communication stations (such as communication elements or functions, such as user equipment or terminal devices, such as user equipment (UEs), or another device with a similar function, such as a modem chipset, chip, module, etc., which may also be part of a station, element, function, or application capable of communication, such as a UE, element, or function usable in a machine-to-machine communication architecture, or attached as a separate element to an element, function, or application capable of communication, etc.) can communicate through one or more channels via one or more communication beams to send several types of data in multiple access domains. In addition, core network elements or network functions may be included, such as gateway network elements / functions, mobility management entities, mobile switching centers, servers, databases, etc.

[0123] The following description may provide other details of alternatives, modifications, and variations: The gNB includes, for example, nodes that provide NR user plane and control plane protocol terminations towards the UE and are connected to the 5GC via the NG interface, for example, according to Section 3.2 of 3GPP TS 38.300 V16.6.0 (2021-06) incorporated by reference.

[0124] The gNB Central Unit (gNB-CU) includes, for example, a logical node that hosts, for example, the RRC, SDAP, and PDCP protocols of the gNB, or the RRC and PDCP protocols of an en-gNB that controls the operation of one or more gNB-DUs. The gNB-CU terminates the F1 interface connected to the gNB-DU.

[0125] The gNB Distributed Unit (gNB-DU) includes, for example, a logical node that hosts, for example, the RLC, MAC, and PHY layers of the gNB or en-gNB, and whose operation is partially controlled by the gNB-CU. One gNB-DU supports one or more cells. One cell is supported by only one gNB-DU. The gNB-DU terminates the F1 interface connected to the gNB-CU.

[0126] The gNB-CU Control Plane (gNB-CU-CP) includes, for example, a logical node that hosts, for example, the control plane part of the RRC and PDCP protocols of the gNB-CU for the en-gNB or gNB. The gNB-CU-CP terminates the E1 interface connected to the gNB-CU-UP and the F1-C interface connected to the gNB-DU.

[0127] The gNB-CU User Plane (gNB-CU-UP) includes, for example, a logical node that hosts, for example, the user plane part of the PDCP protocol of the gNB-CU for the en-gNB, and the user plane parts of the PDCP protocol and SDAP protocol of the gNB-CU for the gNB. The gNB-CU-UP terminates the E1 interface connected to the gNB-CU-CP and the F1-U interface connected to the gNB-DU, for example, according to Section 3.1 of 3GPP TS 38.401 V16.6.0 (2021-07) incorporated by reference.

[0128] There can be different functional splits between the central and distributed units, for example, which are referred to as options:

[0129] Option 1 (Split type 1A):

[0130] · The functional split in this option is similar to the 1A architecture in DC. RRC is located in the central unit. PDCP, RLC, MAC, the physical layer, and RF are located in the distributed unit.

[0131] Option 2 (Split type 3C):

[0132] · The functional split in this option is similar to the 3C architecture in DC. RRC and PDCP are located in the central unit. RLC, MAC, the physical layer, and RF are located in the distributed unit.

[0133] Option 3 (Split within RLC):

[0134] · The low RLC (part of the RLC functions), MAC, physical layer, and RF are located in the distributed unit. The PDCP and high RLC (the other part of the RLC functions) are located in the central unit.

[0135] Option 4 (RLC-MAC split):

[0136] · The MAC, physical layer, and RF are located in the distributed unit. The PDCP and RLC are located in the central unit.

[0137] Otherwise, for example, according to 3GPP TR 38.801 V14.0.0

[0138] (2017-03), Section 11.

[0139] The gNB supports different protocol layers, such as layer 1 (L1) - the physical layer.

[0140] The layer 2 (L2) of NR is split into the following sub-layers: Media Access Control (MAC), Radio Link Control (RLC), Packet Data Convergence Protocol (PDCP), and Service Data Adaptation Protocol (SDAP), where for example:

[0141] · The physical layer provides a transport channel to the MAC sub-layer;

[0142] · The MAC sub-layer provides a logical channel to the RLC sub-layer;

[0143] · The RLC sub-layer provides an RLC channel to the PDCP sub-layer;

[0144] · The PDCP sub-layer provides a radio bearer to the SDAP sub-layer;

[0145] · The SDAP sub-layer provides a QoS flow to the 5GC;

[0146] · Comp. refers to header compression and Segm. refers to segmentation;

[0147] · The control channels include (BCCH, PCCH).

[0148] The layer 3 (L3) includes, for example, Radio Resource Control (RRC), for example according to 3GPP TS 38.300 V16.6.0 (2021-06), Section 6.

[0149] A RAN (Radio Access Network) node or a network node (such as a gNB, a base station, a gNB CU or a gNB DU or a part thereof) can be implemented using, for example, a device having at least one processor and / or at least one memory (with computer-readable instructions (computer programs)), the device being configured to support and / or provide and / or process CU- and / or DU-related functions and / or features, and / or at least one protocol (sub)-layer of the RAN (Radio Access Network), such as layer 2 and / or layer 3.

[0150] The gNB CU and gNB DU parts can be, for example, co-located or physically separated. The gNB DU can even be further split into two parts, for example, one part includes processing equipment and the other part includes antennas. The Central Unit (CU) can also be referred to as BBU / REC / RCC / C-RAN / V-RAN, O-RAN or a part thereof. The Distributed Unit (DU) can also be referred to as RRH / RRU / RE / RU or a part thereof. Hereinafter, in various example embodiments of the present disclosure, the CU-CP (or more generally, the CU) can also be referred to as the (first) network node that supports at least one of the central unit control plane functions or the layer 3 protocol of the radio access network; and similarly, the DU can be referred to as the (second) network node that supports at least one of the distributed unit functions or the layer 2 protocol of the radio access network.

[0151] The gNB-DU supports one or more cells and can thus be used as, for example, the serving cell of a user equipment (UE).

[0152] A user equipment (UE) can include a wireless or mobile device, a device having a radio interface for interacting with the RAN (Radio Access Network), a smart phone, a vehicle-mounted device, an IoT device, an M2M device, etc. Such a UE or device can include: at least one processor; and at least one memory including computer program code; wherein the at least one memory and the computer program code are configured to, together with the at least one processor, cause the device to at least perform certain operations, such as an RRC connection with the RAN. The UE is, for example, configured to generate a message (for example, including a cell ID) to be sent to the RAN via radio (for example, to reach and communicate with the serving cell). The UE can generate, send and receive RRC messages containing one or more RRC PDUs (Packet Data Units).

[0153] The UE can have different states (for example, according to Sections 4.2.1 and 4.4 of 3GPP TS 38.331 V16.5.0 (2021-06) incorporated herein by reference).

[0154] When the RRC connection has been established, the UE is, for example, in the RRC_CONNECTED state or the RRC_INACTIVE state.

[0155] In the RRC_CONNECTED state, the UE can:

[0156] · Store the AS context;

[0157] · Transmit unicast data between UEs;

[0158] · Monitor the control channel associated with the shared data channel to determine whether data

[0159] channel schedules data;

[0160] · Provide channel quality and feedback information;

[0161] · Perform neighbor cell measurements and measurement reporting.

[0162] The RRC protocol includes, for example, the following main functions:

[0163] · RRC connection control;

[0164] · Measurement configuration and reporting;

[0165] · Establish / modify / release measurement configuration (e.g., intra-frequency, inter-frequency, and inter-RAT

[0166] measurements);

[0167] · Establishment and release of measurement gaps;

[0168] · Measurement reporting.

[0169] The general functions and interconnections of the described elements and functions (which also depend on the actual network type) are known to those skilled in the art and are described in the corresponding specification. Therefore, for the sake of brevity, their detailed description can be omitted here. However, it should be noted that, in addition to those described in detail below, several additional network elements and signaling links can be employed to communicate with elements, functions, or applications (such as communication endpoints), communication network control elements (such as servers, gateways, radio network controllers), and other elements of the same or other communication networks.

[0170] The communication network architecture considered in the examples of the embodiments may also be capable of communicating with other networks such as the public switched telephone network or the Internet. The communication network is also capable of supporting cloud services for virtual network elements or their functions, where it should be noted that the virtual network components of the telecommunications network may also be provided by non-cloud resources, such as an internal network, etc. It should be understood that the network elements and / or corresponding functions of the access system, core network, etc. may be implemented by using any node, host, server, access node, or entity suitable for such purposes. Generally, network functions may be implemented as network elements on dedicated hardware, software instances running on dedicated hardware, or virtualized functions instantiated on a suitable platform (e.g., a cloud infrastructure).

[0171] In addition, network elements (such as communication elements, such as a UE, a terminal device, a control element or function, such as an access network element, such as a base station / BS, gNB, radio network controller, a core network control element or function, such as a gateway element, or other network elements or functions described herein), and any other element, function or application can be implemented by software, for example, by a computer program product of a computer; and / or implemented by hardware. To perform its corresponding processing, the corresponding devices, nodes, functions or network elements used may include several components, modules, units, components, etc. (not shown) required for control, processing and / or communication / signaling functions. For example, such components, modules, units and components may include one or more processors or processor units, including one or more processing parts for executing instructions and / or programs and / or for processing data, a storage or memory unit or component (such as ROM, RAM, EEPROM, etc.) used as a workspace for the processor or processing part to store instructions, programs and / or data, an input or interface component (such as a floppy disk, CD-ROM, EEPROM, etc.) for inputting data and instructions by software, a user interface (such as a screen, keyboard, etc.) for providing the user with monitoring and manipulation possibilities, other interfaces or components (such as wired and wireless interface components, including radio interface components such as antenna units, components for forming a radio communication part, etc.) for establishing links and / or connections under the control of the processor unit or part, etc., where the corresponding components forming the interface (such as the radio communication part) may also be located at a remote site (such as a radio head or a radio station, etc.). It should be noted that in this specification, the processing part should not be regarded as only representing the physical part of one or more processors, but can also be regarded as a logical division of the indicated processing tasks executed by one or more processors. It should be understood that according to some examples, a so-called "liquid" or flexible network concept can be adopted, where the operations and functions of network elements, network functions or other entities of the network can be executed in a flexible manner in different entities or functions, such as in nodes, hosts or servers. In other words, the "division of labor" among the involved network elements, functions or entities may vary depending on the situation.

[0172] As described above, the present disclosure generally seeks to provide a means for a UE in the RRC_INACTIVE ( / IDLE) state to be able to receive retransmissions from an RRC_CONNECTED UE when the UE is configured with DRX.

[0173] In Rel-17, NR Multicast / Broadcast Service (MBS) allows UEs to receive multicast only in the RRC_CONNECTED state. In this document, Point-to-Multipoint (PTM) transmission efficiently supplies MBS services to multiple users by using the same radio framework as unicast transmission. Rel-17 only allows UEs in the RRC_CONNECTED state to receive multicast services. Even for PTM operations, the reliability of data reception is ensured via HARQ retransmissions and dynamic MCS selection. In addition, PTP transmission can also be configured for UEs in RRC_CONNECTED.

[0174] Starting from SA2 SI (SP-211645) in Rel-18, the further enhancements of the 5GS architecture are identified and evaluated to provide multicast and broadcast services. Currently, the normative work is starting to finalize the solutions agreed upon in TR 23.700-47. The main focus of SA2 SI is KI#1, which focuses on enabling UEs in the RRC_INACTIVE state to receive multicast services for scalability and energy-saving purposes:

[0175] KI#1: How can end-to-end MBS service delivery, including a large number of UEs, be supported and enhanced:

[0176] Enable UEs to receive multicast MBS session data in the RRC state while in the RRC inactive state.

[0177] After the SA2 work, RAN WID RP-213568 has been agreed upon for Rel-18, which includes the following objectives:

[0178] - Specify the support for multicast reception by UEs in the RRC_INACTIVE state

[0179] [RAN2,RAN3]

[0180] ○ PTM configuration for UEs receiving multicast in the RRC_INACTIVE state

[0181] [RAN2]

[0182] ○ Study the impact of mobility and state transitions on UEs receiving multicast in RRC_INACTIVE. (Seamless / lossless mobility is not required) [RAN2,RAN3]

[0183] When the UE is in the RRC_INACTIVE state, the configuration of multicast services in the cell should be applied to start / continue receiving the multicast services that the UE has joined. RAN2 / 3 is currently studying how this configuration should be implemented.

[0184] One option that has been agreed upon is to provide configuration using a method similar to Rel-17 broadcasting, i.e., the cell periodically broadcasts SIB / MCCH (Multicast Control Channel) so that RRC_INACTIVE UEs can receive the configuration itself and any updates to it. Additionally, when a UE is sent from RRC_CONNECTED to RRC_INACTIVE, the UE can be provided with the configuration to receive multicast services in the RRC_INACTIVE state while camping on the serving cell. The sending of the UE from RRC_CONNECTED to RRC_INACTIVE is performed via an RRC release message that includes suspendConfig.

[0185] Furthermore, it has been agreed that at least in some scenarios, there will be UEs in both RRC_CONNECTED and RRC_INACTIVE states receiving the same multicast data (PDSCH) and potentially the same PDCCH that schedules the data.

[0186] For Rel-17 MBS multicast in RRC_CONNECTED, the UE can be configured with Discontinuous Reception (DRX) to receive MBS multicast services, thus saving UE power. The DRX operation uses two configurable timers, namely the DRX HARQ / Hybrid ARQ RTT (Round-Trip Time) timer and the DRX retransmission timer (these timers are fully configured by the gNB for each UE) to indicate to the UE when to monitor for potential PTM retransmissions. The operation is summarized as follows:

[0187] 1: The UE receives a PDSCH transmission (e.g., PTM).

[0188] 2: The UE is typically configured with HARQ feedback and is indicated the PUCCH (Physical Uplink Control Channel) resources it will use for HARQ feedback.

[0189] 3: The UE sends HARQ feedback on the PUCCH and starts the DRX HARQ RTT timer at the end of the PUCCH symbol (e.g., if the PUCCH includes symbols 3 to 5 of a slot, the timer starts at the end of symbol 5).

[0190] Note that long PUCCH format 1 and format 3 are typically 14 symbols. Short PUCCH has two symbols, which are typically located at the end of a slot, but the specification also allows other locations.

[0191] 4: When the RTT timer expires, if the reception (decoding) of the PUSCH for the corresponding HARQ process is not successful, the UE starts the DRX retransmission timer and, while the DRX retransmission timer is running, the UE monitors the PDCCH for retransmissions.

[0192] In Rel-17, these HARQ retransmission related timers are configured only when HARQ feedback is enabled for the UE.

[0193] The parameter K1 (PDSCH-to-HARQ_feedback timing indicator) in the DCI (Downlink Control Information) / PDCCH points to the time slot of the PUCCH resource in which the HARQ feedback should be sent (if enabled). Another parameter in the DCI is the PRI (PUCCH Resource Indicator), which then selects which PUCCH resources ((multiple) symbols and frequency resources) will be used in that time slot. The interpretation of K1 and PRI is configured for the UE in the connected mode, rather than for the UE in the inactive / idle mode. Therefore, the UE in the inactive / idle mode does not know when the HARQ feedback will be sent if enabled, and thus also does not know when to start the DRX HARQ RTT timer.

[0194] Note that the number of PUCCH resources can vary according to the number of Orthogonal Cover Codes (OCCs), the number of symbols (short or long PUCCH), the number of PRBs, and the cyclic shift. Therefore, the PRI will indicate one PUCCH resource among those PUCCH resources configured in the PUCCH resource set.

[0195] One possible solution is to configure the complete PUCCH configuration for the UE in RRC_INACTIVE / IDLE, such that the UE will have the same information as the UE in the active mode, and thus will know exactly when the HARQ feedback should be sent if enabled. Then, based on the configuration and information received via the DCI, the UE in the inactive / idle mode will know exactly when to start the HARQ RTT timer, which activates the DRX retransmission timer upon expiration to receive potential HARQ PTM retransmissions. This will require additional configuration, the sole purpose of which is to receive potential PTM retransmissions, which, while enabling the proper start of the HARQ RTT timer, also increases the signaling overhead. In addition, the interpretation of the PRI depends on the actual HARQ feedback size to be generated. Therefore, this approach also requires more computation on the UE side to generate the HARQ feedback.

[0196] Note that in the case of ACK / NACK feedback, the UE selects the "PUCCH resource set" based on the size of the HARQ feedback it wants to send. Then, the PRI points to the correct PUCCH resource ((multiple) PRBs) in that PUCCH resource set. There can be up to 4 PUCCH resource sets. This means that different UEs receiving the same multicast transmission can send ACK / NACK feedback at different times or on different symbols.

[0197] In view of the above, it is proposed according to the present disclosure that instead of configuring a complete PUCCH configuration for a UE in the non-active / idle (RRC_INACTIVE / IDLE) mode, instead:

[0198] ○ The parameter dl-DataToUL-ACK-MulticastDCI-Format4-1 or dl-DataToUL-ACK can also be configured for a UE in the non-active / idle state, that is, this parameter can be provided to the UE via the MCCH or via an RRCRelease message, which can be per TMGI (MBS service) or a common message for all multicast services.

[0199] - Note that DCI formats 4_1 and 4_2 are used to schedule multicast data. For each of them, a list can be configured separately, namely dl-DataToUL

[0200] -ACK-MulticastDCI-Format4-1 or dl-DataToUL-ACK. K1=x in the transmitted DCI is mapped to the x-th row of this list to understand the time slot (= timing) of the PUCCH.

[0201] ○ Then the UE can use the existing rules to interpret K1

[0202] (PDSCH-to-HARQ_feedback timing indicator): For DCI format 4_1, the PDSCH-to-HARQ_feedback timing indicator field (K1) value is provided by dl-DataToUL-ACK-MulticastDCI-Format4-1, or if dl-DataToUL-ACK-MulticastDCI-Format4-1 is not provided, this value is provided by

[0203] {1,2,3,4,5,6,7,8}.

[0204] - For example:

[0205] K1 = 2

[0206] dl-DataToUL-ACK-MulticastDCI-Format4-1 or dl-DataToUL-ACK = {2,4,6,8,10,12,14,16}

[0207] PRI = 2

[0208] PUCCH configuration -> A number of PUCCH resources that the UE can use to send HARQ feedback in the future

[0209] Frequency domain:

[0210] Between 5.2 MHz and 5.25 MHz, there is PUCCH resource 1

[0211] Between 5.25 MHz and 5.30 MHz, there is PUCCH resource 2

[0212] Based on K1, the UE already knows the time slot in which it will send HARQ feedback, but does not know the exact symbol. To know this symbol, in practice, the UE should be configured with a complete PUCCH configuration (as shown in the above example). Therefore, according to the present disclosure, a method is proposed to, instead of configuring a complete PUCCH configuration for a UE in an inactive / idle mode, instead:

[0213] ○ The UE is configured with a new rule for starting the DRX HARQ RTT timer:

[0214] The UE always starts the timer in the nth symbol of the time slot indicated by K1, where n can be configurable or fixed in the standard (for example, always after the first symbol of the time slot, or always after the last symbol of the time slot). That is, if the configuration of n is not provided to the UE, the UE can use a fixed value of the symbol, and if the configuration is given, the UE can use the configured value of n. The new rule is provided via the same configuration (RRC release and / or MCCH), or is a pre-configured value at the UE, for example, always hard-coded as 1 by the standard.

[0215] ○ The network node (for example, an access node such as a gNB) can consider the knowledge of when an inactive / idle UE starts the DRX HARQ RTT timer to schedule retransmissions (anyway, the network has to do this because different UEs may send ACK / NACK for PTM transmissions in different symbols). Specifically, the network node can ensure that retransmissions are scheduled when the UE expects a retransmission (i.e., when the retransmission timer is running).

[0216] ○ Alternatively (especially if the HARQ RTT timer always starts after the first symbol of the time slot), the UE may need to extend the duration of the configured drx-RetransmissionTimerDL

[0217] - for PTM by one time slot to ensure that all potential PTM retransmissions are received. Since the UE may start the RTT timer in the first symbol, but other UEs in RRC_CONNECTED may start in the last symbol, the UE may need a retransmission timer that is 1 time slot larger to cover this difference.

[0218] Therefore, the proposed solution reduces the signaling volume because the complete PUCCH configuration can be omitted. As is known from the 3GPP specifications, the complete PUCCH configuration includes various parameters related to resources, formats, power control, etc. According to an embodiment, only one PUCCH parameter is sufficient for the proper configuration of the retransmission timer, such as dl-DataToUL-ACK-MulticastDCI-Format4-1 or dl-DataToUL-ACK, as described herein.

[0219] Another solution according to the present disclosure is to specify a new "drx-InactiveRetranmissionTimerDL-PTM" timer, which indicates the maximum time that the UE expects to receive a retransmission after the successful reception of the PDCCH and the failed decoding of the TB on the PDSCH associated with the MBS session. In this alternative, the UE starts the retransmission timer in the time slot indicated by K1 without starting the RTT timer. During this timer period, the UE will expect a retransmission. The UE that fails to receive the packet will trigger this timer and thus extend its active time (if it has sufficient power). The timer is triggered immediately after the time slot indicated by K1 in the decoded DCI. Note that the timer can be cell-specific or MBS session-specific. In one embodiment, the timer is configured via a broadcast message such as MCCH.

[0220] Alternatively, according to the present disclosure, a new timer drx_InactiveRetransmissionTimerDL-PTM can be started immediately after the reception or decoding of the PDSCH. The advantage of doing so is that the inactive UE will not need to interpret K1. The disadvantage is a slight increase in power consumption. In this alternative, the UE starts the retransmission timer immediately after the end of the PDSCH that has not been successfully decoded without starting the RTT timer. During this timer period, the UE will expect a retransmission.

[0221] Alternatively, according to the present disclosure, the gNB should specify a set of multiple "Inactive-RetranmissionTimerDL-PTM" timers. Each timer within the timer set can be configured for a specific cell or MBS session. The timer set can be configured via dedicated signaling, such as RRC release. The gNB then signals the timers in the timer set using several bits in a broadcast message (e.g., on the MCCH) so that the UE in the inactive / idle state can select the corresponding timer. For example, when the timer set includes eight timers, only three bits in the MCCH are sufficient to address the corresponding timer to the UE. The timer set should be coordinated between cells so that the UE that reselects a new cell can understand the MCCH.

[0222] Reference is now made to the accompanying drawings. In particular, it should be noted that, unless otherwise specified, the same or similar reference numerals used in the drawings of the present disclosure may represent the same or similar elements, and thus their repeated descriptions may be omitted for the sake of brevity.

[0223] Solution 1:

[0224] Figure 1 An example of a signaling diagram illustrating PTM transmission (retransmission) according to an exemplary embodiment of the present disclosure is schematically shown, particularly including the following method steps.

[0225] Step S11: The UE is configured with a DRX retransmission timer and dl-DataToUL-ACK via a dedicated RRC (S11a) (e.g., RRCRelease), or via the MCCH (S11b).

[0226] Note that DCI formats 4_1 and 4_2 are used to schedule multicast data. For each of them, a list can be configured separately, namely dl-DataToUL-ACK-MulticastDCI-Format4-1 or dl-DataToUL-ACK. K1 = x in the transmitted DCI is mapped to the x-th row of this list to understand the time slot (= timing) of the PUCCH.

[0227] Step S12: The PTM transmission is scheduled via a DCI sent via a group common PDCCH address addressed to the G-RNTI (or G-CS-RNTI). The DCI includes K1, and the UE receives the PDCCH but does not correctly decode the transport block sent via the PDSCH.

[0228] Step S13: Based on K1 received via the DCI, the configured dl-DataToUL-ACK, and the new rule, the UE determines when to start the drx-HARQ-RTT-Timer (which triggers the drx-RetransmissionTimer upon expiration, during which the UE monitors the group common PDCCH addressed to the G-RNTI for potential PTM retransmission).

[0229] - New rule for starting the DRX HARQ RTT timer: The UE always starts the timer in the n-th symbol of the time slot indicated by K1, where n can be configurable or fixed in the standard (e.g., always after the first symbol of the time slot, or always after the last symbol of the time slot). That is, if the configuration of n is not provided to the UE, the UE can use the fixed value of the symbol, and if the configuration is given,

[0230] then the UE can use the configured value of n.

[0231] - The network node may consider when to start the DRX HARQ RTT timer for an inactive / idle UE to schedule retransmissions (anyway, the network has to do so because different UEs may send ACK / NACKs for PTM transmissions in different symbols).

[0232] - Alternatively (e.g., if the HARQ RTT timer always starts after the first symbol of a time slot), the UE may extend the duration of the configured drx-RetransmissionTimerDL-PTM by one time slot to ensure that all potential PTM retransmission opportunities are monitored. This alternative is preferably provided as a fixed option and may exist without explicit enable / disable.

[0233] Step S14: The UE monitors the PDCCH for potential PTM retransmissions during the drx-RetransmissionTimer and stops monitoring when the drx-RetransmissionTimer expires.

[0234] One time slot contains 14 symbols. And typically based on the PUCCH configuration, each PUCCH resource is located in some symbols. For example, PUCCH resource 1 may be located in symbols 3 to 5 of a time slot. And typically, the UE starts the first retransmission timer after the 5th symbol after sending the PUCCH in this resource.

[0235] Solution 2:

[0236] Figure 2 Schematically illustrates an example of signaling graph transmission (retransmission) according to an example embodiment of the present disclosure, particularly including the following method steps.

[0237] Step S21: The UE is configured with a DRX retransmission timer and a complete PUCCH configuration via dedicated RRC (S21a) (e.g., RRCRelease) or via MCCH (S21b). By the complete PUCCH configuration, it is intended to represent the PUCCH configuration that the UE typically uses to provide HARQ feedback during multicast data transmission in the RRC_CONNECTED state.

[0238] Step S22: The PTM transmission is scheduled via DCI sent via a group common PDCCH addressed to a G-RNTI (or G-CS-RNTI). The DCI includes K1 and PRI. The UE receives the PDCCH but does not correctly decode the transport block sent via the PDSCH.

[0239] Step S23: Based on K1 and PRI received via DCI and the configured PUCCH configuration, the UE determines when to start the drx-HARQ-RTT-Timer timer (which triggers the drx-RetransmissionTimer when it expires, during which the UE monitors the group common PDCCH addressed to the G-RNTI for potential PTM retransmission).

[0240] Step S24: The UE monitors the PDCCH for potential PTM retransmission during the drx-RetransmissionTimer and stops monitoring when the drx-RetransmissionTimer expires.

[0241] Solution 3:

[0242] Figure 3 Schematically illustrates an example of a signaling diagram of a transmission (retransmission) according to an example embodiment of the present disclosure, particularly including the following method steps.

[0243] Step S31: The gNB configures the drx-InactiveRetransmissionTimerDL-PTM via the MCCH message.

[0244] Step S32: The gNB starts PTM transmission to the UE.

[0245] Step S33: The UE can decode the PDCCH but cannot decode the TB on the PDSCH channel and thus triggers the drx-InactiveRetransmissionTimerDL-PTM timer indicated by the MCCH.

[0246] Step S34: The UE monitors the PDCCH for potential PTM retransmission during the drx-InactiveRetransmissionTimerDL-PTM and stops monitoring when the drx-InactiveRetransmissionTimerDL-PTM expires.

[0247] In this alternative, the UE starts the retransmission timer in the time slot indicated by K1 without starting the RTT timer. During this timer period, the UE will expect retransmission.

[0248] In another alternative, the UE starts the retransmission timer immediately after the end of the unsuccessfully decoded PDSCH without starting the RTT timer. During this timer period, the UE will expect retransmission.

[0249] Solution 4:

[0250] Figure 4Schematically illustrates an example of signaling graph transmission (retransmission) according to an example embodiment of the present disclosure, particularly including the following method steps.

[0251] Step S41: The gNB configures a set of inactive retransmission timers via dedicated signaling.

[0252] Step S42: The gNB signals a bit in the MCCH to indicate the retransmission timers in the set of inactive retransmission timers to be configured for UEs in the inactive / idle state.

[0253] Step S43: The UE can decode the PDCCH but cannot decode the TB on the PDSCH channel.

[0254] Step S44: The UE triggers the indicated retransmission timer, expecting to receive a retransmission while the timer is still running.

[0255] Step S45: The UE monitors the PDCCH for potential PTM retransmissions during the triggered retransmission timer and stops monitoring when the retransmission timer expires.

[0256] In summary, in Solutions 1 and 2, the UE should receive both the RTT timer and the retransmission timer simultaneously. In Solution 3, the UE should receive a new combined retransmission timer (in principle replacing the combination of the RTT and retransmission timers).

[0257] In addition, for all the above solutions, the UE can be configured during the MBS session or before the session actually starts. Preferably, the steps described in the above figures relate to the same MBS.

[0258] In addition, the G-RNTI (or G-CS-RNTI) used in the above solutions can be replaced by another set of IDs, for example, in future standards.

[0259] In addition, in the above solutions, the case where the UE receives the TB but decodes it incorrectly is taken as an example. Alternatively or additionally, the above solutions apply to the case where the UE cannot receive the TB at all, even though it is scheduled via DCI. In this case, the UE cannot even start decoding, resulting in a decoding failure.

[0260] One possible result of standardization is that only the configuration part (Steps S11a / S11b, S21a / S21b in the above figures) will be standardized, and the UE behavior is determined by the implementation. Then, the UE either attempts to decode the PTM retransmission or does not decode the PTM retransmission.

[0261] It should be noted that although in the above example embodiments (with reference to the accompanying drawings), the messages transmitted / exchanged between network components / elements may appear to have specific / explicit names, depending on various implementations (e.g., underlining techniques), these messages may have different names and / or be transmitted / exchanged in different forms / formats, as understood and recognized by those skilled in the art.

[0262] According to some example embodiments, corresponding methods suitable for being executed by the devices (network elements / components) as described above, such as UEs, CUs, DUs, etc., are also provided.

[0263] However, it should be noted that the above device (equipment) features correspond to the corresponding method features, but for the sake of brevity, these method features may not be explicitly described. The disclosure of this document is considered to also extend to such method features. In particular, the present disclosure is understood to relate to methods of operating the above devices and / or providing and / or arranging the corresponding elements of these devices.

[0264] Furthermore, according to some additional example embodiments, a corresponding device (e.g., implementing the UEs, CUs, DUs, etc. as described above) is also provided, which includes at least one processing circuitry system and at least one memory for storing instructions executed by the processing circuitry system, wherein the at least one memory and the instructions are configured to cause the corresponding device to at least execute the corresponding steps as described above together with the at least one processing circuitry system.

[0265] However, in some other example embodiments, a corresponding device (e.g., implementing the UEs, CUs, DUs, etc. as described above) is provided, which includes corresponding components configured to at least execute the corresponding steps as described above.

[0266] It should be noted that the examples of the embodiments of the present disclosure are applicable to various different network configurations. In other words, the examples shown in the above accompanying drawings, which serve as the basis for the above examples, are merely illustrative and do not limit the present disclosure in any way. That is to say, based on the defined principles, other existing and proposed new functions available in the corresponding operating environment can be used in combination with the examples of the embodiments of the present disclosure.

[0267] It should also be noted that the disclosed example embodiments can be implemented in various ways using hardware and / or software configurations. For example, the disclosed embodiments can be implemented using dedicated hardware and / or hardware associated with software that can be executed thereon. The components and / or elements in the accompanying drawings are merely examples and do not limit the scope of use or functions of any hardware, software combined with hardware, firmware, embedded logic components, or combinations of two or more such components implementing the specific embodiments of the present disclosure.

[0268] It should also be noted that the specification and the drawings only illustrate the principles of the present disclosure. Those skilled in the art will be able to implement various arrangements, which, although not explicitly described or illustrated herein, embody the principles of the present disclosure and are included within its spirit and scope. In addition, all examples and embodiments outlined in the present disclosure are mainly for illustrative purposes only to help the reader understand the principles of the proposed method. Moreover, all statements of the principles, aspects and embodiments of the present disclosure provided herein and their specific examples are intended to cover their equivalents.

[0269] List of Abbreviations:

[0270] DCI Downlink Control Information

[0271] DRX Discontinuous Reception

[0272] HARQ Hybrid Automatic Repeat reQuest

[0273] MBS Multicast / Broadcast Service

[0274] MCCH MBS Control Channel

[0275] PTM Point-to-Multipoint

[0276] PTP Point-to-Point

[0277] RTT Round-Trip Time

[0278] TMGI Temporary Mobile Group Identity

Claims

1. A user equipment UE, comprising: at least one processor, and At least one memory storing instructions, which, when executed by the at least one processor, cause the UE to at least: during or before a multicast / broadcast service MBS session: receiving a configuration message from a network node, the configuration message configuring at least one retransmission timer; When the UE is in an inactive state or an idle state, receiving a physical downlink control channel PDCCH transmission, the PDCCH transmission is associated with the MBS session, and a transport block TB of the MBS session is scheduled using a group identifier, the group identifier identifies a UE group, the UE group includes: the UE in the inactive state or the idle state, and one or more UEs in a connected state; receiving the scheduled TB in the inactive state or the idle state via a point-to-multipoint PTM physical downlink shared channel PDSCH transmission associated with the MBS session; and In case failure in decoding the received TB is determined: Based on the configuration message, starting the at least one retransmission timer; and Before the at least one retransmission timer expires, monitoring the PDCCH for at least one PTM retransmission for the failed TB, wherein the at least one PTM retransmission is requested by the one or more UEs in the connected state via at least one hybrid automatic repeat request HARQ feedback to the network node.

2. The UE according to claim 1, wherein the at least one retransmission timer comprises a HARQ round trip time (RTT) timer and a discontinuous reception (DRX) retransmission timer, The UE is configured in the inactive state or the idle state as follows: receiving, via the PDCCH transmission, downlink control information DCI, the DCI comprising a timing indicator for indicating a time slot for the at least one HARQ feedback, After a predetermined symbol in the indicated time slot, starting the HARQ RTT timer; and After the HARQ RTT timer expires, the DRX retransmission timer is started.

3. The UE according to claim 2, wherein: The indicated time slot comprises a plurality of symbols, The UE is preconfigured with a fixed number indicating the corresponding symbol included in the indicated time slot as the predetermined symbol which is a default for all MBS sessions.

4. The UE according to claim 2, wherein: The indicated time slot comprises a plurality of symbols, The configuration message is further configured with a specific number for the UE, and the specific number indicates the corresponding symbol of the indicated time slot as: the predetermined symbol for a specific MBS session, or a default symbol for all MBS sessions.

5. The UE according to any one of claims 2 to 4, wherein the UE is configured to: When the predetermined symbol is the first symbol in the indicated time slot, the configured DRX retransmission timer is extended by at least one additional time slot.

6. The UE according to any one of claims 1 to 5, wherein the configuration message is per temporary mobile group identifier TMGI or a corresponding identifier, the corresponding identifier identifying a specific multicast service or all multicast services of the UE group.

7. A UE according to any one of claims 2 to 6, wherein the configuration message includes information for further configuring a list of values ​​for the UE, the list of values ​​being used to interpret the timing indicator by referring to the values ​​included in the list, and wherein the UE is configured to determine the time slot based on one of the values ​​in the list indicated by the received timing indicator.

8. The UE according to any one of claims 2 to 7, wherein: The configuration message includes a complete PUCCH configuration for the UE, and In addition to the timing indicator, the DCI further includes a PUCCH resource indicator PRI, the PRI indicating: the predetermined symbol included in the time slot indicated by the timing indicator and used to send the at least one HARQ feedback.

9. The UE according to claim 7 or 8, wherein the timing indicator is a PDSCH-to-HARQ_feedback timing indicator, wherein the list is provided via a dl-DataToUL-ACK parameter or a dl-DataToUL-ACK-MulticastDCI-Format4-1 parameter, or the list includes values ​​{1,2,3,4,5,6,7,8}.

10. The UE according to any one of claims 1 to 9, wherein the UE is configured to: in the inactive state or idle state, receive the same PDCCH transmission associated with the MBS session as the one or more UEs in the connected state.

11. The UE according to claim 1, wherein: The PTM PDSCH transmission for the failed TB includes a plurality of symbols, The UE is further configured to, in the inactive state or the idle state: The at least one retransmission timer is started after a last symbol included in the PTM PDSCH transmission for the TB that failed.

12. The UE according to claim 1, wherein: The UE is configured in the inactive state or the idle state to receive, via the PDCCH transmission, downlink control information DCI for scheduling the failed TB transmission, wherein the DCI includes information for indicating a time slot in which the HARQ feedback in response to the failed TB is sent by the one or more UEs in the connected state, The UE is further configured to, in the inactive state or the idle state: It is determined to start the at least one retransmission timer in the indicated time slot.

13. The UE according to any one of claims 1 to 12, wherein the configuration message is a radio resource control (RRC) release message or an MBS control channel (MCCH) message.

14. A network node of a radio access network, configured to establish communication to a group of UEs, the group being identified by a group identifier, the network node comprising: at least one processor, and at least one memory storing instructions, which when executed by the at least one processor, cause the network node to at least: during or before a multicast / broadcast service MBS session, Sending a configuration message to at least one UE among the multiple UEs, the configuration message being used to configure at least one retransmission timer for the at least one UE, wherein the at least one UE is in an inactive state or an idle state, and at least one UE is in a connected state; scheduling a transport block (TB) to the group of UEs identified by the group identifier via one or more physical downlink control channel (PDCCH) transmissions associated with the MBS session; sending the scheduled TB to the UE group identified by the group identifier via a point-to-multipoint PTM physical downlink shared channel PDSCH associated with the MBS session; In response to receiving at least one hybrid automatic repeat request (HARQ) feedback indicating a failure to decode the TB from the at least one UE in a connected state, determining resources for retransmission of the sent TB; as well as Initiating a retransmission for the failed TB at the determined resource and based on the at least one retransmission timer configured for the at least one UE in an inactive state or an idle state, The configuration message includes the following information, and the information is used for the at least one UE in an inactive state or an idle state to determine when to start the at least one retransmission timer based on the configuration message.

15. A method for a user equipment UE, during or before a multicast / broadcast service MBS session: receiving a configuration message from a network node, the configuration message configuring at least one retransmission timer; When the UE is in an inactive state or an idle state, receiving a physical downlink control channel PDCCH transmission, the PDCCH transmission is associated with the MBS session, and a transport block TB of the MBS session is scheduled using a group identifier, the group identifier identifies a UE group, the UE group comprising: the UE in the inactive state or the idle state, and one or more UEs in a connected state; receiving the scheduled TB in the inactive state or the idle state via a point-to-multipoint PTM physical downlink shared channel PDSCH transmission associated with the MBS session; and In case failure in decoding the received TB is determined: Based on the configuration message, starting the at least one retransmission timer; and Before the at least one retransmission timer expires, monitoring the PDCCH for at least one PTM retransmission for the failed TB, wherein the at least one PTM retransmission is requested by the one or more UEs in the connected state via at least one hybrid automatic repeat request HARQ feedback to the network node.

16. The method according to claim 14, wherein the at least one retransmission timer comprises a HARQ round trip time (RTT) timer and a discontinuous reception (DRX) retransmission timer, The UE performs the following in the inactive state or the idle state: receiving, via the PDCCH transmission, downlink control information DCI, the DCI comprising a timing indicator for indicating a time slot for the at least one HARQ feedback, After a predetermined symbol in the indicated time slot, starting the HARQ RTT timer; and After the HARQ RTT timer expires, the DRX retransmission timer is started.

17. The method of claim 16, wherein: The indicated time slot comprises a plurality of symbols, The UE is preconfigured with a fixed number indicating the corresponding symbol included in the indicated time slot as the predetermined symbol which is a default for all MBS sessions.

18. The method of claim 16, wherein: The indicated time slot comprises a plurality of symbols, The configuration message is further configured with a specific number for the UE, and the specific number indicates the corresponding symbol of the indicated time slot as: the predetermined symbol for a specific MBS session, or a default symbol for all MBS sessions.

19. The method according to any one of claims 16 to 18, wherein the UE performs the following: When the predetermined symbol is the first symbol in the indicated time slot, the configured DRX retransmission timer is extended by at least one additional time slot.

20. The method according to any one of claims 15 to 19, wherein the configuration message is per temporary mobile group identity (TMGI) or a corresponding identifier, the corresponding identifier identifying a specific multicast service or all multicast services for the UE group.

21. A method according to any one of claims 16 to 20, wherein the configuration message includes information for further configuring the UE with a list of values, the list of values ​​being used to interpret the timing indicator by referring to the values ​​included in the list, and wherein the UE determines the time slot based on one of the values ​​in the list indicated by the received timing indicator.

22. A method according to any one of claims 16 to 21, wherein: The configuration message includes a complete PUCCH configuration for the UE, and In addition to the timing indicator, the DCI further includes a PUCCH resource indicator PRI, the PRI indicating: the predetermined symbol included in the time slot indicated by the timing indicator and used to send the at least one HARQ feedback.

23. The method of claim 21 or 22, wherein the timing indicator is a PDSCH-to-HARQ_feedback timing indicator, wherein the list is provided via a dl-DataToUL-ACK parameter or a dl-DataToUL-ACK-MulticastDCI-Format4-1 parameter, or the list comprises values ​​{1, 2, 3, 4, 5, 6, 7, 8}.

24. The method according to any one of claims 15 to 23, wherein the UE in the inactive state or idle state receives the same PDCCH transmission associated with the MBS session as the one or more UEs in a connected state.

25. The method of claim 15, wherein: The PTM PDSCH transmission for the failed TB includes a plurality of symbols, The UE starts the at least one retransmission timer in the inactive state or the idle state after a last symbol included in the PTM PDSCH transmission for the failed TB.

26. The method of claim 15, wherein: The UE receives, in the inactive state or the idle state, downlink control information DCI for scheduling the failed TB transmission via the PDCCH transmission, wherein the DCI includes information for indicating a time slot in which the HARQ feedback in response to the failed TB is sent by the one or more UEs in the connected state, And wherein the UE, in the inactive state or the idle state, determines to start the at least one retransmission timer in the indicated time slot.

27. The method according to any one of claims 15 to 26, wherein the configuration message is a Radio Resource Control (RRC) release message or an MBS Control Channel (MCCH) message.

28. A method of a network node of a radio access network, the network node being configured to establish communications to a group of UEs, the group being identified by a group identifier, the method comprising: During or before a Multicast / Broadcast Service MBS session, Sending a configuration message to at least one UE among the multiple UEs, where the configuration message is used to configure at least one retransmission timer for the at least one UE, wherein the at least one UE is in an inactive state or an idle state, and the remaining UEs are in a connected state; scheduling a transport block (TB) to the group of UEs identified by the group identifier via one or more physical downlink control channel (PDCCH) transmissions associated with the MBS session; sending the scheduled TB to the UE group identified by the group identifier via a point-to-multipoint PTM physical downlink shared channel PDSCH associated with the MBS session; In response to receiving at least one hybrid automatic repeat request (HARQ) feedback from the remaining UEs in a connected state indicating a failure to decode the TB at the UE group, determining resources for retransmission of the sent TB; as well as Initiating a retransmission for the failed TB at the determined resource and based on the at least one retransmission timer configured for the at least one UE in the inactive state or the idle state, The configuration message includes the following information, and the information is used for the at least one UE in an inactive state or an idle state to determine when to start the at least one retransmission timer based on the configuration message.

Images