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

Abstract

This document describes 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: receive a configuration message from a network node configuring at least one retransmission timer; and when the UE is in an inactive or idle state, receive Physical Downlink Control Channel (PDCCH) transmissions associated with the MBS session and schedule transport blocks (TBs) of the MBS session using a group identifier that identifies a UE group comprising: UEs in an inactive or idle state. The UE in the active state and one or more UEs in the connected state; receiving scheduled TBs in the inactive or idle state via the Point-to-Multipoint PTM Physical Downlink Shared Channel (PDSCH) associated with the MBS session; and in the event of a failure to decode the received TB: starting at least one retransmission timer based on a configuration message; and monitoring the PDCCH for at least one PTM retransmission for the failed TB before the at least one retransmission timer expires, the at least one PTM retransmission being requested by 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 particularly to the reception of point-to-multipoint transmissions at a user equipment. Background Technology

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

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

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

[0005] If DRX is configured for multicast, the DRX retransmission timer should also be configured for inactive (or idle) UEs, as has been proposed for connected UEs where HARQ feedback is disabled. Even if a UE is configured with a DRX retransmission timer, it is unclear when the DRX HARQ RTT timer should be started, because inactive or idle UEs do not send HARQ feedback, and by definition, the HARQ RTT timer is started after HARQ feedback is sent. Since inactive (or idle) UEs are not configured with PUCCH resources, they may not understand the HARQ feedback-related parameters in the DCI that schedules PTM transmissions, and therefore do not know when the DRX HARQ RTT timer should be started.

[0006] Relevant existing technologies include, for example:

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

[0008] Nokia's contribution R2-2306392 to the Rel-17 revision recommends configuring a DRX PTM retransmission timer for UEs with HARQ feedback disabled, allowing these UEs to receive PTM retransmissions requested by other UEs whose HARQ feedback is not disabled. It also recommends that these UEs start a DRX HARQ RTT timer if they know when HARQ feedback should be sent (if enabled). This disclosure addresses another scenario where UEs in the RRC_INACTIVE or RRC_IDLE state, without configured PUCCH resources, are intended to receive retransmissions from UEs in the RRC_CONNECTED state.

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

[0010] According to a first aspect of this disclosure, a user equipment (UE) is provided, the UE comprising:

[0011] At least one processor, and

[0012] At least one memory stores instructions that, 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 the network node, which configures at least one retransmission timer;

[0014] When the UE is in an inactive or idle state, it receives Physical Downlink Control Channel (PDCCH) transmissions associated with the MBS session and uses a group identifier to schedule the transport block (TB) of the MBS session. The group identifier identifies a UE group, which includes: UEs in an inactive or idle state and one or more UEs in a connected state.

[0015] Scheduled TBs are received in inactive or idle states via the Point-to-Multipoint PTM Physical Downlink Shared Channel (PDSCH) associated with the MBS session; and

[0016] In the event that decoding of the received TB has failed:

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

[0018] Before at least one retransmission timer expires, monitor the PDCCH for at least one PTM retransmission for a 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.

[0019] In some examples, 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] The UE is configured as follows when inactive or idle:

[0021] Downlink control information (DCI) is received via PDCCH transmission. This DCI includes a timing indicator for indicating a time slot used for at least one HARQ feedback.

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

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

[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 required to receive PTM retransmissions.

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

[0026] In some examples:

[0027] The indicated time slot includes multiple symbols.

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

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

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

[0031] 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.

[0032] In some examples, the configuration message identifies the TMGI or corresponding identifier for each temporary mobile group, which identifies a specific multicast service or all multicast services of the UE group.

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

[0034] In some examples:

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

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

[0037] In some examples, the timing indicator is the 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 specification for 5G new radios.

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

[0039] In some examples:

[0040] The PTM PDSCH transmission for the failed TB includes multiple symbols.

[0041] The UE is also configured to, in an inactive or idle state:

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

[0043] In some examples:

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

[0045] The UE is also configured to, in an inactive or idle state:

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

[0047] In some examples, the UE is also made to:

[0048] Before receiving the configuration message, a signaling message is received from the network node. This signaling message specifically includes an RRC release message, which is configured with a set of retransmission timers. Each retransmission timer is configured to serve the corresponding cell of the UE or the corresponding MBS session.

[0049] Receive a configuration message for a retransmission timer from the set of retransmission timers indicated 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 this disclosure, a network node of a wireless access network is provided, the network node being configured to establish communication to a group of UEs identified by a group identifier, the network node comprising:

[0053] At least one processor, and

[0054] At least one memory stores 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 of a plurality of UEs, the configuration message being used to configure at least one retransmission timer for at least one UE, wherein at least one UE is in an inactive or idle state and at least one UE is in a connected state;

[0056] Transmitted via one or more physical downlink control channels (PDCCH) associated with the MBS session to the UE group scheduled transport block (TB) identified by the group identifier;

[0057] The scheduled TB is sent to the UE group identified by the group identifier via the point-to-multipoint PTM physical downlink shared channel PDSCH associated with the MBS session.

[0058] In response to receiving at least one Hybrid Automatic Repeat Request (HARQ) feedback indicating a failure to decode a TB from at least one UE in a connected state, resources for retransmission of the transmitted TB are determined; and

[0059] At the identified resource location, and based on at least one retransmission timer configured for at least one UE in an inactive or idle state, a retransmission for the failed TB is initiated.

[0060] The configuration message includes information that at least one UE in an inactive or idle state uses to determine when to start at least one retransmission timer.

[0061] In some examples, 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] The network nodes are also made to:

