Managing hybrid automatic repeat request transmission of multicast and / or broadcast services - Patents.com

Abstract

A user equipment (UE) for receiving a multicast and / or broadcast service (MBS) (i) attempts to receive (902) a first transmission from a base station via multicast, the first transmission including MBS data packets associated with the MBS; (ii) transmits (904) an indication to the base station of whether the UE successfully received the first transmission according to a mechanism for automatic retransmission of undelivered packets; (iii) in response to the transmitting, attempts to receive (906) a second transmission from the base station via unicast according to the mechanism; and (iv) determines (908) whether the second transmission is a new transmission or a retransmission of the first transmission.

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Application No. 63 / 297,897, entitled “Managing Hybrid Automatic Repeat Request Transmission for Multicast and / or Broadcast Services,” filed on January 10, 2022, and is hereby incorporated by reference in its entirety.

[0002] The present disclosure relates to wireless communications, and more particularly to enabling automatic retransmission of undelivered packets, such as hybrid automatic repeat request (HARQ), for one or more multicast and / or broadcast services (MBS). [Background technology]

[0003] The background art provided herein is described for purposes of generally presenting the context of the present disclosure. The work of the inventors identified herein, to the extent described in this Background section, and aspects of the present disclosure that may not qualify as prior art at the time of filing, are not admitted expressly or impliedly as prior art to the present disclosure.

[0004] In telecommunication systems, the Packet Data Convergence Protocol (PDCP) sublayer of the radio protocol stack provides services such as transport, encryption, and integrity protection of user plane data. For example, the PDCP sublayer defined for the Evolved Universal Terrestrial Radio Access (EUTRA) air interface (see 3rd Generation Partnership Project (3GPP) specification TS 36.323) and New Radio (NR) (see 3GPP specification TS 38.323) provides ordering of protocol data units (PDUs) in the uplink direction from a user device (also known as user equipment or "UE") to a base station and in the downlink direction from a base station to a UE. The PDCP sublayer also provides services for signaling radio bearers (SRBs) to the Radio Resource Control (RRC) sublayer. The PDCP sublayer further provides services for data radio bearers (DRBs) to the Service Data Adaptation Protocol (SDAP) sublayer or protocol layers such as the Internet Protocol (IP) layer, the Ethernet protocol layer, and the Internet Control Message Protocol (ICMP) layer. Generally speaking, a UE and a base station may exchange RRC messages and non-access stratum (NAS) messages using SRBs, and may transmit data in the user plane using DRBs.

[0005] In some scenarios, a UE can simultaneously utilize the resources of several nodes (e.g., base stations or components of distributed or disaggregated base stations) of a Radio Access Network (RAN) interconnected by a backhaul. When these network nodes support different Radio Access Technologies (RATs), this connection type is called Multi-Radio Dual Connectivity (MR-DC). When operating in MR-DC, the cell(s) associated with the base station acting as a Master Node (MN) define a Master Cell Group (MCG) and the cells associated with the base station acting as a Secondary Node (SN) define a Secondary Cell Group (SCG). The MCG covers a Primary Cell (PCell) and zero, one or more Secondary Cells (SCells), and the SCG covers a Primary Secondary Cell (PSCell) and zero, one or more SCells. The UE communicates with the MN (through the MCG) and with the SN (through the SCG). In other scenarios, the UE utilizes the resources of one base station at a time, in a Single Connectivity (SC). A UE in a SC communicates only with the MN through the MCG. The base station and / or the UE decide when the UE should establish a radio connection with another base station. For example, the base station may decide to hand over the UE to another base station and initiate a handover procedure. In other scenarios, the UE may simultaneously utilize resources of another RAN node (e.g., a base station or a component of a distributed or disaggregated base station) interconnected by a backhaul.

[0006] The UE can use several types of SRBs and DRBs. The so-called "SRB1" resources carry RRC messages, including in some cases NAS messages, over a dedicated control channel (DCCH), and the "SRB2" resources support RRC messages, including logged measurement information or NAS messages, also over the DCCH, but with lower priority than the SRB1 resources. More generally, the SRB1 and SRB2 resources allow the UE and MN to exchange RRC messages related to the MN and embed RRC messages related to the SN, and are sometimes called MCG SRBs. The "SRB3" resources allow the UE and SN to exchange RRC messages related to the SN, and are sometimes called SCG SRBs. The split SRBs allow the UE to exchange RRC messages directly with the MN via the MN and SN lower layer resources. Furthermore, a DRB that terminates at an MN and uses lower layer resources of only the MN may be referred to as an MCG DRB, a DRB that terminates at an SN and uses lower layer resources of only the SN may be referred to as an SCG DRB, and a DRB that terminates at an MN or an SN but uses lower layer resources of both the MN and the SN may be referred to as a split DRB. A DRB that terminates at an MN but uses lower layer resources of only the SN may be referred to as an MN-terminated SCG DRB. A DRB that terminates at an SN but uses lower layer resources of only the MN may be referred to as an SN-terminated MCG DRB.

[0007] The UE can perform handover procedures to switch from one cell to another cell, regardless of SC or DC operation. These procedures involve messaging (e.g., RRC signaling and preparation) between the RAN node and the UE. The UE may handover from a cell of a serving base station to a target cell of a target base station, or from a first distributed unit (DU) of a serving base station to a target cell of a second DU of the same base station, depending on the scenario. In a DC scenario, the UE can perform a PSCell change procedure to change the PSCell. These procedures involve messaging (e.g., RRC signaling and preparation) between the RAN node and the UE. The UE may perform a PSCell change from a PSCell of a serving SN to a target PSCell of a target SN, or from a PSCell of a source DU of a base station to a PSCell of a target DU of the same base station, depending on the scenario. Additionally, the UE may perform a handover or PSCell change within a cell for synchronous reconfiguration.

[0008] Base stations operating in accordance with the fifth generation (5G) new radio (NR) requirements support significantly larger bandwidths than fourth generation (4G) base stations. Thus, for Release 15, the Third Generation Partnership Project (3GPP) proposes that user equipment units (UEs) support 100 MHz bandwidth in Frequency Range 1 (FR1) and 400 MHz bandwidth in Frequency Range (FR2). Since the bandwidth of typical carriers is relatively large in 5G NR, 3GPP proposes in Release 17 that 5G NR base stations can provide multicast and / or broadcast service(s) (MBS) to UEs. MBS can be useful for many content distribution applications, such as, for example, IPv4 / IPv6 multicast distribution, IPTV, over-the-air software distribution, group communication, Internet of Things (IoT) applications, V2X applications, and emergency messages related to public safety.

[0009] 5G NR provides both point-to-point (PTP) and point-to-multipoint (PTM) delivery methods for transmission of MBS packet flows over the air interface. In PTP communication, the RAN node transmits different copies of each MBS data packet to different UEs over the air interface. On the other hand, in PTM communication, the RAN node transmits a single copy of each MBS data packet to multiple UEs over the air interface. However, in some scenarios, it is unclear how a base station uses a HARQ mechanism to transmit MBS data to one or more UEs over PTM transmission (i.e., multicast) and / or PTP transmission (i.e., unicast). Summary of the Invention

[0010] Generally speaking, a base station (e.g., a component of an integrated base station or a distributed base station) and / or a UE may implement a mechanism for automatically retransmitting undelivered packets, such as HARQ, to improve MBS reliability. The base station may initially send a first transmission to the UE including an MBS packet, and may send a subsequent second transmission to the UE in response to feedback received from the UE for the first transmission. The base station may determine how to send the subsequent second transmission (e.g., via multicast or unicast) based on a variety of factors. Such factors may relate to whether the UE supports or has enabled PTP retransmission, whether the first transmission was delivered via multicast or unicast, the type of feedback received from the UE for the first transmission, and network bandwidth conditions for the first transmission. The UE can determine whether the second transmission is a new transmission or a retransmission of the first transmission based on various factors related to whether the UE supports or has enabled PTP retransmission, whether the first and second transmissions have the same transport block size, and which RNTI was used to receive the second transmission.

[0011] One example of an embodiment of these techniques is a method implemented in a UE for receiving an MBS. The method may be executed by processing hardware and includes attempting to receive a first transmission from a base station via multicast, the first transmission including MBS data packets associated with the MBS, sending an indication to the base station of whether the UE successfully received the first transmission according to a mechanism for automatic retransmission of undelivered packets, and in response to the sending, attempting to receive a second transmission from the base station via unicast according to the mechanism, and determining whether the second transmission is a new transmission or a retransmission of the first transmission.

[0012] Another example embodiment of these techniques is a UE that includes processing hardware configured to perform the methods described above.

[0013] Yet another exemplary embodiment of these techniques is a method at a base station for receiving an MBS. The method may be performed by processing hardware and includes transmitting a first transmission including an MBS data packet associated with the MBS to a plurality of UEs using a mechanism for automatic retransmission of undelivered packets, receiving an indication from at least one of the plurality of UEs of whether the UE successfully received the first transmission, and in response to receiving, determining, by the processing hardware, whether to transmit a second transmission via multicast or unicast according to the mechanism.

[0014] Yet another exemplary embodiment of these techniques is a base station that includes processing hardware configured to perform the methods described above. [Brief description of the drawings]

[0015] [Figure 1A] 1 is a block diagram of an example system in which the techniques of the present disclosure for managing multicast radio resources may be implemented. [Figure 1B]FIG. 1B is a block diagram of an exemplary base station in which a centralized unit (CU) and a distributed unit (DU) can operate in the system of FIG. 1A. [Figure 2A] 1B is a block diagram of an example protocol stack by which the UE of FIG. 1A can communicate with the base station of FIG. 1A. [Figure 2B] FIG. 1B is a block diagram of an example protocol stack by which the UE of FIG. 1A can communicate with the DU and CU of the base station. [Diagram 3] FIG. 1 is a block diagram of an example tunnel architecture for MBS and PDU sessions. [Figure 4] FIG. 1 is a block diagram of an example tunnel architecture for an MRB and a DRB. [Figure 5A] FIG. 1C is a messaging diagram of an example scenario in which the CN and base station of FIG. 1A and / or FIG. 1B manage transmission of downlink data for different MBS sessions joined by different UEs. [Figure 5B] FIG. 5B is a messaging diagram of an example scenario similar to that of FIG. 5A, but in which one of the UEs participates in both the first and second MBS sessions. [Figure 6A] FIG. 13 is a flow diagram of an example method that may be implemented in a UE of the present disclosure for performing a HARQ process when the UE does not support PTP retransmission. [Figure 6B] FIG. 13 is a flow diagram of an example method that may be implemented in a UE of the present disclosure for performing a HARQ process when the UE supports PTP retransmission. [Figure 6C] FIG. 13 is a flow diagram of an example method that may be implemented in a UE of the present disclosure for performing a HARQ process when the UE has enabled or disabled PTP retransmissions. [Figure 6D] FIG. 1 is a flow diagram of an example method that may be implemented in a UE of the present disclosure for performing an HARQ process that includes comparing transport block sizes of HARQ transmissions. [Figure 6E]A flow diagram of an example method that may be implemented in a UE of the present disclosure for performing a HARQ process using a C-RNTI or G-RNTI to process HARQ transmissions. [Figure 7A] 1 is a flow diagram of an example method that may be implemented in a base station of the present disclosure for performing a HARQ process based on whether a UE supports PTP retransmission. [Figure 7B] 1 is a flow diagram of an example method that may be implemented in a base station of the present disclosure for performing a HARQ process based on whether a UE has PTP retransmission enabled. [Figure 7C] FIG. 13 is a flow diagram of an example method that may be implemented in a base station of the present disclosure for performing an HARQ process in which the method of sending an HARQ transmission to a UE is to control how subsequent HARQ transmissions are sent to the UE. [Figure 8A] FIG. 13 is a flow diagram of an example method that may be implemented in a base station of the present disclosure for performing a HARQ process in which the type of HARQ feedback received from the UE in response to a HARQ transmission determines how to send a subsequent HARQ transmission to the UE. [Figure 8B] FIG. 1 is a flow diagram of an example method that may be implemented in a base station of the present disclosure for performing an HARQ process in which network bandwidth considerations associated with the HARQ transmission determine how to send a subsequent HARQ transmission to a UE. [Figure 9] 1B is a flow diagram of an example method for receiving an MBS that may be implemented in the UE of FIG. 1A. [Figure 10] 1C is a flow diagram of an example method for providing MBS that may be implemented in the base station of FIG. 1A or FIG. 1B. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0016] FIG 1A illustrates an example wireless communication system 100 in which techniques of the present disclosure for managing transmission and reception of multicast and / or broadcast service (MBS) information may be implemented. The wireless communication system 100 includes user equipment (UE) 102A, 102B, and 103, and base stations 104, 106 of a radio access network (RAN) 105 connected to a core network (CN) 110. In other implementations or scenarios, the wireless communication system 100 may instead include more or fewer UEs and / or more or fewer base stations than those illustrated in FIG 1A. The base stations 104, 106 may be any suitable type or types of base stations, such as, for example, an evolved Node B (eNB), a next generation eNB (ng-eNB), or a 5G Node B (gNB). As a more specific example, the base station 104 may be an eNB or a gNB, and the base station 106 may be a gNB.

[0017] The base station 104 supports a cell 124, and the base station 106 supports a cell 126. The cell 124 partially overlaps with the cell 126, so that the UE 102A can be within range to communicate with the base station 104 and at the same time within range to communicate with the base station 106 (or within range to detect or measure a signal from the base station 106). The overlap can, for example, enable the UE 102A to handover between cells (e.g., from the cell 124 to the cell 126) or between base stations (e.g., from the base station 104 to the base station 106) before the UE 102A experiences a radio link failure. Additionally, the overlap can enable various dual connectivity (DC) scenarios. For example, the UE 102A can communicate with the base station 104 (acting as a master node (MN)) and the base station 106 (acting as a secondary node (SN)) in DC. When UE 102A is in DC with base station 104 and base station 106, base station 104 operates as a master eNB (MeNB), master ng-eNB (Mng-eNB), or master gNB (MgNB), and base station 106 operates as a secondary gNB (SgNB) or secondary ng-eNB (Sng-eNB).

[0018] In non-MBS (unicast) operation, the UE 102A may use a radio bearer (e.g., DRB or SRB) that terminates at the MN (e.g., base station 104) or SN (e.g., base station 106) at different times. For example, after a handover or SN change to the base station 106, the UE 102A may use a radio bearer (e.g., DRB or SRB) that terminates at the base station 106. The UE 102A may apply one or more security keys when communicating on a radio bearer in an uplink (UE 102A to base station) direction and / or a downlink (base station to UE 102A) direction. In non-MBS operation, the UE 102A transmits data to a base station via a radio bearer on (i.e., within) the uplink (UL) bandwidth portion (BWP) of the cell and / or receives data from a base station via a radio bearer on the downlink (DL) BWP of the cell. The UL BWP may be an initial UL BWP or a dedicated UL BWP, and the DL BWP may be an initial DL BWP or a dedicated DL BWP. The UE 102A may receive paging, system information, public alert message(s), or random access response on the DL BWP. In this non-MBS operation, the UE 102A may be in a connected state. Alternatively, the UE 102A may be in an idle or inactive state if the UE 102A supports small data transmission in the idle or inactive state.

[0019] In MBS operation, the UE 102A can use an MBS radio bearer (MRB) that terminates at a MN (e.g., base station 104) or a SN (e.g., base station 106) at different times. For example, after handover or SN change, the UE 102A can use an MRB that terminates at a base station 106 that can operate as a MN or SN. In some scenarios, the base station (e.g., MN or SN) can transmit MBS data to the UE 102A via a unicast radio resource (i.e., radio resource dedicated to the UE 102A) via the MRB. In other scenarios, the base station (e.g., MN or SN) can transmit MBS data via a multicast radio resource (i.e., radio resource common to the UE 102A and one or more other UEs) or via a DL BWP of a cell from the base station to the UE 102A via the MRB. The DL BWP can be an initial DL BWP, a dedicated DL BWP, or an MBS DL BWP (i.e., a DL BWP specific to the MBS or a DL BWP not for unicast).

