Managing data transmission using different radio resources

Abstract

Methods are provided for managing packet transmissions that may be implemented in a node of a radio access network. One such method includes receiving a packet from an upstream node via a downlink tunnel, selecting a semi-persistent scheduling radio resource for transmitting the packet to one or more UEs based on one or more properties of the downlink tunnel, and transmitting the packet to one or more UEs over a radio interface using the semi-persistent scheduling radio resource. Another method includes receiving a packet associated with a Quality of Service (QoS) flow from an upstream node, selecting a semi-persistent scheduling radio resource for transmitting the packet to one or more UEs based on the QoS flow, and transmitting the packet to one or more UEs over a radio interface using the semi-persistent scheduling radio resource.

Description

[Technical Field]

[0001] The present disclosure relates to wireless communications, and more particularly to enabling data transmission using different radio resources, for example for unicast services and multicast and / or broadcast services. [Background technology]

[0002] The background discussion provided herein is intended to provide an overall context for the present disclosure. To the extent described in this Background section, the work of the inventors named herein, as well as aspects of the description that may not qualify as prior art at the time of filing, are not expressly or implicitly admitted as prior art to the present disclosure.

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

[0004] In some scenarios, a UE can simultaneously utilize resources of multiple nodes (e.g., base stations or components of a distributed or separated base station) of a radio access network (RAN) interconnected by a backhaul. When these network nodes support different radio access technologies (RATs), this type of connection is called multi-radio dual connectivity (MR-DC). When operating in MR-DC, cells associated with a base station operating as a master node (MN) define a master cell group (MCG), and cells associated with a base station operating as a secondary node (SN) define a secondary cell group (SCG). The MCG covers a primary cell (PCell) and zero, one, or more secondary cells (SCells), and the SCG covers a primary secondary cell (PSCell) and zero, one, or more SCells. The UE communicates with the MN (via the MCG) and with the SN (via the SCG). In other scenarios, the UE utilizes resources of one base station at a time, in single connectivity (SC). A UE in an SC only communicates with the MN via the MCG. The base station and / or the UE decide when the UE should establish a radio connection with another base station. For example, the base station may decide to hand over the UE to another base station and initiate a handover procedure. In other scenarios, the UE may simultaneously utilize resources of another RAN node (e.g., a base station or a component of a distributed or separated base station) interconnected by a backhaul.

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

[0006] In both SC and DC operation, the UE can perform handover procedures to switch from one cell to another. These procedures involve messaging (e.g., RRC signaling and preparation) between the RAN node and the UE. Depending on the scenario, the UE may hand over from a cell of a serving base station to a target cell of a target base station, or from a cell of a first distributed unit (DU) of the serving base station to a target cell of a second distributed unit (DU) of the same base station. In DC scenarios, the UE can perform PSCell exchange procedures to exchange PSCells. These procedures involve messaging (e.g., RRC signaling and preparation) between the RAN node and the UE. Depending on the scenario, the UE may perform a PSCell change from a PSCell of a serving SN to a target PSCell of a target SN, or from a PSCell of a source DU of a base station to a PSCell of a target DU of the same base station. Additionally, the UE may perform a handover or PSCell change within a cell for synchronized reconfiguration.

[0007] Base stations operating in accordance with fifth-generation (5G) New Radio (NR) requirements support much wider bandwidths than fourth-generation (4G) base stations. Accordingly, the 3rd Generation Partnership Project (3GPP) proposed in Release 15 that UEs should support a 100 MHz bandwidth in Frequency Range 1 (FR1) and a 400 MHz bandwidth in Frequency Range 2 (FR2). Because the bandwidth of a typical carrier in 5G NR is relatively wide, 3GPP proposed in Release 17 that 5G NR base stations should be capable of providing multicast and / or broadcast services (MBS) to UEs. MBS can be useful in many content distribution applications, such as transparent IPv4 / IPv6 multicast distribution, IPTV, wireless software distribution, group communications, Internet of Things (IoT) applications, V2X applications, and public safety emergency messages. Summary of the Invention [Problem to be solved by the invention]

[0008] 5G NR provides both point-to-point (PTP) and point-to-multipoint (PTM) delivery methods for transmitting MBS packet flows over the air interface. In PTP communication, a RAN node transmits different copies of each MBS data packet to different UEs over the air interface. In PTM communication, a RAN node transmits a single copy of each MBS data packet to multiple UEs over the air interface. However, in some scenarios, it is unclear how a base station receives MBS data packets from the core network and how the base station transmits each MBS data packet to one or more UEs. [Means for solving the problem]

[0009] Using the techniques of the present disclosure, a RAN node (e.g., an integrated base station or a distributed unit of a distributed base station) manages transmission of MBS and / or other packets to one or more UEs (e.g., multiple UEs that have participated in a particular MBS session). In one aspect, when the RAN node receives a packet via a downlink tunnel (e.g., from a core network or from a central unit of a distributed base station, etc.), the RAN node selects either a semi-persistent scheduling (SPS) radio resource or a dynamic scheduling radio resource based on one or more properties of the downlink tunnel (e.g., one or more transport layer configuration parameters, such as an IP address and / or a tunnel endpoint identifier (TEID) of the packet). For example, the RAN node may select an SPS multicast radio resource if the downlink tunnel through which the packet was received is a common (i.e., shared, not UE-specific) DL tunnel configured at the RAN node for communication of MBS data packets. Conversely, the RAN node may select a dynamic scheduling (unicast or multicast) radio resource or an SPS unicast radio resource, for example, if the tunnel is a different DL tunnel (e.g., not a common tunnel and / or not a tunnel for MBS data packets) or if the packet is received over a control plane interface. The RAN node then transmits the packet to one or more UEs according to the selected radio resource (e.g., by sending a PDU to the UEs, where the PDU includes the packet and the logical channel identification information selected by the RAN node for the packet).

[0010] In another aspect, when a RAN node receives a packet associated with a particular Quality of Service (QoS) flow (e.g., via a downlink tunnel), the RAN node selects either a semi-persistent scheduling (SPS) radio resource or a dynamic scheduling radio resource based on the particular QoS flow. For example, the RAN node may select an SPS multicast radio resource if the packet is associated with a first QoS flow, but may select a dynamic scheduling (unicast or multicast) radio resource or an SPS unicast radio resource if the packet is associated with a different QoS flow or if the packet is otherwise received over a control plane interface. The RAN node then transmits the packet to one or more UEs according to the selected radio resource (e.g., by transmitting a PDU to the UE, where the PDU includes the packet and the logical channel identification information selected by the RAN node for the packet).

[0011] An exemplary embodiment of these techniques is a method for managing packet transmission, the method being implemented in a node of a RAN, that includes receiving, by processing hardware, a packet from an upstream node via a downlink (DL) tunnel, selecting, by the processing hardware, a semi-persistent scheduling radio resource for transmitting the packet to one or more UEs based on one or more properties of the DL tunnel, and transmitting, by the processing hardware, the packet over the air interface to the one or more UEs using the semi-persistent scheduling radio resource.

[0012] Another exemplary embodiment of these techniques is another method for managing packet transmission, the method being implemented by a node of a RAN, the method including receiving, by processing hardware from an upstream node, packets associated with a Quality of Service (QoS) flow, selecting, by the processing hardware based on the QoS flow, semi-persistent scheduling radio resources for transmitting the packets to one or more UEs, and transmitting, by the processing hardware, the packets over an air interface to the one or more UEs using the semi-persistent scheduling radio resources. [Brief explanation of the drawings]

