Managing Hybrid Automated Retransmission Requests for Multicast and / or Broadcast Services

Abstract

The present invention provides an apparatus or method for managing the transmission of hybrid automatic retransmission requests. [Solution] User equipment (UE) for receiving multicast and / or broadcast services (MBS) (i) attempts to receive (902) a first transmission from a base station via multicast that includes MBS data packets associated with the MBS; (ii) sends an indication to the base station (904) whether the UE has succeeded in receiving the first transmission, in accordance with a mechanism for automatically retransmitting undelivered packets; (iii) attempts to receive (906) a second transmission from the base station via unicast in accordance with a mechanism, in response to the transmission; 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, filed on January 10, 2022, entitled "Managing Hybrid Automatic Repeat Request Transmission for Multicast and / or Broadcast Services", which is hereby incorporated by reference in its entirety.

[0002] This disclosure relates to wireless communication, and more particularly, to enabling automatic re - transmission of undelivered packets, such as Hybrid Automatic Repeat Request (HARQ), for one or more multicast and / or broadcast services (MBS).

Background Art

[0003] For the purpose of generally presenting the context of the present disclosure, the background art provided herein is described. The work of the inventors specified herein is not, in the scope described in this background art section, and aspects of this document that may not be eligible as prior art at the time of filing, are not admitted as prior art to the present disclosure, either expressly or implicitly.

[0004] In telecommunications systems, the Packet Data Convergence Protocol (PDCP) sublayer of the radio protocol stack provides services such as the transfer, encryption, and integrity protection of user plane data. For example, the PDCP sublayer, defined for the Evolutionary Universal Terrestrial Radio Access (EUTRA) radio interface (see Third Generation Partnership Project (3GPP®) specification TS36.323) and New Radio (NR) (see 3GPP specification TS38.323), provides the ordering of protocol data units (PDUs) in the uplink direction from the user device (also known as user equipment or "UE") to the base station and in the downlink direction from the base station to the 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 Adaptive Protocol (SDAP) sublayer, or to protocol layers such as the Internet Protocol (IP) layer, the Ethernet Protocol layer, and the Internet Control Message Protocol (ICMP) layer. Generally speaking, UEs and base stations can use SRBs to exchange RRC messages and non-access layer (NAS) messages, and use DRBs to transmit data on the user plane.

[0005] In some scenarios, a UE can simultaneously utilize the resources of multiple nodes in a backhaul-interconnected radio access network (RAN) (e.g., a base station or components of a distributed or disaggregated base station). 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, a base station acting as a master node (MN) and associated cells define a master cell group (MCG), and a base station acting as a secondary node (SN) and associated cells define a secondary cell group (SCG). The MCG covers primary cells (PCells) and 0, 1, or more secondary cells (SCells), while the SCG covers primary secondary cells (PSCells) and 0, 1, or more SCells. The UE communicates with the MN (via the MCG) and with the SN (via the SCG). In other scenarios, the UE is in a single-connection (SC), utilizing the resources of only one base station at a time. In SC, the UE communicates only with the MN via the MCG. A base station and / or UE decide when the UE should establish a radio connection with another base station. For example, a 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 the resources of another RAN node interconnected in the backhaul (e.g., another base station, or a component of a distributed or disaggregated base station).

[0006] A UE can use several types of SRBs and DRBs. The so-called "SRB1" resource carries RRC messages, including NAS messages in some cases, via a dedicated control channel (DCCH), while the "SRB2" resource supports RRC messages, including logged measurement information or NAS messages, also via the DCCH, but with a lower priority than the SRB1 resource. More generally, 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" resource allows the UE and SN to exchange RRC messages related to the SN, and is sometimes called SCG SRBs. The segmented SRBs allow the UE to directly exchange RRC messages with the MN via lower-layer resources for the MN and SN. Furthermore, a DRB that terminates at MN and uses only MN lower-layer resources is sometimes called an MCG DRB, a DRB that terminates at SN and uses only SN lower-layer resources is sometimes called an SCG DRB, and a DRB that terminates at either MN or SN but uses both MN and SN lower-layer resources is sometimes called a split DRB. A DRB that terminates at MN but uses only SN lower-layer resources is sometimes called an MN-terminated SCG DRB. A DRB that terminates at SN but uses only MN lower-layer resources is sometimes called an SN-terminated MCG DRB.

[0007] Regardless of whether it is in SC or DC operation, the UE can perform handover procedures to switch from one cell to another. These procedures involve messaging between the RAN node and the UE (e.g., RRC signaling and preparation). Depending on the scenario, the UE may hand over from a service-providing base station's cell to a target cell of a target base station, or from a first distributed unit (DU) of a service-providing base station to a target cell of a second DU of the same base station. In a DC scenario, the UE can change a PSCell by performing a PSCell change procedure. These procedures involve messaging between the RAN node and the UE (e.g., RRC signaling and preparation). Depending on the scenario, the UE may perform a PSCell change from a service-providing SN's PSCell to a target SN's target PSCell, or from a base station's source DU's PSCell to a target DU of the same base station. Furthermore, the UE may perform a handover or PSCell change within a cell for synchronous reconfiguration.

[0008] Base stations operating under the new fifth-generation (5G) radio (NR) requirements support significantly larger bandwidths than fourth-generation (4G) base stations. Therefore, the Third Generation Partnership Project (3GPP) proposes in Release 15 that user equipment units (UEs) support 100 MHz bandwidth in frequency range 1 (FR1) and 400 MHz bandwidth in frequency range 2 (FR2). Because typical carrier bandwidths in 5G NR are relatively wide, 3GPP proposes in Release 17 that 5G NR base stations can provide multicast and / or broadcast services (MBS) to UEs. MBS can be useful for many content delivery applications, such as IPv4 / IPv6 multicast distribution, IPTV, software distribution over the radio, group communications, Internet of Things (IoT) applications, V2X applications, and emergency messaging related to public safety.

[0009] 5G NR provides both point-to-point (PTP) and point-to-multipoint (PTM) delivery methods for transmitting MBS packet flows over the radio interface. In PTP communication, a RAN node sends different copies of each MBS data packet to different UEs over the radio interface. In PTM communication, on the other hand, a RAN node sends a single copy of each MBS data packet to multiple UEs over the radio interface. However, in some scenarios, it is unclear how a base station can use the HARQ mechanism to send MBS data to one or more UEs via PTM transmission (i.e., multicast) and / or PTP transmission (i.e., unicast). [Overview of the project]

[0010] Generally speaking, base stations (e.g., components of integrated or distributed base stations) and / or UEs implement mechanisms, such as HARQ, to automatically retransmit undelivered packets and improve MBS reliability. The base station first sends a first transmission containing MBS packets to the UE, and then sends a subsequent second transmission to the UE in response to feedback received from the UE regarding the first transmission. The base station may decide how to send the subsequent second transmission (e.g., via multicast or unicast) based on various factors. Such factors 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 regarding the first transmission, and network bandwidth conditions for the first transmission. Based on various factors relating to whether the UE supports or has enabled PTP retransmission, and whether the first and second transmissions have the same transport block size, the UE can determine whether the second transmission is a new transmission or a retransmission of the first transmission, and which RNTI was used to receive the second transmission.

[0011] An example of an embodiment of these technologies is a method implemented in a UE to receive an MBS. The method can be performed by processing hardware and includes: attempting to receive a first transmission from a base station via multicast, which includes MBS data packets associated with an MBS; sending an indication to the base station whether the UE has successfully received the first transmission, in accordance with an automatic retransmission mechanism for undelivered packets; and in response to the transmission, attempting to receive a second transmission from the base station via unicast, in accordance with a mechanism; and determining whether the second transmission is a new transmission or a retransmission of the first transmission.

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

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

[0014] Another exemplary embodiment of these technologies is a base station comprising processing hardware configured to perform the methods described above. [Brief explanation of the drawing]

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

[0016] Figure 1A shows an exemplary wireless communication system 100 that can implement the techniques of this disclosure for managing the transmission and reception of multicast and / or broadcast service (MBS) information. The wireless communication system 100 includes user equipment (UEs) 102A, 102B, and 103, as well as base stations 104, 106 of a radio access network (RAN) 105 connected to a core network (CN) 110. In other embodiments or scenarios, the wireless communication system 100 may instead include more or fewer UEs and / or more or fewer base stations than those shown in Figure 1A. Base stations 104, 106 can be any suitable one or more types of base stations, such as evolved node B (eNB), next-generation eNB (ng-eNB), or 5G node B (gNB). In a more specific example, base station 104 may be an eNB or a gNB, and base station 106 may be a gNB.

[0017] Base station 104 supports cell 124, and base station 106 supports cell 126. Because cell 124 partially overlaps with cell 126, UE102A can be within range of communicating with base station 104 and simultaneously within range of communicating with base station 106 (or within range of detecting or measuring signals from base station 106). The overlap allows UE102A to perform handovers between cells (e.g., from cell 124 to cell 126) or between base stations (e.g., from base station 104 to base station 106) before UE102A experiences a radio link failure. Furthermore, the overlap enables various dual-connection (DC) scenarios. For example, UE102A can communicate with base station 104 (acting as a master node (MN)) and base station 106 (acting as a secondary node (SN)) in a DC. When UE102A is in DC with base stations 104 and 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, UE102A can use radio bearers (e.g., DRB or SRB) that terminate at MN (e.g., base station 104) or SN (e.g., base station 106) at different times. For example, after a handover to base station 106 or an SN change, UE102A can use radio bearers (e.g., DRB or SRB) that terminate at base station 106. UE102A can apply one or more security keys when communicating with radio bearers in the uplink (from UE102A to base station) and / or downlink (from base station to UE102A) directions. In non-MBS operation, UE102A transmits data to base stations via radio bearers on (i.e., within) the cell's uplink (UL) bandwidth portion (BWP), and / or receives data from base stations via radio bearers on the cell's downlink (DL) BWP. The UL BWP can be either the initial UL BWP or a dedicated UL BWP, and the DL BWP can be either the initial DL BWP or a dedicated DL BWP. The UE102A can receive paging, system information, public warning messages, or random access responses on the DL BWP. In this non-MBS operation, the UE102A can be connected. Alternatively, the UE102A can be idle or inactive if it supports small data transmissions while idle or inactive.

[0019] In MBS operation, UE102A can use an MBS radio bearer (MRB) that terminates at either the MN (e.g., base station 104) or the SN (e.g., base station 106) at different times. For example, after a handover or SN change, UE102A can use an MRB that terminates at base station 106, which can operate as either the MN or the SN. In some scenarios, the base station (e.g., MN or SN) can transmit MBS data to UE102A via the MRB over a unicast radio resource (i.e., a radio resource dedicated to UE102A). In other scenarios, the base station (e.g., MN or SN) can transmit MBS data via the MRB over a multicast radio resource (i.e., a radio resource common to UE102A and one or more other UEs) or over a cell DL BWP from the base station to UE102A. 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 MBS, or a DL BWP not for unicast).

[0020] The base station 104 includes processing hardware 130 which may include one or more general-purpose processors (e.g., a central processing unit (CPU)), computer-readable memory for storing machine-readable instructions executable by one or more general-purpose processors, and / or special-purpose processing units. In the exemplary embodiment shown in Figure 1A, the processing hardware 130 includes an MBS controller 132 configured to manage or control the 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 the HARQ process, 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 an MN or SN during non-MBS operation.

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