[0020] The base station 104 comprises processing hardware 130, which may include one or more general-purpose processors (e.g., central processing unit (CPU)), computer-readable memory storing machine-readable instructions executable by the one or more general-purpose processor(s), and / or special-purpose processing units. The processing hardware 130 in the exemplary implementation of FIG. 1A includes an MBS controller 132 configured to manage or control transmission of MBS information received from the CN 110 or edge server. For example, the MBS controller 132 may be configured to support radio resource control (RRC) configurations, procedures and messaging associated with MBS procedures, including HARQ processes, and / or other operations associated with those configurations and / or procedures, as described below. The processing hardware 130 may also include a non-MBS controller 134 configured to manage or control one or more RRC configurations and / or RRC procedures when the base station 104 operates as a MN or SN during non-MBS operation.

[0021] Base station 106 includes processing hardware 140, which may include one or more general-purpose processors (e.g., CPUs), computer-readable memory storing machine-readable instructions executable by the general-purpose processor(s), and / or special-purpose processing units. The processing hardware 140 in the exemplary implementation of FIG. 1A includes an MBS controller 142 and a non-MBS controller 144, which may be similar to controllers 132 and 134, respectively, of base station 130. Although not shown in FIG. 1A, RAN 105 may include additional base stations having processing hardware similar to processing hardware 130 of base station 104 and / or processing hardware 140 of base station 106.

[0022] The UE 102A includes processing hardware 150, which may include one or more general-purpose processors (e.g., CPUs), computer-readable memory storing machine-readable instructions executable by the general-purpose processor(s), and / or special-purpose processing units. The processing hardware 150 in the exemplary embodiment of FIG. 1A includes an MBS controller 152 configured to manage or control reception of MBS information. For example, the UE MBS controller 152 may be configured to support RRC configurations, procedures and messaging associated with MBS procedures, including HARQ processes, and / or other operations associated with those configurations and / or procedures, as described below. The processing hardware 150 may also include a non-MBS controller 154 configured to manage or control one or more RRC configurations and / or RRC procedures according to any of the embodiments described below when the UE 102A communicates with the MN and / or SN during non-MBS operation. Although not shown in FIG. 1A, the UEs 102B and 103 may include processing hardware similar to the processing hardware 150 of the UE 102A.

[0023] The CN 110 may be an evolved packet core (EPC) 111 or a fifth generation core (5GC) 160, both of which are shown in FIG. 1A. The base station 104 may be an eNB supporting an S1 interface for communicating with the EPC 111, an ng-eNB supporting an NG interface for communicating with the 5GC 160, or a gNB supporting an NR radio interface and an NG interface for communicating with the 5GC 160. The base station 106 may be an EUTRA-NR DC (EN-DC) gNB (en-gNB) with an S1 interface to the EPC 111, an en-gNB that does not connect to the EPC 111, a gNB supporting an NR radio interface and an NG interface to the 5GC 160, or an ng-eNB supporting an EUTRA radio interface and an NG interface to the 5GC 160. The base stations 104 and 106 may support an X2 interface or an Xn interface to directly exchange messages with each other during the scenarios described below.

[0024] Among other components, the EPC 111 may include a Serving Gateway (SGW) 112, a Mobility Management Entity (MME) 114, and a Packet Data Network Gateway (PGW) 116. The SGW 112 is generally configured to forward user plane packets related to voice calls, video calls, Internet traffic, etc., and the MME 114 is configured to manage authentication, registration, paging, and other related functions. The PGW 116 provides connectivity from a UE (e.g., UE 102A or 102B) to one or more external packet data networks, such as an Internet network and / or an Internet Protocol (IP) Multimedia Subsystem (IMS) network. The 5GC 160 includes a User Plane Function (UPF) 162, an Access and Mobility Management (AMF) 164, and / or a Session Management Function (SMF) 166. The UPF 162 is generally configured to forward user plane packets related to voice calls, video calls, Internet traffic, etc., the AMF 164 is generally configured to manage authentication, registration, paging, and other related functions, and the SMF 166 is generally configured to manage PDU sessions.

[0025] The UPF 162, AMF 164, and / or SMF 166 may be configured to support MBS. For example, the SMF 166 may be configured to manage or control MBS transport, configure the UPF 162 and / or the RAN 105 for MBS flows, and / or manage or set up one or more MBS or PDU sessions for MBS for a UE (e.g., UE 102A or 102B). The UPF 162 is configured to forward MBS data packets, such as audio, video, Internet traffic, etc., to the RAN 105. The UPF 162 and / or SMF 166 may be configured for both non-MBS unicast services and MBS, or for MBS only.

[0026] In general, the wireless communication system 100 may include any suitable number of base stations supporting NR cells and / or EUTRA cells. More specifically, the EPC 111 or 5GC 160 may be connected to any suitable number of base stations supporting NR cells and / or EUTRA cells. In the following examples, specific reference is made to specific CN types (EPC, 5GC) and RAT types (5G NR and EUTRA), but in general, the techniques of the present disclosure may also be applied to other suitable radio access technologies and / or core network technologies, such as, for example, sixth generation (6G) radio access and / or 6G core network or 5G NR-6G DC.

[0027] In different configurations or scenarios of the wireless communication system 100, the base station 104 may operate as an MeNB, an Mng-eNB, or an MgNB, and the base station 106 may operate as an SgNB or an Sng-eNB. The UE 102A may communicate with the base stations 104 and 106 via the same radio access technology (RAT), such as EUTRA or NR, or via different RATs.

[0028] When the base station 104 is an MeNB and the base station 106 is an SgNB, the UE 102A can be in an EN-DC with the MeNB 104 and the SgNB 106. When the base station 104 is an Mng-eNB and the base station 106 is an SgNB, the UE 102A can be in a Next Generation (NG) EUTRA-NR DC (NGEN-DC) with the Mng-eNB 104 and the SgNB 106. When the base station 104 is an MgNB and the base station 106 is an SgNB, the UE 102A can be in an NR-NR DC (NR-DC) with the MgNB 104 and the SgNB 106. When the base station 104 is an MgNB and the base station 106 is an SgNB, the UE 102A can be in an NR-EUTRA DC (NE-DC) with the MgNB 104 and the Sng-eNB 106.

[0029] 1B illustrates an exemplary distributed implementation of any one or more of the base stations 104 and 106. In this implementation, the base station 104 or 106 includes a central unit (CU) 172 and one or more distributed units (DUs) 174. The CU 172 includes processing hardware, such as one or more general-purpose processors (e.g., CPUs), and computer-readable memory that stores machine-readable instructions executable by the general-purpose processor(s), and / or special-purpose processing units. For example, the CU 172 can include some or all of the processing hardware 130 or 140 of FIG. 1A.

[0030] Each of the DUs 174 also comprises processing hardware that may include one or more general-purpose processors (e.g., CPUs) and computer-readable memory that stores machine-readable instructions executable by the one or more general-purpose processors, and / or special-purpose processing units. For example, the processing hardware may include a Medium Access Control (MAC) controller configured to manage or control one or more MAC operations or procedures (e.g., random access procedures) and a Radio Link Control (RLC) controller configured to manage or control one or more RLC operations or procedures when the base station (e.g., base station 104) operates as a MN or SN. The processing hardware may also include a PHY layer controller configured to manage or control one or more PHY layer operations or procedures.

[0031] In some implementations, the CU 172 may include one or more logical nodes (CU-CP(s) 172A) that host a control plane portion of the Packet Data Convergence Protocol (PDCP) protocol and / or a Radio Resource Control (RRC) protocol for the CU 172. The CU 172 may also include one or more logical nodes (CU-UP(s) 172B) that host a user plane portion of the PDCP protocol and / or a Service Data Adaptation Protocol (SDAP) protocol for the CU 172. As described herein, the CU-CP(s) 172A may transmit non-MBS control information and MBS control information, and the CU-UP(s) 172B may transmit non-MBS data packets and MBS data packets.

[0032] The CU-CP(s) 172A may be connected to multiple CU-UP(s) 172B via an E1 interface. The CU-CP(s) 172A selects the appropriate CU-UP(s) 172B for the service requested for the UE 102A. In some embodiments, a single CU-UP 172B may be connected to multiple CU-CPs 172A via an E1 interface. The CU-CP 172A may be connected to one or more DUs 174 via an F1-C interface. The CU-UP 172B may be connected to one or more DUs 174 via an F1-U interface under the control of the same CU-CP 172A. In some embodiments, one DU 174 may be connected to multiple CU-UPs 172B under the control of the same CU-CP 172A. In such an embodiment, the connection between the CU-UP 172B and the DU 174 is established by the CU-CP 172A using a bearer context management function.

[0033] 2A illustrates a simplified example protocol stack 200 according to which a UE (e.g., UE 102A, 102B, or 103) can communicate with an eNB / ng-eNB or gNB (e.g., one or more of base stations 104, 106). In the example protocol stack 200, the EUTRA PHY sublayer 202A provides transport channels to the EUTRA MAC sublayer 204A, which in turn provides logical channels to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A then provides RLC channels to the EUTRA PDCP sublayer 208 and possibly to the NR PDCP sublayer 210. Similarly, the NR PHY 202B provides transport channels to the NR MAC sublayer 204B, which in turn provides logical channels to the NR RLC sublayer 206B. The NR RLC sublayer 206B then provides RLC channels to the NR PDCP sublayer 210. The UE 102A, in some embodiments, supports both EUTRA and NR stacks, supports handover between EUTRA and NR base stations, and / or supports DC over EUTRA and NR interfaces, as shown in Figure 2A. Additionally, as shown in Figure 2A, the UE 102A can support layering of an NR PDCP 210 over the EUTRA RLC 206A, and an SDAP sublayer 212 over the NR PDCP sublayer 210. The sublayers are also referred to herein simply as "layers."

[0034] The EUTRA PDCP sublayer 208 and the NRPDCP sublayer 210 receive packets that may be referred to as service data units (SDUs) (e.g., from an IP layer layered directly or indirectly on the PDCP layer 208 or 210) and output packets that may be referred to as protocol data units (PDUs) (e.g., to the RLC layer 206A or 206B). For simplicity, this disclosure refers to both SDUs and PDUs as "packets" except where the distinction between SDUs and PDUs is relevant. The packets can be MBS packets or non-MBS packets. The MBS packets may include, for example, application content for an MBS service (e.g., IPv4 / IPv6 multicast distribution, IPTV, over-the-air software distribution, group communication, IoT applications, V2X applications, and / or emergency messages related to public safety). As another example, the MBS packets may include application control information for an MBS service.

[0035] In the control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide SRBs to exchange, for example, RRC messages or non-access stratum (NAS) messages. In the user plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide DRBs to support data exchange. The data exchanged with the NR PDCP sublayer 210 can be, for example, SDAP PDUs, IP packets, or Ethernet packets.

[0036] In a scenario where the UE 102A, 102B, or 103 operates in an EN-DC where the base station 104 operates as an MeNB and the base station 106 operates as an SgNB, the wireless communication system 100 may provide the UE 102A, 102B, or 103 with an MN terminated bearer using the EUTRA PDCP sublayer 208 or an MN terminated bearer using the NR PDCP sublayer 210. The wireless communication system 100 may also provide the UE 102A, 102B, or 103 with an SN terminated bearer using only the NR PDCP sublayer 210 in various scenarios. The MN terminated bearer may be an MCG bearer, a split bearer, or an MN terminated SCG bearer. The SN terminated bearer may be an SCG bearer, a split bearer, or an SN terminated MCG bearer. The MN terminated bearer may be an SRB (e.g., SRB1 or SRB2) or a DRB. The SN terminated bearer may be an SRB or a DRB.

[0037] In some implementations, a base station (e.g., base station 104, 106) broadcasts MBS data packets over one or more MBS radio bearers (MRB(s)), and then the UE 102A, 102B, or 103 receives the MBS data packets over the MRB(s). The base station may include configuration(s) of the MRB(s) in multicast configuration parameters (sometimes also referred to as MBS configuration parameters) described below. In some implementations, the base station broadcasts MBS data packets over the RLC sublayer 206, the MAC sublayer 204, and the PHY sublayer 202, and in response, the UE 102A receives the MBS data using the PHY sublayer 202, the MAC sublayer 204, and the RLC sublayer 206. In such implementations, the base station and the UE 102A, 102B, or 103 may not use the PDCP sublayer 208 and the SDAP sublayer 212 to communicate the MBS data packets. In other embodiments, the base station transmits the MBS data packets via the PDCP sublayer 208, the RLC sublayer 206, the MAC sublayer 204, and the PHY sublayer 202, and in response, the UE 102A, 102B, or 103 receives the MBS data packets using the PHY sublayer 202, the MAC sublayer 204, the RLC sublayer 206, and the PDCP sublayer 208. In such embodiments, the base station and the UE 102A, 102B, or 103 may not use the SDAP sublayer 212 to communicate the MBS data packets. In yet another embodiment, the base station transmits the MBS data packets via the SDAP sublayer 212, the PDCP sublayer 208, the RLC sublayer 206, the MAC sublayer 204, and the PHY sublayer 202, and in response, the UE 102A, 102B, or 103 receives the MBS data packets using the PHY sublayer 202, the MAC sublayer 204, the RLC sublayer 206, the PDCP sublayer 208, and the SDAP sublayer 212.

[0038] FIG. 2B illustrates a simplified example protocol stack 250 that a UE 102A, 102B, or 103 may use to communicate with a DU (e.g., DU 174) and a CU (e.g., CU 172). The radio protocol stack 200 of FIG. 2A is functionally divided by the radio protocol stack 250 of FIG. 2B as shown. The CU in either the base station 104 or 106 may retain all control and higher layer functions (e.g., RRC 214, SDAP 212, NR PDCP 210), while lower layer operations (e.g., NR RLC 206B, NR MAC 204B, and NR PHY 202B) may be delegated to the DU. To support a connection to 5GC, the NR PDCP 210 provides an SRB to the RRC 214, which in turn provides a DRB to the SDAP 212, which in turn provides an SRB to the RRC 214.

[0039] 3, the MBS session 302A may include a tunnel 312A with endpoints at the CN 110 and the base station 104 / 106. The MBS session 302A may correspond to a particular session ID, such as, for example, a Temporary Mobile Group Identity (TMGI). The MBS data may include, for example, IP packets, TCP / IP packets, UDP / IP packets, Real-time Transport Protocol (RTP) / UDP / IP packets, or RTP / TCP / IP packets.

[0040] In some cases, the CN 110 and / or base station 104 / 106 configure the tunnel 312A only for MBS traffic directed from the CN 110 to the base station 104 / 106, and the tunnel 312A may be referred to as a downlink (DL). However, in other cases, the CN 110 and base station 104 / 106 use the tunnel 312A for downlink and uplink (UL) MBS traffic to support, for example, a command or service request from a UE. Furthermore, because the base station 104 / 106 can direct MBS traffic arriving via the tunnel 312A to multiple UEs, the tunnel 312A may be referred to as a common tunnel or a common DL tunnel.

[0041] The tunnel 312A may operate at a transport layer or sublayer, e.g., a User Datagram Protocol (UDP) protocol layered on the Internet Protocol (IP). As a more specific example, the tunnel 312A may be associated with a General Packet Radio Service (GPRS) Tunneling Protocol (GTP). The tunnel 312A may correspond, for example, to a particular IP address (e.g., an IP address of the base station 104 / 106) and a particular Tunnel Endpoint Identifier (TEID) (e.g., assigned by the base station 104 / 106). More generally, the tunnel 312A may have any suitable transport layer configuration. The CN 110 may specify the IP address and the TEID address in the header(s) of the tunnel packet including the MBS data packet and transmit the tunnel packet downstream to the base station 104 / 106 via the tunnel 312A (e.g., the header(s) may include the IP address and / or the TEID). For example, the header(s) may include an IP header and a GTP header including the IP address and the TEID, respectively. Thus, base stations 104 / 106 can use the IP address and / or TEID to identify data packets traveling through tunnel 312A.