[0013] [Figure 1A] FIG. 1 is a block diagram of an example system in which techniques of the present disclosure for managing data transmission using different radio resources may be implemented. [Figure 1B] 1B is a block diagram of an exemplary base station in which a centralized unit (CU) and a distributed unit (DU) can operate in the system of FIG. 1A. [Figure 2A] 1B is a block diagram of an example protocol stack according to which the UE of FIG. 1A may communicate with the base station of FIG. 1A. [Figure 2B] 1B is a block diagram of an example protocol stack according to which the UE of FIG. 1A may communicate with the DU and CU of the base station. [Figure 3] FIG. 1 is a block diagram illustrating an example tunnel architecture for MBS and PDU sessions. [Figure 4] FIG. 2 is a block diagram illustrating an example tunnel architecture for an MRB and a DRB. [Figure 5A] FIG. 1C is a messaging diagram of an example scenario in which the CN and base station of FIG. 1A and / or FIG. 1B manage the transmission of downlink data for different MBS sessions in which different UEs participate. [Figure 5B]FIG. 5B is a messaging diagram of an example scenario similar to that of FIG. 5A, but in which one of the UEs participates in both the first MBS session and the second MBS session. [Figure 6A] 1 is a flow chart illustrating an example method that may be implemented in a RAN node of the present disclosure for determining whether to transmit a packet (e.g., an MBS data packet) using a semi-persistent scheduling (SPS) radio resource or a dynamic scheduling radio resource depending on whether the packet arrived via a particular first tunnel. [Figure 6B] 1 is a flow chart illustrating an example method that may be implemented in a RAN node of the present disclosure for determining whether to transmit a packet (e.g., an MBS data packet) using an SPS radio resource or a dynamic scheduling radio resource depending on whether the packet arrived via a first tunnel, a second tunnel, a third tunnel, or a control plane interface. [Figure 6C] 1 is a flow chart illustrating an example method that may be implemented in a RAN node of the present disclosure for determining whether to transmit a packet (e.g., an MBS data packet) using an SPS radio resource or a dynamic scheduling radio resource depending on whether the packet arrived via a first tunnel, a second tunnel, a third tunnel, or a control plane interface. [Figure 7A] 6B is a flow diagram illustrating an example method similar to that of FIG. 6A that may be implemented in a RAN node of the present disclosure, but further illustrating the selection of a logical channel identification for a received packet and the generation of a PDU that includes the packet and the logical channel identification. [Figure 7B]6B is a flow chart illustrating an example method that may be implemented in a RAN node of the present disclosure, similar to the method of FIG. 6B, but further illustrating the selection of a logical channel identification for a received packet and the generation of a PDU that includes the packet and the logical channel identification. [Figure 7C] 6D is a flow diagram illustrating an example method similar to that of FIG. 6C that may be implemented in a RAN node of the present disclosure, but further illustrating the selection of a logical channel identification for a received packet and the generation of a PDU that includes the packet and the logical channel identification. [Figure 8A] 1 is a flow diagram illustrating an example method that may be implemented in a RAN node of the present disclosure for determining whether to transmit a packet (e.g., an MBS data packet) using an SPS radio resource or a dynamic scheduling radio resource depending on whether the packet is associated with a particular first quality of service (QoS) flow. [Figure 8B] 1 is a flow diagram illustrating an example method that may be implemented in a RAN node of the present disclosure for determining whether to transmit a packet (e.g., an MBS data packet) using SPS radio resources or dynamic scheduling radio resources depending on whether the packet is associated with a first QoS flow, a second QoS flow, a third QoS flow, or arrived over a control plane interface. [Figure 8C] 1 is a flow diagram illustrating an example method that may be implemented in a RAN node of the present disclosure for determining whether to transmit a packet (e.g., an MBS data packet) using SPS radio resources or dynamic scheduling radio resources depending on whether the packet is associated with a first QoS flow, a second QoS flow, a third QoS flow, or arrived over a control plane interface. [Figure 9A]8B is a flow diagram illustrating an example method similar to that of FIG. 8A that may be implemented in a RAN node of the present disclosure, but further illustrating the selection of a logical channel identification for a received packet and the generation of a PDU that includes the packet and the logical channel identification. [Figure 9B] 8B is a flow diagram illustrating an example method that may be implemented in a RAN node of the present disclosure, similar to the method of FIG. 8B, but further illustrating the selection of a logical channel identification for a received packet and the generation of a PDU that includes the packet and the logical channel identification. [Figure 9C] 8C is a flow diagram illustrating an example method that may be implemented in a RAN node of the present disclosure, similar to the method of FIG. 8C, but further illustrating the selection of a logical channel identification for a received packet and the generation of a PDU that includes the packet and the logical channel identification. DETAILED DESCRIPTION OF THE INVENTION

[0014] Generally, a radio access network (RAN) and / or a core network (CN) can implement the techniques of this disclosure to manage data transmissions. A RAN node (e.g., a base station or a component of a base station, such as a distributed unit (DU) of a distributed base station) can determine whether to transmit packets (e.g., multicast and / or wireless services (MBS) data packets) to user equipments (UEs) using semi-persistent scheduling (SPS) radio resources or dynamic scheduling radio resources. For example, the RAN node can transmit MBS data packets to a first set of one or more UEs via SPS multicast radio resources and to a second set of one or more UEs via dynamic scheduling multicast radio resources. In the same example, the base station may transmit another packet to one or more other UEs via unicast (SPS or dynamic scheduling) radio resources.

[0015] In some implementations, a RAN node may determine whether to transmit a packet to a UE using SPS or dynamic scheduling radio resources based on one or more properties of a downlink (DL) tunnel through which the RAN node received the packet (e.g., an Internet Protocol (IP) address and / or a Tunnel Endpoint Identifier (TEID)). In other implementations, a RAN node may determine whether to transmit a packet to a UE using SPS or dynamic scheduling radio resources based on a Quality of Service (QoS) flow associated with the packet. For example, if a QoS flow ID associated with a received MBS data packet is a first QoS flow ID, the RAN node may transmit the MBS data packet to the UE using SPS radio resources. However, if instead the QoS flow ID associated with the MBS data packet is a second QoS flow ID, the RAN node may transmit the MBS data packet to the UE using dynamic scheduling radio resources.

[0016] Also, in some implementations, the RAN node may determine a logical channel ID for a packet based on one or more DL tunnel characteristics or QoS flows. For example, the RAN node may identify or select a first logical channel ID if the QoS flow ID associated with the received MBS data packet is a first QoS flow ID, and may identify or select a second logical channel ID if the QoS flow ID associated with the MBS data packet is a second QoS flow ID.

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

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

[0019] In non-MBS (unicast) operation, the UE 102A may use radio bearers (e.g., DRBs or SRBs) that terminate at different times at the MN (e.g., base station 104) or the SN (e.g., base station 106). For example, after a handover to the base station 106 or an SN change, the UE 102A may use radio bearers (e.g., DRBs or SRBs) that terminate at the base station 106. The UE 102A may apply one or more security keys in the uplink (UE 102A to base station) and / or downlink (base station to UE 102A) directions when communicating on the radio bearers. In non-MBS operation, the UE 102A transmits data to a base station via radio bearers of (i.e., within) the uplink (UL) bandwidth portion (BWP) of the cell and / or receives data from a base station via radio bearers on the downlink (DL) BWP of the cell. The UL BWP may be an initial UL BWP or a dedicated UL BWP, and the DL BWP may be an initial DL BWP or a dedicated DL BWP. The UE 102A can receive paging, system information, public warning messages, or random access responses on the DL BWP. In this non-MBS operation, the UE 102A may be in a connected state. Alternatively, the UE 102A may be in an idle or inactive state if it supports small data transmission (which may also be referred to as "early data transmission") in the idle or inactive state.

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

[0021] The base station 104 includes processing hardware 130, which may include one or more general-purpose processors (e.g., central processing units (CPUs)), computer-readable memory that stores machine-readable instructions executable on the one or more general-purpose processors, and / or special-purpose processing units. The processing hardware 130 in the example implementation of FIG. 1A includes an MBS controller 132 configured to manage or control transmission of MBS information received from the CN 110 or edge server. For example, as discussed below, the MBS controller 132 may be configured to support radio resource control (RRC) configurations, procedures and messaging related to MBS procedures, and / or other operations related to those configurations and / or procedures. 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.

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