[0022] UE102A comprises processing hardware 150 which may include one or more general-purpose processors (e.g., CPUs), computer-readable memory for storing machine-readable instructions executable by the general-purpose processors, and / or special-purpose processing units. In the exemplary embodiment shown in Figure 1A, the processing hardware 150 includes an MBS controller 152 configured to manage or control the reception of MBS information. For example, the UE MBS controller 152 may be configured to support RRC configurations, MBS procedures and associated procedures and messaging, and / or other operations associated with those configurations and / or procedures, including the HARQ process, 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 one of the embodiments described below, when UE102A communicates with MN and / or SN during non-MBS operation. Although not shown in Figure 1A, UE102B and 103 may include processing hardware similar to the processing hardware 150 of UE102A.

[0023] CN110 may be an evolved packet core (EPC) 111 or a fifth-generation core (5GC) 160, both shown in Figure 1A. 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 both an NR radio interface and an NG interface for communicating with the 5GC 160. 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 not connected to the EPC 111, a gNB supporting both an NR radio interface and an NG interface to the 5GC 160, or an ng-eNB supporting both an EUTRA radio interface and an NG interface to the 5GC 160. 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 EPC111 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 the UE (e.g., UE102A or 102B) to one or more external packet data networks, such as the Internet network and / or an Internet Protocol (IP) Multimedia Subsystem (IMS) network. The 5GC160 includes User Plane Functions (UPF) 162, Access and Mobility Management (AMF) 164, and / or Session Management Functions (SMF) 166. UPF162 is generally configured to forward user plane packets related to voice calls, video calls, internet traffic, etc., AMF164 is generally configured to manage authentication, registration, paging, and other related functions, and SMF166 is generally configured to manage PDU sessions.

[0025] UPF162, AMF164, and / or SMF166 can be configured to support MBS. For example, SMF166 can be configured to manage or control MBS transport, configure UPF162 and / or RAN105 for MBS flows, and / or manage or set up one or more MBS sessions or PDU sessions for MBS for a UE (e.g., UE102A or 102B). UPF162 is configured to forward MBS data packets, such as audio, video, and internet traffic, to RAN105. UPF162 and / or SMF166 can be configured for both non-MBS unicast services and MBS, or for MBS only.

[0026] Generally, the wireless communication system 100 may include any suitable number of base stations that support NR cells and / or EUTRA cells. More specifically, the EPC 111 or 5GC 160 may be connected to any suitable number of base stations that support NR cells and / or EUTRA cells. In the following embodiments, specific CN types (EPC, 5GC) and RAT types (5G NR and EUTRA) are specifically referred to, but generally, the technology of this disclosure can 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 networks or 5G NR-6G DC.

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

[0028] When base station 104 is a MeNB and base station 106 is an SgNB, UE102A can be in an EN-DC with MeNB104 and SgNB106. When base station 104 is a Mng-eNB and base station 106 is an SgNB, UE102A can be in a next-generation (NG) EUTRA-NR DC (NGEN-DC) with Mng-eNB104 and SgNB106. When base station 104 is a MgNB and base station 106 is an SgNB, UE102A can be in an NR-NR DC (NR-DC) with MgNB104 and SgNB106. When base station 104 is a MgNB and base station 106 is an Sng-eNB, UE102A can be in an NR-EUTRA DC (NE-DC) with MgNB104 and Sng-eNB106.

[0029] Figure 1B shows one or more exemplary distributed embodiments of base stations 104 and 106. In this embodiment, 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 for storing machine-readable instructions executable by the general-purpose processor(s), and / or special-purpose processing units. For example, the CU 172 may include some or all of the processing hardware 130 or 140 in Figure 1A.

[0030] Each DU174 also includes processing hardware which may include one or more general-purpose processors (e.g., CPUs), computer-readable memory for storing 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 MAC controller configured to manage or control one or more media access control (MAC) operations or procedures (e.g., random access procedures), and an RLC controller configured to manage or control one or more radio link control (RLC) operations or procedures when a base station (e.g., base station 104) operates as an MN or SN. The processing hardware may also include a PHY layer controller configured to manage or control one or more physical (PHY) layer operations or procedures.

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

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

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

[0034] The EUTRA PDCP sublayer 208 and NRPDCP sublayer 210 receive packets that may be called Service Data Units (SDUs) (e.g., from the IP layer layered directly or indirectly on PDCP layer 208 or 210) and output packets that may be called Protocol Data Units (PDUs) (e.g., to RLC layer 206A or 206B). For simplicity, in this disclosure, both SDUs and PDUs are referred to as “packets” unless the difference between SDUs and PDUs is relevant. Packets can be MBS packets or non-MBS packets. MBS packets may contain, for example, application content for MBS services (e.g., IPv4 / IPv6 multicast distribution, IPTV, software distribution over radio, group communications, IoT applications, V2X applications, and / or emergency messages related to public safety). As another example, MBS packets may contain application control information for MBS services.

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

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

[0037] In some embodiments, a base station (e.g., base stations 104, 106) broadcasts MBS data packets via one or more MBS radio bearers (MRBs), and a UE 102A, 102B, or 103 then receives the MBS data packets via the MRBs. The base station may include the configuration(s) of the MRBs in the multicast configuration parameters (sometimes also called MBS configuration parameters) described below. In some embodiments, the base station broadcasts MBS data packets via the RLC sublayer 206, MAC sublayer 204, and PHY sublayer 202, and accordingly, UE 102A receives the MBS data using the PHY sublayer 202, MAC sublayer 204, and RLC sublayer 206. In such embodiments, the base station and UE 102A, 102B, or 103 may not use the PDCP sublayer 208 and SDAP sublayer 212 to communicate the MBS data packets. In other embodiments, the base station transmits MBS data packets via the PDCP sublayer 208, RLC sublayer 206, MAC sublayer 204, and PHY sublayer 202, and accordingly, UE 102A, 102B, or 103 receives the MBS data packets using the PHY sublayer 202, MAC sublayer 204, RLC sublayer 206, and PDCP sublayer 208. In such embodiments, the base station and 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 MBS data packets via the SDAP sublayer 212, PDCP sublayer 208, RLC sublayer 206, MAC sublayer 204, and PHY sublayer 202, and in response, UE 102A, 102B, or 103 receives the MBS data packets using the PHY sublayer 202, MAC sublayer 204, RLC sublayer 206, PDCP sublayer 208, and SDAP sublayer 212.

[0038] Figure 2B shows a simplified exemplary protocol stack 250 that can be used by UE102A, 102B, or 103 to communicate with DU (e.g., DU174) and CU (e.g., CU172). The radio protocol stack 200 in Figure 2A is functionally divided by the radio protocol stack 250 in Figure 2B, as shown. The CU, located in either base station 104 or 106, can hold all control and higher-layer functions (e.g., RRC214, SDAP212, NR PDCP210), while lower-layer operations (e.g., NR RLC206B, NR MAC204B, and NR PHY202B) can be delegated to the DU. To support connectivity to 5GC, NR PDCP210 provides SRB to RRC214, NR PDCP210 provides DRB to SDAP212, and NR PDCP210 provides SRB to RRC214.

[0039] Referring to Figure 3, an MBS session 302A may include a tunnel 312A with endpoints at CN110 and base stations 104 / 106. An MBS session 302A may correspond to a specific session ID, such as Temporary Mobile Group Identification (TMGI). 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, CN110 and / or base stations 104 / 106 configure tunnel 312A only for MBS traffic directed from CN110 to base stations 104 / 106, and tunnel 312A may be referred to as the downlink (DL). However, in other cases, CN110 and base stations 104 / 106 use tunnel 312A for both downlink and uplink (UL) MBS traffic to support, for example, commands or service requests from UEs. Furthermore, since base stations 104 / 106 can direct MBS traffic arriving through tunnel 312A to multiple UEs, tunnel 312A may be referred to as the common tunnel or common DL tunnel.

[0041] Tunnel 312A can operate on a transport layer or sublayer, such as a User Datagram Protocol (UDP) layered on top of the Internet Protocol (IP). More specifically, tunnel 312A can be associated with the General-Package Radio System (GPRS) Tunneling Protocol (GTP). Tunnel 312A can correspond, for example, to a specific IP address (e.g., the IP address of base stations 104 / 106) and a specific Tunnel Endpoint Identifier (TEID) (e.g., assigned by base stations 104 / 106). More generally, tunnel 312A can have any suitable transport layer configuration. CN110 can specify the IP address and TEID address in the header(s) of the tunnel packet containing the MBS data packet and transmit the tunnel packet downstream to base stations 104 / 106 via tunnel 312A (for example, the header(s) can include the IP address and / or TEID). For example, the header(s) can include an IP header and a GTP header, each containing the IP address and TEID, respectively. Therefore, base stations 104 / 106 can identify data packets traveling through tunnel 312A using their IP addresses and / or TEIDs.

[0042] As shown in Figure 3, base stations 104 / 106 map traffic within tunnel 312A to N radio bearers 314A-1, 314A-2, ... 314A-N (wherein N≧1), which can be configured as MBS radio bearers or MRBs. Each MRB can correspond to its 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 MRB314A can correspond to, for example, its respective MBS traffic channel (MTCH). Base stations 104 / 106 and CN110 can also maintain another MBS session 302B, which similarly may include tunnel 312B corresponding to MRB314B-1, 314B-2, ... 314B-N (wherein N≧1). Each MRB314B can correspond to its respective logical channel.

[0043] MBS traffic can include one or more Quality of Service (QoS) flows for each of the tunnels 312A, 312B, etc. For example, MBS traffic on tunnel 312B can include a set of flows 316, such as QoS flows 316A, 316B, ..., 316L. Furthermore, a logical channel of an MRB can support a single QoS flow or multiple QoS flows. In the exemplary configuration of Figure 3, base stations 104 / 106 map QoS flows 316A and 316B to the MTCH of MRB314B-1 and QoS flow 316L to the MTCH of MRB314B-N.

[0044] In various scenarios, the CN110 can assign different types of MBS traffic to different QoS flows. For example, a flow with a relatively high QoS value can handle audio packets, while a flow with a relatively low QoS value can handle video packets. Another example is that a flow with a relatively high QoS value can handle I-frames or full images used in video compression, while a flow with a relatively low QoS value can handle predictive pictures that only include P-frames or changes to I-frames.

[0045] Continuing to refer to Figure 3, base stations 104 / 106 and CN110 can maintain one or more PDU sessions to support unicast traffic between CN110 and a specific UE. A PDU session 304A may include UE-specific DL tunnels and / or UE-specific UL tunnels 322A corresponding to one or more DRB324A such as DRB324A-1, 324A-2, ..., 324-N. Each DRB324A may correspond to its own logical channel, such as a dedicated traffic channel (DTCH).

[0046] Referring to Figure 4, when base stations 104 / 106 are implemented in a distributed configuration, CU172 and DU174A / 174B can establish tunnels for downlink and / or uplink data associated with the MRB or DRB. The above MRB314A-1 can be implemented as MRB402A, connecting CU172 to multiple UEs, such as UE102A and 102B. MRB402A can include a DL tunnel 412A connecting CU172 and DU174A / 174B, and a DL logical channel 422A corresponding to the DL tunnel 412A. In particular, DU174A / 174B can map downlink traffic received via the DL tunnel 412A to the DL logical channel 422A, which may be, for example, an MTCH or DTCH. The DL tunnel 412A can be a common DL tunnel, and CU172 transmits MBS data packets to multiple UEs via the common DL tunnel. Alternatively, DL tunnel 412A can be a UE-specific DL tunnel, and CU172 can send MBS data packets to a specific UE via the UE-specific DL tunnel.