[0042] As shown in FIG. 3, the base station 104 / 106 maps the traffic in the tunnel 312A to N radio bearers 314A-1, 314A-2, ... 314A-N, where N > 1, which may be configured as MBS radio bearers or MRBs. Each MRB may correspond to a respective logical channel. As described above, the PDCP sublayer provides support for radio bearers such as SRBs, DRBs, and MRBs, and the EUTRA or NR MAC sublayer provides logical channels to the EUTRA or NR RLC sublayer. Each of the MRBs 314A may correspond to, for example, a respective MBS traffic channel (MTCH). The base station 104 / 106 and the CN 110 may also maintain another MBS session 302B, and may similarly include a tunnel 312B corresponding to MRBs 314B-1, 314B-2, ... 314B-N, where N > 1. Each MRB 314B may correspond to a respective logical channel.

[0043] The MBS traffic may include one or more quality of service (QoS) flows for each of the tunnels 312A, 312B, etc. For example, the MBS traffic on the tunnel 312B may include a set of flows 316, such as QoS flows 316A, 316B, ... 316L. Furthermore, the logical channel of an MRB may support a single QoS flow or multiple QoS flows. In the exemplary configuration of FIG. 3, the base station 104 / 106 maps the QoS flows 316A and 316B to the MTCH of the MRB 314B-1 and maps the QoS flow 316L to the MTCH of the MRB 314B-N.

[0044] In various scenarios, the CN 110 can assign different types of MBS traffic to different QoS flows. For example, flows with relatively high QoS values ​​can correspond to audio packets, and flows with relatively low QoS values ​​can correspond to video packets. As another example, flows with relatively high QoS values ​​can correspond to I-frames or full images used in video compression, and flows with relatively low QoS values ​​can correspond to predicted pictures that only include changes to P-frames or I-frames.

[0045] 3, the base station 104 / 106 and the CN 110 can maintain one or more PDU sessions to support unicast traffic between the CN 110 and a particular UE. The PDU session 304A can include a UE-specific DL tunnel and / or a UE-specific UL tunnel 322A corresponding to one or more DRBs 324A, such as DRBs 324A-1, 324A-2, ... 324-N. Each DRB 324A can correspond to a respective logical channel, such as a Dedicated Traffic Channel (DTCH).

[0046] Now referring to FIG. 4, when the base station 104 / 106 is implemented in a distributed manner, the CU 172 and the DU 174A / 174B can establish tunnels for downlink data and / or uplink data associated with the MRB or DRB. The above MRB 314A-1 can be implemented as an MRB 402A connecting the CU 172 to multiple UEs, such as UEs 102A and 102B. The MRB 402A can include a DL tunnel 412A connecting the CU 172 and the DU 174A / 174B, and a DL logical channel 422A corresponding to the DL tunnel 412A. In particular, the DU 174A / 174B can map the downlink traffic received via the DL tunnel 412A to the DL logical channel 422A, which can be, for example, an MTCH or a DTCH. The DL tunnel 412A can be a common DL tunnel, and the CU 172 transmits MBS data packets to multiple UEs via the common DL tunnel. Alternatively, the DL tunnel 412A can be a UE-specific DL tunnel, and the CU 172 transmits MBS data packets to a particular UE via the UE-specific DL tunnel.

[0047] Optionally, the MRB 402A also includes a UL tunnel 413A connecting the CU 172 and the DU 174A / 174B, and a UL logical channel 423A corresponding to the UL tunnel 413A. The UL logical channel 423A can be, for example, a DTCH. The DU 174A / 174B can map uplink traffic received via the UL logical channel 423A to the UL tunnel 413A.

[0048] The tunnels 412A and 413A may operate at the transport layer or sublayer of the F1-U interface. As a more specific example, the CU 172 and DU 174A / 174B may utilize the F1-U for user plane traffic, and the tunnels 412A and 413A may be associated with a GTP-U protocol layered on UDP / IP, with the IP layered on the appropriate data link layer and physical (PHY) layer. Furthermore, the MRB(s) 402 and / or DRB(s) 404 may additionally support control plane traffic, at least in some cases. More specifically, the CU 172 and DU 174A / 174B may exchange F1-AP messages over the F1-C interface, which relies on the Stream Control Transmission Protocol (SCTP) layered on IP, with the IP layered on the appropriate data link layer and PHY layer, similar to the F1-U.

[0049] Similarly, the MRB 402B may include a DL tunnel 412B and, optionally, a UL tunnel 413B. The DL tunnel 412B may correspond to a DL logical channel 422B, and the UL tunnel 413B may correspond to a UL logical channel 423B.

[0050] The CU 172 uses the DRB 404A to transmit MBS data packets or unicast data packets associated with a PDU session to a particular UE (e.g., UE 102A or UE 102B) in some cases. The DRB 404A may include a UE-specific DL tunnel 432A connecting the CU 172 and the DU 174A / 174B, and a DL logical channel 442A corresponding to the DL tunnel 432A. In particular, the DU 174A / 174B may map downlink traffic received via the DL tunnel 432A to the DL logical channel 442A, which may be, for example, a DTCH. The DRB 404A further includes a UE-specific UL tunnel 433A connecting the CU 172 and the DU 174A / 174B, and a UL logical channel 443A corresponding to the UL tunnel 433A. The UL logical channel 443A may be, for example, a PUSCH. The DU 174A / 174B can map the uplink traffic received via the UL logical channel 443A to the UL tunnel 433A.

[0051] Similarly, the DRB 404B may include a UE-specific DL tunnel 432B corresponding to the DL logical channel 442B and a UE-specific UL tunnel 433B corresponding to the UL logical channel 443B.

[0052] Next, FIG. 5A shows an example scenario 500A in which, in response to a CN requesting resources for a first MBS session, the base station 104 configures a first common tunnel for MBS data, and in response to the CN requesting resources for a second MBS session, the base station 104 configures a second common tunnel for MBS data.

[0053] A UE 102 (e.g., UE 102A in FIG. 1A) first performs an MBS session join procedure (502) with the CN 110 via a base station 104 to join a first MBS session. In some scenarios, the UE 102 subsequently performs one or more additional MBS join procedures, and thus event 502 is the first of multiple MBS join procedures. Because the base station 104 configures a common DL tunnel for MBS traffic (rather than a UE-specific tunnel as described below), procedures 502 and 586 can occur in either order. In other words, the base station 104 can configure the common DL tunnel before even a single UE joins the first MBS session.

[0054] To perform the MBS session join procedure, in some embodiments, the UE 102 sends an MBS session join request message to the CN 110 via the base station 104. In response, the CN 110 can send an MBS session join response message to the UE 102 via the base station 104 to grant the UE 102 access to the first MBS session. In some embodiments, the UE 102 can include a first MBS session ID of the first MBS session in the MBS session join request message. The CN 110 optionally includes the first MBS session ID in the MBS session join response message. In some embodiments, the UE 102 can send an MBS session join complete message to the CN 110 via the base station 104 in response to the MBS session join response message.

[0055] The UE 102 may possibly perform additional MBS session join procedure(s) with the CN 110 via the RAN 105 (e.g., the base station 104 or the base station 106) to join the additional MBS session(s). For example, the UE 102 may perform a second MBS session join procedure with the CN 110 via the RAN 105 to join the second MBS session. Similar to event 502, the UE 102 in some implementations may send a second MBS session join request message to the CN 110 via the base station 104, and the CN 110 may respond with a second MBS session join response message to grant the UE 102 access to the second MBS session. In some implementations, the UE 102 may send a second MBS session join completion message to the CN 110 via the base station 104 in response to the second MBS session join response message. In some implementations, the UE 102 may include a second MBS session ID of the second MBS session in the second MBS session join request message. CN 110 optionally includes the second MBS session ID in the second MBS session join response message. In some implementations, UE 102 can include the first MBS session ID and the second MBS session ID in an MBS session join request message (e.g., the first MBS session join request message) and join the first MBS session and the second MBS session simultaneously. In such a case, CN 110 can send an MBS session response message to admit either the first MBS session or the second MBS session, or both the first and second MBS sessions.

[0056] In some embodiments, the MBS session join request message, the MBS session join response message, and the MBS session join complete message can be Session Initiation Protocol (SIP) messages. In other embodiments, the MBS session join request message, the MBS session join response message, and the MBS session join complete message can be NAS messages, such as 5G Mobility Management (5GMM) messages or 5G Session Management messages (5GSM). For 5GSM messages, the UE 102 can send a (first) UL container message including the MBS session join request message to the CN 110 via the base station 104, the CN 110 can send a DL container message including the MBS session join response message to the UE 102 via the base station 104, and the UE 102 can send a (second) UL container message including the MBS session join complete message to the CN 110 via the base station 104. These container messages can be 5GMM messages. In some embodiments, the MBS session join request message, the MBS session join response, and the MBS session join complete message may be a PDU session change request message, a PDU session change command message, and a PDU session change complete message, respectively. To simplify the following description, the terms MBS session join request message, MBS session join response message, and / or MBS session join complete message may refer to either the respective container messages or the respective messages without the container.

[0057] In some embodiments, the UE 102 may perform a PDU session establishment procedure with the CN 110 via the base station 104 to establish a PDU session in order to perform the (first) MBS session join procedure. During the PDU session establishment procedure, the UE 102 may communicate a PDU session ID of the PDU session with the CN 110 via the base station 104.

[0058] Before, during, or after the first MBS session join procedure (event 502), the CN 110 may send (504) a (first) CN-to-BS message to the CU 172 including the first MBS session ID and / or PDU session ID to request the CU 172 to configure resources for the first MBS session. The CN 110 may additionally include in the first CN-to-BS message a quality of service (QoS) configuration(s) for the first MBS session. In response to receiving (504) the first CN-to-BS message, the CU 172 may send (506) a CU-to-DU message (e.g., an MBS context setup request message) to the DU 174 to request setup of an MBS context and / or a common DL tunnel for the first MBS session. The MBS context setup request message may include the first MBS session ID, the MRB ID(s), and the QoS configuration(s) for the first MBS session.

[0059] In response to receiving the CU-DU message (506), the DU 174 sends a DU-CU message (e.g., an MBS context setup response message) including a first DL transport layer configuration to the CU to configure a common CU-DU DL tunnel for the first MBS session (e.g., for the MRB identified by one of the MRB ID(s)). The DU 174 can include additional DL transport layer configuration(s) in the DU-CU message and configure additional common CU-DU DL tunnel(s) for additional MRB(s) identified by additional MRB ID(s) of the MRB IDs. In some implementations, the DU 174 can include MRB ID(s) associated with the first DL transport layer configuration and / or the additional DL transport layer configuration(s) in the DU-CU message. In some embodiments, the CU-DU message of event 506 is a generic F1AP message or a dedicated F1AP message specifically defined for conveying this type of request (e.g., an MBS context setup request message). In some embodiments, the DU-CU message of event 508 is a generic F1AP message or a dedicated F1AP message specifically defined for this purpose (e.g., an MBS context setup response message). The CN 110 may additionally include quality of service (QoS) configuration(s) for the first MBS session. In such a case, the CU 172 may include the QoS configuration(s) in the CU-DU message (event 506).

[0060] The CU 172 may then send (510) a first inter-BS-CN message (e.g., an MBS Session Resource Setup Response message) including a DL transport layer configuration to configure the common DL tunnel. The CU 172 may include a first MBS Session ID and / or a PDU Session ID in the first inter-BS-CN message. The first inter-BS-CN message may include a DL transport layer configuration for configuring the common DL tunnel in the CN 110 to transmit the MBS data to the CU 172. The DL transport layer configuration includes a transport layer address (e.g., an IP address and / or a TEID) to identify the common DL tunnel.

[0061] In some embodiments, the CN-BS message of event 504 can be a generic NGAP message or a dedicated NGAP message specifically defined to request resources for an MBS session (e.g., an MBS Session Resource Setup Request message). In some embodiments, the BS-CN message of event 510 can be a generic NGAP message or a dedicated NGAP message specifically defined to convey resources for an MBS session (e.g., an MBS Session Resource Setup Response message). In such a case, the CN-BS message of event 504 and the BS-CN message of event 510 can be non-UE specific messages.

[0062] In some embodiments, the QoS configuration(s) include QoS parameters for the first MBS session. In some embodiments, the QoS configuration includes configuration parameters for configuring one or more QoS flows for the MBS session (e.g., MBS session 302A of FIG. 3). In some embodiments, the configuration parameters include one or more QoS flow IDs that identify the QoS flow(s). Each of the QoS flow ID(s) identifies a particular QoS flow of the QoS flow(s). In some embodiments, the configuration parameters include QoS parameters for each QoS flow. The QoS parameters may include, for example, a 5G QoS identifier (5QI), a priority level, a packet delay budget, a packet error rate, an averaging window, and / or a maximum data burst amount. The CN 110 may assign different values ​​of the QoS parameters to the QoS flows.

[0063] Events 504, 506, 508, and 510 are collectively referred to as an MBS session resource setup procedure 586 in FIGS. 5A and 5B.

[0064] If the CN 110 grants the UE 102 additional MBS session(s) in additional MBS session join procedure(s), the CN 110 may include additional MBS session ID(s) and / or QoS configuration(s) for the additional MBS session ID(s) in the first CN-BS message, the second CN-BS message (described below in connection with Event 512), or additional CN-BS message(s) similar to the first CN-BS message or the second CN-BS message. In such a case, the CU 172 includes additional transport layer configuration(s) for the additional MBS session(s) and configures additional common DL tunnel(s) in the first BS-CN message, the second BS-CN message (described below in connection with Event 519), or additional BS-CN message(s) similar to the first BS-CN message or the second BS-CN message. Each transport layer configuration(s) may configure a specific DL tunnel of the common DL tunnel(s) and may be associated with a specific MBS session of the additional MBS session(s). Alternatively, the CN 110 may perform additional MBS session resource setup procedure(s) with the CU 172 to obtain the additional transport layer configuration(s) from the CU 172, similar to the single-session MBS session resource setup procedure 586. The transport layer configurations may be different to distinguish different common DL tunnels. In particular, any pair of transport layer configurations may have different IP addresses, different DL TEIDs, or both different IP addresses and different DLTEIDs.

[0065] In some embodiments, the CN 110 may indicate in the CN-BS message of event 504 a list of UEs participating in the first MBS session. In other embodiments, the CN 110 may send (512) another second CN-BS message to the CU 172 indicating a list of UEs participating in the first MBS session. The CN 110 may include the first MBS session ID and / or PDU session ID in the second CN-BS message. The CU 172 may send (519) a second BS-CN message to the CN 110 in response to the second CN-BS message of event 512. In such a case, the second CN-BS message may be a non-UE specific message, i.e., a message that is not specific to the UE 102A or the UE 102B. The CU 172 may include the first MBS session ID and / or PDU session ID in the second BS-CN message. For example, the list of UEs includes the UE 102. To indicate the list of UEs, the CN 110 may include a list of (CN UE interface ID, RAN UE interface ID) pairs, each identifying a specific UE among the UEs. The CN 110 assigns the CN UE interface ID, and the CU 172 assigns the RAN UE interface ID. Before the CN 110 transmits the list of (CN UE interface ID, RAN UE interface ID) pairs, the CU 172 transmits a BS-CN inter-message (e.g., an NGAP message, an initial UE message, or a path switch request message) including the RAN UE interface ID to the CN 110 for each UE, and the CN 110 transmits a CN-BS inter-message (e.g., an NGAP message, an initial context setup request T message, or a path switch request acknowledgement message) including the CN UE interface ID to the CU 172 for each UE. In one example, the list of pairs includes a first pair (first CN UE interface ID and first RAN UE interface ID) that identifies the UE 102.In some embodiments, the "CN UE Interface ID" can be an "AMF UE NGAP ID" and the "RAN UE Interface ID" can be a "RAN UE NGAP ID". In other embodiments, the CN 110 can include a list of UE IDs, each identifying a particular UE in the set of UEs. In some embodiments, the CN 110 can assign UE IDs and transmit each of the UE IDs to a particular UE among the UEs in a NAS procedure (e.g., a registration procedure) that the CN 110 performs with the particular UE. For example, the list of UE IDs can include a first UE ID of the UE 102A and a second UE ID of the UE 102B. In some embodiments, the UE ID is an S-Temporary Mobile Subscriber Identity (S-TMSI) (e.g., 5G-S-TMSI). Before the CN 110 transmits the list of UE IDs, the CU 172 can receive a UE ID for each UE from the UE 102 or the CN 110. For example, the CU 172 may receive an RRC message (e.g., an RRC Setup Complete message) including the UE ID from the UE 102 during an RRC connection establishment procedure. In another example, the CU 172 may receive a CN-BS message (e.g., an NGAP message, an Initial Context Setup Request message, or a UE Information Transfer message) including the UE ID from the CN 110.