[0063] Downlink control information (DCI) is transmitted via PDCCH to at least one UE in an inactive or idle state. This DCI includes a timing indicator for indicating a time slot used for at least one HARQ feedback.

[0064] The configuration message also includes information for configuring at least one UE 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., it can be understood as depicting the minimum time required to receive PTM retransmissions.

[0066] In some examples, the configuration message 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 also configured to pre-configure a fixed number to at least one UE, the fixed number indicating the corresponding symbol included in the indicated time slot, which serves as the default predetermined symbol for all MBS sessions; or

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

[0070] In some examples, network nodes are configured as follows:

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

[0072] In some examples, network nodes are also made to:

[0073] Configuration messages are sent according to each Temporary Mobile Group Identifier (TMGI) or its corresponding identifier, which indicates whether the message is sent to a specific multicast service or all multicast services of the UE group.

[0074] In some examples, the configuration message includes information for configuring a list of values ​​for at least one UE, the list of values ​​being used to interpret the 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 a value in the received timing indicator indicator list.

[0075] In some examples:

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

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

[0078] In some examples, the timing indicator is the 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 specification for 5G new radios.

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

[0080] In some examples:

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

[0082] The network node is enabled to indicate that at least one UE is in an inactive or idle state:

[0083] At least one retransmission timer is started after the last symbol included in the PTM PDSCH transmission for the failed TB.

[0084] In some examples, the network node is also configured to: transmit downlink control information (DCI) via PDCCH to at least one UE in an inactive or idle state, indicating a failed TB transmission, wherein the DCI includes timing indicator information to indicate a time slot in which at least one HARQ feedback is transmitted by the remaining UEs in a connected state in response to the failed TB; and

[0085] The network node is enabled to indicate that at least one UE is in an inactive or idle state:

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

[0087] In some examples, network nodes are also made to:

[0088] Before sending the configuration message, a signaling message is sent to at least one UE. This signaling message specifically includes an RRC release message for configuring a set of retransmission timers for at least one UE. Each retransmission timer is configured to serve the corresponding cell of at least one UE or for the corresponding MBS session; and

[0089] Instruct at least one UE to select a 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 this disclosure, a system is provided configured to support multicast / broadcast services (MBS), the system comprising:

[0092] A group of user equipment (UEs) comprising UEs according to the first aspect and related examples, and one or more UEs in a connected state configured to support the Hybrid Automatic Repeat Request (HARQ) procedure, the group being identified by a group identifier; and

[0093] According to the second aspect and related examples, the network node is configured to schedule and send data associated with MBS to the group.

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

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

[0096] When a UE is in an inactive or idle state, it receives Physical Downlink Control Channel (PDCCH) transmissions associated with an MBS session and uses a group identifier to schedule the transport block (TB) of the MBS session. The group identifier identifies a UE group, which includes: UEs in an inactive or idle state and one or more UEs in a connected state.

[0097] Scheduled TBs are received in inactive or idle states via the Point-to-Multipoint PTM Physical Downlink Shared Channel (PDSCH) associated with the MBS session; and

[0098] In the event that decoding of the received TB has failed:

[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 for a 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 this disclosure, a method is provided for a network node of a radio access network, the network node being configured to establish communication with a group of UEs identified by a group identifier, the method comprising: during or before a multicast / broadcast service MBS session:

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

[0103] Transmitted via one or more physical downlink control channels (PDCCH) associated with the MBS session to the UE group scheduled transport block (TB) identified by the group identifier;

[0104] The scheduled TB is sent to the UE group identified by the group identifier via the 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 TB at the UE group from other UEs in the connected state, resources for retransmission of the transmitted TB are determined; and

[0106] At the identified resource location, and based on at least one retransmission timer configured for at least one UE in an inactive or idle state, a retransmission for the failed TB is initiated.

[0107] The configuration message includes information that at least one UE in an inactive or idle state uses to determine when to start at least one retransmission timer.

[0108] According to a sixth aspect of this disclosure, a computer program is provided, the computer program including instructions for causing a device to perform the method according to the fourth aspect, or for causing the device to perform the method according to the fifth aspect.

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

[0110] Furthermore, according to some other example embodiments, for example, a computer program product for a wireless communication device is provided, the product including at least one processor and a software code portion for performing the corresponding steps disclosed herein when the product is run on the device. The computer program product may include a computer-readable medium on which the aforementioned software code portion is stored. Furthermore, the computer program product may be directly loadable into a computer's internal memory and / or transmittable via a network by means of at least one of upload, download, and push processes.

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

[0112] It is worth noting that the methods according to this disclosure relate to methods of operating apparatus according to the above-described exemplary embodiments and variations thereof, and corresponding statements regarding the apparatus also apply to the corresponding methods, and vice versa; therefore, for the sake of brevity, similar descriptions may be omitted. Furthermore, even without explicit disclosure, the foregoing aspects can be combined in various ways. Those skilled in the art will understand that combinations of these aspects and features / steps are possible unless they create an explicit exclusionary contradiction.

[0113] Implementations of the disclosed device may include, but are not limited to, using 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 device may also include using other conventional and / or custom hardware, such as software-programmable processors, such as graphics processing unit (GPU) processors.

[0114] Other and additional exemplary embodiments of this disclosure will become apparent during the following discussion with reference to the accompanying drawings. Attached Figure Description

[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 An example of a signaling diagram for PTM transmission (retransmission) according to an exemplary embodiment of the present disclosure is illustrated schematically;

[0117] Figure 2 An example of a signaling diagram for PTM transmission (retransmission) according to an exemplary embodiment of the present disclosure is illustrated schematically;

[0118] Figure 3 An example signaling diagram of PTM transmission (retransmission) according to an exemplary embodiment of the present disclosure is schematically illustrated; and

[0119] Figure 4 An example signaling diagram of a PTM transmission (retransmission) according to an exemplary embodiment of the present disclosure is illustrated schematically. Detailed Implementation

[0120] In the following description, various exemplary embodiments will be illustrated using communication network architectures based on 3GPP standards (such as 5G / NR) for communication networks as examples of communication networks to which embodiments can be applied, without limiting the embodiments to this architecture. It will be apparent to those skilled in the art that the embodiments can also be applied to other types of communication networks where mobile communication principles are integrated with D2D (device-to-device) or V2X (vehicle-to-everything) configurations, such as SL (sidechains), e.g., Wi-Fi, Global System for Microwave Access Interoperability (WiMAX). Personal Communication Services (PCS) Wideband Code Division Multiple Access (WCDMA), systems using Ultra Wideband (UWB) technology, Mobile Ad Hoc Networks (MANET), wired access, etc. Furthermore, without loss of generality, while some examples of the embodiments are described in relation to mobile communication networks, the principles of this disclosure can be extended and applied to any other type of communication network, such as wired communication networks.

[0121] The following examples and embodiments should be understood as illustrative examples only. Although the specification may refer to "an," "one," or "some" examples or embodiments in multiple places, this does not necessarily mean that each such reference relates to the same example(s) or embodiment(s), nor does it mean that the feature applies only to a single example or embodiment. Individual features of different embodiments may also be combined to provide other embodiments. Furthermore, terms such as "comprising" and "including" should be understood not to limit the described embodiments to consisting only of those 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 (telecommunications) network, including a mobile communication system (some examples of which are applicable), may include the architecture of one or more communication networks, including (multiple) radio access network subsystems and (multiple) core networks. This 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 transceiver stations (such as base stations (BS), access points (AP), NodeBs (NBs), eNBs, or gNBs), distributed units (DUs) or centralized / central units (CUs) that control a corresponding coverage area or (multiple) cells, and one or more communication stations (such as communication elements or functions, such as user equipment or terminal equipment, such as user equipment (UE), or another device with similar functionality, such as modem chipsets, chips, modules, etc., which may also be part of a communication-enabled station, element, function, or application, such as a UE, element, or function that can be used in a machine-to-machine communication architecture, or attached as a separate element to a communication-enabled element, function, or application, etc.) capable of communicating via one or more channels and one or more communication beams to transmit several types of data in multiple access domains. In addition, it may include core network elements or network functions, such as gateway network elements / functions, mobility management entities, mobile switching centers, servers, databases, etc.

[0123] The following description may provide further details on alternatives, modifications and variations: gNB includes, for example, nodes that provide NR user plane and control plane protocol termination toward the UE and are connected to 5GC via 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 gNB's RRC, SDAP, and PDCP protocols, or the en-gNB's RRC and PDCP protocols that control the operation of one or more gNB-DUs. The gNB-CU terminates the F1 interface connected to the gNB-DU.

[0125] A gNB Distributed Unit (gNB-DU) includes, for example, a logical node that hosts the RLC, MAC, and PHY layers of, for example, a gNB or en-gNB, and its operation is partially controlled by the gNB-CU. A gNB-DU supports one or more cells. A 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 the control plane portion of the gNB-CU's RRC and PDCP protocols, for example, for 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 portion of the PDCP protocol for the gNB-CU used by the en-gNB, and the user plane portions of the PDCP and SDAP protocols for the gNB-CU used by 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] Different functional divisions can exist between the central and distributed units, for example, referred to as options:

[0129] Option 1 (Class 1A split):

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

[0131] Option 2 (3C category split):

[0132] • The functional breakdown in this option is similar to the 3C architecture in a DC (Distributed Control) system. RRC and PDCP reside in the central unit. RLC, MAC, physical layer, and RF reside in the distributed units.

[0133] Option 3 (Split within RLC):

[0134] • Low RLC (part of the RLC functionality), MAC, physical layer, and RF are located in the distributed unit. PDCP and high RLC (another part of the RLC functionality) are located in the central unit.

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

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

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

[0138] (2017-03) Section 11.

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

[0140] NR's Layer 2 (L2) is divided into the following sublayers: Media Access Control (MAC), Radio Link Control (RLC), Packet Data Convergence Protocol (PDCP), and Service Data Adaptation Protocol (SDAP), among which:

[0141] • The physical layer provides a transmission channel to the MAC sublayer;

[0142] • The MAC sublayer provides logical channels to the RLC sublayer;

[0143] • The RLC sublayer provides RLC channels to the PDCP sublayer;

[0144] • The PDCP sublayer provides radio bearers to the SDAP sublayer;

[0145] • The SDAP sublayer provides QoS flows to 5GC;

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

[0147] • Control channels include (BCCH, PCCH).

[0148] Layer 3 (L3) includes, for example, Radio Resource Control (RRC), as per Section 6 of 3GPP TS38.300V16.6.0 (2021-06) incorporated by reference.

[0149] RAN (Radio Access Network) nodes or network nodes (such as gNBs, base stations, gNB CUs or gNB DUs or portions thereof) may be implemented using means, for example, having at least one processor and / or at least one memory (with computer-readable instructions (computer programs)) 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 portions may, for example, be co-located or physically separate. The gNB DU may even be further divided into two parts, for example, one part including processing equipment and the other part including antennas. The Central Unit (CU) may also be referred to as BBU / REC / RCC / C-RAN / V-RAN, O-RAN, or a portion thereof. The Distributed Unit (DU) may also be referred to as RRH / RRU / RE / RU, or a portion thereof. In the various exemplary embodiments of this disclosure below, the CU-CP (or more generally, the CU) may also be referred to as a (first) network node supporting at least one of the Layer 3 protocols of the Central Unit Control Plane Function or the Radio Access Network; and similarly, the DU may be referred to as a (second) network node supporting at least one of the Layer 2 protocols of the Distributed Unit Function or the Radio Access Network.

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

[0152] User equipment (UE) may include wireless or mobile devices, devices with a radio interface for interacting with a RAN (Radio Access Network), smartphones, vehicle-mounted devices, IoT devices, M2M devices, etc. Such a UE or device may 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, together with the at least one processor, to enable the device to perform at least certain operations, such as an RRC connection with the RAN. The UE may be configured, for example, to generate messages (e.g., including a cell ID) for transmission to the RAN via radio (e.g., to reach and communicate with the serving cell). The UE may generate, transmit, and receive RRC messages containing one or more RRC PDUs (Packet Data Units).

[0153] The UE can have different states (e.g., according to sections 42.1 and 4.4 of 3GPP TS 38.331 V16.5.0 (2021-06) incorporated herein by reference).

[0154] When an RRC connection has been established, the UE is in, for example, 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 with the UE;

[0158] • Monitor the control channel associated with the shared data channel to determine if it is a data channel.

[0159] Channel scheduling data;

[0160] • Provides channel quality and feedback information;

[0161] • Perform neighboring cell measurements and generate measurement reports.

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

[0163] • RRC connection control;

[0164] • Measurement configuration and reporting;

[0165] • Create / modify / publish measurement configurations (e.g., intra-frequency, inter-frequency, and inter-RAT).

[0166] Measurement);

[0167] • Establishment and release of the measurement gap;

[0168] • Measurement report.

[0169] The general functions and interconnections of the described elements and features (which also depend on the actual network type) are known to those skilled in the art and are described in the corresponding specifications; therefore, for the sake of brevity, their detailed description may be omitted here. However, it should be noted that, in addition to those described in detail below, several additional network elements and signaling links may be employed to communicate with elements, features, 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 able to communicate with other networks such as the public switched telephone network or the Internet. The communication network can also support cloud services for virtual network elements or their functions. It should be noted that virtual network components of a telecommunications network may also be provided by non-cloud resources, such as internal networks. It should be understood that network elements and / or corresponding functions of access systems, core networks, etc., can be implemented using any node, host, server, access node, or entity suitable for such purposes. Typically, network functions can be implemented as network elements on dedicated hardware, software instances running on dedicated hardware, or virtualized functions instantiated on a suitable platform (e.g., cloud infrastructure).

[0171] Furthermore, network elements (such as communication elements, such as UEs, terminal equipment, control elements or functions, such as access network elements, such as base stations / BSs, gNBs, radio network controllers, core network control elements or functions, such as gateway elements, or other network elements or functions described herein), and any other elements, functions, or applications, may be implemented in software, such as computer program products of a computer; and / or in hardware. To perform their respective processing, the corresponding devices, nodes, functions, or network elements used may include several parts, modules, units, components, etc. (not shown) required for control, processing, and / or communication / signaling functions. For example, such components, modules, units, and parts may include one or more processors or processor units, including one or more processing sections for executing instructions and / or programs and / or processing data; storage or memory units or components (e.g., ROM, RAM, EEPROM, etc.) serving as working areas for storing instructions, programs, and / or data, acting as processors or processing sections; input or interface components (e.g., floppy disks, CD-ROMs, EEPROMs, etc.) for inputting data and instructions via software; user interfaces (e.g., screens, keyboards, etc.) for providing users with the possibility of monitoring and manipulation; and other interfaces or components for establishing links and / or connections under the control of processor units or sections (e.g., wired and wireless interface components, radio interface components including, for example, antenna units, components for forming radio communication sections, etc.), wherein the corresponding components forming the interfaces (such as radio communication sections) may also be located at remote sites (e.g., radio head units or radio stations, etc.). It should be noted that in this specification, a processing section should not be considered merely as a physical portion representing one or more processors, but may also be considered as a logical division of the referred processing tasks performed by one or more processors. It should be understood that, according to some examples, a so-called "fluid" or flexible network concept can be adopted, in which the operation and function of network elements, network functions, or another entity of the network can be performed in a flexible manner in different entities or functions, such as in nodes, hosts, or servers. In other words, the "division of labor" between the network elements, functions, or entities involved can vary from situation to situation.

[0172] As described above, this disclosure generally seeks to provide a means for a UE in the RRC_INACTIVE ( / IDLE) state 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 provides MBS service to multiple users using the same radio framework as unicast transmission. Rel-17 only allows UEs in the RRC_CONNECTED state to receive multicast service. Even for PTM operation, reliable data reception is ensured via HARQ retransmission and dynamic MCS selection. Furthermore, PTP transmission can be configured for UEs in the RRC_CONNECTED state.

[0174] Rel-18, starting with SA2 SI (SP-211645), identifies and evaluates further enhancements to the 5GS architecture to provide multicast and broadcast services. Currently, specification work is beginning to finalize the solutions agreed upon in TR 23.700-47. A major focus of SA2 SI is KI#1, which emphasizes enabling UEs in the RRC_INACTIVE state to receive multicast services for scalability and energy efficiency purposes.

[0175] KI#1: How to support and enhance end-to-end MBS service delivery, including a large number of UEs:

[0176] In the RRC inactive state, this enables the UE to receive multicast MBS session data in the RRC state.

[0177] Following the work on SA2, RAN WID RP-213568 has reached an agreement on Rel-18, which includes the following objectives:

[0178] - Specifies support for multicast reception by a UE in the RRC_INACTIVE state.

[0179] [RAN2,RAN3]

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

[0181] [RAN2]

[0182] ○ Investigate 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 multicast service configuration in the cell should be applied to begin / continue receiving multicast services that the UE has joined. RAN2 / 3 is currently investigating how this configuration should be implemented.

[0184] One agreed-upon option is to provide configuration using a method similar to Rel-17 broadcasting, whereby the cell periodically broadcasts the SIB / MCCH (Multicast Control Channel), allowing the RRC_INACTIVE UE to receive the configuration itself and any updates thereto. Furthermore, when the UE is sent from RRC_CONNECTED to RRC_INACTIVE, the UE can be configured to receive multicast services in the RRC_INACTIVE state while camped at the serving cell. The transmission 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, UEs in both the RRC_CONNECTED and RRC_INACTIVE states will simultaneously receive the same multicast data (PDSCH) and may also receive the same PDCCH for scheduling data.

[0186] For Rel-17 MBS multicast in RRC_CONNECTED, the UE can be configured with Discontinuous Reception (DRX) to receive MBS multicast services, thereby saving UE power. DRX operation uses two configurable timers, namely the DRX HARQ / hybrid ARQRTT (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 below:

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

[0188] 2: The UE is typically configured with HARQ feedback and is instructed to use the PUCCH (Physical Uplink Control Channel) resources 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 the time slot, the timer starts at the end of symbol 5).

[0190] Note that long PUCCH formats 1 and 3 are typically 14 symbols. Short PUCCHs have two symbols, which are usually located at the end of the slot, but the specification also allows for other positions.

[0191] 4: When the RTT timer expires, if the reception (decoding) of the PUSCH in the corresponding HARQ procedure fails, the UE starts the DRX retransmission timer, and while the DRX retransmission timer is running, the UE monitors the PDCCH to receive retransmissions.

[0192] In Rel-17, these HARQ retransmission-related timers are only configured 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 (if enabled) where the PUCCH resources in which HARQ feedback should be sent. Another parameter in the DCI is PRI (PUCCH resource indicator), which selects which PUCCH resources (multiple symbol and frequency resources) will be used in that time slot. The interpretation of K1 and PRI is configured for UEs in connected mode, not for UEs in inactive / idle mode. Therefore, UEs in inactive / idle mode do not know when HARQ feedback will be sent if enabled, and thus do not know when the DRX HARQ RTT timer will start.

[0194] Note that the number of PUCCH resources can vary depending on the number of orthogonal color codes (OCC), the number of symbols (short or long PUCCH), the number of PRBs, and cyclic shifts. Therefore, PRI will indicate one of the PUCCH resources configured in the PUCCH resource set.

[0195] One possible solution is to configure a full PUCCH configuration for UEs in RRC_INACTIVE / IDLE mode, giving them the same information as UEs in active mode, and thus allowing them to know precisely when HARQ feedback should be sent if enabled. Then, based on the configuration and information received via DCI, UEs in inactive / idle mode will know exactly when to start a HARQ RTT timer, which, upon expiration, activates a DRX retransmission timer to receive potential HARQ PTM retransmissions. This requires additional configuration solely for receiving potential PTM retransmissions, which increases signaling overhead while enabling proper activation of the HARQ RTT timer. Furthermore, the interpretation of PRI depends on the actual size of the HARQ feedback to be generated. Therefore, this approach also requires more computation on the UE side to generate 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) within that PUCCH resource set. There can be up to four 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, in accordance with this disclosure, instead of configuring a full PUCCH configuration for a UE in inactive / idle (RRC_INACTIVE / IDLE) mode, that is:

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

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

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