[0047] Optionally, the MRB402A also includes a UL tunnel 413A connecting the CU172 and the DU174A / 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 DU174A / 174B can map uplink traffic received via the UL logical channel 423A to the UL tunnel 413A.

[0048] Tunnels 412A and 413A can operate at the transport layer or sublayer of the F1-U interface. More specifically, CU172 and DU174A / 174B can utilize F1-U for user plane traffic, and tunnels 412A and 413A can be associated with the GTP-U protocol layered over UDP / IP, with IP layered over the appropriate data link layer and physical (PHY) layer. Furthermore, MRB(s) 402 and / or DRB(s) 404 additionally support control plane traffic in at least some cases. More specifically, CU172 and DU174A / 174B can exchange F1-AP messages via an F1-C interface that relies on the Stream Controlled Transmit Protocol (SCTP) layered over IP, with IP layered over the appropriate data link layer and PHY layer, similar to F1-U.

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

[0050] CU172 may, in some cases, use DRB404A to transmit MBS data packets or unicast data packets associated with PDU sessions to a specific UE (e.g., UE102A or UE102B). DRB404A may include a UE-specific DL tunnel 432A connecting CU172 and DU174A / 174B, and a DL logical channel 442A corresponding to DL tunnel 432A. In particular, DU174A / 174B can map downlink traffic received via DL tunnel 432A to DL logical channel 442A, which may be, for example, DTCH. DRB404A may further include a UE-specific UL tunnel 433A connecting CU172 and DU174A / 174B, and a UL logical channel 443A corresponding to UL tunnel 433A. UL logical channel 443A may be, for example, PUSCH. The DU174A / 174B can map uplink traffic received via UL logical channel 443A to UL tunnel 433A.

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

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

[0053] UE102 (for example, UE102A in Figure 1A) first joins the first MBS session by performing the MBS session join procedure with CN110 via base station 104 (502). In some scenarios, UE102 then performs one or more additional MBS join procedures, and therefore event 502 is the first of multiple MBS join procedures. Since base station 104 configures a common DL tunnel for MBS traffic (rather than the UE-specific tunnel described below), procedures 502 and 586 can occur in either order. In other words, base station 104 can configure a common DL tunnel even before a single UE joins the first MBS session.

[0054] In some embodiments, to perform the MBS session join procedure, UE102 sends an MBS session join request message to CN110 via base station 104. In response, CN110 can send an MBS session join response message to UE102 via base station 104 to grant UE102 access to the first MBS session. In some embodiments, UE102 may include the first MBS session ID of the first MBS session in the MBS session join request message. CN110 may optionally include the first MBS session ID in the MBS session join response message. In some embodiments, UE102 may send an MBS session join completion message to CN110 via base station 104 in response to the MBS session join response message.

[0055] UE102 may, in some cases, join an additional MBS session by performing an additional MBS session join procedure with CN110 via RAN105 (e.g., base station 104 or base station 106). For example, UE102 may join a second MBS session by performing a second MBS session join procedure with CN110 via RAN105. Similar to event 502, in some embodiments, UE102 may send a second MBS session join request message to CN110 via base station 104, and CN110 may respond with a second MBS session join response message, granting UE102 access to the second MBS session. In some embodiments, UE102 may send a second MBS session join completion message to CN110 via base station 104 in response to the second MBS session join response message. In some embodiments, UE102 may include the second MBS session ID of the second MBS session in the second MBS session join request message. CN110 optionally includes the second MBS session ID in the second MBS session join response message. In some embodiments, UE102 includes the first MBS session ID and the second MBS session ID in an MBS session join request message (e.g., a first MBS session join request message), allowing it to join both the first and second MBS sessions simultaneously. In such cases, CN110 can send an MBS session response message to allow either the first or second MBS session, or both.

[0056] In some embodiments, the MBS session join request message, MBS session join response message, and MBS session join completion message can be Session Initiation Protocol (SIP) messages. In other embodiments, the MBS session join request message, MBS session join response message, and MBS session join completion message can be NAS messages such as 5G Mobility Management (5GMM) messages or 5G Session Management (5GSM) messages. In the case of 5GSM messages, UE102 can send a (first) UL container message containing the MBS session join request message to CN110 via base station 104, CN110 can send a DL container message containing the MBS session join response message to UE102 via base station 104, and UE102 can send a (second) UL container message containing the MBS session join completion message to CN110 via base station 104. These container messages can be 5GMM messages. In some embodiments, the MBS session join request message, MBS session join response, and MBS session join completion message may be the PDU session change request message, PDU session change command message, and PDU session change completion message, respectively. For the sake of simplicity in the following explanation, the terms MBS session join request message, MBS session join response message, and / or MBS session join completion message may refer to either the respective container message or the respective message without a container.

[0057] In some embodiments, UE102 can establish a PDU session by performing a PDU session establishment procedure with CN110 via base station 104 in order to perform a (first) MBS session join procedure. During the PDU session establishment procedure, UE102 can communicate the PDU session ID of the PDU session with CN110 via base station 104.

[0058] Before, during, or after the first MBS session join procedure (event 502), CN110 may send a (first) CN-BS message to CU172 (504) containing the first MBS session ID and / or PDU session ID, requesting CU172 to configure the resources for the first MBS session. CN110 may additionally include a Quality of Service (QoS) configuration(s) for the first MBS session in the first CN-BS message. Upon receiving the first CN-BS message (504), CU172 sends a CU-DU message (e.g., an MBS context setup request message) to DU174 (506) requesting the setup of the MBS context and / or common DL tunnel for the first MBS session. The MBS context setup request message may include the first MBS session ID, MRB ID(s), and the QoS configuration(s) for the first MBS session.

[0059] Upon receiving a CU-DU message (506), DU174 sends a DU-CU message (e.g., an MBS context setup response message) (508) to the CU, which includes a first DL transport layer configuration, to configure a common CU-DU DL tunnel for the first MBS session (e.g., for an MRB identified by one of the MRB IDs). DU174 may include additional DL transport layer configurations in the DU-CU message to configure additional common CU-DU DL tunnels for additional MRBs identified by additional MRB IDs. In some embodiments, DU174 may include MRB IDs associated with the first DL transport layer configuration and / or additional DL transport layer configurations 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). CN110 may additionally include a Quality of Service (QoS) configuration(s) for the first MBS session. In such cases, CU172 may include the QoS configuration(s) in the CU-DU message (event 506).