[0023] The UE 102A includes processing hardware 150, which may include one or more general-purpose processors (e.g., CPUs), computer-readable memory storing machine-readable instructions executable on the general-purpose processors, and / or dedicated processing units. The processing hardware 150 in the example implementation of FIG. 1A includes an MBS controller 152 configured to manage or control reception of MBS information. For example, as discussed below, the MBS controller 152 may be configured to support RRC configuration, procedures and messaging related to MBS procedures, and / or other operations related to those configurations and / or procedures. The processing hardware 150 may also include a non-MBS controller 154 configured to manage or control one or more RRC configurations and / or RRC procedures according to any of the implementations discussed below when the UE 102A communicates with the MN and / or SN during non-MBS operation. Although not shown in FIG. 1A, the UEs 102B and 103 may each include processing hardware similar to the processing hardware 150 of the UE 102A.

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

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

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

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

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

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

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

[0031] Each of the DUs 174 also includes processing hardware, which may include one or more general-purpose processors (e.g., CPUs) and computer-readable memory that stores machine-readable instructions executable on the one or more general-purpose processors, and / or special-purpose processing units. For example, the processing hardware may include a medium access control (MAC) controller configured to manage or control one or more MAC operations or procedures (e.g., random access procedures), and a radio link control (RLC) controller configured to manage or control one or more RLC operations or procedures when the base station (e.g., base station 104) operates as an MN or SN. The processing hardware may also include a physical (PHY) layer controller configured to manage or control one or more PHY layer operations or procedures.

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

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

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

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

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

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

[0038] In some implementations, a base station (e.g., base station 104 or 106) broadcasts MRB data packets via one or more MRBs, and the UE 102A, 102B, or 103 receives the MBS data packets via the MRBs. The base station may include a configuration for the MRB in multicast configuration parameters (which may also be referred to as MBS configuration parameters), described below. In some implementations, the base station broadcasts the MBS data packets via the RLC sublayer 206, the MAC sublayer 204, and the PHY sublayer 202, and correspondingly, the UE 102A uses the PHY sublayer 202, the MAC sublayer 204, and the RLC sublayer 206 to receive the MBS data packets. In such implementations, the base station and the UE 102A, 102B, or 103 may not use the PDCP sublayer 208 and the SDAP sublayer 212 to communicate the MBS data packets. In other implementations, the base station transmits MBS data packets over the PDCP sublayer 208, the RLC sublayer 206, the MAC sublayer 204, and the PHY sublayer 202, and correspondingly, the UE 102A, 102B, or 103 uses the PHY sublayer 202, the MAC sublayer 204, the RLC sublayer 206, and the PDCP sublayer 208 to receive the MBS data packets. In such implementations, 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 implementation, the base station transmits MBS data packets via the SDAP sublayer 212, the PDCP sublayer 208, the RLC sublayer 206, the MAC sublayer 204, and the PHY sublayer 202, and correspondingly, the UE 102A, 102B, or 103 uses the PHY sublayer 202, the MAC sublayer 204, the RLC sublayer 206, the PDCO sublayer 208, and the SDAP sublayer 212 to receive the MBS data packets.

[0039] FIG. 2B illustrates, in simplified form, an exemplary protocol stack 250 that a UE 102A, 102B, or 103 can use to communicate with a DU (e.g., DU 174) and a CU (e.g., CU 172). The radio protocol stack 200 of FIG. 2A is functionally divided as illustrated by the radio protocol stack 250 of FIG. 2B. The CU in either base station 104, 106 can retain all control and higher layer functions (e.g., RRC 214, SDAP 212, NR PDCP 210), but can delegate lower layer operations (e.g., NR RLC 206B, NR MAC 204B, and NR PHY 202B) to the DU. To support connectivity to 5GC, the NR PDCP 210 provides SRBs to the RRC 214, which in turn provides DRBs to the SDAP 212, which in turn provides SRBs to the RRC 214.

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

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

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

[0043] As shown in FIG. 3, the base station 104 / 106 maps traffic in the tunnel 312A to N radio bearers 314A-1, 314A-2, ..., 314A-N, which may be configured as MBS radio bearers or MRBs, where N >= 1. Each MRB may correspond to a respective logical channel. As discussed above, the PDCP sublayer supports 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. For example, each of the MRBs 314A may correspond to a respective MBS traffic channel (MTCH). The base station 104 / 106 and the CN 110 may also maintain another MBS session 302B, which may similarly include a tunnel 312B corresponding to MRBs 314B-1, 314B-2, ..., 314B-N, where N >= 1. Each of the MRBs 314B may correspond to a respective logical channel.

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

[0045] In various scenarios, the CN 110 can assign different types of MBS traffic to different QoS flows. For example, a flow with a relatively high QoS value may correspond to audio packets, while a flow with a relatively low QoS value may correspond to video packets. As another example, a flow with a relatively high QoS value may correspond to I-frames or full images used in video compression, while a flow with a relatively low QoS value may correspond to P-frames or predicted pictures that contain only changes to I-frames.

[0046] Continuing with reference to Figure 3, the base station 104 / 106 and the CN 110 can maintain one or more PDU sessions to support unicast traffic between the CN 110 and a particular UE. A PDU session 304A may include a UE-specific DL tunnel and / or a UE-specific UL tunnel 322A corresponding to one or more DRBs 324A, such as DRBs 324A-1, 324A-2, ... 324-N. Each of the DRBs 324A may correspond to a respective logical channel, such as a dedicated traffic channel (DTCH).

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

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

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

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

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

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

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

[0054] UE 102 (e.g., UE 102A in FIG. 1A ) initially performs an MBS session join procedure with CN 110 via base station 104 to join a first MBS session (502). While a diagram such as FIG. 5A shows only a single “UE 102,” it is understood that this could be either or both UEs 102A and 102B. In some scenarios, UE 102 subsequently performs one or more additional MBS join procedures, making event 502 the first of multiple MBS join procedures. Because base station 104 configures a common DL tunnel for MBS traffic (rather than a UE-specific tunnel, as discussed below), procedures 502 and 586 can occur in either order. In other words, base station 104 can configure a common DL tunnel even if no UEs yet participate in the first MBS session.

[0055] To perform the MBS session join procedure 502, in some implementations, the UE 102 sends an MBS session join request message to the CN 110 via the base station 104. In response, the CN 110 can send an MBS session join response message to the UE 102 via the base station 104 to grant the UE 102 access to the first MBS session. In some implementations, the UE 102 can include a first MBS session ID for the first MBS session in the MBS session join request message. In some cases, the CN 110 includes the first MBS session ID in the MBS session join response message. In some implementations, the UE 102 can send an MBS session join complete message to the CN 110 via the base station 104 in response to the MBS session join response message.

[0056] In some cases, the UE 102 performs an additional MBS session join procedure with the CN 110 via the RAN 105 (e.g., the base station 104 or the base station 106) to join the additional MBS session. For example, the UE 102 can perform a second MBS session join procedure with the CN 110 via the RAN 105 to join the second MBS session. Similar to event 502, in some implementations, the UE 102 can send a second MBS session join request message to the CN 110 via the base station 104, and the CN 110 can respond with a second MBS session join response message to grant the UE 102 access to the second MBS session. In some implementations, the UE 102 can send a second MBS session join completion message to the CN 110 via the base station 104 in response to the second MBS session join response message. In some implementations, the UE 102 can include a second MBS session ID of the second MBS session in the second MBS session join request message. Optionally, the CN 110 includes the second MBS session ID in the second MBS session join response message. In some implementations, the UE 102 may include 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) to simultaneously join the first MBS session and the second MBS session. In such a case, the CN 110 may send an MBS session response message to admit either the first MBS session or the second MBS session, or both the first MBS session and the second MBS session.

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

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

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

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

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

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

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

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

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