[0201] Then the UE can use 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, the value is provided by...

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

[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 -> Several PUCCH resources that the UE can use to send HARQ feedback in the future.

[0209] Frequency domain:

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

[0211] Between 5.25MHz and 5.30MHz, 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. In practice, to know this symbol, the UE should be configured with a full PUCCH configuration (as shown in the example above). Therefore, according to this disclosure, a method is proposed that, instead of configuring a full PUCCH configuration for a UE in inactive / idle mode, instead:

[0213] ○The UE is configured with a new rule for initiating 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 (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 a fixed value for the symbol, and if the configuration is provided, the UE can use the configured value of n. New rules are provided via the same configuration (RRC release and / or MCCH), or as a pre-configured value at the UE, for example, always hardcoded to 1 by the standard.

[0215] Network nodes (e.g., access nodes such as gNBs) can schedule retransmissions by taking into account knowledge of when inactive / idle UEs start the DRXHARQ RTT timer (the network must do this anyway, as different UEs may send ACK / NACK for PTM transmissions in different symbols). Specifically, network nodes can ensure that retransmissions are scheduled when a UE expects a retransmission (i.e., while 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 configure the drx-RetransmissionTimerDL.

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

[0218] Therefore, the proposed solution reduces signaling load because the full PUCCH configuration can be omitted. As known from the 3GPP specifications, the full PUCCH configuration includes various parameters related to resources, format, power control, etc. According to embodiments, only one PUCCH parameter is sufficient for the appropriate 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 this disclosure is to specify a new “drx-InactiveRetranmissionTimerDL-PTM” timer, which indicates the maximum time the UE expects to receive a retransmission after successful reception of the PDCCH and 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, instead of starting the RTT timer. During this timer period, the UE will expect retransmissions. A UE that fails to receive packets will trigger the 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 this disclosure, a new timer, drx_InactiveRetransmissionTimerDL-PTM, can be started immediately after the reception or decoding of the PDSCH. The advantage of this is that inactive UEs 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 undecoded PDSCH ends, instead of starting the RTT timer. During this timer period, the UE will expect retransmissions.

[0221] Alternatively, according to this 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 a UE in an 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 a UE reselecting a new cell can understand the MCCH.

[0222] Referring now to the accompanying drawings. In particular, it should be noted that, unless otherwise stated, the same or similar reference numerals used in the drawings of this disclosure may denote the same or similar elements, and thus their repeated description may be omitted for the sake of brevity.

[0223] Solution 1:

[0224] Figure 1 An example signaling diagram of PTM transmission (retransmission) according to an exemplary embodiment of the present disclosure is illustrated, 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 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, 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 PUCCH slot (= timing).

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

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

[0229] - New rule for initiating DRX HARQ RTT timers: The UE always initiates the timer in the nth 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 a fixed value for the symbol, while if the configuration is given,

[0230] Then the UE can use the configured n value.

[0231] - Network nodes can consider when inactive / idle UEs start the DRX HARQ RTT timer to schedule retransmissions (the network must do this anyway, as different UEs may send ACK / NACK for PTM transmissions in different symbols).

[0232] - Alternatively (e.g., if the HARQ RTT timer always starts after the first symbol of the slot), the UE can extend the duration of the configured drx-RetransmissionTimerDL-PTM by one 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 retransmission during the drx-RetransmissionTimer period and stops monitoring when the drx-RetransmissionTimer expires.

[0234] A time slot contains 14 symbols. It is typically configured based on PUCCH, with each PUCCH resource located within a set of symbols. For example, PUCCH resource 1 could be located in symbols 3 through 5 of the time slot. Typically, the UE starts the first retransmission timer after transmitting the PUCCH resource 5 symbols later in that resource.

[0235] Solution 2:

[0236] Figure 2 An example of signaling graph transmission (retransmission) according to an exemplary embodiment of the present disclosure is illustrated, specifically including the following method steps.

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

[0238] Step S22: Schedule PTM transmission via DCI sent through a group common PDCCH addressed to G-RNTI (or G-CS-RNTI), DCI including K1 and PRI. The UE receives the PDCCH but does not correctly decode the transport block sent through 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 (which triggers the drx-RetransmissionTimer upon expiration, during which the UE monitors the group common PDCCH addressed to 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 An example of a signaling diagram for transmission (retransmission) according to an exemplary embodiment of the present disclosure is illustrated, particularly including the following method steps.

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

[0244] Step S32: gNB begins transmission to UE's PTM.

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

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

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

[0248] In another alternative, the UE starts a retransmission timer immediately after the undecoded PDSCH ends, instead of starting an RTT timer. During this timer period, the UE will expect a retransmission.

[0249] Solution 4:

[0250] Figure 4An example of signaling graph transmission (retransmission) according to an exemplary embodiment of the present disclosure is illustrated, specifically including the following method steps.

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

[0252] Step S42: The gNB sends a signaling bit in the MCCH to indicate the retransmission timers to be configured in the set of inactive retransmission timers for UEs in an 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 retransmissions while the timer is still running.

[0255] Step S45: The UE monitors the PDCCH for potential PTM retransmission during the triggered retransmission timer period 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 RTT and retransmission timer).

[0257] Furthermore, for all the solutions described above, the UE can be configured during the MBS session or before the session actually begins. Preferably, the steps described in the above figures involve the same MBS.

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

[0259] Furthermore, the above solution takes the example of a UE receiving a TB but encountering an error during decoding. Alternatively or additionally, the above solution applies to situations where the UE is completely unable to receive the TB, even though it is scheduled via DCI. In this case, the UE cannot even begin decoding, thus also leading to decoding failure.

[0260] One possible outcome of standardization is that only the configuration components (steps S11a / S11b and S21a / S21b in the above diagram) will be standardized, and the UE behavior will be determined by the implementation method. Then, the UE will either attempt to decode the PTM retransmission or not decode it.

[0261] It should be noted that although in the above example embodiments (refer to the accompanying drawings), messages transmitted / exchanged between network components / elements may appear to have specific / explicit names, depending on various implementations (e.g., underscore 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 execution by the apparatus (network element / component) described above, such as UE, CU, DU, etc., are also provided.

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

[0264] Furthermore, according to some other example embodiments, a corresponding device (e.g., implementing the UE, CU, DU, etc. as described above) is also provided, the device including at least one processing circuit system and at least one memory for storing instructions executed by the processing circuit system, wherein the at least one memory and the instructions are configured together with the at least one processing circuit system to cause the corresponding device to perform at least the corresponding steps as described above.

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

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

[0267] It should also be noted that the disclosed example embodiments can be implemented in a variety of 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 drawings are merely examples and do not limit the scope or functionality of any hardware, software and hardware combinations, firmware, embedded logic components, or combinations of two or more such components that implement a particular embodiment of this disclosure.

[0268] It should also be noted that the specification and drawings only illustrate the principles of this disclosure. Those skilled in the art will be able to implement various arrangements, which, although not expressly described or shown herein, embody the principles of this disclosure and are included within its spirit and scope. Furthermore, all examples and embodiments outlined in this disclosure are primarily for illustrative purposes to aid the reader in understanding the principles of the proposed methods. Moreover, all statements and specific examples of the principles, aspects, and embodiments of this disclosure provided herein 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 Movement Group Identifier

Claims

1. A user equipment (UE), comprising: At least one processor, and At least one memory stores instructions that, when executed by the at least one processor, cause the UE to at least: during or before a multicast / broadcast service MBS session: Receive a configuration message from a network node, the configuration message configuring at least one retransmission timer; When the UE is in an inactive or idle state, it receives Physical Downlink Control Channel (PDCCH) transmissions associated with the MBS session and uses a group identifier to schedule the transport block (TB) of the MBS session. The group identifier identifies a UE group, which includes the UE in the inactive or idle state and one or more UEs in a connected state. The scheduled TB is received in the inactive or idle state via the Point-to-Multipoint PTM Physical Downlink Shared Channel (PDSCH) associated with the MBS session; and In the event that decoding of the received TB has failed: Based on the configuration message, start the at least one retransmission timer; and Before the expiration of the at least one retransmission timer, the PDCCH for at least one PTM retransmission for the failed TB is monitored, 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 includes a HARQ round-trip time (RTT) timer and a discontinuous reception (DRX) retransmission timer. The UE is configured in the inactive or idle state as follows: Downlink control information (DCI) is received via the PDCCH transmission. The DCI includes a timing indicator for indicating the time slot used for the at least one HARQ feedback. After a predetermined symbol in the indicated time slot, the HARQ RTT timer is started; 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 includes multiple symbols. The UE is pre-configured with a fixed number, which indicates the corresponding symbol included in the indicated time slot as the predetermined symbol that is the default for all MBS sessions.

4. The UE according to claim 2, wherein: The indicated time slot includes multiple symbols. The configuration message also configures a specific number for the UE, which indicates the corresponding symbol of the indicated time slot as either the predetermined symbol for a specific MBS session or the 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 4, wherein the configuration message identifies a TMGI or a corresponding identifier for each temporary mobile group, the corresponding identifier identifying a specific multicast service or all multicast services of the UE group.

7. The UE according to any one of claims 2 to 4, 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 a value in the list indicated by the received timing indicator.

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

9. The UE of claim 7, wherein the timing indicator is a PDSCH-to-HARQ_feedback timing indicator, wherein 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}.

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

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

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

13. The UE according to any one of claims 1 to 4, 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 stores 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, A configuration message is sent to at least one of the plurality of 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 or idle state and at least one UE is in a connected state; Transmitted via one or more physical downlink control channels (PDCCH) associated with the MBS session to the UE group scheduled transport block TB identified by the group identifier; The scheduled TB is sent to the UE group identified by the group identifier via the 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 at least one UE in a connected state, resources for retransmission of the transmitted TB are determined. as well as At the identified resource, and based on the at least one retransmission timer configured for the at least one UE in an inactive or idle state, a retransmission for the failed TB is initiated. The configuration message includes information that the at least one UE in an inactive or idle state uses to determine when to start the at least one retransmission timer.

15. A method for a user equipment (UE) during or before a multicast / broadcast service (MBS) session: Receive a configuration message from a network node, the configuration message configuring at least one retransmission timer; receiving, while the UE is in an inactive or idle state, a physical downlink control channel, PDCCH, transmission, the PDCCH transmission being associated with the MBS session and scheduling a transport block, TB, of the MBS session with a group identifier, the group identifier identifying a group of UEs, the group of UEs including: The UE in the inactive or idle state, and one or more UEs in the connected state; The scheduled TB is received in the inactive or idle state via the Point-to-Multipoint PTM Physical Downlink Shared Channel (PDSCH) associated with the MBS session; and In the event that decoding of the received TB has failed: Based on the configuration message, start the at least one retransmission timer; and Before the expiration of the at least one retransmission timer, the PDCCH for at least one PTM retransmission for the failed TB is monitored, 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 of claim 15, 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 actions in the inactive or idle state: Downlink control information (DCI) is received via the PDCCH transmission. The DCI includes a timing indicator for indicating the time slot used for the at least one HARQ feedback. After a predetermined symbol in the indicated time slot, the HARQ RTT timer is started; and After the HARQ RTT timer expires, the DRX retransmission timer is started.

17. The method of claim 16, wherein: The indicated time slot includes multiple symbols. The UE is pre-configured with a fixed number, which indicates the corresponding symbol included in the indicated time slot as the predetermined symbol that is the default for all MBS sessions.

18. The method of claim 16, wherein: The indicated time slot includes multiple symbols. The configuration message also configures a specific number for the UE, which indicates the corresponding symbol of the indicated time slot as: the predetermined symbol that is the default for a specific MBS session or 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 18, wherein the configuration message identifies a TMGI or a corresponding identifier for each temporary mobile group, the corresponding identifier identifying a specific multicast service or all multicast services of the UE group.

21. The method of any one of claims 16 to 18, 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 determines the time slot based on a value in the list indicated by the received timing indicator.

22. The method according to any one of claims 16 to 18, wherein: The configuration message includes the complete PUCCH configuration for the UE, and In addition to the timing indicator, the DCI also includes a PUCCH resource indicator PRI, which indicates the predetermined symbol included in the time slot indicated by the timing indicator for sending the at least one HARQ feedback.

23. The method of claim 21, wherein the timing indicator is a PDSCH-to-HARQ_feedback timing indicator, wherein 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}.

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

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

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

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

28. A method for a network node in a wireless access network, the network node being configured to establish communication 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 A configuration message is sent to at least one of the plurality of 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 or idle state, and the remaining UEs are in a connected state; Transmitted via one or more physical downlink control channels (PDCCH) associated with the MBS session to the UE group scheduled transport block TB identified by the group identifier; The scheduled TB is sent to the UE group identified by the group identifier via the 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 at the UE group from the other UEs in the connected state, resources for retransmission of the transmitted TB are determined. as well as At the identified resource, and based on the at least one retransmission timer configured for the at least one UE in the inactive or idle state, a retransmission for the failed TB is initiated. The configuration message includes information that the at least one UE in an inactive or idle state uses to determine when to start the at least one retransmission timer.

Images