[0060] Next, CU172 can configure the common DL tunnel by sending a first BS-CN message (e.g., an MBS session resource setup response message) including a DL transport layer configuration (510). CU172 may include a first MBS session ID and / or PDU session ID in the first BS-CN message. The first BS-CN message may include a DL transport layer configuration to configure the common DL tunnel to send MBS data to CU172 in CN110. The DL transport layer configuration includes a transport layer address (e.g., an IP address and / or 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 for requesting 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 for conveying resources for an MBS session (e.g., an MBS session resource setup response message). In such cases, 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 a first MBS session. In some embodiments, the QoS configuration(s) include configuration parameters for configuring one or more QoS flows in an MBS session (e.g., MBS session 302A in Figure 3). In some embodiments, the configuration parameters include one or more QoS flow IDs that identify the QoS flow(s). Each QoS flow ID(s) identifies a specific QoS flow(s) among the QoS flow(s). In some embodiments, the configuration parameters include QoS parameters for each QoS flow. QoS parameters may include, for example, a 5G QoS identifier (5QI), priority level, packet delay budget, packet error rate, averaging window, and / or maximum data burst amount. CN110 can specify different values ​​for QoS parameters for a QoS flow.

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

[0064] If CN110 allows UE102 to join additional MBS sessions in an additional MBS session joining procedure, CN110 may include additional MBS session IDs and / or QoS configurations for the additional MBS session IDs in the first CN-BS message, a second CN-BS message (described below in relation to event 512), or additional CN-BS messages similar to the first or second CN-BS message. In such a case, CU172 may include additional transport layer configurations for the additional MBS sessions and configure additional common DL tunnels in the first BS-CN message, the second BS-CN message (described below in relation to event 519), or additional BS-CN messages similar to the first or second BS-CN message. Each transport layer configuration(s) can configure a specific DL tunnel for a common DL tunnel(s) and associate it with a specific MBS session for an additional MBS session(s). Alternatively, CN110 can obtain additional transport layer configurations(s) from CU172 by performing additional MBS session resource setup procedures(s), similar to the single-session MBS session resource setup procedure 586. Transport layer configurations can differ 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 DL TEIDs.

[0065] In some embodiments, CN110 may indicate a list of UEs participating in the first MBS session in the CN-BS message of event 504. In other embodiments, CN110 may send another second CN-BS message to CU172 (512) indicating a list of UEs participating in the first MBS session. CN110 may include the first MBS session ID and / or PDU session ID in the second CN-BS message. CU172 may send a second BS-CN message to CN110 (519) in response to the second CN-BS message of event 512. In such cases, the second CN-BS message may be a non-UE specific message, i.e., a message not specific to UE102A or UE102B. CU172 may include the first MBS session ID and / or PDU session ID in the second BS-CN message. For example, the list of UEs may include UE102. To indicate a list of UEs, CN110 may include a list of (CN UE interface ID, RAN UE interface ID) pairs, each identifying a specific UE. CN110 assigns the CN UE interface ID, and CU172 assigns the RAN UE interface ID. Before CN110 sends the list of (CN UE interface ID, RAN UE interface ID) pairs, CU172 sends a BS-CN message (e.g., an NGAP message, initial UE message, or path switching request message) containing the RAN UE interface ID to CN110 for each UE, and CN110 sends a CN-BS message (e.g., an NGAP message, initial context setup request T message, or path switching request confirmation message) containing the CN UE interface ID to CU172 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 UE102.In some embodiments, the "CN UE Interface ID" can be the "AMF UE NGAP ID," and the "RAN UE Interface ID" can be the "RAN UE NGAP ID." In other embodiments, CN110 may include a list of UE IDs, each identifying a specific UE within a set of UEs. In some embodiments, CN110 may assign UE IDs and send each of the UE IDs to a specific UE in a NAS procedure (e.g., a registration procedure) that CN110 performs with a particular UE. For example, the list of UE IDs may include a first UE ID for UE102A and a second UE ID for UE102B. In some embodiments, the UE ID is an S-Temporary Mobile Subscriber Identity (S-TMSI) (e.g., 5G-S-TMSI). Before CN110 sends the list of UE IDs, CU172 may receive a UE ID per UE from UE102 or CN110. For example, CU172 may receive an RRC message containing the UE ID from UE102 during the RRC connection establishment procedure (e.g., an RRC setup complete message). In another example, CU172 may receive a CN-BS message containing the UE ID from CN110 (e.g., an NGAP message, an initial context setup request message, or a UE information transfer message).

[0066] In other embodiments, CN110 may send a second CN-BS message to CU172 (512) indicating that UE102 is joining a first MBS session (only). The second CN-BS message may be a UE-related message for UE102; that is, the second CN-BS message is specific to UE102. Upon receiving the second CN-BS message, CU172 may send a UE context request message for UE102 to DU174 (514). In some embodiments, CU172 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(ID). In response to the UE context request message, DU174 receives the MBS data for the first MBS session by sending a UE context response message to CU172 (516) containing the configuration parameters of UE102A. In some embodiments, CU172 may include a QoS configuration(s) in the UE context request message. In such embodiments, CU172 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 MRB(s) / MRB ID(s). In some embodiments, DU174 generates a DU configuration(i.e., a first DU configuration) to include the configuration parameters(i.e., a first set of configuration parameters) and includes the DU configuration in the UE context response message. In some embodiments, the DU configuration may be a CellGroupConfig IE. In other embodiments, the DU configuration may be an MBS-specific IE. In some embodiments, the configuration parameters constitute one or more logical channels (LCs). For example, the configuration parameters include one or more logical channel IDs (LCIDs) to constitute one or more logical channels. Each LCID identifies a specific logical channel among one or more logical channels.

[0067] In some embodiments, the second CN-BS message and the second BS-CN message may be a PDU session resource change request message and a PDU session resource change response message, respectively. In some embodiments, the second CN-BS message and the second BS-CN message may be UE-related messages, i.e., the messages are associated with a specific UE (e.g., UE102A, 102B, or 103).

[0068] In some embodiments, CU172 transmits a first BS-CN message (510) in response to event 512, rather than in response to event 504, as shown in Figure 5A. CN110 can then transmit a CN-BS response message to CU172 in response to the first BS-CN message. In such a case, CU172 can transmit a CU-DU message to DU174 (506) in response to receiving a second CN-BS message, and the first BS-CN message and the CN-BS response message can be non-UE related messages (i.e., the messages are not related to a specific UE).

[0069] In some embodiments, DU174 sends a DU-CU message (508) in response to event 514 (not in response to event 506), and also sends a UE context response message (516) in response to event 514. CU172 can then send a CU-DU response message to DU174 in response to the DU-CU message. In such cases, the DU-CU message and the CU-DU response message can be non-UE related messages, i.e., the messages are not related to a specific UE.

[0070] If CN110 allows UE102 to join additional MBS sessions in an additional MBS session join procedure, CN110 may include additional MBS session IDs and / or QoS configurations in the first or second CN-BS message. In such a case, CU172 may include additional MBS session IDs and additional MRB IDs in the CU-DU message, and DU174 may include additional DU transport layer configurations in the DU-CU message to configure additional CU-DU DL tunnels for the additional MBS sessions. Alternatively, CU172 may perform additional MBS context setup procedures with DU174, as in events 506 and 508, to obtain additional DU DL transport layer configurations. In some embodiments, CU172 includes additional CU DL transport layer configurations(s) for additional MBS sessions(s) to configure additional CN-BS common DL tunnels(s) in the first BS-CN message. Each transport layer configuration(s) can configure a specific DL tunnel for a common CN-BS DL tunnel(s) and be associated with a specific MBS session for an additional MBS session(s). Alternatively, CN110 can obtain additional CU DL transport layer configurations(s) from CU172 by performing an additional MBS session resource setup procedure(s), similar to the MBS session resource setup procedure 586. 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 DL TEIDs.

[0071] In some embodiments, CN110 includes a QoS configuration(s) in the second CN-BS message. In such cases, CN110 may include a QoS configuration(s) in the first CN-BS message, or it may omit a QoS configuration(s). In some embodiments, DU174 receives MBS data for the first MBS session by generating configuration parameters for UE102 in response to receiving a CU-DU message or a UE context request message. In some embodiments, CU172 includes a QoS configuration(s) in the UE context request message and / or the CU-DU message. DU174 can determine the content of the configuration parameters according to the QoS configuration(s). When CU172 does not include a QoS configuration(s) in either the CU-DU message or the UE context request message, DU174 can determine the values ​​of the configuration parameters according to a given QoS configuration.

[0072] In other embodiments, the UE context request message and the UE context response message are the UE context setup request message and the UE context setup response message, respectively. In other embodiments, the UE context request message and the UE context response message are the UE context change request message and the UE context change response message, respectively.

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

[0074] In some embodiments, CU172 generates a PDCP PDU containing an RRC reconfiguration message and sends a CU-DU message containing the PDCP PDU to DU174 (518), DU174 retrieves the PDCP PDU from the CU-DU message and sends the PDCP PDU to UE102 via the RLC layer 206B, MAC layer 204B, and PHY layer 202B (520). UE102 receives the PDCP PDU from DU174 via the PHY layer 202B, MAC layer 204B, and RLC layer 206B (520). In some embodiments, UE102 generates a PDCP PDU containing an RRC reconfiguration complete message and sends the PDCP PDU to DU174 via the RLC layer 206B, MAC layer 204B, and PHY layer 202B (522). DU174 receives a PDCP PDU from UE102 via PHY layer 202B, MAC layer 204B, and RLC layer 206B (522), and transmits a DU-CU message containing the PDCP PDU to CU172 (523). CU172 retrieves the PDCP PDU from the DU-CU message and retrieves an RRC reconstruction complete message from the PDCP PDU.

[0075] Before or after receiving the UE context response message (516), CU172 may send a second BS-CN message to CN110 (519) in response to the second CN-BS message 512. In some embodiments, CU172 sends the second BS-CN message to CN110 (519) before receiving the RRC reconfiguration complete message (523). In other embodiments, CN110 sends the second BS-CN message to CN110 (519) after receiving the RRC reconfiguration complete message (523). CU172 may include a first CN UE interface ID and a first RAN UE interface ID in the second BS-CN message. Alternatively, CU172 may include a first UE ID in the second BS-CN message.

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

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

[0078] After receiving a first BS-CN message (510) or a second BS-CN message (519), CN110 may transmit the MBS data for the first MBS session (e.g., one or more MBS data packets) to CU172 via the common CN-BS DL tunnel (524), and CU172 then transmits the MBS data to DU174 via the common CU-DU tunnel (526). DU174 transmits the MBS data to UE102 via one or more logical channels (528) (e.g., multicast or unicast). UE102 receives the MBS data via one or more logical channels (528). For example, CU172 may receive the MBS data packets (524), generate a PDCP PDU containing the MBS data packets, and transmit the PDCP PDU to DU174 (528). Next, DU174 generates a MAC PDU containing a logical channel ID and a PDCP PDU, and transmits the MAC PDU to UE102 via multicast or unicast (528). UE102 receives the MAC PDU via multicast or unicast (528), obtains the PDCP PDU and 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 packets from the PDCP PDU according to the PDCP configuration in the MRB configuration. In some embodiments, DU174 may transmit (528) the MBS data or MAC PDU to UE102 via one or more multicast transmissions (e.g., dynamic or SPS multicast transmissions). In such cases, UE102 may receive (528) the MBS data or MAC PDU from DU174 via one or more multicast transmissions, as described above.As further described below in Figures 6A-6E, 7A-7C, and 8A-8B, UE102 can receive (528) MBS data or MAC PDU using the HARQ process, and UE102 sends HARQ feedback to base station 104 (e.g., DU174) indicating whether the UE has successfully received the MBS data (e.g., the first MBS data packet). Based on the HARQ feedback, base station 104 (e.g., DU174) transmits (528) the MBS data either as a retransmission (e.g., the first MBS data packet) or as a new transmission (e.g., the second MBS data packet).

[0079] In some embodiments, CU172 may decide and configure a UE-specific CN-BS DL tunnel for UE102 in response to receiving a first CN-BS message or a second CN-BS message. In such cases, CU172 may omit event 506, and the second BS-CN message may include a DL transport layer configuration for configuring the UE-specific DL tunnel. CN110 can then transmit MBS data to CU172 (524) via the UE-specific CN-BS DL tunnel. In some embodiments, CU172 may decide and configure a UE-specific CU-DU DL tunnel for UE102 in response to receiving a first CN-BS message or a second CN-BS message. In such cases, CU172 may omit event 510, and DU174 may include a DL transport layer configuration for configuring the UE-specific CU-DU DL tunnel in its UE context response message. In such a case, CU174 can transmit MBS data to DU174 via a UE-specific CU-DU DL tunnel (526).

[0080] In some embodiments, the configuration parameters may include one or more RLC bearer configurations, each associated with a specific MRB. Each MRB configuration 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 the PDCP-Config IE of the DRB. In some embodiments, the RLC bearer configuration may be the RLC-BearerConfig IE. In some embodiments, the RLC bearer configuration may include a logical channel (LC) ID that constitutes 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 constitutes a logical channel. In some embodiments, the RLC bearer configuration may include an MRB ID.

[0081] In some embodiments, CU172 can configure the MRB as a DL-only RB in an MRB configuration. For example, CU172 can refrain from including UL configuration parameters in the PDCP configuration within the MRB configuration in order to configure the MRB as a DL-only RB. CU172 can include only DL configuration parameters in the MRB configuration, as described above. In such a case, CU172 configures UE102 not to transmit UL PDCP data PDUs to DU174 and / or CU172 via the MRB by excluding the UL configuration parameters for the MRB in the PDCP configuration within the MRB configuration. In another example, DU174 refrains from including UL configuration parameters in the RLC bearer configuration. In such a case, DU174 configures UE102 not to transmit control PDUs(or PDUs) to base station 104 via the logical channel by excluding the UL configuration parameters from the RLC bearer configuration.

[0082] If DU174 includes UL configuration parameters in its RLC bearer configuration, UE102 may send control PDUs (e.g., PDCP control PDUs and / or RLC control PDUs) to DU174 via a logical channel using the UL configuration parameters. If the control PDU is a PDCP control PDU, DU174 may send the PDCP control PDU to CU172. For example, CU172 may be configured to receive MBS data using a compression (decompression) protocol (e.g., Robust Header Compression (ROHC) protocol). In this case, when CU172 receives MBS data packets from CN110 (524), CU172 compresses the MBS data packets using the compression protocol to obtain compressed MBS data packets, and sends the PDCP PDU containing the compressed MBS data packets to DU174 via a common CU-DU DL tunnel (526). Next, DU174 sends the PDCP PDU to UE102 via a logical channel (528) (e.g., multicast or unicast). When UE102 receives the PDCP PDU via the logical channel, UE102 retrieves the compressed MBS data packets from the PDCP PDU. UE102 retrieves the original MBS data packets by decompressing the compressed (decompressed) packets using a compression (decompression) protocol. In such a case, UE102 may send a PDCP control PDU to DU174 via the logical channel, including header compression protocol feedback (e.g., scattered ROHC feedback) for the operation of the header compression (decompression) protocol. DU174 then sends the PDCP control PDU to CU172 via a UE-specific UL tunnel, i.e., the UL tunnel is specific to UE102 (e.g., UE102A). In some embodiments, CU172 may include a CU UL transport layer configuration in the UE context request message that constitutes the UE-specific UL tunnel. The CU UL transport layer configuration includes the CU transport layer address (e.g., Internet Protocol (IP) address) and the CU UL TEID to identify the UE-specific UL tunnel.

[0083] In some embodiments, 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 multiple MRBs. Base station 104 sets the MRB ID to a different value. If CU172 configures a DRB(s) on UE102 for unicast data communication, CU172 can, in some embodiments, set one or more of the MRB IDs(s) to a different value from the DRB IDs(s) of the DRB(s). In such cases, UE102 and CU172 can distinguish whether an RB is an MRB or a DRB according to the RB IDs of the RBs. In other embodiments, CU172 can set one or more of the MRB IDs(s) to a value that can be the same as the DRB IDs(s). In such cases, UE102 and CU172 can distinguish whether an RB is an MRB or a DRB based on the RB's RB ID and the RRC IE that constitutes the RB. For example, a DRB configuration that constitutes a DRB is a DRB-ToAddMod IE that includes a DRB identifier (e.g., drb-Identity or DRB-Identity) and a PDCP configuration. Therefore, UE102 can determine that an RB is a DRB if it receives a DRB-ToAddMod IE that constitutes an RB, and can determine that an RB is an MRB if it receives an MRB-ToAddMod IE that constitutes an RB. Similarly, CU172 can determine that an RB is a DRB if it sends a DRB-ToAddMod IE that constitutes an RB to UE102, and can determine that an RB is an MRB if it sends an MRB-ToAddMod IE that constitutes an RB to UE102.

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

[0085] In some embodiments, the configuration parameters may include one or more dynamic scheduling multicast configuration parameters for the UE102 to receive multicast transmissions, each containing MBS data or a specific portion of MBS data. In some embodiments, the one or more dynamic scheduling multicast configuration parameters may include at least one of the following configuration parameters: • Group Radio Network Temporary Identifier (G-RNTI). DU174 dynamically schedules multicast transmissions for UE102, each containing a specific MAC PDU, by generating a DCI, scrambling the 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 contain an MBS data packet or a portion of an MBS data packet. UE102 receives the DCI and the scrambled CRC on the PDCCH and verifies the scrambled CRC with the G-RNTI. For each multicast transmission, after UE102 verifies that the (scrambled) CRC is valid, UE102 receives the multicast transmission according to the corresponding DCI and retrieves a specific MAC PDU from the multicast transmission. In this case, each multicast transmission is a dynamically scheduled multicast transmission as used in the following description. In some embodiments, each DCI includes configuration parameters that constitute a dynamically scheduled multicast radio resource that schedules the corresponding multicast transmission. In some embodiments, the configuration parameters may include at least one of the following parameters: Each DCI configuration parameter can contain the same and / or different values ​​as the following configuration parameters. • Allocation of frequency domain resources • Allocation of time domain resources • Mapping from virtual resource blocks (VRBs) to physical resource blocks (PRBs) • Modulation coding scheme (MCS) • New data indicator • Redundant version • HARQ process number • Downlink assignment index PUCCH Resource Indicator The HARQ codebook (ID) indicates the HARQ acknowledgment (ACK) codebook index of the HARQ ACK codebook corresponding to the dynamically scheduled multicast transmission received by UE102. DU174 uses the HARQ codebook (ID) to receive the HARQ ACK. If the configuration parameter does not include the HARQ codebook (ID), UE102 and DU174 may use the HARQ codebook (ID) for unicast transmissions. In some embodiments, UE102 can receive the HARQ codebook (ID) from DU174 for unicast transmissions in a DU configuration. In other embodiments, UE102 can receive the HARQ codebook (ID) from DU174 for unicast transmissions in a different DU configuration, as with events 516, 518, and 520. The PUCCH resource configuration indicates a HARQ resource on PUCCH to which UE102 sends HARQ feedback (e.g., HARQ ACK and / or negative ACK (NACK)) for dynamic scheduling multicast transmissions. If the configuration parameter does not include a PUCCH resource configuration, UE102 and DU174 can use the PUCCH resource configuration for unicast transmissions to communicate HARQ feedback. The HARQ NACK-only indication configures UE102 to send only HARQ negative ACKs (NACKs) to dynamic scheduling multicast transmissions that UE102 receives from DU174 and from which UE102 cannot obtain the transport block. In some embodiments, UE102 cannot obtain the transport block because it fails the cyclic redundancy check (CRC) of the transport block or because UE102 does not receive the dynamic scheduling multicast transmission. According to the indication, UE102 refrains from sending HARQ ACKs to DU174 for dynamic scheduling multicast transmissions that UE102 successfully receives and from which UE102 obtains the transport block. If the configuration parameter does not include the indication, UE102 can send HARQ ACKs to DU174 for dynamic scheduling multicast transmissions that UE102 successfully receives and from which UE102 obtains the transport block. The HARQ ACK / NACK indication configures UE102 to send a HARQ NACK for dynamic scheduling multicast transmissions where UE102 cannot obtain the transport block, and to send a HARQ ACK for dynamic scheduling multicast transmissions that UE102 successfully receives and from which UE102 obtains the transport block. If the configuration parameter does not include the indication, UE102 refrains from sending a HARQ ACK to DU174 for dynamic scheduling multicast transmissions that UE102 successfully receives and from which UE102 obtains the transport block. In such cases, UE102 is only permitted to send a HARQ NACK to DU174 for dynamic scheduling multicast transmissions where UE102 cannot obtain the transport block. The HARQ ACK indication configures UE102 to send a HARQ ACK for dynamic scheduling multicast transmissions that UE102 successfully receives and from which UE102 acquires the transport block. If the configuration parameter does not include the indication, UE102 refrains from sending a HARQ ACK to DU174 for dynamic scheduling multicast transmissions from which UE102 successfully acquires the transport block. In such cases, UE102 is only permitted to send a HARQ NACK to DU174 for dynamic scheduling multicast transmissions from which UE102 does not acquire the transport block. In some embodiments, DU174 may include any one of the following: HARQ NACK indication, HARQ ACK / NACK indication, and HARQ ACK indication. The Modulation Coding Scheme (MCS) configuration refers to the MCS table used by DU174 to send dynamic scheduling multicast transmissions and by UE102 to receive dynamic scheduling multicast transmissions. For example, the MCS table can be an MCS table defined in 3GPP Specification 38.214 (e.g., the low SE64QAM 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 DU174 does not include an MCS configuration within its DU configuration, UE102 and DU174 can apply a predefined MCS table in 3GPP Specification 38.214. For example, the predefined MCS table can be a 256QAM table or a 64QAM table, for example, the non-low SE64QAM tables shown in Table 5.1.3.1-2 or Table 5.1.3.1-1 of Specification 38.214, respectively. If DU174 does not include an MCS configuration in its DU configuration, UE102 and DU174 can apply the MCS table for unicast transmission to receive dynamic scheduling multicast transmissions from DU174. In some embodiments, DU174 may include a PDSCH configuration (e.g., PDSCH-Config) in its DU configuration that configures the MCS table for unicast transmission. In other embodiments, DU174 may send another DU configuration, including a PDSCH configuration, to UE102, as with events 516, 518, and 520. The aggregation factor is the number of repetitions for a dynamic scheduling multicast transmission(s). DU174 can transmit (i.e., multicast) the number of repetitions for a dynamic scheduling multicast transmission(s) according to the aggregation factor, and UE102 receives the repetitions based on the aggregation factor. If DU174 does not include an aggregation factor in its DU configuration, UE102 may apply the aggregation factor for a unicast transmission(s). In some embodiments, DU174 may include an aggregation factor in its DU configuration for a unicast transmission(s) to UE102. In other embodiments, DU174 may transmit another DU configuration to UE102 that includes an aggregation factor for a unicast transmission, as with events 516, 518, and 520.

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

[0087] In some embodiments, the configuration parameters may include at least one semi-persistent scheduling (SPS) multicast configuration for the UE102 to receive MBS data. Each of the at least one SPS multicast configuration may include at least one of the following parameters for SPS multicast transmission. • The scheduling radio network temporary identifier (G-CS-RNTI) of the group configuration used to activate or deactivate the SPS multicast radio resource. DU174 can activate the UE102's SPS multicast radio resource 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 resource, DU174 periodically transmits multicast transmissions on the SPS multicast radio resource according to the DCI. UE102 receives the DCI and the scrambled CRC on the PDCCH and verifies the scrambled CRC with the G-CS-RNTI. After UE102 verifies that the (scrambled) CRC is valid, UE102 activates (receives) the SPS multicast radio resource in accordance with the DCI and periodically receives multicast transmissions on the SPS multicast radio resource in accordance with the SPS multicast radio resource activation command (i.e., DCI) before UE102 deactivates the SPS multicast radio resource. In this case, the multicast transmission is the SPS multicast transmission used in the following description. In some embodiments, DU174 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 G-CS-RNTI, and transmitting the DCI and the scrambled CRC on the PDCCH. UE102 receives the DCI and the scrambled CRC on the PDCCH and verifies the scrambled CRC with G-CS-RNTI. After UE102 verifies that the (scrambled) CRC is enabled, UE102 deactivates the SPS multicast radio resource; that is, it stops receiving on the SPS multicast radio resource. Each SPS multicast transmit contains a specific MAC PDU that can contain an MBS data packet or a portion of an MBS data packet.In some embodiments, the SPS multicast radio resource activation command (i.e., DCI) includes configuration parameters that constitute the SPS multicast radio resource. In some embodiments, the configuration parameters may include at least one of the following parameters: • Allocation of frequency domain resources • Allocation of time domain resources • Mapping from virtual resource blocks (VRBs) to physical resource blocks (PRBs) • Modulation coding scheme (MCS) • New data indicator • Redundant version • HARQ process number • Downlink assignment index PUCCH Resource Indicator • Periodicity indicates the periodicity of SPS multicast radio resources. The number of HARQ processes indicates the number of HARQ processes used to communicate SPS multicast transmissions. DU174 uses a maximum of the number of HARQ processes to send SPS multicast transmissions, and UE102 uses a maximum of the number of HARQ processes to receive SPS multicast transmissions. The 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 UE102. If the configuration parameter does not include the HARQ codebook (ID), UE102 may use the HARQ codebook (ID) for dynamic scheduling multicast transmissions as described above. Alternatively, UE102 may use the HARQ codebook (ID) for unicast transmissions. In some embodiments, as described above, UE102 may receive the HARQ codebook (ID) from DU174 for unicast transmissions in a DU configuration. The HARQ process ID offset indicates the offset used when deriving the HARQ process ID for DU174 to send SPS multicast transmissions and for UE102 to receive SPS multicast transmissions. The PUCCH resource configuration for SPS multicast transmission indicates a HARQ resource on the PUCCH to which UE102 sends HARQ feedback (e.g., HARQ ACK and / or negative ACK (NACK)) for SPS multicast transmission. If the configuration parameters do not include a PUCCH resource configuration for SPS multicast transmission, UE102 and DU174 can communicate HARQ feedback as described above using the PUCCH resource configuration for dynamic scheduling multicast transmission. Alternatively, UE102 can use the PUCCH resource configuration for unicast transmission. In some embodiments, UE102 can use the PUCCH resource configuration for unicast transmission as described above. The HARQ NACK-only indication configures UE102 to send only HARQ negative ACKs (NACKs) to SPS multicast transmissions that UE102 receives from DU174 and from which UE102 cannot obtain the transport block. In some embodiments, UE102 cannot obtain the transport block because UE102 fails the cyclic redundancy check (CRC) of the transport block or because UE102 does not receive the dynamically scheduled multicast transmission. According to the indication, UE102 refrains from sending HARQ ACKs to DU174 for SPS multicast transmissions that UE102 successfully receives and from which UE102 obtains the transport block. If the configuration parameter does not include the indication, UE102 can send HARQ ACKs to DU174 for SPS multicast transmissions that UE102 successfully receives and from which UE102 obtains the transport block. The HARQ ACK / NACK indication configures UE102 to send a HARQ NACK for SPS multicast transmissions from which it cannot obtain the transport block, and to send a HARQ ACK for SPS multicast transmissions that UE102 successfully receives and from which it obtains the transport block. If the configuration parameter does not include the indication, UE102 refrains from sending a HARQ ACK to DU174 for SPS multicast transmissions that UE102 successfully receives and from which it obtains the transport block. In such cases, UE102 is only permitted to send a HARQ NACK to DU174 for SPS multicast transmissions from which it cannot obtain the transport block. The HARQ ACK indication configures UE102 to send a HARQ ACK for SPS multicast transmissions that it successfully receives and from which UE102 obtains the transport block. If the configuration parameter does not include the indication, UE102 refrains from sending a HARQ ACK to DU174 for SPS multicast transmissions from which UE102 successfully obtains the transport block. In such cases, UE102 is only permitted to send a HARQ NACK to DU174 for SPS multicast transmissions from which UE102 fails to obtain the transport block. In some embodiments, DU174 may include any one of the following: HARQ NACK indication, HARQ ACK / NACK indication, and HARQ ACK indication. The aggregation factor is the number of repetitions for an SPS multicast transmission. DU174 can transmit (i.e., multicast) the number of SPS multicast transmission repetitions according to the aggregation factor, and UE102 receives the repetitions based on the aggregation factor. If DU174 does not include an aggregation factor in its DU configuration, UE102 and DU174 can apply the aggregation factor for dynamic scheduling multicast transmission as described above in some embodiments. Alternatively, UE102 and DU174 can apply the aggregation factor for unicast transmission. In some embodiments, UE102 and DU174 can apply the aggregation factor for unicast transmission as described above. The MCS configuration refers to the MCS table used by DU174 to send SPS multicast transmissions and by UE102 to receive SPS multicast transmissions. For example, the MCS table can be an MCS table defined in 3GPP Specification 38.214 (e.g., the low SE64QAM 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 DU174 does not include an MCS configuration in its DU configuration, UE102 and DU174 can apply a predefined MCS table in 3GPP Specification 38.214. For example, the predefined MCS table can be a 256QAM table or a 64QAM table, for example, the non-low SE64QAM tables shown in Table 5.1.3.1-2 or Table 5.1.3.1-1 of Specification 38.214, respectively. If DU174 does not include an MCS configuration in its DU configuration, UE102 and DU174 can, in other embodiments, apply the MCS table for dynamic scheduling multicast transmission as described above to receive SPS multicast transmissions from DU174. Alternatively, UE102 and DU174 can apply the MCS table for unicast transmission to receive SPS multicast transmissions from DU174. In some embodiments, UE102 and DU174 can, as described above, apply the MCS table for unicast transmission to receive SPS multicast transmissions from DU174. In some embodiments, DU174 may include a PDSCH configuration (e.g., PDSCH-Config) in its DU configuration that configures the MCS table for unicast transmission. In other embodiments, DU174 may send another DU configuration including a PDSCH configuration to UE102, as with events 516, 518, and 520.

[0088] In some embodiments, CU172 may include an MBS session join response message in its RRC reconfiguration message. UE102 may include an MBS session join completion message in its RRC reconfiguration completion message. Alternatively, UE102 may send a UL RRC message containing the MBS session join completion message to CU172 via DU174. The UL RRC message can be a ULInformationTransfer message or any suitable RRC message that can include a UL NAS PDU. CU172 may include an MBS session join completion message in a second BS-CN message. Alternatively, CU172 may send a BS-CN message (e.g., an UPLINK NAS TRANSPORT message) containing the MBS session join completion message to CN110.

[0089] In other embodiments, CU172 sends a DL RRC message to UE102 that includes an MBS session join response message. The DL RRC message can be any suitable RRC message that includes a DLInformationTransfer message, another RRC reconfiguration message, or a DL NAS PDU. UE102 may send a UL RRC message to CU172 via DU174 that includes an MBS session join completion message. The UL RRC message can be any suitable RRC message that includes a ULInformationTransfer message, another RRC reconfiguration completion message, or a UL NAS PDU.

[0090] Continuing to refer to Figure 5A, UE103 can perform the MBS session join procedure (530) similar to the procedure 502 described above. UE103 can perform the PDU session establishment procedure with CN110 via base station 104 as described above. In the PDU session establishment procedure, UE103 can communicate the PDU session ID with CN110. UE103 can join a different MBS session from UE102 by sending an MBS session join request and specifying a different MBS session ID (e.g., a second MBS session ID).

[0091] CU172 includes additional transport layer configurations for additional MBS sessions to configure additional common DL tunnels in the MBS resource setup and UE-specific MBS session configuration procedures, as well as in the first or second BS-CN message. Each transport layer configuration can configure a specific common DL tunnel for the common DL tunnels and associate it with a specific MBS session for the additional MBS sessions. Transport layer configurations can differ 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, CU172 and CN110 perform the MBS session resource setup procedure (587) for the second MBS session, similar to the MBS session resource setup procedure (586) for the first MBS session, to establish the second common CN-BS DL tunnel and the second common CU-DU DL tunnel. UE103, CU172, and CN110 perform the UE-specific MBS session configuration procedure (589) for the second MBS session, similar to the UE-specific MBS session configuration procedure (590) for the first MBS session. In procedure 587, CU172 may obtain a second set of configuration parameters from DU174 and send an RRC reconfiguration message to UE103 containing the second set of configuration parameters and the second MRB configuration(s). Exemplary embodiments of the second set of configuration parameters and the second MRB configuration(s) are similar to those of the first set of configuration parameters and the first MRB configuration(s), respectively, as described above.

[0093] In the 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 those 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] Next, CN110 can transmit the MBS data for the first MBS session to CU172 via its respective common CN-BS DL tunnel (532) and transmit the MBS data for the second MBS session (538). Then, CU172 transmits the MBS data for the first MBS session to DU174 via its respective common CU-DU DL tunnel (534) and transmits the MBS data for the second MBS session (540). DU174, similar to event 528, transmits the MBS data for the second MBS session to UE103 via one or more logical channels and / or MRBs (536) (e.g., multicast or unicast) and the MBS data for the first MBS session to UE102 via one or more logical channels and / or MRBs (542) (e.g., multicast or unicast). UE102 receives (542) MBS data for the first MBS session via one or more logical channels, similar to event 528, and UE103 receives (536) MBS data for the second MBS session via one or more logical channels, which may be different from the logical channels of the first MBS session. In some embodiments, DU174 may transmit (536) MBS data or MAC PDU(s) containing MBS data to UE103 via one or more multicast transmissions (e.g., dynamic or SPS multicast transmission(s)) as described above. In such cases, UE103 may receive (536) MBS data or MAC PDU(s) from DU174 via one or more multicast transmissions as described above. In some embodiments, DU174 may transmit (542) MBS data or MAC PDU(s) containing MBS data to UE102 via one or more multicast transmissions (e.g., dynamic or SPS multicast transmission(s)) as described above. In such a case, UE102 can receive (542) MBS data or MAC PDU(s) from DU174 via one or more multicast transmissions, as described above.

[0095] Figure 5B shows an exemplary scenario 500B similar to scenario 500A shown in Figure 5A. However, in exemplary scenario 500B, UE103 participates in both the second MBS session and the first MBS session (i.e., the same MBS session joined by UE102 in step 502) for the same period of time. More specifically, UE103 can perform the MBS session join procedure for the second MBS session (530) and can perform the MBS session join procedure for the first MBS session (531). Then, base station 104 and CN110 perform the MBS session resource setup procedure for the second MBS session (587). UE103, base station 104, and CN110 perform the UE-specific MBS session configuration procedure for the second MBS session (589). Furthermore, UE103, base station 104, and CN perform UE-specific MBS session configuration procedures for the first MBS session (591), similar to event 590.

[0096] UE103 can join the same MBS session as UE102 by specifying the same MBS session ID (e.g., the first MBS session ID) in its MBS session join request. In exemplary scenario 500B, UE103 joins the first MBS session after base station 104 begins sending MBS data packets for the first MBS session to UE102 (528). CN110 sends a CN-BS message containing the MBS session ID and / or PDU session ID to CU172 to indicate that UE103 should begin receiving MBS data for the first MBS session corresponding to the first MBS session ID.

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

[0098] In any case, CN110 can then transmit the MBS data for the first MBS session and the MBS data for the second MBS session to CU172 (532, 538). CU172 then transmits the MBS data for the first MBS session and the MBS data for the second MBS session to DU174 (534, 540). DU174 transmits the MBS data for the second MBS session to UE103 via one or more logical channels and / or MRBs (536) (e.g., multicast or unicast), and transmits the MBS data for the first MBS session to UE103 via one or more logical channels and / or MRBs (546) (e.g., multicast or unicast). UE103 can receive MBS data for a first MBS session (536) and receive MBS data for a second MBS session (546) during the same period, so that UE103 can receive MBS data for two sets of MBS data for different MBS sessions at the same time. Furthermore, DU174 transmits (542) the MBS data for the first MBS session to UE102 via one or more logical channels and / or MRBs (multicast or unicast). In some embodiments, DU174 transmits (542 and 546) the MBS data for the first MBS session to UE102 and 103 respectively via multicast. In other embodiments, DU174 transmits (542 and 546) the MBS data for the first MBS session separately to UE102 and 103 via unicast.

[0099] In some embodiments, CU172 sends two instances of the MBS data for the first MBS session to DU174 (544). The DU then sends the first instance of the MBS data for the first MBS session to UE102 (542) and the second instance of the MBS data for the first MBS session to UE103 (546). In other embodiments, DU174 receives a single instance of the MBS data for the first MBS session from CU172 and sends the MBS data for the first MBS session to each of the UEs that participated in the first MBS session.

[0100] Next, with reference to Figures 6A-8B, several exemplary methods that can 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 can each cause UEs and RAN nodes (i.e., base stations) implementing the described methods to follow different paths shown in the figures under different circumstances (e.g., at different times). Each of these methods can be implemented as a set of instructions stored in a non-temporary computer-readable medium and executable by one or more processors, and / or by processing hardware.

[0101] Generally speaking, these methods ensure that the UE reliably receives MBS data packets(s) via the HARQ process. In the HARQ process, a RAN node can send an MBS data packet to the UE, and in response, the UE can send HARQ feedback to the RAN node indicating that the MBS data packet was not successfully received (e.g., a HARQ negative acknowledgment (NACK)) or that the MBS data packet was successfully received (e.g., an HARQ acknowledgment (ACK)). The RAN node can then either retransmit the MBS data packet (if the HARQ feedback is a HARQ NACK) or send a new MBS data packet (if the HARQ feedback is a HARQ ACK).

[0102] In some scenarios, during the HARQ process, a RAN node can send MBS data packets to a UE via multicast (i.e., MBS multicast transmission, or simply "multicast transmission"), and after receiving HARQ feedback from the UE, it can retransmit the MBS data packets or send new MBS data packets via unicast (i.e., MBS unicast transmission, or simply "unicast transmission"). Thus, when both multicast and unicast transmissions are used to send to the UE in the same HARQ process (i.e., each DCI that sends to the UE and prepares the UE to receive multicast and unicast transmissions contains the same HARQ process number), the HARQ process can be considered "shared" or "mixed". However, in some cases, the UE may not support PTP retransmission and therefore cannot receive a unicast transmission as a unicast retransmission. In some embodiments, the RAN node can consider the UE's ability to receive PTP retransmissions.

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

[0104] Looking at Figures 6A to 6E, these figures generally illustrate the various ways in which a UE attempts to receive a first transmission, including MBS data packets and a subsequent second transmission, according to the HARQ process, and further determines whether the second transmission is a new transmission or a retransmission of the first transmission. Figures 6A to 6C show a UE making a decision considering whether the UE supports or has enabled PTP retransmission. Figure 6D shows a UE making a decision by comparing the transport block sizes of the first and second transmissions. Figure 6E shows a UE making a decision by determining which RNTI was used to receive the second transmission.

[0105] Referring first to Figure 6A, a UE (e.g., UE102, UE103) can implement Method 600A to receive MBS data packets(s) from a RAN (e.g., DU174, CU172, or base station 104) via multicast and unicast in a shared HARQ process.

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

[0107] In block 604, in preparation for receiving MBS data packets(s) using the HARQ process, the UE receives from the RAN node a first DCI (i.e., the CRC of the first DCI) having the 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 identifies whether the first DCI is for a new transmission (i.e., a new HARQ transmission not previously sent to the UE) carrying MBS data packets(s) or for a retransmission (i.e., a HARQ retransmission) carrying previous undelivered MBS data packets(s).

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

[0109] In block 608, the UE receives and processes the multicast transmission according to the decisions made in the first DCI and block 606 (see, for example, events 528, 536, and 542).

[0110] In 610, the UE sends 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 MBS data packets(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 (and thus indicating the same HARQ process) and a second NDI value. Similar to the first NDI value, the second NDI value identifies whether the second DCI is for a new transmission (carrying new MBS data packets(s)) or a retransmission (carrying previous undelivered MBS data packets(s)). In some embodiments, the first and second NDI values ​​may be the same or different.

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

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

[0114] Next, in block 616, the UE receives the unicast transmission in accordance with the decision made in the second DCI and 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 embodiments, the UE assigns a HARQ process associated with a first HARQ process number and receives multicast and unicast transmissions. In some embodiments, the UE sends a first HARQ feedback according to a first configuration (e.g., a PUCCH configuration or a HARQ ACK / NACK configuration) and a second HARQ feedback according to a second configuration (e.g., a PUCCH configuration or a HARQ ACK / NACK configuration). In other embodiments, the UE sends both the first and second HARQ feedback according to a configuration (e.g., a PUCCH configuration or a HARQ ACK / NACK configuration).

[0117] In some embodiments, the first DCI may include a field indicating a specific uplink carrier or cell for the first HARQ feedback, for example, according to a first configuration. The UE transmits the first HARQ feedback on the specific carrier or cell according to the indication in the field. In other embodiments, the first DCI may not include a field indicating a specific uplink carrier or cell for the first HARQ feedback. In such cases, 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 a first configuration. In some embodiments, the second DCI may include a field indicating a specific uplink carrier or cell for the second HARQ feedback, for example, according to a second configuration. In such cases, the UE transmits the second HARQ feedback on a specific carrier or cell. In other embodiments, the second DCI may not include a field indicating a specific uplink carrier or cell for the second HARQ feedback. In such a case, the UE transmits a second HARQ feedback on a predetermined uplink carrier (e.g., primary component carrier) or a predetermined cell (e.g., primary cell), for example, according to a second configuration.

[0118] If the UE determines that the first NDI value is toggled by comparing it to the NDI value of a DCI received before the first DCI addressing the HARQ process, the UE determines in block 606 that the multicast transmission is a new transmission. 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 obtains the transport block by decoding the data of the multicast transmission (i.e., the channel coding bits). In some embodiments, in response to determining that the multicast transmission is a new transmission, the UE flushes the soft buffer associated with the HARQ process to receive the multicast transmission. If the UE determines that the first NDI value is not toggled by comparing it to the above NDI value, the UE determines in block 606 that the multicast transmission is a retransmission. In response to determining that the multicast transmission is a retransmission, the UE combines the data of the multicast transmission (i.e., the channel coding bits) with the data currently in the soft buffer (i.e., the channel coding bits), decodes the combined data, and obtains a transport block. If the UE successfully retrieves the MAC PDU from the transport block, or verifies that the transport block's CRC is valid, the UE provides the first HARQ feedback as a HARQ ACK. If the UE is unable to retrieve the MAC PDU from the transport block, or verifies that the transport block's CRC is invalid, the UE provides the first HARQ feedback as a HARQ NACK.

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

[0120] In some embodiments of block 602, the UE can send a first RRC message (e.g., a UECapabilityInformation message) containing UE capabilities to a RAN node. In some embodiments, the UE can send the first RRC message to a RAN node in response to receiving a second RRC message (e.g., a UECapabilityEnquiry message) from the RAN node. In some embodiments, the UE capability can be a UE-NR-Capability IE. In one embodiment, the UE capability may include an indication that PTP retransmission of the MBS is not supported. In another embodiment, the UE capability may omit an indication that PTP retransmission of the MBS is supported. In some embodiments, the UE capability 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 transmissions including HARQ new transmissions and HARQ retransmissions scheduled by G-RNTI). More specifically, the UE capability includes an MBS PTM indication indicating support for PTM transmission of the MBS. In embodiments where the UE supports PTM retransmission, the UE may support PTM retransmission by default without explicitly indicating that the UE capability supports PTM retransmission. Alternatively, the UE capability may include an indication that the UE supports PTM retransmission.

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

[0122] Figure 6B shows an exemplary Method 600B similar to Method 600A, except that the UE in Method 600B supports PTP retransmission. Thus, in Method 600B, the UE in block 603 optionally transmits UE capability indicating support for PTP retransmission to the RAN node. In other embodiments, as described above with respect to Figure 6A, the RAN node receives the UE capability indirectly from the UE via a CN (e.g., CN110) that is communicably coupled to the RAN node. Also, as described above with respect to Figure 6A, the UE capability can indicate that the UE supports MBS PTM transmission. In some embodiments, a UE that supports MBS PTM transmission is instructed to support PTP retransmission. In such cases, the UE can indirectly indicate support for PTP retransmission in its UE capability by including an explicit MBS PTM indication in the UE capability. In such cases, the MBS PTM indication indicates that the UE supports both PTM transmission and PTP retransmission.

[0123] Method 600B proceeds to blocks 604, 606, 608, 610, and 612, similar to Method 600A in Figure 6A. In an embodiment in which a RAN node receives a UE capability from the UE (e.g., in block 603) or from another entity (e.g., CN110) indicating that the UE supports PTP retransmission, the RAN node decides that the UE supports PTP retransmission and accordingly sends a DCI (e.g., a second DCI in block 612) to schedule a HARQ retransmission containing the UE's MBS data.

[0124] In block 614 of Figure 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, whereas in block 615 of Figure 6B, the UE determines whether the unicast transmission is a new transmission or a retransmission based on the second NDI value.

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

[0126] If the UE determines that the second NDI value does not toggle compared to the first NDI value, the UE determines in block 615 that the unicast transmission is a retransmission. In response to the determination that the unicast transmission is a retransmission, the UE combines the data (i.e., the channel coding bits of the unicast transmission) with the data (i.e., the channel coding bits) currently in the soft buffer (e.g., containing the channel coding bits of the multicast transmission), decodes the combined data, and obtains the transport block.

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

[0128] Figure 6C shows an exemplary Method 600C, 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, like methods 600A and 600B, begins in block 604 and proceeds through blocks 606, 608, 610, and 612. In block 613, depending on the reception of the second DCI, the UE determines whether MBS PTP retransmission is enabled. If the UE determines that PTP retransmission is not enabled, method 600C proceeds to block 614 as shown above in Figure 6A. Otherwise (i.e., the UE determines that PTP retransmission is enabled), method 600C proceeds to block 615 as shown above in Figure 6B.

[0130] In some embodiments, if the UE supports PTP retransmission, the UE enables PTP retransmission; 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 Identification Module (USIM). If the flag indicates that PTP retransmission is enabled, the UE indicates that the UE supports PTP retransmission in its capabilities. If the flag indicates that PTP retransmission is disabled, the UE indicates that the UE does not support PTP retransmission in its capabilities. In some embodiments, if a RAN node configures the UE to enable PTP retransmission, the UE enables 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 indicating that the UE supports PTP retransmission. In other embodiments, if the RAN node does not configure the UE to enable PTP retransmission, the UE disables PTP retransmission. In some embodiments, a RAN node refrains from configuring the UE to enable PTP retransmission if the RAN node receives a UE capability indicating that the UE does not support PTP retransmission. In other embodiments, the RAN refrains from configuring the UE to enable PTP retransmission because the RAN node does not support PTP retransmission.

[0131] Figure 6D shows an exemplary method 600D similar to 600B, except that the UE in method 600B determines whether a unicast transmission is a new transmission or a retransmission of a previous undelivered multicast transmission according to a second NDI value, whereas the UE in method 600D makes the decision 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 in block 603 and proceeds to blocks 604, 606, 608, and 610. Subsequently, in block 612, the UE of Method 600B receives a second DCI containing a first HARQ process number and a second NDI value, whereas in block 622, the UE of Method 600D receives a second DCI containing a first HARQ process number and the same first NDI value contained in the first DCI of block 604.

[0133] In block 623, the UE compares the transport block indicated by the first DCI in block 604 with the transport block indicated by the second DCI in 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 this 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] Figure 6E shows an exemplary Method 600E similar to Method 600A. The difference is that in Method 600A, the UE uses C-RNTI to receive and determine that a unicast transmission is a new transmission, whereas in Method 600E, the UE determines which RNTI (e.g., C-RNTI or G-RNTI) the UE used to determine whether the HARQ transmission from the RAN node was a new transmission or a retransmission.