[0066] In some implementations, the CN 110 may indicate a list of UEs participating in the first MBS session in the CN-to-BS message of event 504. In other implementations, the CN 110 may send another second CN-to-BS message to the CU 172 indicating a list of UEs participating in the first MBS session (512). The CN 110 may include the first MBS session ID and / or PDU session ID in the second CN-to-BS message. The CU 172 may send a second BS-to-CN message to the CN 110 in response to the second CN-to-BS message of event 512 (519). In such a case, the second CN-to-BS message may be a non-UE-specific message, e.g., a message that is not specific to UE 102A or UE 102B. The CU 172 may include the first MBS session ID and / or PDU session ID in the second BS-to-CN message. For example, the list of UEs may include UE 102. To indicate the list of UEs, the CN 110 may include a list of (CN UE interface ID, RAN UE interface ID) pairs, each of which identifies a specific UE. The CN 110 assigns the CN UE interface ID, and the CU 172 assigns the RAN UE interface ID. Before the CN 110 transmits the list of (CN UE interface ID, RAN UE interface ID) pairs, the CU 172 transmits a BS-to-CN message (e.g., an NGAP message, an INITIAL UE message, or a PATH SWITCH REQUEST message) containing the RAN UE interface ID to the CN 110 for each of the UEs, and the CN 110 transmits a CN-to-BS message (e.g., an NGAP message, an INITIAL CONTEXT SETUP REQUEST message, or a PATH SWITCH REQUEST ACKNOWLEDGE message) containing the CN UE interface ID to the CU 172 for each of the UEs. In one example, the list of pairs includes a first pair (first CN UE interface ID and first RAN UE interface ID) that identifies the UE 102.In some implementations, the "CN UE interface ID" may be an "AMF UE NGAP ID," and the "RAN UE interface ID" may be a "RAN UE NGAP ID." In other implementations, the CN 110 may include a list of UE IDs, each identifying a specific UE in the set of UEs. In some implementations, the CN 110 may assign the UE IDs and transmit each of the UE IDs to a specific UE in a NAS procedure (e.g., a registration procedure) that the CN 110 performs with the specific UE. For example, the list of UE IDs may include a first UE ID of the UE 102A and a second UE ID of the UE 102B. In some implementations, the UE IDs are S-Temporary Mobile Subscriber Identities (S-TMSIs) (e.g., 5G-S-TMSI). Before the CN 110 transmits the list of UE IDs, the CU 172 may receive the UE IDs from the UE 102 or the CN 110 for each of the UEs. For example, the CU 172 may receive an RRC message (e.g., an RRCSetupComplete message) including the UE ID from the UE 102 during an RRC connection establishment procedure. In another example, the CU 172 may receive a CN-to-BS message (e.g., an NGAP message, an INITIAL CONTEXT SETUP REQUEST message, or a UE INFORMATION TRANSFER message) from the CN 110 including the UE ID.

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

[0068] In some implementations, the second CN-to-BS message and the second BS-to-CN message may be a PDU session resource modification request message and a PDU session resource modification response message, respectively. In some implementations, the second CN-to-BS message and the second BS-to-CN message may be UE-related messages, i.e., the messages are associated with a particular UE (e.g., UE 102A, 102B, or 103).

[0069] 5A , the CU 172 may transmit a first BS-to-CN message (510) in response to event 512 and without responding to event 504. The CN 110 may then transmit a CN-to-BS response message to the CU 172 in response to the first BS-to-CN message. In such a case, the CU 172 may transmit a CU-to-DU message to the DU 174 in response to receiving the second CN-to-BS message (506), and the first BS-to-CN message and the CN-to-BS response message may be non-UE-associated messages (i.e., the messages are not associated with a particular UE).

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

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

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

[0073] In some implementations, the UE context request message and the UE context response message are UE Context Setup Request and UE Context Setup Response messages, respectively. In other implementations, the UE context request message and the UE context response message are UE Context Modification Request and UE Context Modification Response messages, respectively.

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

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

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

[0077] In some implementations, the CU 172 includes the CU DL transport layer configuration in the second BS-to-CN message and / or the additional BS-to-CN message. In other words, the CU 172 can send the same CU DL transport layer configuration in the BS-to-CN message in response to the CN-to-BS message indicating that the UE will participate in the same MBS session. In such implementations, the CN 110 can blend the MBS resource setup procedure 586 and the second CN-to-BS message and the BS-to-CN message into a single procedure.

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

[0079] After receiving the first BS-to-CN message (510) or after receiving the second BS-to-CN message (519), the CN 110 can transmit MBS data (e.g., one or more MBS data packets) for the first MBS session to the CU 172 via the common CN-to-BS DL tunnel (524), and the CU 172 transmits the MBS data to the DU 174 via the common CU-to-DU tunnel (526). The DU 174 transmits (e.g., multicast or unicast) the MBS data to the UE 102 via one or more logical channels (528). The UE 102 receives the MBS data via one or more logical channels (528). For example, the CU 172 may receive the MBS data packet (524), generate a PDCP PDU including the MBS data packet, and transmit the PDCP PDU to the DU 174 (528). The DU 174 then generates a MAC PDU including the logical channel ID and the PDCP PDU and transmits the MAC PDU to the UE 102 via multicast or unicast (528). The UE 102 receives the MAC PDU via multicast or unicast (528), extracts the PDCP PDU and the logical channel ID from the MAC PDU, identifies the PDCP PDU associated with the MRB according to the logical channel ID, and extracts the MBS data packets from the PDCP PDU according to the PDCP configuration in the MRB configuration. In some implementations, the DU 174 may transmit the MBS data or MAC PDU to the UE 102 via one or more multicast transmissions (e.g., dynamic multicast transmissions or SPS multicast transmissions) as described above (528). In such a case, the UE 102 may receive the MBS data or MAC PDU from the DU 174 via one or more multicast transmissions as described above (528).

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

[0081] In some implementations, the configuration parameters may also include one or more RLC bearer configurations, each associated with a specific MRB. Each of the MRB configurations may include an MRB ID, a PDCP configuration, a first MBS session ID, a PDCP reestablishment indication (e.g., reestablishPDCP), and / or a PDCP recovery indication (e.g., recoveryPDCP). In some implementations, the PDCP configuration may be a PDCP-Config IE for the DRB. In other implementations, the RLC bearer configuration may be an RLC-BearerConfig IE. In some implementations, the RLC bearer configuration may include a logical channel (LC) ID that configures a logical channel. In some implementations, the logical channel may be a multicast traffic channel (MTCH). In other implementations, the logical channel may be a dedicated traffic channel (DTCH). In some implementations, the configuration parameters may include a logical channel configuration (e.g., a LogicaChannelConfig IE) that configures a logical channel. In some implementations, the RLC bearer configuration may include an MRB ID.

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

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

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

[0085] In some implementations, the configuration parameters for receiving MBS data of the first MBS session include one or more logical channel (LC) IDs for configuring one or more logical channels. In some implementations, the logical channel may be a DTCH. In other implementations, the logical channel may be an MTCH.