[0066] In other embodiments, the CN 110 may send (512) a second CN-BS message to the CU 172 indicating that the UE 102 will participate in the first MBS session (only). The second CN-BS message may be a UE-related message for the UE 102. That is, the second CN-BS message is specific to the UE 102. In response to receiving the second CN-BS message, the CU 172 may send (514) a UE context request message for the UE 102 to the DU 174. In some embodiments, the CU 172 may include in the UE context request message the first MBS session ID and / or the MRB ID(s) of the MRB(s) associated with the first MBS session(s). In response to the UE context request message, the DU 174 sends (516) a UE context response message including configuration parameters for the UE 102A to the CU 172 to receive MBS data for the first MBS session. In some implementations, the CU 172 may include the QoS configuration(s) in the UE context request message. In such a case, the CU 172 may or may not include the QoS configuration(s) in the CU-DU message. Some or all of the configuration parameters may be associated with the MRB(s) / MRB ID(s). In some implementations, the DU 174 generates a DU configuration (i.e., a first DU configuration) to include the configuration parameters (i.e., the first plurality of configuration parameters) and includes the DU configuration in the UE context response message. In some implementations, the DU configuration may be a CellGroupConfig IE. In other implementations, the DU configuration may be an MBS-specific IE. In some implementations, the configuration parameters configure one or more logical channels (LC). For example, the configuration parameters include one or more logical channel IDs (LCIDs) to configure one or more logical channels. Each LCID identifies a particular logical channel of the one or more logical channels.

[0067] In some embodiments, the second CN-BS message and the second BS-CN message can be a PDU session resource modification request message and a PDU session resource modification response message, respectively. In some embodiments, the second CN-BS message and the second BS-CN message can be a UE-related message, i.e., the message is associated with a particular UE (e.g., UE 102A, 102B, or 103).

[0068] In some implementations, the CU 172 sends (510) the first inter-BS-CN message in response to event 512, rather than in response to event 504, as shown in FIG. 5A. The CN 110 may then send (506) an inter-CN-DU message to the CU 172 in response to the first inter-BS-CN message. In such a case, the CU 172 may send (506) an inter-CU-DU message to the DU 174 in response to receiving the second inter-CN-BS message, and the first inter-BS-CN message and the inter-CN-BS response message may be non-UE associated messages (i.e., the messages are not associated with a particular UE).

[0069] In some embodiments, in addition to sending (508) a DU-CU message in response to event 514 (rather than in response to event 506), the DU 174 also sends (516) a UE context response message in response to event 514. The CU 172 can then send a CU-DU response message to the DU 174 in response to the DU-CU message. In such a case, the DU-CU message and the CU-DU response message can be non-UE-associated messages, i.e., the messages are not associated with a particular UE.

[0070] If the CN 110 grants the UE 102 additional MBS session(s) in additional MBS session join procedure(s), the CN 110 may include additional MBS session ID(s) and / or QoS configuration(s) for the additional MBS session ID(s) in the first CN-BS message or the second CN-BS message. In such a case, the CU 172 may include additional MBS session ID(s) and additional MRB ID(s) in the CU-DU message, and the DU 174 may include additional DU transport layer configuration(s) in the DU-CU message to configure additional CU-DU DL tunnel(s) for the additional MBS session(s). Alternatively, the CU 172 may perform additional MBS context setup procedure(s) with the DU 174 to obtain additional DU DL transport layer configuration(s), similar to events 506 and 508. In some implementations, the CU 172 includes in the first BS-CN message additional CU DL transport layer configuration(s) of the additional MBS session(s) to configure additional CN-BS common DL tunnel(s). Each transport layer configuration(s) can configure a specific DL tunnel of the common CN-BS DL tunnel(s) and associate with a specific MBS session of the additional MBS session(s). Alternatively, the CN 110 can perform additional MBS session resource setup procedure(s) with the CU 172 to obtain the additional CU DL transport layer configuration(s) from the CU 172, similar to the MBS session resource setup procedure 586. The transport layer configurations can be different to distinguish different common DL tunnels. In particular, any pair of transport layer configurations can have different IP addresses, different DL TEIDs, or both different IP addresses and different DLTEIDs.

[0071] In some embodiments, the CN 110 includes the QoS configuration(s) in the second CN-BS message. In such a case, the CN 110 may include the QoS configuration(s) in the first CN-BS message or may omit the QoS configuration(s). In some embodiments, the DU 174 generates configuration parameters for the UE 102 in response to receiving the CU-DU message or the UE context request message to receive MBS data of the first MBS session. In some embodiments, the CU 172 includes the QoS configuration(s) in the UE context request message and / or the CU-DU message. The DU 174 can determine the content of the configuration parameters according to the QoS configuration(s). When the CU 172 does not include the QoS configuration(s) in the CU-DU message or the UE context request message, the DU 174 can determine the value of the configuration parameter according to the predefined QoS configuration.

[0072] In another embodiment, the UE context request message and the UE context response message are a UE context setup request message and a UE context setup response message, respectively. In another embodiment, the UE context request message and the UE context response message are a UE context modification request message and a UE context modification response message, respectively.

[0073] After receiving (516) the UE context response message, the CU 172 generates (518) an RRC reconfiguration message including the configuration parameters and one or more MRB configurations (i.e., first MRB configuration(s)) and sends (520) the RRC reconfiguration message to the DU 174. The DU 174 then sends (520) an RRC reconfiguration message to the UE 102. The UE 102 then sends (522) an RRC reconfiguration complete message to the DU 174 and then to the CU 172. Events 512, 514, 516, 518, 519 (described below), 520, 522, and 523 are collectively referred to in Figures 5A and 5B as a UE-specific MBS session configuration procedure 590.

[0074] In some embodiments, the CU 172 generates a PDCP PDU including the RRC reconfiguration message and transmits (518) a CU-to-DU message including the PDCP PDU to the DU 174, and the DU 174 obtains the PDCP PDU from the CU-to-DU message and transmits (520) the PDCP PDU to the UE 102 via the RLC layer 206B, the MAC layer 204B, and the PHY layer 202B. The UE 102 receives (520) the PDCP PDU from the DU 174 via the PHY layer 202B, the MAC layer 204B, and the RLC layer 206B. In some embodiments, the UE 102 generates a PDCP PDU including the RRC reconfiguration complete message and transmits (522) the PDCP PDU to the DU 174 via the RLC layer 206B, the MAC layer 204B, and the PHY layer 202B. The DU 174 receives (522) a PDCP PDU from the UE 102 via the PHY layer 202B, the MAC layer 204B, and the RLC layer 206B, and transmits (523) a DU-CU message including the PDCP PDU to the CU 172. The CU 172 obtains the PDCP PDU from the DU-CU message, and obtains an RRC reconfiguration complete message from the PDCP PDU.

[0075] Before or after receiving (516) the UE context response message, the CU 172 may transmit (519) the second inter-BS-CN message to the CN 110 in response to the second inter-CN-BS message 512. In some implementations, the CU 172 transmits (519) the second inter-BS-CN message to the CN 110 before receiving (523) the RRC reconfiguration complete message. In other implementations, the CN 110 transmits (519) the second inter-BS-CN message to the CN 110 after receiving (523) the RRC reconfiguration complete message. The CU 172 may include the first CN UE interface ID and the first RAN UE interface ID in the second inter-BS-CN message. Alternatively, the CU 172 may include the first UE ID in the second inter-BS-CN message.

[0076] In some implementations, the CU 172 includes the CU DL transport layer configuration(s) in the second inter-BS-CN message and / or in the additional inter-BS-CN message. In other words, the CU 172 can send the same CU DL transport layer configuration(s) in an inter-BS-CN message in response to an inter-CN-BS message indicating UEs participating in the same MBS session. In such implementations, the CN 110 can merge the MBS resource setup procedure 586 and the second inter-CN-BS message and the inter-BS-CN message into a single procedure.

[0077] If the CU 172 performs an MBS resource setup procedure 586 (e.g., events 504, 510) with the CN 110 to establish a common CN-BS DL tunnel for the first MBS session, the CU 172 may refrain from including the DL transport layer configuration of the first MBS session in the second BS-CN message. In such a case, the CN 110 may refrain from including the UL transport layer configuration of the first MBS session in the second CN-BS message. If the DU 174 performs an MBS resource setup procedure (e.g., events 506, 508) with the CU 172 to establish a common CU-DU DL tunnel for the first MBS session, the DU 174 may refrain from including the DL transport layer configuration of the first MBS session in the UE context response message. In such a case, the CU 172 may refrain from including the UL transport layer configuration of the first MBS session in the UE context request message.

[0078] After receiving (510) the first BS-CN message or after receiving (519) the second BS-CN message, the CN 110 can transmit (524) MBS data (e.g., one or more MBS data packets) of the first MBS session to the CU 172 via a common CN-BS DL tunnel, which then transmits (526) the MBS data to the DU 174 via a common CU-DU tunnel. The DU 174 transmits (528) the MBS data to the UE 102 via one or more logical channels (e.g., multicast or unicast). The UE 102 receives (528) the MBS data via one or more logical channels. For example, the CU 172 may receive (524) the MBS data packet, generate a PDCP PDU including the MBS data packet, and transmit (528) the PDCP PDU to the DU 174. The DU 174 then generates a MAC PDU including the logical channel ID and the PDCP PDU, and transmits (528) the MAC PDU to the UE 102 via multicast or unicast. The UE 102 receives (528) the MAC PDU via multicast or unicast, obtains the PDCP PDU and the logical channel ID from the MAC PDU, identifies the PDCP PDU associated with the MRB according to the logical channel ID, and obtains the MBS data packet from the PDCP PDU according to the PDCP configuration in the MRB configuration. In some implementations, the DU 174 can transmit (528) the MBS data or MAC PDU to the UE 102 via one or more multicast transmissions (e.g., dynamic or SPS multicast transmission(s)) as described above. In such a case, the UE 102 can receive (528) the MBS data or MAC PDU from the DU 174 via one or more multicast transmissions as described above.As further described below in Figures 6A-6E, 7A-7C, and 8A-8B, the UE 102 can receive (528) the MBS data or MAC PDU using a HARQ process, and the UE 102 transmits HARQ feedback to the base station 104 (e.g., the DU 174) to indicate whether the UE successfully received the MBS data (e.g., the first MBS data packet). Based on the HARQ feedback, the base station 104 (e.g., the DU 174) transmits (528) the MBS data as either a retransmission (e.g., the first MBS data packet) or a new transmission (e.g., the second MBS data packet).

[0079] In some implementations, the CU 172 may determine and configure a UE-specific CN-BS DL tunnel for the UE 102 in response to receiving the first CN-BS message or the second CN-BS message. In such a case, the CU 172 may omit event 506 and may include in the second BS-CN message a DL transport layer configuration for configuring the UE-specific DL tunnel. The CN 110 may transmit (524) the MBS data to the CU 172 via the UE-specific CN-BS DL tunnel. In some implementations, the CU 172 may determine and configure a UE-specific CU-DU DL tunnel for the UE 102 in response to receiving the first CN-BS message or the second CN-BS message. In such a case, the CU 172 may omit event 510 and the DU 174 may include in the UE context response message a DL transport layer configuration for configuring the UE-specific CU-DU DL tunnel. In such a case, the CU 174 may transmit (526) the MBS data to the DU 174 via a UE-specific CU-DU DL tunnel.

[0080] In some embodiments, the configuration parameters may also include one or more RLC bearer configurations, each associated with a particular MRB. Each MRB configuration(s) may include an MRB ID, a PDCP configuration, a first MBS session ID, a PDCP re-establishment indication (e.g., reestablishPDCP), and / or a PDCP recovery indication (e.g., recoveryPDCP). In some embodiments, the PDCP configuration may be a PDCP-Config IE of the DRB. In some embodiments, the RLC bearer configuration may be an RLC-BearerConfig IE. In some embodiments, the RLC bearer configuration may include a logical channel (LC) ID that configures a logical channel. In some embodiments, the logical channel may be a Multicast Traffic Channel (MTCH). In other embodiments, the logical channel may be a Dedicated Traffic Channel (DTCH). In some embodiments, the configuration parameters may include a logical channel configuration (e.g., LogicalChannelConfig IE) that configures a logical channel. In some embodiments, the RLC bearer configuration may include an MRB ID.

[0081] In some implementations, the CU 172 can configure the MRB as a DL-only RB in the MRB configuration. For example, the CU 172 can refrain from including UL configuration parameters in the PDCP configuration in the MRB configuration to configure the MRB as a DL-only RB. The CU 172 can include only DL configuration parameters in the MRB configuration, for example, as described above. In such a case, the CU 172 configures the UE 102 not to transmit UL PDCP data PDUs to the DU 174 and / or the CU 172 via the MRB by excluding UL configuration parameters of the MRB in the PDCP configuration in the MRB configuration. In another example, the DU 174 refrains from including UL configuration parameters in the RLC bearer configuration. In such a case, the DU 174 is configured to prevent the UE 102 from transmitting control PDU(s) to the base station 104 via the logical channel by excluding UL configuration parameters from the RLC bearer configuration.

[0082] If the DU 174 includes UL configuration parameter(s) in the RLC bearer configuration, the UE 102 may transmit control PDU(s) (e.g., PDCP control PDU(s) and / or RLC control PDU(s)) to the DU 174 via a logical channel using the UL configuration parameter(s). If the control PDU is a PDCP control PDU, the DU 174 may transmit the PDCP control PDU to the CU 172. For example, the CU 172 may configure the UE to receive MBS data using a compression (decompression) protocol (e.g., a robust header compression (ROHC) protocol). In this case, when the CU 172 receives (524) an MBS data packet from the CN 110, the CU 172 compresses the MBS data packet using the compression protocol to obtain compressed MBS data packet(s) and transmits (526) the PDCP PDU including the compressed MBS data packet to the DU 174 via a common CU-DU DL tunnel. The DU 174 then transmits (528) the PDCP PDU to the UE 102 via a logical channel (e.g., multicast or unicast). When the UE 102 receives the PDCP PDU via the logical channel, the UE 102 obtains the compressed MBS data packet from the PDCP PDU. The UE 102 decompresses the compressed MBS data packet(s) with a compression (decompression) protocol to obtain the original MBS data packet. In such a case, the UE 102 may transmit a PDCP control PDU including a header compression protocol feedback (e.g., interspersed ROHC feedback) for the operation of the header compression (decompression) protocol to the DU 174 via a logical channel. The DU 174 then transmits the PDCP control PDU to the CU 172 via a UE-specific UL tunnel. That is, the UL tunnel is specific to the UE 102 (e.g., UE 102A). In some implementations, the CU 172 may include a CU UL transport layer configuration for configuring a UE-specific UL tunnel in the UE context request message. The CU UL transport layer configuration includes a CU transport layer address (eg, an Internet Protocol (IP) address) and a CU UL TEID to identify a UE-specific UL tunnel.