[0135] Method 600E, like Method 600A, optionally begins in block 602 and proceeds to blocks 604, 606, 608, and 610. In block 611, in preparation for receiving subsequent HARQ transmissions from the RAN node, the UE receives a second DCI with a scrambled CRC, the second DCI containing the first HARQ process number and the 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, in block 633, the UE verifies that the scrambled CRC in block 611 is valid using C-RNTI, then in block 634, the UE determines that the subsequent transmission is a new transmission (i.e., a new unicast transmission), regardless of the second NDI value. If, in block 633, the UE verifies that the scrambled CRC in block 611 is valid using G-RNTI, then in block 635, the UE determines, according to the second NDI value, whether the subsequent transmission is a new transmission (i.e., a new multicast transmission) or a retransmission (i.e., a multicast retransmission).

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

[0138] Looking at Figures 7A-7C and 8A-8B, these figures generally illustrate the various ways in which a RAN node, following the HARQ process, decides whether to send a first transmission containing MBS data packets and a subsequent second transmission via multicast or unicast. Figures 7A-7B show a RAN node making a decision considering whether the UE supports or has enabled PTP retransmission. Figure 7C shows a RAN node making a decision considering whether the first transmission was sent via multicast or unicast. Figure 8A shows a RAN node making a decision considering HARQ feedback for the first transmission received from the UE. Figure 8B shows a RAN node making a decision considering the network bandwidth conditions associated with the first transmission.