[0086] In some implementations, the configuration parameters may include dynamic scheduling multicast configuration parameters for the UE 102 to receive multicast transmissions each including MBS data or a specific portion of MBS data. In some implementations, the dynamic scheduling multicast configuration parameters may include at least one of the following configuration parameters: Group Radio Network Temporary Identifier (G-RNTI). The DU 174 dynamically schedules each multicast transmission including a specific MAC PDU for the UE 102 by generating a DCI, scrambling the CRC of the DCI using the G-RNTI, and transmitting the DCI and scrambled CRC on the PDCCH. The MAC PDU may include an MBS data packet or a portion of an MBS data packet. The UE 102 receives the DCI and scrambled CRC on the PDCCH and verifies the scrambled CRC using the G-RNTI. After the UE 102 verifies that the (scrambled) CRC is valid for each multicast transmission, the UE 102 receives the multicast transmission according to the corresponding DCI and extracts the specific MAC PDU from the multicast transmission. In this case, each multicast transmission is a dynamic scheduling multicast transmission, as used in the following description. In some implementations, each DCI includes configuration parameters that configure the dynamic scheduling multicast radio resources that schedule the corresponding multicast transmission. In some implementations, the configuration parameters may include at least one of the following parameters: The configuration parameters of each DCI may include the same and / or different values ​​for the following configuration parameters: Frequency domain resource allocation Time domain resource allocation Virtual Resource Block (VRB) to Physical Resource Block (PRB) mapping Modulation and Coding Scheme (MCS) New data indicators Redundant version HARQ process number Downlink allocation index PUCCH resource indicator A HARQ codebook (ID), indicating a HARQ ACK codebook index for a corresponding HARQ acknowledgement (ACK) codebook for a dynamic scheduling multicast transmission received by the UE 102. The DU 174 receives the HARQ ACK using the HARQ codebook (ID). If the configuration parameters do not include a HARQ codebook (ID), the UE 102 and the DU 174 may use the HARQ codebook (ID) for unicast transmission. In some implementations, the UE 102 may receive a HARQ codebook (ID) for unicast transmission in a DU configuration from the DU 174. In other implementations, the UE 102 may receive a HARQ codebook (ID) for unicast transmission in another DU configuration from the DU 174, similar to events 516, 518, and 520. A PUCCH resource configuration, indicating HARQ resources on the PUCCH on which the UE 102 transmits HARQ feedback (e.g., HARQ ACKs and / or negative ACKs (NACKs)) for dynamic scheduling multicast transmissions. If the configuration parameters do not include a PUCCH resource configuration, the UE 102 and the DU 174 may communicate HARQ feedback using the PUCCH resource configuration for unicast transmissions. A HARQ NACK only indication, which configures the UE 102 to transmit only HARQ negative ACKs (NACKs) for dynamic scheduling multicast transmissions that the UE 102 receives from the DU 174 and from which the UE 102 fails to acquire a transport block. In some implementations, the UE 102 fails to acquire a transport block because the UE 102 fails a cyclic redundancy check (CRC) for the transport block or because the UE 102 does not receive the dynamic scheduling multicast transmission. In accordance with this indication, the UE 102 refrains from transmitting HARQ ACKs to the DU 174 for dynamic scheduling multicast transmissions that the UE 102 successfully receives and from which the UE 102 acquires a transport block. If the configuration parameter does not include this indication, the UE 102 can transmit HARQ ACKs to the DU 174 for dynamic scheduling multicast transmissions that the UE 102 successfully receives and from which the UE 102 acquires a transport block. A HARQ ACK / NACK indication that configures the UE 102 to send HARQ NACKs for dynamic scheduling multicast transmissions for which the UE 102 fails to acquire a transport block, as well as to send HARQ ACKs for dynamic scheduling multicast transmissions for which the UE 102 successfully receives and from which the UE 102 acquires a transport block. If the configuration parameter does not include this indication, the UE 102 refrains from sending HARQ ACKs to the DUs 174 for dynamic scheduling multicast transmissions for which the UE 102 successfully receives and from which the UE 102 acquires a transport block. In such a case, the UE 102 is only permitted to send HARQ NACKs to the DUs 174 for dynamic scheduling multicast transmissions for which the UE 102 fails to acquire a transport block. A HARQ NACK indication that configures the UE 102 to send a HARQ ACK for a dynamic scheduling multicast transmission that the UE 102 successfully receives and from which the UE 102 acquires a transport block. If the configuration parameter does not include this indication, the UE 102 refrains from sending a HARQ ACK to the DU 174 for a dynamic scheduling multicast transmission for which the UE 102 successfully acquires a transport block. In such a case, the UE 102 is only permitted to send a HARQ NACK to the DU 174 for a dynamic scheduling multicast transmission for which the UE 102 fails to acquire a transport block. In some implementations, the DU 174 may include any one of a HARQ NACK indication, a HARQ ACK / NACK indication, and a HARQ ACK indication. A modulation and coding scheme (MCS) configuration, indicating the MCS table that the DU 174 uses to transmit dynamic scheduling multicast transmissions and that the UE 102 uses to receive dynamic scheduling multicast transmissions. For example, the MCS table may be an MCS table defined in 3GPP® Specification 38.214 (e.g., the low-SE 64QAM table shown in Table 5.1.3.1-3 of 3GPP® TS 38.214 or a new table specific to multicast transmissions). In some implementations, if the DU 174 does not include an MCS configuration in the DU configuration, the UE 102 and the DU 174 may apply a pre-defined MCS table in 3GPP® Specification 38.214. For example, the pre-defined MCS table may be, for example, the 256QAM table or the 64QAM table shown in Table 5.1.3.1-2 or Table 5.1.3.1-1 of Specification 38.214, respectively. If the DU 174 does not include an MCS configuration in the DU configuration, the UE 102 and the DU 174 can apply an MCS table for unicast transmissions to receive dynamic scheduling multicast transmissions from the DU 174. In some implementations, the DU 174 can include a PDSCH configuration (e.g., PDSCH-Config) that configures an MCS table for unicast transmissions in the DU configuration. In other implementations, the DU 174 can send another DU configuration including a PDSCH configuration to the UE 102, similar to events 516, 518, and 520. An aggregation factor, which is the number of repetitions of the dynamic scheduling multicast transmission. The DU 174 can transmit (i.e., multicast) a number of repetitions of the dynamic scheduling multicast transmission according to the aggregation factor, and the UE 102 receives the repetitions based on the aggregation factor. If the DU 174 does not include an aggregation factor in the DU configuration, in some implementations, the UE 102 can apply the aggregation factor for unicast transmissions. In some implementations, the DU 174 can include an aggregation factor for unicast transmissions to the UE 102 in the DU configuration. In other implementations, the DU 174 can transmit another DU configuration including an aggregation factor for unicast transmissions to the UE 102, similar to events 516, 518, and 520.

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

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

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

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

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

[0092] The CU 172 includes additional transport layer configurations for the additional MBS sessions to configure the additional common DL tunnels in the BS-to-CN message, similar to the first BS-to-CN message or the second BS-to-CN message, during the MBS resource setup and UE-specific MBS session configuration procedure. Each of the transport layer configurations configures a specific common DL tunnel of the common DL tunnels and may be associated with a specific MBS session of the additional MBS sessions. The transport layer configurations may be different to distinguish between different common DL tunnels. In particular, any pair of transport layer configurations may have different IP addresses, different DL TEIDs, or different IP addresses and different DL TEIDs.

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

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

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

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

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

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

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

[0100] In some implementations, the CU 172 transmits the second entity of MBS data for the first MBS session to the DU 174 (544). The DU then transmits the first entity of MBS data for the first MBS session to the UE 102 (542) and transmits the second entity of MBS data for the first MBS session to the UE 103 (546). In other implementations, the DU 174 receives the single entity of MBS data for the first MBS session from the CU 172 and transmits the MBS data for the first MBS session to each of the UEs that participated in the first MBS session.

[0101] Some example methods that may be implemented by the devices shown in Figures 1A and / or 1B will now be discussed with respect to Figures 6A through 9C. It will be understood that for each of Figures 6A through 9C, different packets may cause a RAN node implementing the illustrated method to follow different paths shown in the figures in different instances (e.g., at different times). Each of these methods may be implemented as a set of instructions stored on a non-transitory computer-readable medium and executable by one or more processors, and / or may be implemented by processing hardware.

[0102] 6A , a RAN node, such as a base station 104 or a DU 174, can implement / perform method 600A to determine whether to transmit a packet via an SPS radio resource or a dynamic scheduling radio resource based on whether the packet is received via a particular DL tunnel. Method 600A begins at block 602, where the RAN node receives a packet from a network node (e.g., a CU, CU-UP, CU-CP, AMF, or (MB-)UPF) (e.g., events 512, 518, 524, 526, 532, 534, 538, 540, 544, 589, 590, 591). In block 604, the RAN node determines whether the packet is received via a particular first DL tunnel. Based on this determination, the RAN node selects an SPS or dynamic scheduling radio resource for transmitting the packet. When the RAN node receives a packet via the first DL tunnel, flow proceeds to block 606 and (optional) block 608. At block 606, the RAN node transmits a packet to at least one first UE via an SPS radio resource (e.g., events 528, 536, 542, 546). At block 608, the RAN node transmits a packet to at least one second UE via a dynamic scheduling radio resource (e.g., events 528, 536, 542, 546). Otherwise, when the RAN node did not receive a packet via the first DL tunnel (e.g., if the RAN node received the packet via a second DL tunnel or via a control plane interface message), flow proceeds to block 610. At block 610, the RAN node transmits a packet to at least one second UE via a dynamic scheduling radio resource (e.g., events 520, 528, 536, 542, 546).