[0083] In some implementations, the MRB configuration can be an MRB-ToAddMod IE that includes an MRB ID (e.g., mrb-Identity or MRB-Identity). The MRB ID identifies a particular MRB among the MRB(s). The base station 104 sets the MRB ID to a different value. When the CU 172 configures the UE 102 with DRB(s) for unicast data communication, the CU 172 can set one or more of the MRB ID(s) to a value different from the DRB ID(s) of the DRB(s) in some implementations. In such a case, the UE 102 and the CU 172 can distinguish whether the RB is an MRB or a DRB according to the RB ID of the RB. In other implementations, the CU 172 can set one or more of the MRB ID(s) to a value that can be the same as the DRB ID(s). In such a case, the UE 102 and the CU 172 can distinguish whether an RB is an MRB or a DRB according to the RB ID of the RB and the RRC IE that configures the RB. For example, the DRB configuration that configures the DRB is a DRB-ToAddMod IE that includes a DRB identifier (e.g., drb-Identity or DRB-Identity) and a PDCP configuration. Thus, the UE 102 can determine that an RB is a DRB if the UE 102 receives a DRB-ToAddMod IE that configures an RB, and can determine that an RB is an MRB if the UE 102 receives a MRB-ToAddMod IE that configures an RB. Similarly, the CU 172 can determine that an RB is a DRB if the CU 172 sends a DRB-ToAddMod IE that configures an RB to the UE 102, and can determine that an RB is an MRB if the CU 172 sends a MRB-ToAddMod IE that configures an RB to the UE 102.

[0084] In some implementations, the configuration parameters for receiving MBS data of the first MBS session include one or more logical channel (LC) IDs to configure one or more logical channels. In some implementations, the logical channel(s) can be dedicated traffic channel(s) (DTCH(s)). In other implementations, the logical channel(s) can be multicast traffic channel(s) (MTCH(s)).

[0085] In some implementations, the configuration parameters may include dynamic scheduling multicast configuration parameter(s) for the UE 102 to receive a multicast transmission, each of which includes the MBS data or a particular portion of the MBS data. In some implementations, the dynamic scheduling multicast configuration parameter(s) may include at least one of the following configuration parameters: Group Radio Network Temporary Identifier (G-RNTI). The DU 174 dynamically schedules each multicast transmission of the UE 102, including a specific MAC PDU, by generating a DCI, scrambling a cyclic redundancy check (CRC) of the DCI with the G-RNTI, and transmitting the DCI and the scrambled CRC on the PDCCH. The MAC PDU may include an MBS data packet or a part of an MBS data packet. The UE 102 receives the DCI and the scrambled CRC on the PDCCH and verifies the scrambled CRC with the G-RNTI. For each multicast transmission, after the UE 102 verifies that the (scrambled) CRC is valid, the UE 102 receives the multicast transmission according to the corresponding DCI and obtains the specific MAC PDU from the multicast transmission. In this case, each multicast transmission is a dynamic scheduling multicast transmission, which is used in the following description. In some embodiments, each DCI includes configuration parameters that configure dynamic scheduling multicast radio resources that schedule the corresponding multicast transmission. In some embodiments, the configuration parameters may include at least one of the following parameters: The configuration parameters of each DCI may include the same and / or different values ​​as the following configuration parameters. Frequency domain resource allocation Time domain resource allocation Virtual Resource Block (VRB) to Physical Resource Block (PRB) mapping Modulation Coding Scheme (MCS) New Data Indicator Redundancy version HARQ process number Downlink Allocation Index PUCCH resource indicator ·HARQ Codebook (ID) indicates the HARQ Acknowledgement (ACK) codebook index of the HARQ ACK codebook corresponding to the dynamic scheduling multicast transmission received by the UE 102. The DU 174 uses the HARQ codebook (ID) to receive the HARQ ACK. If the configuration parameters do not include the HARQ codebook (ID), the UE 102 and the DU 174 may use the HARQ codebook (ID) for unicast transmission. In some embodiments, the UE 102 may receive the HARQ codebook (ID) for unicast transmission in the DU configuration from the DU 174. In other embodiments, the UE 102 may receive the HARQ codebook (ID) for unicast transmission in another DU configuration from the DU 174, similar to events 516, 518, and 520. The PUCCH resource configuration indicates the HARQ resources on the PUCCH on which the UE 102 transmits HARQ feedback (e.g., HARQ ACK and / or negative ACK (NACK)) for dynamic scheduling multicast transmission. If the configuration parameters do not include a PUCCH resource configuration, the UE 102 and the DU 174 can use the PUCCH resource configuration for unicast transmissions to communicate HARQ feedback. The HARQ NACK only indication configures the UE 102 to transmit only HARQ negative ACKs (NACKs) for dynamic scheduling multicast transmissions that the UE 102 receives from the DU 174 and from which the UE 102 is unable to obtain a transport block. In some embodiments, the UE 102 is unable to obtain a transport block because the UE 102 fails a Cyclic Redundancy Check (CRC) of the transport block or because the UE 102 does not receive the dynamic scheduling multicast transmission. In accordance with the indication, the UE 102 refrains from transmitting HARQ ACKs to the DU 174 for dynamic scheduling multicast transmissions that the UE 102 successfully receives and from which the UE 102 obtains a transport block. If the configuration parameter does not include the indication, the UE 102 may transmit HARQ ACKs to the DU 174 for dynamic scheduling multicast transmissions that the UE 102 successfully receives and from which the UE 102 obtains a transport block. The HARQ ACK / NACK indication configures the UE 102 to transmit HARQ NACKs for dynamic scheduling multicast transmissions for which the UE 102 cannot obtain a transport block, and to transmit HARQ ACKs for dynamic scheduling multicast transmissions which the UE 102 successfully receives and from which the UE 102 obtains a transport block. If the configuration parameters do not include an indication, the UE 102 refrains from transmitting HARQ ACKs to the DU 174 for dynamic scheduling multicast transmissions which the UE 102 successfully receives and from which the UE 102 obtains a transport block. In such a case, the UE 102 is only allowed to transmit HARQ NACKs to the DU 174 for dynamic scheduling multicast transmissions for which the UE 102 cannot obtain a transport block. The HARQ ACK indication configures the UE 102 to transmit HARQ ACKs for dynamic scheduling multicast transmissions that the UE 102 successfully receives and from which the UE 102 obtains transport blocks. If the configuration parameter does not include an indication, the UE 102 refrains from transmitting HARQ ACKs to the DU 174 for dynamic scheduling multicast transmissions for which the UE 102 successfully obtains transport blocks. In such a case, the UE 102 is only permitted to transmit HARQ NACKs to the DU 174 for dynamic scheduling multicast transmissions for which the UE 102 fails to obtain transport blocks. In some implementations, the DU 174 may include any one of a HARQ NACK indication, a HARQ ACK / NACK indication, and a HARQ ACK indication. The Modulation and Coding Scheme (MCS) configuration indicates the MCS table that the DU 174 uses to transmit dynamic scheduling multicast transmissions and that the UE 102 uses to receive dynamic scheduling multicast transmissions. For example, the MCS table can be an MCS table defined in 3GPP specification 38.214 (e.g., a low SE 64 QAM table shown in table 5.1.3.1-3 of 3GPP TS 38.214, or a new table specific to multicast transmissions). In some embodiments, if the DU 174 does not include an MCS configuration in the DU configuration, the UE 102 and DU 174 can apply a predefined MCS table in 3GPP specification 38.214. For example, the predefined MCS table can be a 256 QAM table or a 64 QAM table, e.g., a non-low SE 64 QAM table shown in table 5.1.3.1-2 or table 5.1.3.1-1 of specification 38.214, respectively. If the DU 174 does not include the MCS configuration in the DU configuration, the UE 102 and the DU 174 may apply the MCS table for unicast transmission to receive the dynamic scheduling multicast transmission from the DU 174. In some embodiments, the DU 174 may include a PDSCH configuration (e.g., PDSCH-Config) in the DU configuration that configures the MCS table for unicast transmission. In other embodiments, the DU 174 may transmit another DU configuration including the PDSCH configuration to the UE 102, similar to events 516, 518, and 520. The aggregation factor is the number of repetitions of the dynamic scheduling multicast transmission(s). The DU 174 can transmit (i.e., multicast) the number of repetitions of the dynamic scheduling multicast transmission according to the aggregation factor, and the UE 102 receives the repetitions based on the aggregation factor. If the DU 174 does not include an aggregation factor in the DU configuration, the UE 102 can apply the aggregation factor for unicast transmission(s) in some embodiments. In some embodiments, the DU 174 can include an aggregation factor in the DU configuration for unicast transmission(s) to the UE 102. In other embodiments, the DU 174 can transmit another DU configuration including an aggregation factor for unicast transmission to the UE 102, similar to events 516, 518, and 520, to the UE 102.

[0086] The RRC reconfiguration message of the UE participating in the first MBS session includes the same configuration parameters for receiving MBS data of the first MBS session, and in some embodiments, the RRC reconfiguration message of the UE may include the same or different configuration parameters for receiving non-MBS data.

[0087] In some implementations, the configuration parameters may include at least one semi-persistent scheduling (SPS) multicast configuration for the UE 102 to receive the MBS data. Each of the at least one SPS multicast configuration may include at least one of the following parameters for SPS multicast transmission: · Group-configured Scheduling Radio Network Temporary Identifier (G-CS-RNTI) used to activate or deactivate SPS multicast radio resources. The DU 174 can activate the SPS multicast radio resources for the UE 102 by generating an SPS multicast radio resource activation command (i.e., DCI), scrambling the CRC of the DCI with the G-CS-RNTI, and transmitting the DCI and the scrambled CRC on the PDCCH. After activating the SPS multicast radio resources, the DU 174 periodically transmits multicast transmissions on the SPS multicast radio resources according to the DCI. The UE 102 receives the DCI and the scrambled CRC on the PDCCH and verifies the scrambled CRC with the G-CS-RNTI. After the UE 102 verifies that the (scrambled) CRC is valid, the UE 102 activates (receives) the SPS multicast radio resource in response to the DCI, and periodically receives a multicast transmission on the SPS multicast radio resource according to the SPS multicast radio resource activation command (i.e., DCI) before the UE 102 deactivates the SPS multicast radio resource. In this case, the multicast transmission is the SPS multicast transmission used in the following description. In some implementations, the DU 174 can deactivate (or release) the SPS multicast radio resource by generating an SPS multicast radio resource deactivation command (i.e., DCI), scrambling the CRC of the DCI with the G-CS-RNTI, and transmitting the DCI and the scrambled CRC on the PDCCH. The UE 102 receives the DCI and the scrambled CRC on the PDCCH and verifies the scrambled CRC with the G-CS-RNTI. After the UE 102 verifies that the (scrambled) CRC is valid, the UE 102 deactivates the SPS multicast radio resource, i.e., stops receiving on the SPS multicast radio resource. Each SPS multicast transmission includes a specific MAC PDU that can include an MBS data packet or a portion of an MBS data packet.In some implementations, the SPS multicast radio resource activation command (i.e., DCI) includes configuration parameters to configure the SPS multicast radio resources. In some implementations, the configuration parameters may include at least one of the following parameters: Frequency domain resource allocation Time domain resource allocation Virtual Resource Block (VRB) to Physical Resource Block (PRB) mapping Modulation Coding Scheme (MCS) New Data Indicator Redundancy version HARQ process number Downlink Allocation Index PUCCH resource indicator Periodicity indicates the periodicity of the SPS multicast radio resource. The number of HARQ processes indicates the number of HARQ processes for communicating the SPS multicast transmission. The DU 174 transmits the SPS multicast transmission using at most the number of HARQ processes, and the UE 102 receives the SPS multicast transmission using at most the number of HARQ processes. HARQ Codebook ID indicates the HARQ ACK codebook index of the HARQ ACK codebook corresponding to the SPS multicast transmission or SPS multicast radio resource deactivation command received by the UE 102. If the configuration parameters do not include the HARQ codebook (ID), the UE 102 may use the HARQ codebook (ID) for dynamic scheduling multicast transmission, as described above. Alternatively, the UE 102 may use the HARQ codebook (ID) for unicast transmission. In some embodiments, the UE 102 may receive the HARQ codebook (ID) for unicast transmission in the DU configuration from the DU 174, as described above. · HARQ process ID offset indicates the offset used to derive the HARQ process ID for the DU 174 to send SPS multicast transmissions and for the UE 102 to receive SPS multicast transmissions. The PUCCH resource configuration for SPS multicast transmission indicates the HARQ resources on the PUCCH on which the UE 102 transmits HARQ feedback (e.g., HARQ ACK and / or negative ACK (NACK)) for the SPS multicast transmission. If the configuration parameters do not include the PUCCH resource configuration for SPS multicast transmission, the UE 102 and the DU 174 may use the PUCCH resource configuration for dynamic scheduling multicast transmission to communicate the HARQ feedback as described above. Alternatively, the UE 102 may use the PUCCH resource configuration for unicast transmission. In some implementations, the UE 102 may use the PUCCH resource configuration for unicast transmission as described above. The HARQ NACK only indication configures the UE 102 to transmit only HARQ negative ACKs (NACKs) for SPS multicast transmissions that the UE 102 receives from the DU 174 and from which the UE 102 is unable to obtain a transport block. In some implementations, the UE 102 is unable to obtain a transport block because the UE 102 fails a cyclic redundancy check (CRC) of the transport block or because the UE 102 does not receive a dynamic scheduling multicast transmission. In accordance with the indication, the UE 102 refrains from transmitting HARQ ACKs to the DU 174 for SPS multicast transmissions that the UE 102 successfully receives and from which the UE 102 obtains a transport block. If the configuration parameter does not include the indication, the UE 102 may transmit HARQ ACKs to the DU 174 for SPS multicast transmissions that the UE 102 successfully receives and from which the UE 102 obtains a transport block. The HARQ ACK / NACK indication configures the UE 102 to send HARQ NACKs for SPS multicast transmissions for which the UE 102 cannot obtain a transport block, and to send HARQ ACKs for SPS multicast transmissions which the UE 102 successfully receives and from which the UE 102 obtains a transport block. If the configuration parameters do not include an indication, the UE 102 refrains from sending HARQ ACKs to the DU 174 for SPS multicast transmissions which the UE 102 successfully receives and from which the UE 102 obtains a transport block. In such a case, the UE 102 is only allowed to send HARQ NACKs to the DU 174 for SPS multicast transmissions for which the UE 102 cannot obtain a transport block. The HARQ ACK indication configures the UE 102 to transmit HARQ ACKs for SPS multicast transmissions that the UE 102 successfully receives and from which the UE 102 obtains transport blocks. If the configuration parameter does not include an indication, the UE 102 refrains from transmitting HARQ ACKs to the DU 174 for SPS multicast transmissions for which the UE 102 successfully obtains transport blocks. In such a case, the UE 102 is only permitted to transmit HARQ NACKs to the DU 174 for SPS multicast transmissions for which the UE 102 fails to obtain transport blocks. In some implementations, the DU 174 may include any one of a HARQ NACK indication, a HARQ ACK / NACK indication, and a HARQ ACK indication. The aggregation factor is the number of repetitions of the SPS multicast transmission(s). The DU 174 may transmit (i.e., multicast) the number of repetitions of the SPS multicast transmission according to the aggregation factor, and the UE 102 may receive the repetitions based on the aggregation factor. If the DU 174 does not include an aggregation factor in the DU configuration, the UE 102 and the DU 174 may apply the aggregation factor for the dynamic scheduling multicast transmission, as described above, in some embodiments. Alternatively, the UE 102 and the DU 174 may apply the aggregation factor for the unicast transmission(s). In some embodiments, the UE 102 and the DU 174 may apply the aggregation factor for the unicast transmission(s) as described above. The MCS configuration indicates the MCS table that the DU 174 uses to transmit the SPS multicast transmission and that the UE 102 uses to receive the SPS multicast transmission. For example, the MCS table can be an MCS table defined in 3GPP specification 38.214 (e.g., a low-SE 64 QAM table shown in table 5.1.3.1-3 of 3GPP TS 38.214, or a new table specific to multicast transmission). In some embodiments, if the DU 174 does not include an MCS configuration in the DU configuration, the UE 102 and the DU 174 can apply a predefined MCS table in 3GPP specification 38.214. For example, the predefined MCS table can be a 256 QAM table or a 64 QAM table, e.g., a non-low-SE 64 QAM table shown in table 5.1.3.1-2 or table 5.1.3.1-1 of specification 38.214, respectively. If the DU 174 does not include the MCS configuration in the DU configuration, the UE 102 and the DU 174 may receive the SPS multicast transmission from the DU 174 by applying the MCS table for dynamic scheduling multicast transmission as described above in other embodiments. Alternatively, the UE 102 and the DU 174 may receive the SPS multicast transmission from the DU 174 by applying the MCS table for unicast transmission as described above. In some embodiments, the UE 102 and the DU 174 may receive the SPS multicast transmission from the DU 174 by applying the MCS table for unicast transmission as described above. In some embodiments, the DU 174 may include in the DU configuration a PDSCH configuration (e.g., PDSCH-Config) that configures the MCS table for unicast transmission. In other embodiments, the DU 174 may transmit another DU configuration including the PDSCH configuration to the UE 102, similar to events 516, 518, and 520.