[0139] Referring first to Figure 7A, a RAN node (e.g., base station 104 or DU174) can implement method 700A to send MBS data packets (or more) to UEs (e.g., UE102, UE103) via multicast and unicast. Generally, in response to receiving a HARQ NACK from a UE, the RAN node in Figure 7A decides how to send subsequent HARQ transmissions (e.g., via multicast or unicast) based on whether the UE supports PTP retransmission.

[0140] Method 700A begins in block 702, in which the RAN node sends a HARQ transmission of MBS data via multicast (see, for example, events 528, 536, and 542). In some embodiments, the HARQ transmission can be a new HARQ transmission or a HARQ retransmission.

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

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

[0143] In some embodiments, in block 702, the RAN node sends a HARQ transmission over multicast using the HARQ process. In such cases, the RAN node can configure the HARQ process for multicast transmission. The RAN node then decides to use the HARQ process for a unicast transmission to the UE, for example, because the MBS is inactive or the UE has stopped receiving from the MBS. In response to this decision, the RAN node decides to reconfigure the HARQ process for unicast transmission. In response to reconfiguring the HARQ process for unicast transmission, the RAN node toggles the NDI of the HARQ process. After reconfiguring the HARQ process, the RAN node decides to send a unicast transmission to the UE using the HARQ process. In response to this decision, the RAN node sends the DCI to the UE, which includes the toggled NDI and the HARQ process number of the HARQ process. The RAN node generates a CRC for the DCI, scrambles the CRC at the UE's C-RNTI, and sends the DCI and the scrambled CRC to the UE at the PDCCH.