[0103] In some implementations, if the packet is received (at block 602) over a DL tunnel rather than a control plane interface, block 604 includes determining the DL tunnel over which the packet was received based on one or more properties of the DL tunnel. The one or more properties may be transport layer configuration parameters associated with the DL tunnel, such as an IP address and / or TEID in the packet and / or any other suitable parameters associated with the DL tunnel.

[0104] In some implementations, the first DL tunnel may be a common DL tunnel, and the second DL tunnel may be a UE-specific DL tunnel. In such cases, the SPS radio resource may be an SPS multicast radio resource, and the dynamic scheduling radio resource may be a dynamic scheduling unicast radio resource. In other implementations, the first DL tunnel and the second DL tunnel may be a common DL tunnel. In such cases, the SPS radio resource may be an SPS multicast radio resource, and the dynamic scheduling radio resource may be a dynamic scheduling multicast radio resource. In still other implementations, the first DL tunnel and the second DL tunnel may be UE-specific DL tunnels. In such cases, the SPS radio resource may be an SPS unicast radio resource, and the dynamic scheduling radio resource may be a dynamic scheduling unicast radio resource.

[0105] In some implementations, the at least one UE, the at least one second UE, and the at least one third UE may include the same UE and / or different UEs (i.e., the sets may be fully overlapping, partially overlapping, or not overlapping at all).

[0106] In some implementations, the packet may be an IP packet, an Ethernet packet, or a user plane (UP) packet. In such cases, the RAN node (e.g., base station 104) receives the packet from a UPF (e.g., UPF 162 or MB-UPF 162). In some implementations, the packet may be associated with an MBS session. In other implementations, the packet is not associated with an MBS session. In some implementations, the packet may be associated with a PDU session.

[0107] In other implementations, the packet may be a NAS PDU containing a NAS message. In such a case, the RAN node (e.g., base station 104) receives the NAS PDU from an AMF (e.g., AMF 164). The RAN node may receive a control plane interface message from the AMF containing the NAS PDU. For example, the control plane interface message may be the CN-to-BS message of event 512 or another CN-to-BS message.

[0108] In some implementations, the packet may be a PDCP PDU, and the DU (e.g., DU 174) receives the PDCP PDU from the CU (e.g., CU 172). If the PDCP PDU includes an IP packet, an Ethernet packet, an MBS data packet, or a user plane (UP) packet, the DU may receive the PDCP PDU from a CU or CU-UP (e.g., CU-UP 172B). If the PDCP PDU includes an RRC message, the DU may receive the PDCP PDU from a CU-CP (e.g., CU-CP 172A) via a control plane interface. For example, the DU may receive a control plane interface message including the PDCP PDU from a CU or CU-UP. For example, the control plane interface message may be the CU-to-DU message of event 518 or another CU-to-DU message.

[0109] In some implementations, the DU receives a control plane interface message including the packet from the AMF. For example, the control plane interface message may be a CN-to-BS message or a CU-to-DU message, e.g., as described above. In some implementations, the control plane interface message is an F1AP message or a W1AP message. In other implementations, the control plane interface message is an NGAP message or an S1AP message. In some implementations, the control plane interface message is a UE-related message, i.e., the message is associated with a particular UE.

[0110] 6B illustrates an example method 600B that is similar to method 600A, except that in method 600B, the RAN node determines in block 605 that the packet was received via a particular DL tunnel (in this example, the first DL tunnel, the second DL tunnel, or the third tunnel) or via a control plane interface (e.g., a control plane interface message containing the packet). When the RAN node determines that the packet was received via (1) the first DL tunnel, (2) the second DL tunnel, or (3) the third DL tunnel or control plane interface, flow proceeds to (1) block 607 (and optionally block 609), (2) block 611, or (3) block 612, respectively. Based on this determination, the RAN node selects an SPS or dynamic scheduling radio resource for transmitting the packet. When the RAN node determines that the packet was received via the first DL tunnel, flow proceeds to block 607 (and optionally block 609) instead of blocks 606 and 608. In block 607, the RAN node transmits a packet to at least one first UE via an SPS multicast radio resource (e.g., events 528, 536, 542, 546). In block 609, the RAN node transmits a packet to at least one second UE via a dynamic scheduling multicast radio resource. When the RAN node determines that it has received a packet via a second DL tunnel, the flow proceeds to block 611. In block 611, the RAN node transmits a packet to at least one third UE via a dynamic scheduling multicast radio resource (e.g., events 528, 536, 542, 546). When the RAN node determines that it has received a packet via a third DL tunnel or control plane interface, the flow proceeds to block 612. In block 612, the RAN node transmits a packet to a specific UE via a dynamic scheduling unicast radio resource.

[0111] In some implementations, if the packet is received (at block 602) over a DL tunnel rather than a control plane interface, block 605 includes determining the DL tunnel over which the packet was received based on one or more properties of the DL tunnel. The one or more properties may be transport layer configuration parameters associated with the DL tunnel, such as an IP address and / or TEID in the packet and / or any other suitable parameters associated with the DL tunnel.

[0112] 6C illustrates an example method 600C that is similar to methods 600A and 600B, except that in method 600C, if the RAN node determines in block 605 that the packet was received via the second DL tunnel, then flow proceeds to block 613 instead of block 611. In block 613, the RAN node transmits the packet to the particular UE over an SPS unicast radio resource.

[0113] 7A , a RAN node, such as the base station 104 or the DU 174, can implement / perform method 700A similar to method 600A to select a first logical channel identification (LCID) or a second logical channel ID for a packet (e.g., an MBS data packet) and transmit the packet via an SPS radio resource or a dynamic scheduling radio resource depending on whether the packet arrived via a particular DL tunnel. Method 700A begins at block 702, where the RAN node receives a packet from a network node (e.g., a CU, a CU-CP, a CU-UP, an AMF, or an (MB-)UPF) (e.g., events 512, 518, 524, 526, 532, 534, 538, 540, 544, 589, 590, 591). In block 704, the RAN node determines whether the packet has been received via a particular first DL tunnel. Based on this determination, the RAN node selects an SPS or dynamic scheduling radio resource for transmitting the packet. When the RAN node determines in block 704 that it has received a packet via the first DL tunnel, the flow proceeds to block 706. In block 706, the RAN node determines (e.g., identifies or selects) a first logical channel ID. In block 708, the RAN node generates a PDU (e.g., a MAC PDU) including the first logical channel ID and the packet. In block 710, the RAN node transmits the PDU to at least one first UE via SPS radio resources (e.g., events 528, 536, 542, 546). In block 712, the RAN node transmits the PDU to at least one second UE via dynamic scheduling radio resources (e.g., events 528, 536, 542, 546). Otherwise, when the RAN node determines in block 704 that it did not receive the packet over the first DL tunnel (e.g., if the RAN node received the packet over a second DL tunnel or control plane interface, such as a control plane interface message containing the packet), flow proceeds to block 714.In block 714, the RAN node determines (e.g., identifies or selects) a second logical channel ID. In block 716, the RAN node generates a PDU (e.g., a MAC PDU) that includes the second logical channel ID and the packet. In block 718, the RAN node transmits the PDU to at least one third UE via a dynamically scheduled radio resource (e.g., events 520, 528, 536, 542, 546).