[0088] In some embodiments, the CU 172 may include an MBS session join response message in the RRC reconfiguration message. The UE 102 may include an MBS session join complete message in the RRC reconfiguration complete message. Alternatively, the UE 102 may send a UL RRC message including an MBS session join complete message to the CU 172 via the DU 174. The UL RRC message may be a UL Information Transfer message or any suitable RRC message that may include a UL NAS PDU. The CU 172 may include an MBS session join complete message in the second BS-CN message. Alternatively, the CU 172 may send a BS-CN message (e.g., an UPLINK NAS TRANSPORT message) including an MBS session join complete message to the CN 110.

[0089] In another embodiment, the CU 172 sends a DL RRC message including an MBS Session Join Response message to the UE 102. The DL RRC message can be any suitable RRC message that can include a DL Information Transfer message, another RRC Reconfiguration message, or a DL NAS PDU. The UE 102 can send a UL RRC message including an MBS Session Join Complete message to the CU 172 via the DU 174. The UL RRC message can be any suitable RRC message that can include a UL Information Transfer message, another RRC Reconfiguration Complete message, or a UL NAS PDU.

[0090] Continuing to refer to FIG. 5A, the UE 103 may perform (530) an MBS session join procedure similar to procedure 502 above. The UE 103 may perform a PDU session establishment procedure with the CN 110 via the base station 104, as described above. The UE 103 may communicate a PDU session ID with the CN 110 in the PDU session establishment procedure. The UE 103 may join a different MBS session than the UE 102 by sending an MBS session join request and specifying a different MBS session ID (e.g., a second MBS session ID).

[0091] The CU172 includes additional transport layer configuration(s) for the additional MBS session(s) to configure the additional common DL tunnel(s) in the inter-BS-CN message(s) in the MBS resource setup and UE-specific MBS session configuration procedure(s) as well as the first inter-BS-CN message or the second inter-BS-CN message. Each transport layer configuration(s) can configure a specific common DL tunnel of the common DL tunnel(s) and associate with a specific MBS session of the additional MBS session(s). The transport layer configurations can be different to distinguish different common DL tunnels. In particular, any pair of transport layer configurations can have different IP addresses, different DL TEIDs, or different IP addresses and different DL TEIDs.

[0092] Next, the CU 172 and the CN 110 perform (587) an MBS session resource setup procedure for the second MBS session, similar to the above-mentioned MBS session resource setup procedure 586 for the first MBS session, to establish a second common CN-BS DL tunnel and a second common CU-DU DL tunnel. The UE 103, the CU 172, and the CN 110 perform (589) a UE-specific MBS session configuration procedure for the second MBS session, similar to the above-mentioned UE-specific MBS session configuration procedure 590 for the first MBS session. In procedure 587, the CU 172 can obtain a second plurality of configuration parameters from the DU 174 and transmit an RRC reconfiguration message including the second plurality of configuration parameters and the second MRB configuration(s) to the UE 103. Exemplary implementations of the second plurality of configuration parameters and the second MRB configuration(s) are respectively similar to the first plurality of configuration parameters and the first MRB configuration(s), as described above.

[0093] In a UE-specific MBS session configuration procedure 589 for the second MBS session, the RRC reconfiguration message may include a different LCID (value), MRB configuration, and RLC bearer configuration than in the RRC reconfiguration message of event 520. The RRC reconfiguration message may have, for example, a different G-RNTI, LCID, and / or RLC bearer configuration.

[0094] The CN 110 can then transmit (532) the MBS data of the first MBS session and transmit (538) the MBS data of the second MBS session to the CU 172 via the respective common CN-BS DL tunnels. The CU 172 then transmits (534) the MBS data of the first MBS session and transmits (540) the MBS data of the second MBS session to the DU 174 via the respective common CU-DU DL tunnels. The DU 174 transmits (536) (e.g., multicast or unicast) the MBS data of the second MBS session to the UE 103 via one or more logical channels and / or MRB(s) and transmits (542) (e.g., multicast or unicast) the MBS data of the first MBS session to the UE 102 via one or more logical channels and / or MRB(s), similar to event 528. The UE 102 receives (542) the MBS data of the first MBS session via one or more logical channels, similar to event 528, and the UE 103 receives (536) the MBS data of the second MBS session via one or more logical channels, which may be different from the logical channel of the first MBS session. In some implementations, the DU 174 may transmit (536) the MBS data or MAC PDU(s) including the MBS data to the UE 103 via one or more multicast transmissions (e.g., dynamic or SPS multicast transmission(s)), as described above. In such a case, the UE 103 may receive (536) the MBS data or MAC PDU(s) via one or more multicast transmissions from the DU 174, as described above. In some implementations, the DU 174 may transmit (542) the MBS data or MAC PDU(s) including the MBS data to the UE 102 via one or more multicast transmissions (e.g., dynamic or SPS multicast transmission(s)), as described above. In such a case, the UE 102 may receive 542 the MBS data or MAC PDU(s) via one or more multicast transmissions from the DU 174, as described above.

[0095] 5B illustrates an example scenario 500B similar to the scenario 500A illustrated in FIG. 5A. However, in the example scenario 500B, the UE 103 participates in both the second MBS session (as in the example scenario 500A) and the first MBS session (i.e., the same MBS session joined by the UE 102 in procedure 502) for the same period of time. More specifically, the UE 103 may perform (530) an MBS session join procedure for the second MBS session and may perform (531) an MBS session join procedure for the first MBS session. The base station 104 and the CN 110 then perform (587) an MBS session resource setup procedure for the second MBS session. The UE 103, the base station 104, and the CN 110 perform (589) a UE-specific MBS session configuration procedure for the second MBS session. Additionally, the UE 103, the base station 104, and the CN perform 591 a UE-specific MBS session configuration procedure for the first MBS session, similar to event 590.

[0096] The UE 103 can join the same MBS session as the UE 102 by specifying the same MBS session ID (e.g., the first MBS session ID) in the MBS session join request. In the example scenario 500B, the UE 103 joins the first MBS session after the base station 104 starts transmitting (528) MBS data packets of the first MBS session to the UE 102. The CN 110 sends a CN-to-BS message including the MBS session ID and / or the PDU session ID to the CU 172 to indicate that the UE 103 should start receiving MBS data of the first MBS session corresponding to the first MBS session ID.

[0097] The CU 172 or the CN 110 determines that a DL tunnel for the first MBS session already exists and does not need to perform procedure 586. However, optionally, the CU 172 sends a CU-DU message to the DU 174 to request the setup of an MBS context and / or a common DL tunnel for the first MBS session, and the DU 174 responds with a DU configuration. The CU 172 sends an RRC reconfiguration message to the UE 103 to configure the UE 103 to receive MBS traffic for the first MBS session. When the UEs 102 and 103 operate in the same cell or different cells, the RRC reconfiguration message can include the same LCID (value), MRB configuration, and RLC bearer configuration as the UE 102. When the UEs 102 and 103 operate in different cells, the RRC reconfiguration message can have, for example, different G-RNTI, LCID, and / or RLC bearer configuration. When UE102 and 103 operate in different cells, the RRC reconfiguration message may include the same MRB configuration as UE102. As shown in FIG. 3, CU172 may map data packets arriving via a common CN-BS DL tunnel to one or more MRBs, each corresponding to a common CU-DU DL tunnel and / or each logical channel. Furthermore, the RRC reconfiguration message may include the same LCID (value), MRB configuration, and RLC bearer configuration for the first MBS session of UE103 as the LCID (value), MRB configuration, and RLC bearer configuration for the second MBS session of UE103. Thus, UE103 may receive MBS data of the first and second MBS sessions via the same logical channel(s) and / or MRB(s).

[0098] In any case, the CN 110 can then transmit (532, 538) the MBS data of the first MBS session and the MBS data of the second MBS session to the CU 172. The CU 172 then transmits (534, 540) the MBS data of the first MBS session and the MBS data of the second MBS session to the DU 174. The DU 174 transmits (536) (e.g., multicast or unicast) the MBS data of the second MBS session to the UE 103 via one or more logical channels and / or MRB(s) and transmits (546) (e.g., multicast or unicast) the MBS data of the first MBS session to the UE 103 via one or more logical channels and / or MRB(s). The UE 103 can receive (536) the MBS data of the first MBS session and can receive (546) the MBS data of the second MBS session during the same period, such that the UE 103 can receive two sets of MBS data of different MBS sessions at once. Additionally, the DU 174 transmits (542) the MBS data of the first MBS session to the UE 102 via one or more logical channels and / or MRB(s) (e.g., multicast or unicast). In some implementations, the DU 174 transmits (542 and 546) the MBS data of the first MBS session to the UEs 102 and 103, respectively, via multicast. In other implementations, the DU 174 transmits (542 and 546) the MBS data of the first MBS session to the UEs 102 and 103 separately via unicast.

[0099] In some embodiments, the CU 172 transmits (544) two instances of the MBS data for the first MBS session to the DU 174. The DU then transmits (542) a first instance of the MBS data for the first MBS session to the UE 102 and transmits (546) a second instance of the MBS data for the first MBS session to the UE 103. In other embodiments, the DU 174 receives a single instance of the MBS data for the first MBS session from the CU 172 and transmits the MBS data for the first MBS session to each of the UEs that have joined the first MBS session.

[0100]

[0033] With reference now to Figures 6A-8B, several example methods that may be implemented by the devices shown in Figures 1A and / or 1B will be described. For each of Figures 6A-8B, it should be understood that different packets may cause the UE and RAN nodes (i.e., base stations) implementing the described methods to follow different paths as shown in the figures in different circumstances (e.g., at different times). Each of these methods may be implemented as a set of instructions stored on a non-transitory computer-readable medium and executable by one or more processors, and / or may be implemented by processing hardware.

[0101] Generally speaking, these methods allow the UE to reliably receive the MBS data packet(s) via a HARQ process. In the HARQ process, a RAN node can transmit the MBS data packet to the UE, and in response, the UE can transmit HARQ feedback (e.g., a HARQ negative acknowledgement (NACK)) indicating that the MBS data packet was not successfully received or a HARQ acknowledgement (ACK) indicating that the MBS data packet was successfully received to the RAN node. The RAN node can then retransmit the MBS data packet (when the HARQ feedback is a HARQ NACK) or transmit a new MBS data packet (when the HARQ feedback is a HARQ ACK).

[0102] In some scenarios, during a HARQ process, the RAN node may transmit the MBS data packet to the UE via multicast (i.e., MBS multicast transmission, or simply "multicast transmission"), and may retransmit the MBS data packet or transmit a new MBS data packet via unicast (i.e., MBS unicast transmission, or simply "unicast transmission") after receiving HARQ feedback from the UE. In this manner, when the same HARQ process is used to transmit both multicast and unicast transmissions to the UE (i.e., the respective DCIs transmitted to the UE and preparing the UE to receive multicast and unicast transmissions include the same HARQ process number), the HARQ process may be considered "shared" or "mixed". However, in some cases, the UE may not support PTP retransmissions and therefore may not be able to receive the unicast transmission as a unicast retransmission. The RAN node may take into account the UE's ability to receive PTP retransmissions in some implementations.

[0103] In some scenarios, the RAN node does not need to consider at all whether the UE supports PTP retransmission when performing the HARQ process. In one such scenario, the RAN can send a multicast transmission to the UE and retransmit the MBS data packet via multicast (i.e., multicast retransmission) after receiving a HARQ NACK from the UE. In another such scenario, the RAN can send the MBS data packet via unicast (i.e., unicast transmission) and retransmit the MBS data packet via unicast (i.e., unicast retransmission) after receiving a HARQ NACK from the UE. In this way, the HARQ process in these scenarios is not considered to be shared or mixed because the RAN node maintains either multicast or unicast throughout the HARQ process.

[0104] Turning now to Figures 6A-6E, these figures generally illustrate various ways in which a UE may attempt to receive a first transmission including an MBS data packet and a subsequent second transmission according to a HARQ process, and further determine whether the second transmission is a new transmission or a retransmission of the first transmission. Figures 6A-6C illustrate a UE making a decision taking into account whether the UE supports PTP retransmission or has enabled PTP retransmission. Figure 6D illustrates a UE making a decision comparing the transport block sizes of the first and second transmissions. Figure 6E illustrates a UE making a decision determining which RNTI was used to receive the second transmission.

[0105] Referring first to FIG. 6A, a UE (e.g., UE 102, UE 103) can perform method 600A to receive MBS data packet(s) from a RAN (e.g., DU 174, CU 172, or base station 104) via multicast and unicast in a shared HARQ process.

[0106] Beforehand, in block 602, the UE optionally transmits a UE capability to the RAN node indicating that the UE does not support PTP retransmission of the MBS. When the UE does not support PTP retransmission of the MBS, the UE does not support receiving retransmissions of the same MBS data packets that were not previously transmitted from the RAN node. In some embodiments, when the UE does not support PTP retransmission of the MBS, the UE does not support receiving unicast HARQ retransmissions of the same MBS data packets that were not previously transmitted from the RAN node in a multicast HARQ transmission.

[0107] In block 604, in preparation for receiving the MBS data packet(s) using the HARQ process, the UE receives from the RAN node a first DCI (i.e., a CRC of the first DCI) having a CRC scrambled by the G-RNTI to schedule a multicast transmission, the first DCI including a first HARQ process number and a first new data indicator (NDI) value. The first HARQ process number identifies the HARQ process, and the NDI specifies whether the first DCI is for a new transmission carrying the MBS data packet(s) (i.e., a new HARQ transmission not previously transmitted to the UE) or for a retransmission carrying a previous undelivered MBS data packet(s) (i.e., a HARQ retransmission).

[0108] In block 606, the UE determines whether the multicast transmission is a new transmission or a retransmission according to the first HARQ process number and the first NDI value.

[0109] In block 608, the UE receives and processes the multicast transmission in accordance with the first DCI and the decision made in block 606 (see, eg, events 528, 536, 542).

[0110] At 610, the UE transmits a first HARQ feedback to the RAN node to indicate whether the UE successfully received and processed the multicast transmission. The first HARQ feedback can be a HARQ NACK, indicating that the multicast transmission was not successfully received, or a HARQ ACK, indicating that the multicast transmission was successfully received.