[0144] Figure 7B shows an exemplary method 700B similar to method 700A, except that the RAN node in Figure 7B determines how to send subsequent HARQ transmissions based on whether the UE has enabled PTP retransmission. For example, if the RAN node sends an RRC reconfiguration message to the UE to configure or enable PTP retransmission, as described above with respect to Figure 6C, the RAN node determines in block 707 that PTP retransmission is enabled for the UE and proceeds to block 708. In 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 shows an exemplary Method 700C similar to Method 700A or Method 700B, except that the RAN node in Figure 7C omits considerations related to whether the UE supports or enables PTP retransmission. Instead, the RAN node in Figure 7C determines how to transmit subsequent HARQ transmissions (e.g., via multicast or unicast) based on how the previous HARQ transmission was transmitted (e.g., via multicast or unicast).

[0146] In block 703, the RAN node sends the HARQ transmission. Therefore, in block 705, the RAN node decides whether the HARQ transmission is sent via unicast or multicast.

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

[0148] Referring first to Figure 8A, a RAN node (e.g., base station 104 or DU174) can implement method 800A, which involves sending MBS data packets (or more) to UEs (e.g., UE102, UE103) via multicast and unicast.

[0149] Method 800A begins in block 802, in which the RAN node sends to the UE in PDCCH the first DCI and the CRC scrambled by G-RNTI (i.e., the CRC of the DCI) to schedule the UE's first (new) multicast transmission of the first MBS data packet. The first DCI contains the first HARQ process number, the first NDI value, and the first unreserved MCS value (e.g., the first I MCS Includes the value.

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