[0114] 7B shows an example method 700B similar to methods 700A and 600B. When the RAN node determines in block 705 (similar to block 605) that it has received a packet via (1) the first DL tunnel, (2) the second DL tunnel, or (3) the third DL tunnel or control plane interface, the flow proceeds to (1) block 706, (2) block 714, or (3) block 720, respectively. Based on this determination, the RAN node selects an SPS or dynamic scheduling radio resource for transmitting the packet. When the RAN node determines in block 705 that it has received a packet via the first DL tunnel, the flow proceeds to block 706. In block 706, the RAN node determines (e.g., identifies or selects) a first logical channel ID. In block 708, the RAN node generates a PDU (e.g., a MAC PDU) including the first logical channel ID and the packet. In block 711, the RAN node transmits a PDU to at least one first UE via an SPS multicast radio resource (e.g., events 528, 536, 542, 546). In block 713, the RAN node transmits a PDU to at least one second UE via a dynamic scheduling multicast radio resource (e.g., events 528, 536, 542, 546). When the RAN node determines in block 705 that it has received a packet via the second DL tunnel, the flow proceeds to block 714. In block 714, the RAN node determines (e.g., identifies or selects) a second logical channel ID. In block 716, the RAN node generates a PDU (e.g., a MAC PDU) including the second logical channel ID and the packet. In block 719, the RAN node transmits the PDU to at least one third UE via a dynamic scheduling multicast radio resource (e.g., events 528, 536, 542, 546). When the RAN node determines in block 705 that it has received a packet via a third DL tunnel or control plane interface, the flow proceeds to block 720 .In block 720, the RAN node determines (e.g., identifies or selects) a third logical channel ID. In block 722, the RAN node generates a PDU (e.g., a MAC PDU) that includes the third logical channel ID and the packet. In block 724, the RAN node transmits the PDU to the specific UE via a dynamic unicast radio resource (see, e.g., event 520).

[0115] 7C illustrates an example method 700C that is similar to methods 700A and 700B, except that in method 700C, after block 716, flow proceeds to block 717 instead of block 719. In block 717, the RAN node transmits a PDU to a particular UE over an SPS unicast radio resource (e.g., event 520).

[0116] While Figures 6A-6C and 7A-7C relate to implementations and / or scenarios in which the RAN node selects an SPS or dynamic scheduling radio resource (multicast or unicast) based on one or more properties of the DL tunnel through which the RAN node receives packets from an upstream node, Figures 8A-8C and 9A-9C instead relate to implementations and / or scenarios in which the RAN node makes its selection based on the QoS flow.

[0117] 8A , a RAN node, such as a base station 104 or a DU 174, can perform method 800A to determine whether to transmit a packet via an SPS radio resource or a dynamic scheduling radio resource based on whether the packet is received via (i.e., associated with) a particular QoS flow. The examples and implementations discussed above for method 600A may also apply to method 800A. Method 800A begins at block 802, where the RAN node receives a packet from a network node (e.g., a CU, CU-UP, CU-CP, (MB-)UPF, or AMF) via a DL tunnel or a control plane interface (e.g., a control plane interface message) (e.g., events 512, 518, 524, 526, 532, 534, 538, 540, 544, 589, 590, 591). At block 804, the RAN node determines whether the packet is received via a particular first QoS flow. When the RAN node receives a packet via the first QoS flow, flow proceeds to block 806 (and optionally block 808). In block 806, the RAN node transmits the packet to at least one first UE via an SPS radio resource (e.g., events 528, 536, 542, 546). In block 808, the RAN node transmits the packet to at least one second UE via a dynamic scheduling radio resource (e.g., events 528, 536, 542, 546). Otherwise, when the RAN node does not receive the packet via the first QoS flow (e.g., if the RAN node receives the packet via a second QoS flow or a control plane interface message), flow proceeds to block 810. In block 810, the RAN node transmits the packet to at least one second UE via a dynamic scheduling radio resource (e.g., events 520, 528, 536, 542, 546).

[0118] In some implementations, a RAN node (e.g., a base station 104) can receive from a network node a first interface message including a first QoS flow identifier (ID) constituting a first QoS flow and a second interface message including a second QoS ID constituting a second QoS flow. The first interface message and the second interface message can include first and second QoS parameters, respectively. If the RAN node and the network node are a base station and an AMF, respectively, the first interface message and the second interface message can be CN-to-BS messages as described above. If the RAN node and the network node are a DU and a CU, respectively, the first interface message and the second interface message can be CU-to-DU messages as described above. In other implementations, a RAN node (e.g., a base station 104) can receive from a network node a (single) interface message including a first QoS flow ID constituting a first QoS flow and a second interface message including a QoS flow ID constituting a second QoS flow. If the RAN node and the network node are a base station and an AMF, respectively, the interface message may be a CN-to-BS message as described above. If the RAN node and the network node are a DU and a CU, respectively, the interface message may be a CU-to-DU message as described above.

[0119] In some implementations, the RAN node may receive a tunnel packet including a QoS flow ID and a packet from a network node, at block 802. In such implementations, the RAN node may determine whether the packet was received via a first QoS flow by determining whether the QoS flow ID is a first QoS flow ID, at block 804. If the QoS flow ID is the first QoS flow ID, the RAN node determines that the packet was received via the first QoS flow. Otherwise, if the QoS flow ID is a second QoS flow ID, the RAN node determines that the packet was received via the second QoS flow. In some implementations, the DL tunnel may be a common DL tunnel as described above.

[0120] 8B illustrates an example method 800B that is similar to method 800A, except that in method 800B, the RAN node determines in block 805 that it has received a packet via (1) the first QoS flow, (2) the second QoS flow, or (3) a third QoS flow or control plane interface (e.g., a control plane interface message containing the packet). When the RAN node determines that it has received the packet via (1) the first QoS flow, (2) the second QoS flow, or (3) the third QoS flow or control plane interface message, flow proceeds to (1) block 807 (and optionally 809), (2) block 811, or (3) block 812, respectively. When the RAN node determines that it has received the packet via the first QoS flow, flow proceeds to block 807 (and optionally block 809) instead of blocks 806 and 808. In block 807, the RAN node transmits a packet to at least one first UE via an SPS multicast radio resource (e.g., events 528, 536, 542, 546). In block 809, the RAN node transmits a packet to at least one second UE via a dynamic scheduling multicast radio resource. When the RAN node determines that it has received a packet via a second QoS flow, the flow proceeds to block 811. In block 811, the RAN node transmits a packet to at least one third UE via a dynamic scheduling multicast radio resource (e.g., events 528, 536, 542, 546). When the RAN node determines that it has received a packet via a third QoS flow or control plane interface, the flow proceeds to block 812. In block 812, the RAN node transmits a packet to a specific UE via a dynamic scheduling unicast radio resource.

[0121] 8C illustrates an example method 800C that is similar to method 800B, except that in method 800C, if the packet is received over a second QoS flow, the flow proceeds to block 813 instead of block 811. In block 813, the RAN node transmits the packet over an SPS unicast radio resource to the particular UE.

[0122] 9A , a RAN node, such as a base station 104 or a DU 174, may implement / execute method 900A similar to method 800A, but with additional details of method 700A (e.g., Logical Channel Identification (LCID) determination and PDU generation), to select a first LCID or a second LCID for a data packet and transmit the data packet over an SPS radio resource or a dynamic scheduling radio resource depending on whether the data packet arrived over (i.e., is associated with) a particular QoS flow. Method 900A begins at block 902, where the RAN node receives a packet from a network node (e.g., a CU, CU-CP, CU-UP, AMF, or (MB-)UPF) over a DL tunnel or a control plane interface (e.g., a control plane interface message including the packet) (e.g., events 512, 518, 524, 526, 532, 534, 538, 540, 544, 589, 590, 591). In block 904, the RAN node determines whether it has received a packet via a first DL QoS flow. When the RAN node determines in block 904 that it has received a packet via the first DL QoS flow, the flow proceeds to block 906. In block 906, the RAN node determines (e.g., identifies or selects) a first logical channel ID. In block 908, the RAN node generates a PDU (e.g., a MAC PDU) including the first logical channel ID and the packet. In block 910, the RAN node transmits the PDU to at least one first UE via SPS radio resources (e.g., events 528, 536, 542, 546). In block 912, the RAN node transmits the PDU to at least one second UE via dynamic scheduling radio resources (e.g., events 528, 536, 542, 546).Otherwise, when the RAN node determines in block 904 that it did not receive the packet via the first QoS flow (e.g., if the RAN node received the packet via a second QoS flow or a control plane interface), the flow proceeds to block 914. In block 914, the RAN node determines (e.g., identifies or selects) a second logical channel ID. In block 916, the RAN node generates a PDU (e.g., a MAC PDU) that includes the second logical channel ID and the packet. In block 918, the RAN node transmits the PDU to at least one third UE via a dynamically scheduled radio resource (e.g., events 520, 528, 536, 542, 546).