[0111] In block 612, in preparation for receiving the MBS data packet(s) using the same HARQ process, the UE receives from the RAN node a second DCI (i.e., the CRC of the second DCI) having a CRC scrambled by the C-RNTI (i.e., the UE's C-RNTI) to schedule a unicast transmission, the second DCI including the first HARQ process number (thus indicating the same HARQ process) and a second NDI value. Similar to the first NDI value, the second NDI value specifies whether the second DCI is for a new transmission (carrying new MBS data packet(s)) or for a retransmission (carrying previous undelivered MBS data packet(s)). In some implementations, the first and second NDI values ​​may be the same or different.

[0112] In an embodiment in which the RAN node receives a UE capability from the UE (e.g., in block 602) or from another entity (e.g., CN 110) indicating that the UE does not support PTP retransmissions, the RAN node determines that the UE does not support PTP retransmissions of the MBS and accordingly refrains from transmitting DCI that could otherwise be used to schedule unicast HARQ retransmissions of the UE.

[0113] In block 614, the UE determines that the unicast transmission is a new transmission regardless of the second NDI value. In some embodiments, the UE ignores the second NDI value and determines that the unicast transmission is a new transmission if it determines that the first HARQ process number included in the second DCI is the same as that included in the first DCI.

[0114] Then, in block 616 , the UE receives the unicast transmission in accordance with the second DCI and the decision made in block 614 .

[0115] In block 618, the UE sends a second HARQ feedback to the RAN node to indicate whether the UE successfully received and processed the unicast transmission. The second HARQ feedback can be a HARQ NACK, indicating that the unicast transmission was not successfully received, or a HARQ ACK, indicating that the unicast transmission was successfully received.

[0116] In some implementations, the UE allocates a HARQ process associated with the first HARQ process number to receive multicast and unicast transmissions. In some implementations, the UE transmits the first HARQ feedback according to a first configuration (e.g., a PUCCH configuration or a HARQ ACK / NACK configuration) and transmits the second HARQ feedback according to a second configuration (e.g., a PUCCH configuration or a HARQ ACK / NACK configuration). In other implementations, the UE transmits the first HARQ feedback and the second HARQ feedback according to a configuration (e.g., a PUCCH configuration or a HARQ ACK / NACK configuration).

[0117] In some implementations, the first DCI may include a field indicating a specific uplink carrier or a specific cell for the first HARQ feedback, for example, according to the first configuration. The UE transmits the first HARQ feedback on a specific carrier or a specific cell according to the indication in the field. In other implementations, the first DCI does not include a field indicating a specific uplink carrier or a specific cell for the first HARQ feedback. In such a case, the UE transmits the first HARQ feedback on a predetermined uplink carrier (e.g., a primary component carrier) or a predetermined cell (e.g., a primary cell), for example, according to the first configuration. In some implementations, the second DCI may include a field indicating a specific uplink carrier or a specific cell for the second HARQ feedback, for example, according to the second configuration. In such a case, the UE transmits the second HARQ feedback on a specific carrier or a specific cell. In other implementations, the second DCI does not include a field indicating a specific uplink carrier or a specific cell for the second HARQ feedback. In such a case, the UE may transmit second HARQ feedback on a predetermined uplink carrier (eg, a primary component carrier) or a predetermined cell (eg, a primary cell) according to, for example, a second configuration.

[0118] If the UE determines that the first NDI value is toggled compared to the NDI value of the DCI received prior to the first DCI addressing the HARQ process, the UE determines that the multicast transmission is a new transmission at block 606. In response to determining that the multicast transmission is a new transmission, the UE obtains a transport block from the multicast transmission. For example, the UE decodes the data (i.e., channel coding bits) of the multicast transmission to obtain the transport block. In some implementations, in response to determining that the multicast transmission is a new transmission, the UE flushes a soft buffer associated with the HARQ process to receive the multicast transmission. If the UE determines that the first NDI value is not toggled compared to the NDI value, the UE determines that the multicast transmission is a retransmission at block 606. In response to determining that the multicast transmission is a retransmission, the UE combines the data (i.e., channel coding bits) of the multicast transmission with the data (i.e., channel coding bits) currently in the soft buffer and decodes the combined data to obtain the transport block. If the UE successfully retrieves a MAC PDU from the transport block or verifies that the CRC of the transport block is valid, the UE provides the first HARQ feedback as a HARQ ACK. If the UE cannot retrieve a MAC PDU from the transport block or verifies that the CRC of the transport block is invalid, the UE provides the first HARQ feedback as a HARQ NACK.

[0119] In some implementations, in response to determining that the unicast transmission is a new transmission, the UE retrieves a second transport block from the unicast transmission. In some implementations, in response to determining that the unicast transmission is a new transmission, the UE flushes a soft buffer associated with the HARQ process to receive the unicast transmission. If the UE successfully retrieves a MAC PDU from the second transport block or verifies that the CRC of the second transport block is valid, the UE provides the second HARQ feedback as a HARQ ACK. If the UE cannot retrieve a MAC PDU from the second transport block or verifies that the CRC of the second transport block is invalid, the UE provides the second HARQ feedback as a HARQ NACK.

[0120] In some implementations of block 602, the UE may transmit a first RRC message (e.g., a UECapabilityInformation message) to the RAN node including the UE capabilities. In some implementations, the UE may transmit the first RRC message to the RAN node in response to receiving a second RRC message (e.g., a UECapabilityEnquiry message) from the RAN node. In some implementations, the UE capabilities may be a UE-NR-Capability IE. In one implementation, the UE capabilities may include an indication indicating that PTP retransmission of the MBS is not supported. In another implementation, the UE capabilities may exclude an indication indicating that PTP retransmission of the MBS is supported. In some implementations, the UE capabilities may indicate that the UE supports PTM transmission of the MBS. That is, the UE can receive the MBS via PTM transmission (i.e., multicast transmission including HARQ new transmission and HARQ retransmission scheduled by the G-RNTI). More specifically, the UE capabilities include an MBS PTM indication indicating support for PTM transmission of the MBS. In embodiments in which the UE supports PTM transmission, the UE may support PTM retransmission by default without explicitly indicating that the UE supports PTM retransmission in the UE capabilities, or the UE capabilities may include an indication that the UE supports PTM retransmission.

[0121] In some implementations of block 602, the UE may send a first NAS message to the CN (e.g., CN 110) including a UE capability ID that identifies the UE capabilities stored in the CN or a network node from which the CN can receive the UE capabilities. In such a case, the CN sends an interface message including the UE capabilities to the RAN node. For example, the interface message may be an NG Application Protocol (NGAP) message defined in 3GPP specification 38.413. In any case, after receiving the UE capabilities from the UE or CN, the RAN knows whether the UE is capable of receiving PTP retransmissions and / or PTM transmissions.

[0122] FIG. 6B illustrates an exemplary method 600B similar to method 600A, except that the UE of method 600B supports PTP retransmission. Thus, in method 600B, the UE of block 603 optionally transmits a UE capability indicating support of PTP retransmission to the RAN node. In other embodiments, as described above with respect to FIG. 6A, the RAN node receives the UE capability indirectly from the UE via a CN (e.g., CN 110) communicatively coupled to the RAN node. Also, as described above with respect to FIG. 6A, the UE capability may indicate that the UE supports PTM transmission of MBS. In some embodiments, a UE that supports PTM transmission of MBS is instructed to support PTP retransmission. In such a case, the UE may indirectly indicate support of PTP retransmission in the UE capability by including an explicit MBS PTM indication in the UE capability. In such a case, the MBS PTM indication indicates that the UE supports both PTM transmission and PTP retransmission.

[0123] Method 600B proceeds similarly to method 600A of FIG. 6A at blocks 604, 606, 608, 610, and 612. In an embodiment in which the RAN node receives a UE capability from the UE (e.g., in block 603) or from another entity (e.g., CN 110) indicating that the UE supports PTP retransmission, the RAN node determines that the UE supports PTP retransmission and responsively transmits a DCI (e.g., the second DCI in block 612) to schedule a HARQ retransmission including the UE's MBS data.

[0124] Whereas in block 614 of FIG. 6A the UE determines that the unicast transmission is a new transmission regardless of the second NDI value included in the second DCI in block 612, in block 615 of FIG. 6B the UE determines whether the unicast transmission is a new transmission or a retransmission with the second NDI value.

[0125] If the UE determines that the second NDI value is toggled compared to the first NDI value, the UE determines that the unicast transmission is a new transmission at block 615. In response to determining that the unicast transmission is a new transmission, the UE obtains a transport block from the unicast transmission. For example, the UE decodes data (i.e., channel coding bits) of the unicast transmission to obtain the transport block. In some implementations, in response to determining that the unicast transmission is a new transmission, the UE flushes a soft buffer associated with the HARQ process to receive the unicast transmission.

[0126] If the UE determines that the second NDI value is not toggled compared to the first NDI value, the UE determines that the unicast transmission is a retransmission, at block 615. In response to determining that the unicast transmission is a retransmission, the UE combines the data (i.e., the channel coded bits of the unicast transmission) and the data (i.e., the channel coded bits) currently in the soft buffer (e.g., including the channel coded bits of the multicast transmission) and decodes the combined data to obtain a transport block.

[0127] If the UE successfully retrieves the MAC PDU from the transport block or verifies that the CRC of the transport block is valid, the UE provides the second HARQ feedback as a HARQ ACK. If the UE cannot retrieve the MAC PDU from the transport block or verifies that the CRC of the transport block is invalid, the UE provides the second HARQ feedback as a HARQ NACK.

[0128] FIG. 6C illustrates an example method 600C that is similar to methods 600A and 600B, except that the UE of method 600C determines whether a unicast transmission is a new transmission or a retransmission based on whether PTP retransmission is enabled.

[0129] Method 600C, similar to methods 600A and 600B, begins at block 604 and proceeds to blocks 606, 608, 610, and 612. In response to receiving the second DCI, the UE determines whether PTP retransmissions of the MBS are enabled at block 613. If the UE determines that PTP retransmissions are not enabled, method 600C proceeds to block 614 as described above in FIG. 6A. Otherwise (i.e., if the UE determines that PTP retransmissions are enabled), method 600C proceeds to block 615 as described above in FIG. 6B.

[0130] In some embodiments, if the UE supports PTP retransmission, the UE enables PTP retransmission, and if the UE does not support PTP retransmission, the UE disables PTP retransmission. In some embodiments, the UE stores a flag in non-volatile memory or a Universal Subscriber Identity Module (USIM). If the flag indicates that PTP retransmission is enabled, the UE indicates that the UE supports PTP retransmission in the UE capabilities. If the flag indicates that PTP retransmission is disabled, the UE indicates that the UE does not support PTP retransmission in the UE capabilities. In some embodiments, the UE enables PTP retransmission if the RAN node configures the UE to enable PTP retransmission. For example, the UE receives an RRC reconfiguration message from the RAN node that configures PTP retransmission. In some embodiments, as described above in blocks 602 and 603, the RAN node can configure the UE to enable PTP retransmission if the RAN node receives a UE capability that indicates that the UE supports PTP retransmission. In other embodiments, the UE disables PTP retransmission if the RAN node does not configure the UE to enable PTP retransmission. In some embodiments, the RAN node refrains from configuring the UE to enable PTP retransmissions if the RAN node receives a UE capability indicating that the UE does not support PTP retransmissions, in other embodiments, the RAN refrains from configuring the UE to enable PTP retransmissions because the RAN node does not support PTP retransmissions.

[0131] 6D illustrates an example method 600D similar to 600B, except that the UE in method 600B determines whether the unicast transmission is a new transmission or a retransmission of a previous undelivered multicast transmission according to the second NDI value, whereas the UE in method 600D performs the determination based on whether the unicast transmission has the same transport block size as the previous undelivered multicast transmission.

[0132] Method 600D, like method 600B, optionally begins at block 603 and proceeds to blocks 604, 606, 608, and 610. Subsequently, in block 612, the UE of method 600B receives a second DCI including a first HARQ process number and a second NDI value, while in block 622, the UE of method 600D receives a second DCI including the first HARQ process number and the same first NDI value included in the first DCI of block 604.

[0133] In block 623, the UE compares the transport block indicated in the first DCI of block 604 with the transport block indicated in the second DCI of block 622. If the UE determines that the transport block sizes are not the same, method 600D proceeds to block 624, where the UE determines that the unicast transmission is a new transmission. In such a case, the UE ignores the first NDI value. Otherwise, if the UE determines that the transport block sizes are the same, method 600D proceeds to block 625, where the UE determines that the unicast transmission is a retransmission.

[0134] 6E illustrates an example method 600E that is similar to method 600A, except that while the UE of method 600A uses the C-RNTI to receive and determine that a unicast transmission is a new transmission, the UE of method 600E determines which RNTI (e.g., the C-RNTI or the G-RNTI) the UE used to determine whether a HARQ transmission from a RAN node is a new transmission or a retransmission.

[0135] Method 600E, similar to method 600A, optionally begins at block 602 and proceeds to blocks 604, 606, 608, and 610. In block 611, in preparation for receiving a subsequent HARQ transmission from the RAN node, the UE receives a second DCI having a scrambled CRC, the second DCI including the first HARQ process number and a second NDI value.

[0136] In block 633, the UE verifies that the scrambled CRC is valid by using either the UE's C-RNTI or G-RNTI. If the UE verifies that the scrambled CRC of block 611 is valid using the C-RNTI in block 633, the UE determines that the subsequent transmission is a new transmission (i.e., a new unicast transmission) regardless of the second NDI value in block 634. If the UE verifies that the scrambled CRC of block 611 is valid using the G-RNTI in block 633, the UE determines that the subsequent transmission is a new transmission (i.e., a new multicast transmission) or a retransmission (i.e., a multicast retransmission) according to the second NDI value in block 635.

[0137] Based on the decision at block 634 or block 635, the UE at block 636 receives and processes the subsequent transmission in accordance with the second DCI. At block 638, the UE transmits second HARQ feedback for the subsequent transmission to the RAN node. Blocks 634, 636, 638 are somewhat similar to blocks 614, 616, and 618, respectively, of Figure 6A, and block 635 is somewhat similar to block 615 of Figure 6B.

[0138] Turning now to Figures 7A-7C and 8A-8B, these figures generally illustrate various ways in which a RAN node may decide whether to send a first transmission including an MBS data packet and send a subsequent second transmission via multicast or unicast in accordance with a HARQ process. Figures 7A-7B illustrate a RAN node making a decision taking into consideration whether the UE supports or has enabled PTP retransmissions. Figure 7C illustrates a RAN node making a decision taking into consideration whether the first transmission was sent via multicast or unicast. Figure 8A illustrates a RAN node making a decision taking into consideration HARQ feedback for the first transmission received from the UE. Figure 8B illustrates a RAN node making a decision taking into consideration network bandwidth conditions associated with the first transmission.

[0139] Referring initially to Figure 7A, a RAN node (e.g., base station 104 or DU 174) may implement a method 700A for transmitting MBS data packet(s) to a UE (e.g., UE 102, UE 103) via multicast and unicast. In general, the RAN node of Figure 7A, in response to receiving a HARQ NACK from the UE, determines how to transmit a subsequent HARQ transmission (e.g., via multicast or unicast) based on whether the UE supports PTP retransmissions.

[0140] The method 700A begins at block 702, where a RAN node sends a HARQ transmission of MBS data via multicast (see, e.g., events 528, 536, 542). In some implementations, the HARQ transmission can be a new HARQ transmission or a HARQ retransmission.

[0141] In block 704, the RAN node receives a HARQ NACK for the HARQ transmission from the UE.

[0142] In block 706, the RAN node determines whether the UE supports PTP retransmission (e.g., based on the UE capabilities described above). If the RAN node determines that the UE supports PTP retransmission, in block 708, the RAN node transmits a HARQ retransmission of the MBS data to the UE via unicast in response to the HARQ NACK (see, e.g., events 528, 536, 542). Otherwise, if the RAN node determines that the UE does not support PTP retransmission, in block 710, the RAN node transmits a HARQ retransmission of the MBS data via multicast in response to the HARQ NACK.

[0143] In some implementations, at block 702, the RAN node transmits a HARQ transmission via multicast using a HARQ process. In such a case, the RAN node may configure the HARQ process for multicast transmission. The RAN node then determines to use the HARQ process for unicast transmission of the UE, for example because the MBS is inactive or the UE stops receiving the MBS. In response to the determination, the RAN node determines to reconfigure the HARQ process for unicast transmission. In response to reconfiguring the HARQ process for unicast transmission, the RAN node toggles an NDI for the HARQ process. After reconfiguring the HARQ process, the RAN node determines to transmit a unicast transmission to the UE using the HARQ process. In response to the determination, the RAN node transmits a DCI to the UE, including the toggled NDI and the HARQ process number of the HARQ process. The RAN node generates a CRC of the DCI, scrambles the CRC with the UE's C-RNTI, and transmits the DCI and the scrambled CRC to the UE on the PDCCH.

[0144] FIG. 7B illustrates an example method 700B similar to method 700A, except that the RAN node of FIG. 7B determines how to transmit a subsequent HARQ transmission based on whether the UE has enabled PTP retransmission. For example, as described above with respect to FIG. 6C, if the RAN node has sent an RRC reconfiguration message to the UE to configure or enable PTP retransmission, the RAN node determines that PTP retransmission is enabled for the UE in block 707 and proceeds to block 708. As another example, if the RAN node receives a UE capability indicating that the UE does not support PTP retransmission, the RAN node refrains from configuring the UE to enable PTP retransmission in block 707 and proceeds to block 710.

[0145] Figure 7C illustrates an example method 700C similar to method 700A or method 700B, except that the RAN node of Figure 7C omits considerations related to whether the UE supports or enables PTP retransmissions. Instead, the RAN node of Figure 7C determines how to transmit a subsequent HARQ transmission (e.g., via multicast or unicast) based on how a previous HARQ transmission was transmitted (e.g., via multicast or unicast).

[0146] In block 703, the RAN node transmits a HARQ transmission. Accordingly, in block 705, the RAN node determines whether the HARQ transmission is transmitted via unicast or multicast.

[0147] In block 704, the RAN node receives a HARQ NACK from the UE. If the RAN node sent a HARQ transmission via unicast in block 705, then the RAN node sends a HARQ retransmission via unicast in response to the HARQ NACK in block 708. On the other hand, if the RAN node sent a HARQ transmission via multicast in block 705, then the RAN node sends a HARQ retransmission via multicast in response to the HARQ NACK in block 710.

[0148] Referring first to FIG. 8A, a RAN node (e.g., a base station 104 or a DU 174) can implement a method 800A for transmitting MBS data packet(s) to a UE (e.g., UE 102, UE 103) via multicast and unicast.

[0149] The method 800A begins at block 802, where a RAN node transmits a first DCI and a CRC (i.e., the CRC of the DCI) scrambled by the G-RNTI to a UE on a PDCCH to schedule a first (new) multicast transmission of a first MBS data packet of the UE. The first DCI includes a first HARQ process number, a first NDI value, and a first non-reserved MCS value (e.g., a first I MCS value).

[0150] In block 804, the RAN node transmits a first multicast transmission according to the first DCI. As a result, in block 806, the RAN node attempts to receive HARQ feedback for the first multicast transmission from the UE.

[0151] If the RAN node receives a HARQ NACK of the first multicast transmission at block 806, the RAN node sends a second DCI and a CRC scrambled by the UE's C-RNTI on the PDCCH to the UE to schedule the UE's first unicast transmission (i.e., a retransmission of the first MBS data packet) at block 808. The second DCI includes a first HARQ process number, a first NDI value, and a reserved MCS value. At block 810, the RAN node then transmits the first unicast transmission according to the second DCI. Although not shown, in some implementations, the RAN node receives a HARQ NACK for the first unicast transmission from the UE. In response, the RAN node can send a fourth DCI and a CRC scrambled by the UE's C-RNTI on the PDCCH to schedule the UE's second unicast transmission (i.e., a retransmission of the first MBS data packet). The fourth DCI includes a first HARQ process number, a first NDI value, and a reserved MCS value. The reserved MCS value of the fourth DCI may be the same as or different from the reserved MCS value of the second DCI. The RAN node then transmits the second unicast transmission according to the fourth DCI.

[0152] On the other hand, if the RAN node does not receive a HARQ NACK for the first multicast transmission at block 806, the RAN node transmits on the PDCCH a third DCI (i.e., the CRC of the third DCI) with a CRC scrambled by the G-RNTI to the UE for scheduling the second multicast transmission (i.e., a new transmission of the second MBS data packet). The second DCI includes the first HARQ process number, the second NDI value, and the non-reserved MCS value (e.g., the second I MCS In block 814, the RAN node then transmits the second multicast transmission in accordance with the third DCI.

[0153] In some implementations, the RAN node may instead transmit a fifth DCI and a CRC scrambled by the G-RNTI on the PDCCH to schedule the third multicast transmission (i.e., a retransmission of the first MBS data) at block 808. The fifth DCI includes the first HARQ process number, the first NDI value, and the reserved MCS value. The RAN node may do so if the UE does not support PTP retransmission or if the RAN node does not enable PTP retransmission for the UE.

[0154] FIG. 8B illustrates an example method 800B that is similar to method 800A, except that the RAN node of FIG. 8B determines how to transmit either the first unicast transmission or the second multicast transmission based on network bandwidth conditions associated with the first multicast transmission.

[0155] Method 800B begins at block 802 and proceeds to block 804, similar to method 800A.

[0156] In block 805, the RAN node receives a HARQ NACK for the first multicast transmission from the UE.

[0157] In block 807, the RAN node determines network bandwidth conditions associated with the first multicast transmission. In some embodiments, the RAN node determines whether the common frequency resource (CFR) on which the RAN node and the UE perform the HARQ process has the same configuration (e.g., the same bandwidth and location of configuration resources such as PRB) as the active DL BWP of the UE. If the RAN node determines in block 807 that the CFR and the active DL BWP have the same configuration, then in block 813, the RAN node transmits the second multicast transmission as a multicast retransmission. This is in contrast to the RAN node of method 800A, where the RAN node transmits the second multicast transmission as a new transmission in block 812. The RAN node then proceeds to block 814, similar to method 800A. In some embodiments or scenarios, because the RAN node has limited spectrum, the RAN node configures the CFR and the active DL BWP to share the exact same spectrum. In such a case, the RAN node can dynamically allocate radio resources for the MBS and unicast services. However, this also increases the complexity in managing radio resources for the MBS and unicast services.

[0158] On the other hand, if the RAN node determines at block 807 that the CFR and active DL BWP have different configurations (e.g., do not have the same configuration resource bandwidth and location such as PRB), the RAN node may therefore transmit the first unicast transmission as a unicast retransmission at block 808 to increase the likelihood that the UE will receive the first unicast transmission, similar to the RAN node of method 800A. The RAN node then proceeds to block 810, similar to method 800A. In such a case, the RAN node may allocate radio resources for the MBS and radio resources for the unicast service separately in the CFR and active DL BWP.

[0159] Referring now to FIG. 9, an example method 900 may be implemented in a UE (eg, UE 102 or UE 103) to receive an MBS from a base station (eg, base station 104, DU 174).

[0160] In block 902, the UE attempts to receive a first transmission including an MBS data packet associated with an MBS from a base station via multicast (eg, at event or block 528, 536, 542, 604, 606, 608).

[0161] At block 904, the UE transmits an indication to the base station, according to a mechanism for automatic retransmission of undelivered packets (eg, at block 610), of whether the UE successfully received the first transmission.

[0162] In response, at block 906, the UE attempts to receive a second transmission from the base station via unicast according to the mechanism (eg, at events 528, 536, 542, 612, 616, 622, 636).

[0163] In block 908, the UE determines whether the second transmission is a new transmission or a retransmission of the first transmission (eg, in blocks 614, 615, 624, 625, 634, 635).

[0164] Referring now to FIG. 10, an example method 1000 may be implemented in a base station (eg, base station 104, DU 174) to provide MBS to a UE (eg, UE 102, UE 103).

[0165] In block 1002, the base station sends a first transmission including MBS data packets associated with the MBS to a plurality of UEs using a mechanism for automatic retransmission of undelivered packets (eg, at events 528, 536, 542, 702, 703, 804).

[0166] In block 1004, the base station receives an indication from at least one of the plurality of UEs of whether the UE successfully received the first transmission (eg, in blocks 704, 805, 806).

[0167] In block 1006, the base station accordingly determines whether to send the second transmission via multicast or unicast according to a mechanism (eg, at events 528, 536, 542, 708, 710, 810, 814).

[0168] The following additional considerations apply to the preceding discussion:

[0169] In some embodiments, "message" is used and can be replaced with "information element (IE)". In some embodiments, "IE" is used and can be replaced with "field". In some embodiments, "config" can be replaced with "configurations" or configuration parameters. In some embodiments, "MBS" can be replaced with "multicast" or "broadcast". In some embodiments, "SPS multicast" can be replaced with "multicast SPS". Similarly, "dynamic scheduling multicast" can be replaced with "multicast dynamic". In some embodiments, "identifier" can be replaced with "identity". In some embodiments, "CFR" is used and can be replaced with "MBS BWP".

[0170] A user device (e.g., UE 102A, 102B, or UE 103) capable of implementing the techniques of this disclosure can be any suitable device capable of wireless communication, such as a smartphone, a tablet computer, a laptop computer, a mobile game console, a point of sale (POS) terminal, a health management device, a drone, a camera, a media streaming dongle or another personal media device, a wearable device such as a smart watch, a wireless hotspot, a femtocell, or a broadband router. Furthermore, the user device may in some cases be embedded in an electronic system such as a vehicle head unit or an advanced driver assistance system (ADAS). Still further, the user device can operate as an Internet of Things (IoT) device or a Mobile Internet Device (MID). Depending on the type, the user device may include one or more general-purpose processors, computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0171] Certain embodiments are described in this disclosure as including logic, or several components or modules. The modules can be software modules (e.g., code stored on a non-transitory machine-readable medium) or hardware modules. A hardware module is a tangible unit that can perform certain operations and can be configured or arranged in a certain manner. For example, a hardware module can include dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware module can also include programmable logic or circuitry that is temporarily configured by software (e.g., contained within a general-purpose processor or other programmable processor) to perform certain operations. The decision to implement a hardware module in a dedicated permanently configured circuitry or in a temporarily configured circuitry (e.g., configured by software) can involve cost and time considerations.

[0172] If implemented in software, the techniques may be provided as part of an operating system, a library used by multiple applications, a specific software application, etc. The software may be executable by one or more general-purpose processors or one or more special-purpose processors.

[0173] After reading this disclosure, those skilled in the art will appreciate further alternative structural and functional designs for implementing a HARQ process for transmitting MBS data through the principles disclosed in this disclosure. Thus, while specific embodiments and applications have been shown and described, it should be understood that the disclosed embodiments are not limited to the precise configuration and components disclosed herein. Various modifications, changes and variations apparent to those skilled in the art may be made in the arrangement, operation and details of the methods and apparatus disclosed herein without departing from the spirit and scope of the appended claims.

Claims

1. A method for receiving a multicast and / or broadcast service (MBS) in a user equipment (UE), comprising: Attempting to receive, by the UE and from a base station via multicast, a first transmission including an MBS data packet associated with the MBS; transmitting, by the UE and to the base station, an indication of whether the UE successfully received the first transmission in accordance with a mechanism for automatic retransmission of undelivered packets; and in response to the transmitting, attempting to receive a second transmission by the UE and from the base station via unicast according to the mechanism, the second transmission including receiving Downlink Control Information (DCI) that includes a new Data Indicator (NDI) value; determining, by the UE and independent of the NDI value, that the second transmission is a new transmission; The method comprising:

2. 2. The method of claim 1, wherein determining that the second transmission is the new transmission regardless of the NDI value includes determining that the UE does not support or has disabled point-to-point (PTP) retransmission.

3. 3. The method of claim 2, further comprising: transmitting, by the UE and to the base station, an indication that the UE does not support or has disabled PTP retransmissions.

4. 2. The method of claim 1, wherein determining that the second transmission is the new transmission, regardless of the NDI value, comprises determining that the first transmission and the second transmission do not have the same transport block size.

5. The DCI is a second DCI, and the NDI value included in the DCI is a second NDI value; Attempting to receive the first transmission includes receiving a first DCI that includes a first NDI value; the first NDI value and the second NDI value are set to the same NDI value; The method according to any one of claims 1 to 4.

6. The DCI is a second DCI, and the NDI value included in the DCI is a second NDI value; Attempting to receive the first transmission includes receiving a first DCI that includes a first NDI value; The first NDI value and the second NDI value are set to different NDI values. The method according to any one of claims 1 to 4.

7. The method of any one of claims 5 to 6, wherein the first DCI and the second DCI include the same process number.

8. 8. The method of claim 1, wherein attempting to receive the first transmission comprises receiving a first scrambled Cyclic Redundancy Check (CRC) and determining that a Group Radio Network Temporary Identifier (G-RNTI) is used to verify the first scrambled CRC.

9. 9. The method of claim 1, wherein attempting to receive the second transmission comprises receiving a second scrambled Cyclic Redundancy Check (CRC) and determining that a Cell RNTI (C-RNTI) is used to verify the second scrambled CRC.

10. The MBS data packet is a first MBS data packet, the MBS is a first MBS service, the new transmission is a first new transmission, and the method includes: Attempting to receive, by the UE and from the base station via multicast, a third transmission including a second MBS data packet associated with a second MBS, including receiving a third scrambled CRC and a third DCI including a third NDI value; transmitting, by the UE and to the base station, an indication of whether the UE successfully received the third transmission in accordance with a mechanism for automatic retransmission of undelivered packets; in response to the UE transmitting the indication of whether the UE successfully received the third transmission, attempting to receive a fourth transmission by the UE and via unicast from the base station in accordance with the mechanism, the fourth transmission including receiving a fourth DCI including a fourth scrambled CRC and a fourth NDI value; determining, by the UE and based on the third NDI value and the fourth NDI value, whether the fourth transmission is a second new transmission or a retransmission; The method of any one of claims 1 to 9, further comprising:

11. 11. The method of claim 10, wherein determining whether the fourth transmission is the second new transmission or the retransmission comprises determining that the fourth transmission is the second new transmission when the third NDI value and the fourth NDI value are set to different NDI values.

12. 11. The method of claim 10, wherein determining whether the fourth transmission is the second new transmission or the retransmission comprises determining that the fourth transmission is the retransmission when the third NDI value and the fourth NDI value are set to a same NDI value.

13. 13. The method of claim 10, wherein determining whether the fourth transmission is the second new transmission or the retransmission comprises determining that the UE supports or has enabled point-to-point (PTP) retransmission.

14. 14. The method of claim 13, further comprising transmitting, by the UE and to the base station, an indication that the UE supports or has enabled PTP retransmissions.

15. 13. The method of claim 10, wherein determining whether the fourth transmission is the second new transmission or the retransmission comprises determining that the third transmission and the fourth transmission have the same transport block size.

16. The method of any one of claims 10 to 15, wherein the first DCI and the second DCI include the same process number.

17. 17. The method of claim 10, wherein attempting to receive the third transmission includes determining that a Group Radio Network Temporary Identifier (G-RNTI) is used to verify the third scrambled CRC.

18. A method according to any one of claims 10 to 17, wherein attempting to receive the fourth transmission comprises determining that a respective C-RNTI is used to verify the fourth scrambled CRC.

19. The method according to any one of claims 1 to 18, wherein the mechanism for automatic retransmission of undelivered packets comprises a Hybrid Automatic Repeat Request (HARQ) technique.

20. A UE including processing hardware and configured to carry out the method according to any one of claims 1 to 19.

Images