[0151] If the RAN node receives a HARQ NACK for the first multicast transmission in block 806, in block 808 the RAN node sends a CRC scrambled by the second DCI and the UE's C-RNTI in the PDCCH to the UE to schedule the UE's first unicast transmission (i.e., retransmission of the first MBS data packet). The second DCI includes the first HARQ process number, the first NDI value, and the reserved MCS value. In block 810, the RAN node then transmits the first unicast transmission according to the second DCI. In some embodiments, though not illustrated, the RAN node receives a HARQ NACK from the UE for the first unicast transmission. Accordingly, the RAN node may send a CRC scrambled by the fourth DCI and the UE's C-RNTI in the PDCCH to schedule the UE's second unicast transmission (i.e., retransmission of the first MBS data packet). The fourth DCI includes the first HARQ process number, the first NDI value, and the 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 sends 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 in block 806, in block 812 the RAN node sends a third DCI (i.e., the CRC of the third DCI) with a CRC scrambled by G-RNTI in the PDCCH to the UE to schedule for the second multicast transmission (i.e., a new transmission of the second MBS data packet). The second DCI has the first HARQ process number, the second NDI value, and an unreserved MCS value (e.g., the second I MCS (Value) is included. In block 814, the RAN node then sends a second multicast transmission according to the third DCI.

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

[0154] Figure 8B shows an exemplary method 800B similar to method 800A, except that the RAN node in Figure 8B determines whether to send a first unicast transmission or a second multicast transmission based on network bandwidth conditions related to the first multicast transmission.

[0155] Method 800B, like Method 800A, begins in block 802 and proceeds to block 804.

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

[0157] In block 807, the RAN node determines the network bandwidth requirements 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 as the UE's Active DL BWP (e.g., the same bandwidth and location of configuration resources such as the PRB). If the RAN node determines in block 807 that the CFR and the Active DL BWP have the same configuration, in block 813, the RAN node transmits a second multicast transmission as a multicast retransmission. This is in contrast to the RAN node in Method 800A, where in block 812, the RAN node transmits the second multicast transmission as a new transmission. The RAN node then proceeds to block 814, as in Method 800A. In some embodiments or scenarios, the RAN node's spectrum is limited, so the RAN node configures the CFR and Active DL BWP to share exactly the same spectrum. In such cases, the RAN node can dynamically allocate radio resources for MBS and unicast services. However, this also increases the complexity of managing radio resources for MBS and unicast services.

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

[0159] Referring here to Figure 9, an exemplary method 900 can be implemented on a UE (e.g., UE102 or UE103) to receive an MBS from a base station (e.g., base station 104, DU174).

[0160] In block 902, the UE attempts to receive a first transmission from the base station via multicast, which contains MBS data packets associated with the MBS (e.g., in events or blocks 528, 536, 542, 604, 606, and 608).

[0161] In block 904, the UE sends an indication to the base station whether it has successfully received the first transmission, in accordance with a mechanism for automatic retransmission of undelivered packets (for example, in block 610).

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

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

[0164] Referring here to Figure 10, the exemplary method 1000 can be implemented in a base station (e.g., base station 104, DU174) to provide MBS to UEs (e.g., UE102, UE103).

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

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

[0167] In block 1006, the base station then decides, according to the mechanism, whether to send a second transmission via multicast or unicast (for example, in events 528, 536, 542, 708, 710, 810, and 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, "configuration" can be replaced with "multiconfiguration" or configuration parameter. 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] User devices capable of implementing the technology of this disclosure (e.g., UE102A, 102B, or UE103) can be any suitable wireless communication device such as a smartphone, tablet computer, laptop computer, mobile game console, point-of-sale (POS) terminal, health management device, drone, camera, media streaming dongle or other personal media device, smartwatch, wireless hotspot, femtocell, or wearable device such as a broadband router. Furthermore, in some cases, the user device may be embedded in an electronic system such as a vehicle head unit or advanced driver-assistance system (ADAS). Moreover, the user device may 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 described in this disclosure include logic, or several components or modules. A module may be a software module (e.g., code stored in a non-temporary machine-readable medium) or a hardware module. A hardware module is a tangible unit capable of performing a certain operation and may be configured or arranged in a certain manner. For example, a hardware module may 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 application-specific integrated circuit (ASIC)) to perform a certain operation. A hardware module may 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 a certain operation. The decision to implement a hardware module in dedicated, permanently configured circuitry or in temporarily configured circuitry (e.g., configured by software) may require consideration of cost and time.

[0172] When implemented in software, the technique may be provided as part of an operating system, a library used by multiple applications, or a specific software application. The software can run on one or more general-purpose processors or one or more special-purpose processors.

[0173] A person skilled in the art will understand, upon reading this disclosure, further alternative structural and functional designs for performing the HARQ process for transmitting MBS data through the principles disclosed herein. Therefore, while specific embodiments and applications are shown and described, it should be understood that the disclosed embodiments are not limited to the exact configurations and components disclosed herein. Various modifications, changes, and variations obvious to a person 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 multicast and / or broadcast services (MBS) on user equipment (UE), Attempting to receive a first transmission, including MBS data packets associated with the MBS, via multicast from the UE and the base station, The UE transmits an indication to the base station, in accordance with a mechanism for automatic retransmission of undelivered packets, indicating whether the UE has successfully received the first transmission. In response to the aforementioned transmission, an attempt to receive a second transmission from the base station via the UE and unicast, in accordance with the mechanism, including an attempt to receive downlink control information (DCI) including a new data indicator (NDI) value, Regardless of the UE and the NDI value, it is determined that the second transmission is a new transmission. The method, including the method described above.

2. The method according to 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. The method of claim 2, further comprising transmitting an indication to the UE and to the base station that the UE does not support or has disabled PTP retransmission.

4. The method according to claim 1, wherein determining that the second transmission is the new transmission, regardless of the NDI value, includes 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 the second NDI value. Attempting to receive the first transmission includes receiving a first DCI which 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 the second NDI value. Attempting to receive the first transmission includes receiving a first DCI which 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 according to any one of claims 5 to 6, wherein the first DCI and the second DCI include the same process number.

8. The method according to any one of claims 1 to 7, wherein attempting to receive the first transmission includes receiving a first scrambled periodic redundancy check (CRC) and determining that a group radio network temporary identifier (G-RNTI) is to be used to verify the first scrambled CRC.

9. The method according to any one of claims 1 to 8, wherein attempting to receive the second transmission includes receiving a second scrambled cyclic redundancy check (CRC) and determining that a cell RNTI (C-RNTI) is to be 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 is An attempt to receive a third transmission, including a second MBS data packet associated with a second MBS, via multicast from the UE and the base station, including an attempt to receive a third scrambled CRC and a third DCI including a third NDI value. The UE transmits an indication to the base station, in accordance with a mechanism for automatic retransmission of undelivered packets, that the UE has successfully received the third transmission. In response to the UE transmitting an indication of whether it has successfully received the third transmission, an attempt to receive a fourth transmission by the UE and via unicast from the base station, in accordance with the mechanism, including an attempt to receive a fourth DCI including a fourth scrambled CRC and a fourth NDI value, Based on the UE and the third NDI value and the fourth NDI value, it is determined whether the fourth transmission is a second new transmission or a retransmission. The method according to any one of claims 1 to 9, further comprising:

11. The method of claim 10, wherein determining whether the fourth transmission is the second new transmission or the retransmission includes 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. The method of claim 10, wherein determining whether the fourth transmission is the second new transmission or the retransmission includes determining that the fourth transmission is the retransmission when the third NDI value and the fourth NDI value are set to the same NDI value.

13. The method according to any one of claims 10 to 12, wherein determining whether the fourth transmission is the second new transmission or the retransmission includes determining whether the UE supports or enables point-to-point (PTP) retransmission.

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

15. The method according to any one of claims 10 to 12, wherein determining whether the fourth transmission is the second new transmission or the retransmission includes determining that the third transmission and the fourth transmission have the same transport block size.

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

17. The method according to any one of claims 10 to 16, 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. The method according to any one of claims 10 to 17, wherein attempting to receive the fourth transmission is to determine that each C-RNTI is to be used to verify the fourth scrambled CRC.

19. The method according to any one of claims 1 to 18, wherein the mechanism for automatically retransmitting undelivered packets includes hybrid automatic retransmission request (HARQ) technology.

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

Images