[0123] 9B illustrates an example method 900B similar to method 800B but with additional details of method 700B (e.g., LCID determination or PDU generation). When the RAN node determines in block 905 that it has received a packet via (1) a first QoS flow, (2) a second QoS flow, or (3) a third QoS flow or control plane interface (e.g., a control plane interface message including the packet), the flow proceeds to (1) block 906, (2) block 914, or (3) block 920, respectively. When the RAN node determines in block 905 that it has received a packet via the first QoS flow, the flow proceeds to block 906. In block 906, the RAN node determines (e.g., identifies or selects) a first logical channel ID. In block 908, the RAN node generates a PDU (e.g., a MAC PDU) including the first logical channel ID and the packet. In block 911, the RAN node transmits a PDU to at least one first UE via an SPS multicast radio resource (e.g., events 528, 536, 542, 546). In block 913, the RAN node transmits a PDU to at least one second UE via a dynamic scheduling multicast radio resource (e.g., events 528, 536, 542, 546). When the RAN node determines in block 905 that it has received a packet via a second QoS flow, the flow proceeds to block 914. In block 914, the RAN node determines (e.g., identifies or selects) a second logical channel ID. In block 916, the RAN node generates a PDU (e.g., a MAC PDU) including the second logical channel ID and the packet. In block 919, the RAN node transmits the PDU to at least one third UE via a dynamic scheduling multicast radio resource (e.g., events 528, 536, 542, 546). When the RAN node determines in block 905 that it has received a third QoS message or packet over the control plane interface, flow proceeds to block 920 .In block 920, the RAN node determines (e.g., identifies or selects) a third logical channel ID. In block 922, the RAN node generates a PDU (e.g., a MAC PDU) that includes the third logical channel ID and the packet. In block 924, the RAN node transmits the PDU to the specific UE over a dynamic unicast radio resource (e.g., event 520).

[0124] 9C illustrates an example method 900C that is similar to method 900B, except that in method 900C, after block 916, flow proceeds to block 917 instead of block 919. In block 917, the RAN node transmits the PDU to the particular UE over an SPS unicast radio resource.

[0125] The following additional considerations apply to the above discussion:

[0126] In some implementations, "message" may be used and replaced by "information element (IE)". In some implementations, "IE" may be used and replaced by "field". In some implementations, "configuration" may be replaced by "configurations" or configuration parameters. In some implementations, "MBS" may be replaced by "multicast" or "broadcast". In some implementations, "SPS multicast" may be replaced by "multicast SPS". Similarly, "dynamic scheduling multicast" may be replaced by "multicast dynamic".

[0127] A user device (e.g., UE 102A or 102B) on which the techniques of this disclosure may be implemented may be any suitable device capable of wireless communication, such as a smartphone, a tablet computer, a laptop computer, a mobile game console, a point-of-sale (POS) terminal, a health management device, a drone, a camera, a media streaming dongle or another personal media device, a wearable device such as a smartwatch, a wireless hotspot, a femtocell, or a broadband router. Furthermore, a user device may in some cases be integrated into an electronic system such as a vehicle head unit or an advanced driver assistance system (ADAS). Still further, a user device may operate as an internet-of-things (IoT) device or a mobile internet device (MID). Depending on the type, a 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.

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

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

[0130] After reading this disclosure, those skilled in the art will recognize still further alternative structural and functional designs for communicating MBS information through the principles disclosed herein. Accordingly, while particular embodiments and applications have been shown and described, it should be understood that the disclosed embodiments are not limited to the precise structure and components disclosed herein. Various modifications, changes, and variations that will be apparent to those skilled in the art may be made in the arrangement, operation, and details of the methods and apparatus disclosed herein without departing from the spirit and scope, as defined in the appended claims. [Explanation of symbols]

[0131] 102UE 103UE 104 Base station 105 RAN 106 Base Station 110 Core Network 111 EPC 112 SGW 114 MME 116 PGW 124 cells 126 cells 130 Processing Hardware 132 MBS Controller 134 Non-MBS Controller 140 Processing Hardware 142 MBS Controller 144 Non-MBS Controller 150 Processing Hardware 152 MBS Controller 154 Non-MBS Controller 160 5GC 162 (MB-)UPF 164 AMF 166 (MB-)SMF 172 CU 174 DU 202 PHY 204 MAC 206 RLC 208 EUTRA PDCP 210NR PDCP 212 SDAP 214 RRC 302 MBS Sessions 304 PDU sessions 312 Tunnel 314 MRB 316 QoS Flows 322 UE-specific DL tunnel and / or UE-specific UL tunnel 324 DRB 402 MRB 404 DRB 412 DL Tunnel 413 UL Tunnel 422 DL logical channels 423 UL logical channels 432 UE-specific DL tunnel 433 UE-specific UL tunnel 442 DL logical channels 443 UL logical channels

Claims

1. 1. A method for managing packet transmission, said method being implemented in a Radio Access Network (RAN) node, comprising: receiving, by the RAN node, packets associated with a Quality of Service (QoS) flow from an upstream node via a downlink (DL) tunnel; selecting, by the RAN node based on the QoS flow, semi-persistent scheduling radio resources for transmitting the packet to one or more UEs in response to determining that the DL tunnel has a first transport layer configuration of a plurality of transport layer configurations; and transmitting, by the RAN node, the packet to the one or more UEs over an air interface using the semi-persistent scheduling radio resource.

2. The method of claim 1 , wherein the packets are data packets associated with a multicast and / or broadcast service (MBS) session.

3. The method of claim 1 , wherein the semi-persistent scheduling radio resource is a multicast radio resource.

4. The method of claim 1 , further comprising selecting a logical channel identification based on the QoS flow.

5. The transmitting step includes: The method of claim 4, comprising including the packet and the logical channel identification information in a protocol data unit (PDU).

6. The method of claim 4 , wherein the logical channel identification information is associated with a multicast traffic channel (MTCH).

7. the receiving, selecting, and transmitting steps occur in a first instance; The method further comprises, in a second case: receiving, by the RAN node, a second packet either (i) in association with a second QoS flow or (ii) via a control plane interface; selecting, by the RAN node, a dynamic scheduling radio resource for transmitting the second packet to a second one or more UEs; and transmitting, by the RAN node, the second packet to the second one or more UEs over the radio interface using the dynamically scheduled radio resource.

8. the second packet is associated with a second QoS flow; The method further comprises, in a third case: receiving, by the RAN node, a third packet either (i) in association with a third QoS flow or (ii) via the control plane interface; selecting, by the RAN node, a second dynamically scheduled radio resource for transmitting the third packet to a third one or more UEs; and transmitting, by the RAN node, the third packet to the third one or more UEs over the air interface using the second dynamically scheduled radio resource.

9. The method of claim 8 , wherein the dynamically scheduled radio resource is a multicast radio resource and the second dynamically scheduled radio resource is a unicast radio resource.

10. In the third case, receiving, by the RAN node, a third packet associated with a third QoS flow; selecting, by the RAN node, a second semi-persistent scheduling radio resource for transmitting the third packet to a particular UE; and transmitting, by the RAN node, the third packet to the particular UE over the air interface using the second semi-persistent scheduling radio resource.

11. the semi-persistent scheduling radio resource is a multicast radio resource; the second semi-persistent scheduling radio resource is a unicast radio resource; The method of claim 10, wherein the dynamically scheduled radio resource is a unicast radio resource.

12. the RAN node is a distributed unit (DU) of a distributed base station; The upstream node is a central unit (CU) of the distributed base station, a user plane function (CU-UP) of the CU, or a control plane function (CU-CP) of the CU; the RAN node is a base station; 7. The method according to claim 1, wherein the upstream node is a User Plane Function (UPF) of a Core Network (CN) or an Access and Mobility Management Function (AMF) of the CN.

13. 7. The method of claim 1, further comprising transmitting, by the RAN node, the packet to at least one other UE over the radio interface using a specific dynamically scheduled radio resource.

14. A network node comprising processing hardware configured to perform the method of any one of claims 1 to 6.

Images