CN118202781A

CN118202781A - Managing multicast and unicast wireless data transmissions

Info

Publication number: CN118202781A
Application number: CN202280073288.8A
Authority: CN
Inventors: C-H·吴
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2021-10-21
Filing date: 2022-10-19
Publication date: 2024-06-14
Also published as: CN118176823A; CN118235519A; CN118140522A

Abstract

There is provided a method performed by a Distributed Unit (DU) of a distributed base station in a Radio Access Network (RAN) for managing transmission of a multicast and/or broadcast service (MBS), the method comprising: receiving MBS data packets from a Central Unit (CU) of the distributed base station via a Downlink (DL) tunnel; selecting a multicast scheme for transmitting the MBS data packet to a plurality of UEs based on one or more attributes of the DL tunnel; and transmitting the data packets to the plurality of UEs via a radio interface using the multicast scheme according to the selection. Additionally, a method implemented in a node of a RAN for managing transmission of data packets is provided, the method comprising: receiving MBS data packets associated with a quality of service (QoS) flow from an upstream node; selecting a logical channel on a radio interface based on the QoS flow; and broadcasting the MBS data packet to a plurality of UEs on the logical channel.

Description

Managing multicast and unicast wireless data transmissions

Technical Field

The present disclosure relates to wireless communications, and more particularly to managing multicast and unicast wireless data transmissions for multicast and/or broadcast services.

Background

The background description provided herein is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.

In a telecommunication system, a Packet Data Convergence Protocol (PDCP) sublayer of a radio protocol stack provides services such as user plane data transfer, ciphering, integrity protection, and the like. For example, PDCP sublayers defined for an Evolved Universal Terrestrial Radio Access (EUTRA) radio interface (see third generation partnership project (3 GPP) specification TS 36.323) and a New Radio (NR) (see 3GPP specification TS 38.323) provide ordering of Protocol Data Units (PDUs) in an uplink direction from a user equipment (also referred to as a user equipment or "UE") to a base station and in a downlink direction from the base station to the UE. The PDCP sublayer also provides services for Signaling Radio Bearers (SRBs) to a Radio Resource Control (RRC) sublayer. The PDCP sublayer also provides services for Data Radio Bearers (DRBs) to a Service Data Adaptation Protocol (SDAP) sublayer or a protocol layer such as an Internet Protocol (IP) layer, an ethernet protocol layer, or an Internet Control Message Protocol (ICMP) layer. In general, the UE and the base station may exchange RRC messages as well as non-access stratum (NAS) messages using SRBs, and may transmit data on a user plane using DRBs.

The RRC sublayer specifies an rrc_idle state in which the UE has no active radio connection with the base station; an rrc_connected state in which the UE has an active radio connection with the base station; and an rrc_inactive state that allows the UE to transition back to the rrc_connected state faster due to Radio Access Network (RAN) level base station coordination and RAN paging procedures.

In some scenarios, the UE can operate in a state (e.g., rrc_idle or rrc_inactive state) where the radio resource control connection with the RAN is INACTIVE, and then transition to the connected state. In general, in the inactive state, the radio connection between the UE and the RAN is suspended. Later, the UE may transition to the connected state when the UE is triggered to send data (e.g., place a call, launch a browser) or receive a paging message from the base station. To perform the handover, the UE may request the base station to establish a radio connection (e.g., by sending an RRC establishment request message to the base station) or resume a suspended radio connection (e.g., by sending an RRC resume request message to the base station) so that the base station may configure the UE to operate in a connected state.

In some cases, a UE in rrc_idle or rrc_inactive state has only one packet (or only relatively small packets) to transmit, or a base station has only one packet (or only relatively small packets) to transmit to a UE operating in rrc_idle or rrc_inactive state. In these cases, a UE in an rrc_idle or rrc_inactive state may perform early data communication without transitioning to an rrc_connected state, for example, by using techniques as specified in 3GPP specifications 36.300v16.4.0, sections 7.3a to 7.3 d.

In some scenarios, a UE may utilize resources of multiple nodes of a RAN (e.g., components of a base station or a distributed base station (also referred to as a split base station)) simultaneously, the multiple nodes being interconnected by a backhaul. When the network nodes support different Radio Access Technologies (RATs), this type of connection is called a multi-radio dual connection (MR-DC). When operating in MR-DC, a cell associated with a base station acting as a primary node (MN) defines a primary cell group (MCG), while a cell associated with a base station acting as a Secondary Node (SN) defines a Secondary Cell Group (SCG) MCG covering one primary cell (PCell) and zero, one or more secondary cells (scells), while SCG covers one primary secondary cell (PSCell) and zero, one or more scells. The UE communicates with the MN (via MCG) and SN (via SCG). In other scenarios, the UE utilizes the resources of one base station at a time in a Single Connection (SC). The UE in SC communicates with the MN only via MCG. The base station and/or the UE determines when the UE should establish a radio connection with another base station. For example, the base station may determine to handover 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 (also referred to as a split) base station), which are interconnected by a backhaul.

The UE may use several types of SRBs and DRBs. So-called "SRB1" resources carry RRC messages, which in some cases include NAS messages, which are transmitted over a Dedicated Control Channel (DCCH), while "SRB2" resources support RRC messages that include recorded measurement information or NAS messages, which are also transmitted over the DCCH but have a lower priority than the SRB1 resources. More generally, the SRB1 and SRB2 resources allow the UE and MN to exchange and embed RRC messages related to the MN, and may also be referred to as MCG SRBs. The "SRB3" resource allows the UE and SN to exchange RRC messages related to the SN, and may also be referred to as SCG SRB. Splitting SRBs allows UEs to exchange RRC messages directly with the MN via the lower layer resources of the MN and SN. Further, a DRB that terminates at the MN and uses lower layer resources of only the MN may be referred to as an MCG DRB, a DRB that terminates at the SN and uses lower layer resources of only the SN may be referred to as an SCG DRB, and a DRB that terminates at the MN or the SN but uses lower layer resources of both the MN and the SN may be referred to as a segmentation DRB. A DRB that terminates at the MN but uses SN-only lower layer resources may be referred to as an SCG DRB that terminates at the MN. A DRB that terminates at the SN but uses only the lower layer resources of the MN may be referred to as an MCG DRB that terminates at the SN.

The UE may perform a handover procedure to handover from one cell to another, whether in SC or DC operation. These procedures involve messaging (e.g., RRC signaling and preparation) between the RAN node and the UE. The UE may be handed 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 DU of the same base station, depending on the scenario. In a DC scenario, the UE may perform a PSCell change procedure to change PSCell. These procedures involve messaging (e.g., RRC signaling and preparation) between the RAN node and the UE. The UE may perform a PSCell change from a PSCell of a service SN to a target PSCell of a target SN, or a PSCell change from a PSCell of a source DU of a base station to a PSCell of a target DU of the same base station, depending on the scenario. Furthermore, the UE may perform handover or PSCell change within the cell to enable synchronous reconfiguration.

The base station operating according to the fifth generation (5G) New Radio (NR) requirements supports a much larger bandwidth than the fourth generation (4G) base station. Therefore, the third generation partnership project (3 GPP) has proposed that for release 15, the ue supports a 100MHz bandwidth in frequency range 1 (FR 1) and a 400MHz bandwidth in frequency range (FR 2). Since the bandwidth of a typical carrier in 5G NR is relatively wide, 3GPP proposes in release 17 that a 5G NR base station can provide multicast and/or broadcast services (MBS) to UEs. MBS can be used for many content delivery applications such as, for example, transparent IPv4/IPv6 multicast delivery, IPTV, wireless software delivery, group communication, internet of things (IoT) applications, V2X applications, and emergency messages related to public safety.

It has been proposed to provide multicast paging for multicast and/or broadcast services (MBS), i.e. by transmitting a multicast paging message or instruction indicating that UEs that have previously indicated an interest in a particular MBS service and that are not operating in an active state are to be paged to provide the MBS service. For example, a Core Network (CN) may receive MBS data to be transmitted to a plurality of UEs of interest, and based on the received MBS data, the CN may transmit a multicast paging message to a Central Unit (CU) of a distributed Base Station (BS), the multicast paging message identifying a group of UEs of interest to the MBS service. A CU may transmit one or more corresponding multicast paging messages to Distributed Units (DUs) of the distributed base station, wherein each CU-to-DU multicast paging message indicates one or more UEs of interest associated with the recipient DU.

The 5G NR supports multicast and unicast delivery methods for transmitting MBS packet streams over a radio interface. In unicast communication, the RAN node transmits a different copy of each MBS data packet to a different UE over the radio interface, while in multicast communication, the RAN node transmits a single copy of each MBS data packet to multiple UEs over the radio interface. However, in some scenarios, it is not clear how the base station receives MBS data packets from the core network, and how the base station transmits each MBS data packet to the UE, including when the base station is implemented in a distributed manner. Furthermore, in some scenarios, it is not clear how a base station maps downlink MBS traffic onto a radio interface, considering two available delivery methods, namely multicast and unicast.

Disclosure of Invention

In one embodiment, a method performed by a Distributed Unit (DU) of a distributed base station in a Radio Access Network (RAN) for managing transmission of multicast and/or broadcast services (MBS) is provided, the method comprising: receiving MBS data packets from a Central Unit (CU) of the distributed base station via a Downlink (DL) tunnel; selecting a multicast scheme for transmitting the MBS data packet to a plurality of UEs based on one or more attributes of the DL tunnel; and transmitting the data packets to the plurality of UEs via a radio interface using the multicast scheme according to the selection.

In another embodiment, a method performed by a node of a Radio Access Network (RAN) for managing transmission of data packets is provided, the method comprising: receiving MBS data packets associated with a quality of service (QoS) flow from an upstream node; selecting a logical channel on a radio interface based on the QoS flow; and broadcasting the MBS data packet to a plurality of UEs on the logical channel.

Drawings

Fig. 1A is a block diagram of an example wireless communication system in which a Core Network (CN), a Base Station (BS), and a User Equipment (UE) may implement techniques of the present disclosure for managing multicast and unicast wireless data transmissions for multicast and/or broadcast services (MBS);

FIG. 1B is a block diagram of an example distributed Base Station (BS) including a Central Unit (CU) and Distributed Units (DU) that may operate in the system of FIG. 1A;

Fig. 2A 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;

Fig. 2B is a block diagram of an example protocol stack according to which the UE of fig. 1A may communicate with DUs and CUs of a distributed base station;

FIG. 2C is a block diagram of another example protocol stack according to which the UE of FIG. 1A may communicate with DUs and CUs of a base station, including supporting the F1AP protocol between CUs and DUs;

Fig. 2D is a block diagram of an example protocol stack according to which CUs and DUs may communicate user plane traffic;

Fig. 2E is a block diagram of an example protocol stack according to which CUs and DUs may communicate control plane traffic;

FIG. 3 is a block diagram illustrating an example tunnel architecture for MBS sessions and PDU sessions;

Fig. 4 is a block diagram illustrating an example MRB and DRB that a distributed base station may configure for communicating multicast, broadcast, and/or unicast traffic with UEs;

fig. 5A is a messaging diagram of an example scenario in which a CN and a distributed base station configure resources for transmitting MBS data of an MBS session to a plurality of UEs;

Fig. 5B is a messaging diagram similar to fig. 5A but where the CN provides a list of UEs joining a non-MBS session before configuring the CN to BS tunnel for the MBS, but not after;

Fig. 6A is a flow chart illustrating an example method for determining whether to use multicast or unicast transmission of a data packet based on whether the data packet arrived via a common tunnel or a UE-specific tunnel, which may be implemented in a RAN node of the present disclosure;

Fig. 6B is a flow chart illustrating an example method for determining whether to use multicast or unicast transmission of a data packet based on whether the data packet arrived via a first tunnel or a second tunnel, which may be implemented in a RAN node of the present disclosure;

Fig. 7 is a flow chart illustrating an example method for determining whether to use multicast or unicast transmission of a data packet according to whether a tunnel through which the data packet arrives has a first or second transport layer configuration, which may be implemented in a RAN node of the present disclosure;

Fig. 8A is a flow chart illustrating an example method for selecting a first logical channel identifier or a second logical channel identifier for a data packet depending on whether the data packet arrived via a common tunnel or a UE-specific tunnel, which may be implemented in a RAN node of the present disclosure;

Fig. 8B is a flow chart illustrating an example method for selecting a first logical channel identifier or a second logical channel identifier for a data packet based on whether the data packet arrives via a first tunnel or a second tunnel, which may be implemented in a RAN node of the present disclosure;

fig. 9 is a flow chart illustrating an example method for selecting a first logical channel identifier or a second logical channel identifier for a data packet depending on whether a tunnel through which the data packet arrives has a first transport layer configuration or a second transport layer configuration, which may be implemented in a RAN node of the present disclosure;

Fig. 10A is a flow chart illustrating an example method for selecting a group network temporary identifier (G-RNTI) and a first logical channel or UE specific RNTI (C-RNTI) and a second logical channel for a data packet based on whether the data packet arrived via a common tunnel or UE specific tunnel, which may be implemented in a RAN node of the present disclosure;

Fig. 10B is a flow chart illustrating an example method for selecting a G-RNTI and a first logical channel or a C-RNTI and a second logical channel for a data packet based on whether the data packet arrived via a first tunnel or a second tunnel, which may be implemented in a RAN node of the present disclosure;

fig. 11 is a flow chart illustrating an example method for selecting a G-RNTI and a first logical channel or a C-RNTI and a second logical channel for a data packet depending on whether a tunnel through which the data packet arrived has a first or second transport layer configuration, which may be implemented in a RAN node of the present disclosure;

Fig. 12 is a flow chart illustrating an example method for selecting a first logical channel identifier or a second logical channel identifier for a data packet based on whether the data packet is associated with a first quality of service (QoS) flow identifier or a second QoS flow identifier, which may be implemented in a RAN node of the present disclosure;

fig. 13 is a flow chart illustrating an example method for determining whether to select a first logical channel identifier or a second logical channel identifier for a data packet based on whether the data packet is associated with a first QoS flow identifier or a second QoS flow identifier or whether to select a second logical channel for the data packet based on whether a tunnel through which the data packet arrives has a first transport layer configuration or a second transport layer configuration, which may be implemented in a RAN node of the present disclosure;

Fig. 14 is a flow chart illustrating an example method for selecting a first logical channel identifier and a G-RNTI or a second logical channel identifier and a G-RNTI for a data packet based on whether the data packet is associated with a first QoS flow identifier or a second QoS flow identifier, which may be implemented in a RAN node of the present disclosure; and

Fig. 15 is a flow chart illustrating an example method for determining whether to select a first logical channel identifier and a G-RNTI or a second logical channel identifier and a G-RNTI for a data packet based on whether the data packet is associated with a first QoS flow identifier or a second QoS flow identifier or whether to select a second logical channel and a G-RNTI for a data packet based on whether a tunnel through which the data packet arrived has a first transport layer configuration or a second transport layer configuration, which may be implemented in a RAN node of the present disclosure.

Detailed Description

In general, a Radio Access Network (RAN) node of the present disclosure selects between a multicast scheme and a unicast scheme to transmit data packets to at least one User Equipment (UE) over a radio interface based on how the data packets are received from an upstream node. More specifically, in some implementations, the RAN node may receive multicast and/or broadcast service (MBS) data packets for a plurality of UEs via a common DL tunnel and determine that the RAN node should use a multicast scheme to transmit the MBS data packets. The RAN node may be a DU of a distributed base station (and the DL tunnel may operate on a CU-to-DU interface) or a DU of a non-distributed base station (and the DL tunnel may operate on a Core Network (CN) to Base Station (BS) or CN to BS interface) in different scenarios.

Fig. 1A depicts an example wireless communication system 100 in which techniques of the present disclosure for managing transmission and reception of MBS information may be implemented. The wireless communication system 100 includes UEs 102A, 102B, 103 and base stations 104, 106 of a RAN 105 connected to a CN 110. In other implementations or scenarios, the wireless communication system 100 may alternatively 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 of base station, 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, base station 104 may be an eNB or a gNB, and base station 106 may be a gNB.

Base station 104 supports cell 124 and base station 106 supports cell 126. Cell 124 partially overlaps with cell 126 such that UE 102A may be in communication with base station 104 while in communication with base station 106 (or within detecting or measuring signals from base station 106). For example, the overlap may enable the UE 102A to switch between cells (e.g., from cell 124 to cell 126) or between base stations (e.g., from base station 104 to base station 106) before the UE 102A experiences a radio link failure. Furthermore, the overlap allows for various Dual Connectivity (DC) scenarios to exist. For example, UE 102A may communicate with base station 104 (acting as a primary node (MN)) and base station 106 (acting as a Secondary Node (SN)) in DC. When UE 102A is in DC with base station 104 and base station 106, base station 104 acts as a master eNB (MeNB), a master ng-eNB (Mng-eNB), or a master gNB (MgNB), and base station 106 acts as a secondary gNB (SgNB) or a secondary ng-eNB (Sng-eNB).

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

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

The base station 104 includes processing hardware 130, which may include one or more general-purpose processors (e.g., central Processing Units (CPUs)) and computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors and/or dedicated processing units. In the example implementation of fig. 1A, the processing hardware 130 includes an MBS controller 132 configured to manage or control transmission of MBS information received from the CN 110 or an edge server. For example, MBS controller 132 may be configured to support Radio Resource Control (RRC) configurations, procedures, and messaging associated with MBS procedures, and/or other operations associated with those configurations and/or procedures, as discussed below. The processing hardware 130 may also include a non-MBS controller 134 configured to manage or control one or more RRC configurations and/or RRC procedures when the base station 104 functions as a MN or SN during non-MBS operations.

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

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

CN 110 may be an Evolved Packet Core (EPC) 111 or a fifth generation core (5 GC) 160, both depicted in fig. 1A. Base station 104 may be an eNB supporting an S1 interface for communicating with EPC 111, a NG-eNB supporting an NG interface for communicating with 5gc 160, or a gNB supporting an NR radio interface and an NG interface for communicating with 5gc 160. Base station 106 may be an EUTRA-NR DC (EN-DC) gNB (EN-gNB) with an S1 interface to EPC 111, an EN-gNB not connected to EPC 111, a gNB supporting an NR radio interface and an NG interface to 5gc 160, or a NG-eNB supporting an EUTRA radio interface and an NG interface to 5gc 160. To exchange messages directly with each other during the scenarios discussed below, base stations 104 and 106 may support an X2 or Xn interface.

EPC 111 may include, among other components, a Serving Gateway (SGW) 112, a Mobility Management Entity (MME) 114, and a packet data network gateway (PGW) 116.SGW 112 is generally configured to communicate user plane packets related to audio calls, video calls, internet traffic, etc., and MME 114 is configured to manage authentication, registration, paging, and other related functions. 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 may include a User Plane Function (UPF) 162 and an access and mobility management function (AMF) 164, and/or a Session Management Function (SMF) 166. The UPF 162 is generally configured to communicate user plane packets related to audio 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.

The UPF 162, AMF 164, and/or SMF 166 may be configured to support MBS. For example, SMF 166 may be configured to manage or control MBS transmissions, to configure UPF 162 and/or RAN 105 for MBS flows, and/or to manage or configure one or more MBS sessions or PDU sessions for MBS for a UE (e.g., UE 102A or 102B). The UPF 162 is configured to communicate MBS data packets of audio, video, internet traffic, etc., to the RAN 105. The UPF 162 and/or SMF 166 may be configured for both non-MBS unicast services and MBS services, or for MBS services only, as represented by the prefix "(MB-)" shown in FIG. 1A.

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

In a different configuration or scenario of the wireless communication system 100, the base station 104 may function as a MeNB, mng-eNB, or MgNB, while the base station 106 may function as a SgNB or Sng-eNB. UE 102A may communicate with base station 104 and base station 106 via the same Radio Access Technology (RAT), such as EUTRA or NR, or via different RATs.

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

Fig. 1B depicts an example distributed implementation of each of one or both of the base stations 104 and 106. In this implementation, the base stations 104, 106 include a Central Unit (CU) 172 and one or more Distributed Units (DUs) 174.CU 172 includes processing hardware, such as one or more general-purpose processors (e.g., CPUs) and computer readable memory storing machine readable instructions executable on the general-purpose processors and/or special-purpose processing units. For example, CU 172 may include some or all of processing hardware 130 or 140 of FIG. 1A.

Each of DUs 174 also includes processing hardware, which may include one or more general-purpose processors (e.g., CPUs) and computer-readable memory storing machine-readable instructions executable on 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 a base station (e.g., base station 104) is acting as a 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 processes.

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

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

Fig. 2A shows in simplified manner an example protocol stack 200 according to which a UE (e.g., UE 102A, 102B, or 103) may communicate with an eNB/ng-eNB or a gNB/en-gNB (e.g., one or both of base stations 104, 106). In the example protocol stack 200, the PHY sublayer 202A of EUTRA 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 in turn provides RLC channels to the EUTRA PDCP sublayer 208 and, in some cases, to the NR PDCP sublayer 210. Similarly, NR PHY 202B provides transport channels to NR MAC sublayer 204B, which in turn provides logical channels to NR RLC sublayer 206B. The NR RLC sublayer 206B in turn provides RLC channels to the NR PDCP sublayer 210. In some implementations, the UE 102A or 102B 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 the EUTRA and NR interfaces. Further, as shown in fig. 2A, the UE 102A or 102B may support NR PDCP 210 layering on EUTRA RLC 206A, and an SDAP sublayer 212 layering on NR PDCP sublayer 210. The sub-layers are also referred to herein simply as "layers".

The EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 receive packets, which 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, which may be referred to as Protocol Data Units (PDUs), e.g., to the RLC layer 206A or 206B. Except where the difference between SDUs and PDUs is important, the present disclosure sometimes refers to both SDUs and PDUs as "packets" for simplicity. The packets may be MBS packets or non-MBS packets. For example, the MBS packets may include application content of the MBS service (e.g., IPv4/IPv6 multicast delivery, IPTV, wireless software delivery, group communication, ioT applications, V2X applications, and/or emergency messages related to public safety). As another example, the MBS packet may include application control information for the MBS service.

On the control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 may provide SRBs to exchange, for example, RRC messages or non-access stratum (NAS) messages. On the user plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 may provide DRBs to support data exchange. The data exchanged on the NR PDCP sublayer 210 may be, for example, an SDAP PDU, an IP packet, or an ethernet packet.

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

In some implementations, a base station (e.g., base station 104 or 106) broadcasts MBS data packets via one or more MRBs, and in turn, UEs 102A or 102B receive MBS data packets via the MRBs. The base station may include the configuration of 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 MBS data packets via RLC sublayer 206, MAC sublayer 204, and PHY sublayer 202, and accordingly, UE 102A or 102B receives MBS data packets using PHY sublayer 202, MAC sublayer 204, and RLC sublayer 206. In such implementations, the base station and the UE 102A or 102B may not use the PDCP sublayer 208 and the SDAP sublayer 212 to transmit MBS data packets. In other implementations, the base station transmits MBS data packets via PDCP sublayer 208, RLC sublayer 206, MAC sublayer 204, and PHY sublayer 202, and accordingly, UE 102A or 102B receives MBS data packets using PHY sublayer 202, MAC sublayer 204, RLC sublayer 206, and PDCP sublayer 208. In such implementations, the base station and the UE 102A or 102B may not use the SDAP sublayer 212 to transmit MBS data packets. In still other implementations, the base station transmits MBS data packets via the SDAP sublayer 212, PDCP sublayer 208, RLC sublayer 206, MAC sublayer 204, and PHY sublayer 202, and accordingly, the UE 102A or 102B receives MBS data packets using the PHY sublayer 202, MAC sublayer 204, RLC sublayer 206, PDCP sublayer 208, and SDAP sublayer 212.

Fig. 2B illustrates in simplified form an example protocol stack 250 that the UE 102A, 102B, or 103 may use to communicate with a DU (e.g., DU 174) and a CU (e.g., CU 172). The radio protocol stack 200 is functionally partitioned as shown by the radio protocol stack 250 in fig. 2B. A CU at either base station 104 or 106 may maintain all control and upper layer functionality (e.g., RRC 214, SDAP 212, NR PDCP 210) while lower layer operations (e.g., NR RLC 206B, NR MAC 204B, and NR PHY 202B) are delegated to DUs. To support a connection with 5GC, NR PDCP 210 provides SRBs to RRC 214, and NR PDCP 210 provides DRBs to SDAP 212 and SRBs to RRC 214.

Fig. 2C shows in a simplified manner an example protocol stack 260 that the UE 102A, 102B, or 103 may use to communicate with a DU (e.g., DU 174) and a CU (e.g., CU 172). The protocol stack 260 is substantially similar to the protocol stack 250, but here the RRC layer 214 is layered over the PDCP layer 210 to convey RRC messages between the UE and the CU 172, which is transparent to the DU 174.

Fig. 2D is a block diagram of an example protocol stack 270 according to which CUs 172 and DUs 174 may communicate user plane traffic. GTP-U layer 278 is layered over UDP 276 and in turn over IP 274. The UDP/IP layers 276, 274 are located above the data link layer 272 and the PHY 271 layers. For example, the PHY layer 271 may be a wired link.

Fig. 2E is a block diagram of an example protocol stack 280 according to which CUs 172 and DUs 174 may communicate control plane traffic. Stack 280 is substantially similar to stack 270, but here a Stream Control Transmission Protocol (SCTP) layer 282 sits on IP layer 274 to convey control messages.

Referring next to fig. 3, which depicts an example architecture 300 of MBS sessions and PDU sessions, MBS session 302A may include tunnel 312A with endpoints located at CN 110 and base stations 104/106 (i.e., base station 104 or base station 106). MBS session 302A may correspond to a certain 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.

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

Tunnel 312A may operate over a transport layer or sub-layer, such as over a User Datagram Protocol (UDP) protocol layered over an Internet Protocol (IP). As a more specific example, tunnel 312A may be associated with a General Packet Radio System (GPRS) tunneling protocol (GTP). For example, tunnel 312A may correspond to a certain IP address (e.g., an IP address of base station 104/106) and a certain Tunnel Endpoint Identifier (TEID) (e.g., assigned by base station 104/106). More generally, tunnel 312A may have any suitable transport layer configuration. CN 110 may specify the IP address and TEID address in the header of the tunnel packet including the MBS data packet and transmit the tunnel packet downstream to base station 104/106 via tunnel 312A. The header may include an IP address and/or TEID. For example, the header includes an IP header and a GTP header, which include an IP address and a TEID, respectively. Thus, the base station 104/106 may use the IP address and/or TEID to identify the data packet communicated via the tunnel 312A.

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

For each of tunnels 312A, 312B, etc., MBS traffic may include one or more quality of service (QoS) flows. For example, MBS traffic on tunnel 312B may include a set of flows 316 that includes QoS flows 316A, 316B, … … 316L, where L >1. Furthermore, the logical channels of the MRB may 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 MTCHs of MRBs 314B-1 and maps QoS flow 316L to MTCHs of MRBs 314B-N.

In various scenarios, CN 110 may allocate different types of MBS services to different QoS flows. For example, a flow with a relatively high QoS value may correspond to an audio packet, while a flow with a relatively low QoS value may correspond to a video packet. As another example, a stream with a relatively higher QoS value may correspond to an I frame or a full picture used in video compression, while a stream with a relatively lower QoS value may correspond to a P frame or a predicted picture that includes only modifications to the I frame.

With continued reference to fig. 3, base stations 104/106 and CN 110 may maintain one or more PDU sessions to support unicast traffic between CN 110 and a particular UE. The 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, …, 324A-N. Each of the DRBs 324A may correspond to a respective logical channel, such as a Dedicated Traffic Channel (DTCH). Base stations 104/106 and CN 110 may also maintain one or more other PDU sessions to support unicast traffic between CN 110 and a particular UE. For example, PDU session 304B may include a UE-specific DL tunnel and/or a UE-specific UL tunnel 322B corresponding to one or more DRBs 324B (such as DRBs 324B-1, 324B-2, …, 324B-N). Each of the DRBs 324B may correspond to a respective logical channel, such as DTCH.

Referring now to fig. 4, which depicts example MRBs and DRBs where base stations 104/106 are implemented in a distributed manner, one or more DUs 174 may be associated with CU 172. CUs 172 and DUs 174 may establish tunnels for downlink data and/or uplink data associated with MRBs or DRBs. MRB 314A-1 discussed above may be implemented as MRB 402A, which connects CU 172 to multiple UEs, such as, for example, UEs 102A and 102B. MRB 402A may include DL tunnel 412A connecting CU 172 with DU 174 and DL logical channel 422A corresponding to DL tunnel 412A. In particular, DU 174 may map downlink traffic received via DL tunnel 412A to DL logical channel 422A, which may be, for example, an MTCH or a DTCH. DL tunnel 412A may be a common DL tunnel via which CU 172 transmits MBS data packets to multiple UEs. Alternatively, DL tunnel 412A may be a UE-specific DL tunnel via which CU 172 transmits MBS data packets to a specific UE.

Optionally, MRB 402A also includes UL tunnel 413A connecting CU 172 with DU 174 and UL logical channel 423A corresponding to UL tunnel 413A. For example, UL logical channel 423A may be DTCH. DU 174 may map uplink traffic received via UL logical channel 423A to UL tunnel 413A.

Tunnels 412A and 413A may operate on a transport layer or sub-layer of the F1-U interface. As a more specific example, CUs 172 and DUs 174 may use F1-U for user plane traffic, and tunnels 412A and 413A may be associated with GTP-U protocols layered over UDP/IP, where IP is layered over the appropriate data link and Physical (PHY) layers. Moreover, in at least some cases, MRB 402 and/or DRB 404 additionally support control plane traffic. More specifically, CU 172 and DU 174 may exchange F1-AP messages over an F1-C interface that relies on the Stream Control Transmission Protocol (SCTP) layered over IP, where IP is layered over the appropriate data link and PHY layers, similar to F1-U.

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.

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

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

Referring now to fig. 5A, in scenario 500A, UE 102 first performs (502) an MBS session joining procedure with CN 110 via base station 104 to join a particular MBS session. While fig. 5A and 5B depict only a single "UE 102", it should be understood that this may be either or both UEs 102A, 102B. In some scenarios, UE 102 then performs additional one or more MBS joining procedures, and event 502 is thus the first MBS joining procedure of the multiple MBS joining procedures. The processes 502 and 586 may occur in any order when the base station 104 configures a common DL tunnel for MBS traffic instead of a UE-specific tunnel. In other words, the base station 104 may configure the common DL tunnel even before a single UE joins the MBS session.

To perform MBS session joining procedure 502, in some implementations, UE 102 sends an MBS session joining request message to CN 110 via base station 104. In response, CN 110 may send an MBS session join response message to UE 102 via base station 104 to authorize UE 102 to access the first MBS session. In some implementations, the UE 102 may include the MBS session ID of the MBS session in the MBS session join request message. In some cases, CN 110 includes the MBS session ID in the MBS session join response message. In some implementations, UE 102 may send an MBS session join complete message to CN 110 via base station 104 in response to the MBS session join response message.

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

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 (5 GMM) messages or 5G session management (5 GSM) messages. In the case of a 5GSM message, UE 102 may transmit (via base station 104) a (first) UL container message including an MBS session join request message to CN 110, CN 110 may transmit (via base station 104) a DL container message including an MBS session join response message to UE 102, and UE 102 may transmit (second) UL container message including an MBS session join complete message to CN 110 via base station 104. These container messages may alternatively be 5GMM messages. In some implementations, the MBS session join request message, the MBS session join response message, and the MBS session join completion message may be a PDU session modification request (PDU Session Modification Request) message, a PDU session modification command (PDU Session Modification Command) message, and a PDU session modification completion (PDU Session Modification Complete) message, respectively. For simplicity of the following description, the MBS session join request message, the MBS session join response message, and/or the MBS session join completion message may also represent their corresponding container messages.

In some implementations, UE 102 may perform (not shown) a PDU session establishment procedure with CN 110 via base station 104 to establish a PDU session in order to perform a (first) MBS session joining procedure. During the PDU session establishment procedure, UE 102 may communicate the PDU session ID of the PDU session with CN 110 via base station 104.

Before, during, or after (first) MBS session joining procedure 502, CN 110 may send (504) a (first) CN-to-BS message including the first MBS session ID and/or PDU session ID to CU 172 to request CU 172 to configure resources for the first MBS session. In response to receiving (504) the first CN-to-BS message, CU 172 sends (506) a CU-to-DU message to DU 174 to request establishment of an MBS context and/or a common DL tunnel for the first MBS session. In response to receiving (506) the CU-to-DU message, DU 174 sends (508) a DU-to-CU message to CU 172 including the first DU DL transport layer configuration to configure a common CU-to-DU DL tunnel for the first MBS session (e.g., for the MRB identified by one of the MRB IDs). DU 174 may 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 ones of the MRB IDs. In some implementations, DU 174 may include an MRB ID associated with the first DL transport layer configuration and/or the additional DL transport layer configuration in the DU to CU message. In some implementations, the CU-to-DU message is a generic F1AP message or a dedicated F1AP message (e.g., MBS context setup request message) specifically defined to convey 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 defined specifically for this purpose (e.g., MBS context setup response message). CN 110 may additionally include a quality of service (QoS) configuration for the first MBS session in the first CN-to-BS message. In such cases, CU 172 may include QoS configuration in the CU-to-DU message (event 506).

CU 172 sends 510 a first BS to CN message (e.g., MBS session resource setup response message) in response to the message of event 504. CU 172 may include the first MBS session ID and/or 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 to cause CN 110 to send MBS data to CU 172. The DL transport layer configuration includes a transport layer address (e.g., IP address and/or TEID) to identify the common DL tunnel. In some implementations, the CN-to-BS message of event 504 is a generic NGAP message or a dedicated NGAP message specifically defined for requesting resources of an MBS session (e.g., an MBS session resource establishment 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 as a resource conveying 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 may be non-UE specific messages.

In some implementations, the QoS configuration includes QoS parameters for MBS sessions. In some implementations, the QoS configuration includes configuration parameters to configure one or more QoS flows for the MBS session (see fig. 3 and description above). In some implementations, the configuration parameters include one or more QoS flow IDs that identify QoS flows. Each of the QoS flow IDs identifies a particular one of the QoS flows. In some implementations, the configuration parameters include QoS parameters for each QoS flow. The QoS parameters may include a 5G QoS identifier (5 QI), a priority level, a packet delay budget, a packet error rate, an average window, and/or a maximum data burst size. CN 110 may assign different QoS parameter values for QoS flows.

Events 504, 506, 508, and 510 are collectively referred to in fig. 5A as MBS session resource establishment procedure 586.

In the case that the CN110 grants the additional MBS session to the UE 102 during the additional MBS session joining, the CN110 may include the additional MBS session ID, and optionally the QoS configuration of the additional MBS session ID, in the first CN-to-BS message, the subsequent CN-to-BS message, or an additional CN-to-BS message similar to the first or subsequent CN-to-BS message. In such cases, CU 172 includes additional transport layer configurations for additional MBS sessions in the first BS-to-CN message, the subsequent BS-to-CN message, or additional BS-to-CN messages similar to the first or subsequent BS-to-CN messages, for configuring additional common DL tunnels. Each of the transport layer configurations configures a particular one of the common DL tunnels and may be associated with a particular one of the additional MBS sessions. Alternatively, cn110 may perform an additional MBS session resource establishment procedure with CU 172 to obtain additional transport layer configuration from CU 172, similar to single session MBS session resource establishment procedure 586 shown in fig. 5A. The transport layer configuration may be different in order to distinguish between different common DL tunnels. Specifically, any pair of transport layer configurations may have different IP addresses, different DL TEIDs, or different IP addresses and different DL TEIDs.

In some implementations, CN 110 may indicate a list of UEs joining the first MBS session in the first CN-to-BS message. In other implementations, CN 110 may send (512) a second CN-to-BS message to CU 172 indicating a list of UEs joining the first MBS session. CN 110 may include the first MBS session ID and/or PDU session ID in the second CN-to-BS message. CU 172 may send (519) a second BS-to-CN message to CN 110 in response to second CN-to-BS message 512. In such cases, 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. CU 172 may include the first MBS session ID and/or PDU session ID in the second BS to CN message. For example, the UE list may include UE 102A and/or UE 102B. To indicate the list of UEs, CN 110 may include a list of (CN UE interface ID, RAN UE interface ID) pairs, each pair identifying a particular UE of the UEs. CN 110 assigns a CN UE interface ID and CU 172 assigns a RAN UE interface ID. Before CN 110 sends (512) the list of pairs (CN UE interface ID, RAN UE interface ID) in the second CN-to-BS message, CU 172 sends (not shown) a BS-to-CN message (e.g., NGAP message, initial UE message (INITIAL UE MESSAGE), or path switch REQUEST (PATH SWITCH REQUEST) message) including the RAN UE interface ID to CN 110 for each of the UEs, and CN 110 sends a CN-to-BS message (e.g., NGAP message, initial context setup request (INITIAL CONTEXT SETUP REQUEST) message, or path switch request acknowledgement (PATH SWITCH REQUEST ACKNOWLEDGE) message) to CU 172. In one example, the list of pairs includes a first pair (first CN UE interface ID and first RAN UE interface ID) identifying UE 102A and a second pair (second CN UE interface ID, second RAN UE interface ID) identifying UE 102B. 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, CN 110 may include a list of UE IDs, each UE ID identifying a particular one of the UEs. In some implementations (not shown), CN 110 may allocate UE IDs and send each of the UE IDs to a particular one of the UEs in NAS procedures (e.g., registration procedures) performed by CN 110 with the particular UE. For example, the list of UE IDs may include a first UE ID of UE 102A and a second UE ID of UE 102B. In some implementations, the UE ID is an S-temporary Mobile subscriber identity (S-TMSI) (e.g., 5G-S-TMSI). CU 172 may receive (not shown) UE IDs from UE 102 or CN 110 for each of the UEs before CN 110 sends (512) the list of UE IDs. For example, CU 172 may receive (not shown) an RRC message (e.g., RRCSetupComplete message) including the UE ID from UE 102 during the RRC connection setup procedure. In another example, CU 172 may receive (not shown) a CN-to-BS message (e.g., NGAP message, initial context setup request (INITIAL CONTEXT SETUP REQUEST) message, or UE info transfer (UE INFORMATION TRANSFER) message) from CN 110 that includes the UE ID.

In other implementations, CN 110 may send (512) a second CN-to-BS message to CU 172 indicating (only) UE 102 (e.g., UE 102A or UE 102B) joining the first MBS session. The second CN-to-BS message may be a UE-related message for UE 102. That is, the second CN-to-BS message is specific to UE 102. In response to receiving the second CN-to-BS message, CU 172 may send 514 a UE context request message for UE 102 to DU 174. In some implementations, CU 172 may include the first MBS session ID and/or an MRB ID of an MRB associated with the first MBS session (ID) in the UE context request message. In response to the UE context request message, DU 174 transmits 516 a UE context response message including configuration parameters to CU 172 to cause UE 102 to receive MBS data for the first MBS session. In some implementations, CU 172 may include QoS configuration in the UE context request message. In such cases, CU 172 may or may not include QoS configuration in the CU-to-DU message sent 506 during MBS session resource establishment procedure 586. The configuration parameter(s) may be associated with the MRB/MRB ID. In some implementations, the DU 174 generates the DU configuration to include the configuration parameters and includes the DU configuration in the UE context response message. In some implementations, the DU configuration can be 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 may include one or more Logical Channel IDs (LCIDs) to configure one or more logical channels. Each of the LCIDs identifies a particular logical channel of the one or more logical channels.

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 or 102B).

In the case where the CN 110 grants the additional MBS session to the UE 102 during the additional MBS session joining, the CN 110 may include the additional MBS session ID and/or the QoS configuration of the additional MBS session ID in the first CN-to-BS message or the second CN-to-BS message. In such cases, CU 172 may include additional MBS session IDs and MRB IDs in the CU-to-DU message, while DU 174 includes additional DU transport layer configurations in the DU-to-CU message to configure additional CN-to-BSDL tunnels for the additional MBS sessions. Alternatively, similar to events 506 and 508, cu 172 may perform additional MBS session resource setup procedures with DU 174 to obtain additional DU DL transport layer configurations. In some implementations, CU 172 includes an additional CU DL transport layer configuration for the additional MBS session in the first BS to CN message for configuring the additional CN to BS common DL tunnel. Each of the transport layer configurations configures a specific DL tunnel of the public CN to BSDL tunnels and may be associated with a specific MBS session of the additional MBS sessions. Alternatively, cn 110 may perform additional MBS session resource establishment procedures with CU 172 to obtain additional CU DL transport layer configurations from CU 172, similar to MBS session resource establishment procedure 586. The transport layer configuration may be different in order 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.

In some implementations, CN 110 includes the QoS configuration in the second CN-to-BS message. In such cases, CN 110 may include the QoS configuration in the first CN-to-BS message, or omit the QoS configuration. In some implementations, the DU 174 generates configuration parameters to cause the UE 102 to receive MBS data for the first MBS session in response to receiving (506) the CU-to-DU message or receiving (514) the UE context request message. In some implementations, CU 172 includes QoS configuration in the UE context request message and/or the CU-to-DU message. DU 174 may determine the contents of the configuration parameters from the QoS configuration. When CU 172 does not include a QoS configuration in either the CU-to-DU message or in the UE context request message, DU 174 may determine the value of the configuration parameter according to a predetermined (default) QoS configuration.

In some implementations, the UE context request message and the UE context response message are a UE context setup request (UE Context Setup Request) message and a UE context setup response (UE Context Setup Response) message, respectively. In other implementations, the UE context request message and the UE context response message are a UE context modification request (UE Context Modification Request) message and a UE context modification (UE Context Modification Response) response message, respectively.

After receiving (516) the UE context response message, CU 172 generates an RRC reconfiguration message including configuration parameters and one or more MRB configurations and transmits (518) the RRC reconfiguration message to DU 174.DU 174 in turn transmits 520 the RRC reconfiguration message to UE 102. UE 102 then transmits 522 an RRC reconfiguration complete message (e.g., RRCReconfigurationComplete message) to DU 174, which in turn transmits 523 the RRC reconfiguration complete message to CU 172.

Events 512, 514, 516, 518, 519, 520, 522, and 523 are collectively referred to in fig. 5A as MBS radio connection reconfiguration procedure 588. Events 514, 516, 518, 520, 522, and 523 are collectively referred to in fig. 5A as MBS radio connection reconfiguration procedure 589.

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

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

In some implementations, respective instances of MBS radio connection reconfiguration procedure 588 occur for each of UE 102A and UE 102B. The configuration parameters for the MBS data for the UE 102A and the UE 102B to receive the first MBS session may be the same.

In some implementations, CU 172 includes a CU DL transport layer configuration in the second BS-to-CN message and/or in subsequent BS-to-CN messages. In other words, CU 172 may 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 joined the same MBS session. In such implementations, CN 110 may mix MBS resource setup procedure 586 and MBS radio connection reconfiguration procedure 588 into a single procedure.

In the case where CU 172 performs MBS resource establishment procedure 586 (e.g., events 504, 510) with CN 110 to establish a common CN-to-BSDL tunnel for the first MBS session, CU 172 may avoid including the DL transport layer configuration for the first MBS session in the second BS-to-CN message. In such cases, CN 110 may avoid including the UL transport layer configuration for the first MBS session in the second CN-to-BS message. In the case where DU 174 performs MBS resource establishment procedure 586 (e.g., events 506, 508) with CU 172 to establish a common CU-to-DU DL tunnel for the first MBS session, DU 174 may avoid including the DL transport layer configuration for the first MBS session in the UE context response message. In such cases, CU 172 may avoid including the UL transport layer configuration for the first MBS session in the UE context request message.

Upon receiving (510) the first BS-to-CN message or receiving (519) the second BS-to-CN message, CN 110 may send (524) MBS data (e.g., one or more MBS data packets, also interchangeably referred to herein as "MBS content data" or "MBS payload data") to CU 172 via a common CN-to-BSDL tunnel, which in turn sends (526) the MBS data to DU 174 via a common CU-to-DU tunnel. DU 174 transmits (e.g., multicasts or unicasts) MBS data to UE 102 (e.g., UE 102A and/or UE 102B) via one or more logical channels (528). UE 102 receives 528 the MBS data via one or more logical channels. For example, CU 172 receives (524) the MBS data packets, generates PDCP PDUs including the MBS data packets, and transmits (526) the PDCP PDUs to DU 174. The DU 174 in turn generates a MAC PDU including a logical channel ID and PDCP PDU and transmits (528) the MAC PDU to the UE 102 via multicast or unicast. The UE 102 receives (528) the MAC PDU via multicast or unicast, retrieves the PDCP PDU and logical channel ID from the MAC PDU, identifies PDCP PDUs associated with the MRB according to the logical channel ID, and retrieves MBS data packets from the PDCP PDUs according to the PDCP configuration within the MRB configuration.

In some implementations, CU 172 may configure (determine) a UE-specific CN-to-BSDL tunnel for UE 102 in response to receiving (504) the first CN-to-BS message or receiving (512) the second CN-to-BS message. In such cases, CU 172 may omit event 506 and may include a DL transport layer configuration in the second BS-to-CN message that configures the UE-specific DL tunnel. CN 110 may tunnel 524 the MBS data to CU 172 via the UE-specific CN to BSDL tunnel. In some implementations, CU 172 may configure (determine) a UE-specific CU-to-DU DL tunnel for UE 102 in response to receiving (504) the first CN-to-BS message or receiving (512) the second CN-to-BS message. In such cases, CU 172 may omit event 510 and DU 174 may include in the UE context response message a DL transport layer configuration that configures the UE-specific CU-to-DU DL tunnel. In such cases, the CU 174 may tunnel 526 MBS data to the DU 174 via a UE-specific CU-to-DU DL tunnel.

In some implementations, one or more MRB configurations configuring one or more MRBs are associated with the first MBS session. In some implementations, the configuration parameters further include one or more RLC bearer configurations, each RLC bearer configuration being associated with a particular MRB. Each of the MRB configurations may include an MRB ID, a PDCP configuration, a first MBS session ID, a PDCP re-establishment indication (e.g., reestablishPDCP), and/or a PDCP restoration indication (e.g., recoveryPDCP). In some implementations, the PDCP configuration may be a PDCP-Config IE of the DRB. In some implementations, the RLC bearer configuration may be RLC-BearerConfig IE. In some implementations, RLC bearer configuration may include configuring a logical channel ID of a Logical Channel (LC). 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., logicalChannelConfig IE) that configures the logical channel. In some implementations, the RLC bearer configuration may include an MRB ID.

In some implementations, CU 172 may configure the MRB as DL-RB only in an MRB configuration. For example, CU 172 avoids including UL configuration parameters in the PDCP configuration in the MRB configuration to configure the MRB as DL-only RBs. For example, as described above, CU 172 includes only DL configuration parameters in the MRB configuration. In such cases, CU 172 configures UE 102 not to transmit UL PDCP data PDUs via MRB to DU 174 and/or CU 172 by excluding UL configuration parameters for the MRB in the PDCP configuration in the MBR configuration. In another example, DU 174 avoids including UL configuration parameters in the RLC bearer configuration. In such cases, DU 174 configures UE 102 not to transmit control PDUs to base station 104 via a logical channel by excluding UL configuration parameters from RLC bearer configuration.

In the case where DU 174 includes UL configuration parameters in the RLC bearer configuration, UE 102 may use the UL configuration parameters to transmit control PDUs (e.g., PDCP control PDUs and/or RLC control PDUs) to DU 174 via a logical channel. If the control PDU is a PDCP control PDU, then DU 174 may send the PDCP control PDU to CU 172. For example, CU 172 may configure UE 102 to receive MBS data using a (decompression) protocol (e.g., a robust header compression (ROHC) protocol), e.g., in an MRB configuration. In this case, when the CU 172 receives (524) the MBS data packet from the CN 110, the CU 172 compresses the MBS data packet using a compression protocol to obtain a compressed MBS data packet, and transmits (526) PDCP PDUs including the compressed MBS data packet to the DU 174 via a common CU-to-DU DL tunnel. The DU 174 in turn transmits (e.g., multicasts or unicasts) the PDCP PDU to the UE 102 via a logical channel (528). When the UE 102 receives the PDCP PDU via the logical channel, the UE 102 retrieves the compressed MBS data packet from the PDCP PDU. The UE 102 decompresses the compressed MBS data packets using a (decompression) protocol to obtain the original MBS data packets. In such cases, the UE 102 may transmit PDCP control PDUs including header compression protocol feedback (e.g., interspersed ROHC feedback (INTERSPERSED ROHC FEEDBACK)) for operation of the header (decompression) protocol to the DU 174 via a logical channel. The DU 174 in turn sends PDCP control PDUs to the CU 172 via a UE-specific UL tunnel, i.e., UL tunnel specific to the UE 102 (e.g., UE 102A). In some implementations, CU 172 may include a CU UL transport layer configuration in the UE context request message that configures the UE-specific UL tunnel. The CU UL transport layer configuration includes a CU transport layer address (e.g., an Internet Protocol (IP) address) and a CU UL TEID to identify a UE-specific UL tunnel.

In some implementations, the MRB configuration may be MRB-ToAddMod IE that includes an MRB ID (e.g., MRB-Identity or MRB-Identity). The MRB ID identifies a particular MRB of the MRBs. The base station 104 sets the MRB ID to a different value. Where CU 172 has configured DRBs to UE 102 for unicast data communication, in some implementations, CU 172 may set one or more of the MRB IDs to a different value than the DRB ID of the DRBs. In such cases, UE 102 and CU 172 may distinguish whether an RB is an MRB or a DRB according to the RB ID of the RB. In other implementations, 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 cases, UE 102 and CU 172 may distinguish whether an RB is an MRB or a DRB based on the RB ID of the RB and the RRC IE configuring the RB. For example, the DRB configuration configuring the DRB is DRB-ToAddMod IE including a DRB Identity (e.g., DRB-Identity or DRB-Identity) and a PDCP configuration. Thus, if the UE 102 receives the DRB-ToAddMod IE of the configured RB, the UE 102 can determine that the RB is a DRB, and if the UE 102 receives the MRB-ToAddMod IE of the configured RB, the RB is an MRB. Similarly, if CU 172 transmits DRB-ToAddMod IE of the configured RB to UE 102, CU 172 can determine that the RB is a DRB, and if CU 172 transmits MRB-ToAddMod IE of the configured RB to UE 102, then it is determined that the RB is an MRB.

In some implementations, the configuration parameters for receiving MBS data for 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. In some implementations, the configuration parameters may or may not include a group radio network temporary identifier (G-RNTI). The RRC reconfiguration message of the UEs joining the first MBS session (e.g., UE 102A and UE 102B) includes the same configuration parameters used to receive the 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 for receiving non-MBS data.

In some implementations, CU 172 may include an MBS session join response message in the RRC reconfiguration message. UE 102 may include the MBS session join complete message in the RRC reconfiguration complete message. Alternatively, UE 102 may send a UL RRC message including an MBS session join complete message to CU 172 via DU 174. The UL RRC message may be a UL information transfer message or any suitable RRC message that may include UL NAS PDUs. CU 172 may include an MBS session join complete message in the second BS to CN message. Alternatively, CU 172 may send BS-to-CN messages (e.g., uplink NAS transport (UPLINK NAS TRANSPORT) messages) including MBS session join completion messages to CN 110.

In other implementations, CU 172 transmits a DL RRC message including the MBS session join response message to UE 102. The DL RRC message may be DLInformationTra nsfer message, another RRC reconfiguration message, or any suitable RRC message that may include a DL NAS PDU. UE 102 may send a UL RRC message including an MBS session join complete message to CU 172 via DU 174. The UL RRC message may be ULInf ormationTransfer message, another RRC reconfiguration complete message, or any suitable RRC message that may include UL NAS PDUs.

With continued reference to fig. 5a, ue 103 may perform (530) an MBS session joining procedure similar to procedure 502 discussed above. UE 103 may perform a PDU session establishment procedure with CN 110 via base station 104 as described with reference to procedure 502. UE 103 may communicate a PDU session ID with CN 110 during PDU session establishment. The UE 103 may join the same MBS session with the UE 102 by sending an MBS session join request and specifying the same MBS session ID. In this example scenario, after the base station 104 begins transmitting 528 MBS data packets to the UE 102, the UE 103 joins the MBS session. CN 110 transmits (532) 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 of the MBS session corresponding to the MBS session ID.

In some scenarios, CU 172 or CN 110 determines that a DL tunnel already exists for the MBS session identified in event 532 and does not need to perform procedure 586. However, optionally, CU 172 sends 534 CU-to-DU message to DU 174 to trigger an MBS radio connection reconfiguration procedure for the first MBS session similar to event 589, and DU 174 responds 536 with a DU configuration.

CU 172 transmits (538) an RRC reconfiguration message to DU 174, and DU 174 transmits (540) an RRC reconfiguration message to UE 103 to configure UE 103 to receive MBS services. When UE 102 (i.e., UE 102A and/or UE 102B) is operating in the same cell as UE 103, the RRC reconfiguration message may include the same LCID (value), MRB configuration, and RLC bearer configuration as event 520. For example, when UEs 102 and 103 operate in different cells, the RRC reconfiguration message may have different G-RNTIs, LCIDs, and/or RLC bearer configurations. When UEs 102 and 103 operate in different cells, the RRC reconfiguration message may include the same MRB configuration as event 520. As shown in fig. 3, CU 172 may map data packets arriving via a common CN-to-BSDL tunnel to one or more MRBs, each MRB corresponding to a common CU-to-DU DL tunnel and/or a corresponding logical channel.

The UE 103 transmits 542 an RRC reconfiguration complete message (e.g., RRCReconfigurationComplete message) to the base station 104 (specifically to the DU 174) in response to the RRC reconfiguration message of event 540. In response to DU 174 of base station 104 receiving (542) the RRC reconfiguration complete message, DU 174 transmits the RRC reconfiguration complete message to CU 172 (not shown in fig. 5A). Before or after receiving (542) the RRC reconfiguration complete message, the base station 104 in some cases sends (539) another BS-to-CN message to the CN 110, e.g., in a manner substantially similar to event 519. For example, the BS to CN message may indicate an updated list of UEs associated with the MBS session specified in event 532. After UE 103 joins (530) the MBS session and obtains (at event 540) the necessary RRC configuration, CU 172 continues to receive (544) the MBS data via the public CN-to-BSDL tunnel and transmits (546) the MBS data to DU 174 via the public CU-to-DU DL tunnel. In some implementations, DU 174 transmits 548 MBS data to UE 102 and UE 103 via multicast. UE 102 and UE 103 may receive 548 MBS data similar to event 528. Alternatively, base station 104 may transmit 548 MBS data to UE 102 and UE 103, respectively, via unicast.

Referring next to fig. 5B, a scenario 500B is depicted that is substantially similar to scenario 500A, but CN 110 provides a list of UEs joining a non-MBS session before configuring the CN-to-BS tunnel for the MBS, but not after. Events in this scenario that are similar to those discussed above are labeled with the same reference numerals, and the example and implementation of fig. 5A is applicable to fig. 5B. Differences between the scenario of fig. 5A and the scenario of fig. 5B are discussed below.

UE 102 performs (550) a PDU session establishment procedure with CN 110 via base station 104, similar to procedure 502, but for non-MBS sessions. After process 550, CN 110 transmits 552 a CN-to-BS message including the PDU session ID to CU 172. CU 172 sends 554 a CU-to-DU message to DU 174 to trigger the reconfiguration procedure for the PDU session, and DU 174 responds 556 with the DU configuration. The following events 558, 560, 562, 563 are similar to events 518, 520, 522, 523 of fig. 5A, but are directed to DRB configurations rather than MRB configurations. Before or after receiving (562) the RRC reconfiguration complete message, the base station 104 in some cases sends (559) another BS-to-CN message to the CN 110, e.g., in a manner substantially similar to event 519. For example, the BS to CN message may indicate an updated list of UEs associated with the MBS session specified in event 552. After UE 102 obtains 560 the necessary RRC configuration, CU 172 continues to receive 564 the non-MBS data via the UE-specific CN-to-BSDL tunnel and transmits 566 the non-MBS data to DU 174 via the UE-specific CU-to-DU DL tunnel and via unicast. Thus, UE 102 may receive 568 non-MBS data from DU 174.

In such cases, similar to the first or second CN-to-BS message, CN 110 may include additional MBS session IDs in the CN-to-BS message during MBS resource setup and UE-specific MBS session configuration, and optionally QoS configuration for the additional MBS session IDs. In such a case, similar to the first or second BS-to-CN message, CU 172 includes additional transport layer configurations for additional MBS sessions in the BS-to-CN message for configuring additional common DL tunnels during MBS resource establishment and UE-specific MBS session configuration. Each of the transport layer configurations configures a particular one of the common DL tunnels and may be associated with a particular one of the additional MBS sessions. The transport layer configuration may be different in order 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.

The UE that is receiving or interested in receiving the MBS may transmit an MBS interest indication to the network (e.g., to CN 110). Based on the MBS interest indication, the network attempts to enable the UE to receive MBS and unicast services according to the UE's capabilities (e.g., the UE's radio capabilities). In the MBS interest indication, the UE may indicate a set of frequencies (including one or more frequencies) that the UE uses to receive the MBS or is interested in receiving the MBS. The MBS interest indication may also indicate a list of MBS services that the UE receives or is interested in receiving on the indicated frequency or frequencies. Furthermore, the UE may transmit an MBS interest indication regardless of whether the serving cell supports MBS. In some cases, the UE may send the first MBS interest indication to the network and later send a second updated MBS interest indication.

In general, a UE (e.g., UE 102A) and/or a RAN (e.g., RAN 105) manage MBS-related information. In response to determining to modify the radio connection between the UE and the RAN, the UE may determine to reserve or release the MBS interest indication. If the UE retains the MBS interest indication, the UE may send an MBS interest indication update to the RAN later. If the UE releases the MBS interest indication, the UE may transmit another MBS interest indication to the RAN after modifying the radio connection.

Likewise, a node of the RAN (e.g., base station 104, or DU 174 and/or CU 172) may also receive the MBS interest indication from the UE and, in response to determining to modify the radio connection between the UE and the RAN, reserve or release the configuration included in the MBS interest indication. The trigger event that may cause the UE and/or RAN to determine to release or retain the MBS interest indication may include, for example, the UE detecting a radio connection failure, or the UE suspending, resuming or re-establishing a radio connection with the RAN.

Furthermore, the MBS interest indication may be stored at the receiving RAN node, at other RAN nodes, and/or at one or more CNs of the wireless communication system. For example, a RAN node receiving an MBS interest indication from a UE may forward the received UE MBS interest indication to another RAN node, CN, etc., any of which may forward the UE MBS interest indication to other RAN nodes and/or CNs.

Referring now to fig. 6A, an example method 600A for determining whether to transmit a data packet using multicast or unicast based on whether the data packet arrived via a common tunnel or a UE-specific tunnel may be implemented in a RAN node (e.g., base station 104 or DU 174) of the present disclosure, for example. The method 600A begins at block 602, where the RAN node receives a data packet (e.g., events 518, 524, 526, 538, 544, 546, 564, 566) from an upstream node. At block 604, the RAN node determines whether the data packet was received via a common DL tunnel. If the data packet is received via a common DL tunnel, the RAN node transmits the data packet to multiple UEs via multicast (e.g., events 528, 548) at block 606. If the data packet is not received via a common DL tunnel (e.g., if the data packet is received via a UE-specific DL tunnel or via a control plane message), the RAN node transmits the data packet to the specific UE via unicast at block 608 (e.g., events 520, 540, 560, 568).

Referring now to fig. 6B, an example method 600B for determining whether to transmit a data packet using multicast or unicast based on whether the data packet arrived via a first tunnel or a second tunnel may be implemented in a RAN node (e.g., base station 104 or DU 174) of the present disclosure, for example. Method 600B is substantially similar to method 600A, except that after block 602, method 600B does not proceed to block 604 as in method 600A, but proceeds to block 605 where the RAN node determines whether the data packet was received via the first DL tunnel or the second DL tunnel. If the data packet is received via the first DL tunnel, the RAN node transmits the data packet to the plurality of UEs via multicast at block 606. If the data packet is received via the second DL tunnel, the RAN node transmits the data packet to the particular UE via unicast at block 608.

Referring now to fig. 7, an example method 700 for determining whether to transmit a data packet using multicast or unicast depending on whether a tunnel through which the data packet arrives has a first or second transport layer configuration may be implemented in a RAN node (e.g., base station 104) of the present disclosure, for example. The method 700 begins at block 702, where the RAN node configures a first DL transport layer configuration including first transport layer information to receive packets (e.g., events 508, 510) from an upstream node. At block 704, the RAN node configures a second DL transport layer configuration including second transport layer information to receive packets from an upstream node (e.g., events 508, 510). At block 706, the RAN node receives DL tunnel packets (e.g., events 518, 524, 526, 538, 544, 546, 564, 566) including the particular transport layer information and the particular data packets from the upstream node. At block 708, the RAN node determines whether the particular transport layer information from the DL tunnel packet is first transport layer information or second transport layer information. If the particular transport layer information is first transport layer information, the method 700 proceeds to block 606 where the RAN node transmits the data packet to the plurality of UEs via multicast (e.g., events 528, 548). If the particular transport layer information is second transport layer information, method 700 proceeds to block 608 where the RAN node transmits the data packet to the particular UE via unicast (e.g., events 520, 540, 560, 568).

Referring now to fig. 8A, an example method 800A for selecting a first logical channel identifier or a second logical channel identifier for a data packet according to whether the data packet arrived via a common tunnel or a UE-specific tunnel may be implemented in a RAN node (e.g., base station 104 or DU 174) of the present disclosure, for example. Method 800A begins at block 802, where a RAN node receives a data packet (e.g., events 518, 524, 526, 538, 544, 546, 564, 566) from an upstream node. At block 804, the RAN node determines whether the data packet was received via a common DL tunnel. If the data packet is received via a common DL tunnel, the RAN node selects a first logical channel ID at block 806. At block 808, the RAN node generates a PDU comprising the first logical channel ID and the data packet. At block 810, the RAN node transmits the PDU to a plurality of UEs (e.g., events 528, 548) via multicast.

If the data packet is not received via a common DL tunnel (e.g., if the data packet is received via a UE-specific DL tunnel or via a control plane message), the RAN node selects a second logical channel ID at block 812. At block 814, the RAN node generates a PDU comprising the second logical channel ID and the data packet. At block 816, the RAN node transmits the PDU to the particular UE (e.g., events 520, 540, 560, 568) via unicast.

Referring now to fig. 8B, an example method 800B for selecting a first logical channel identifier or a second logical channel identifier for a data packet based on whether the data packet arrived via a first tunnel or a second tunnel may be implemented in a RAN node (e.g., base station 104 or DU 174) of the present disclosure, for example. Method 800B is substantially similar to method 800A, except that after block 802, method 800A does not proceed to block 804 as method 800B, but proceeds to block 805 where the RAN node determines whether the data packet was received via the first DL tunnel or the second DL tunnel. If the data packet is received via the first DL tunnel, the RAN node selects a first logical channel ID at block 806. At block 808, the RAN node generates a PDU comprising the first logical channel ID and the data packet. At block 810, the RAN node transmits the PDU to a plurality of UEs via multicast.

If the data packet is not received via the second DL tunnel, the RAN node selects a second logical channel ID at block 812. At block 814, the RAN node generates a PDU comprising the second logical channel ID and the data packet. At block 816, the RAN node transmits the PDU to the particular UE via unicast.

Referring now to fig. 9, in one example, an example method 900 for selecting a first logical channel identifier or a second logical channel identifier for a data packet according to whether a tunnel through which the data packet arrives has a first transport layer configuration or a second transport layer configuration may be implemented in a RAN node (e.g., base station 104) of the present disclosure. The method 900 begins at block 902, where the RAN node configures a first DL transport layer configuration comprising first transport layer information to receive a packet from an upstream node. At block 904, the RAN node configures a second DL transport layer configuration comprising second transport layer information to receive packets from the upstream node. At block 906, the RAN node receives DL tunnel packets (e.g., events 518, 524, 526, 538, 544, 546, 564, 566) including the particular transport layer information and the particular data packets from the upstream node. At block 908, the RAN node determines whether the particular transport layer information from the DL tunnel packet is first transport layer information or second transport layer information. If the particular transport layer information is first transport layer information, method 900 proceeds to block 910, which includes blocks 806, 808, and 810 as discussed above with respect to fig. 8A and 8B. If the particular transport layer information is second transport layer information, method 900 proceeds to block 912, which includes blocks 812, 814, and 816 as discussed above with respect to fig. 8A and 8B.

Referring now to fig. 10A, in one example, an example method 1000A for selecting a group network temporary identifier (G-RNTI) and a first logical channel or UE specific RNTI (C-RNTI) and a second logical channel for a data packet based on whether the data packet arrived via a common tunnel or a UE specific tunnel may be implemented in a RAN node (e.g., base station 104 or DU 174) of the present disclosure. Method 1000A begins at block 1002, where a RAN node receives a data packet (e.g., events 518, 524, 526, 538, 544, 546, 564, 566) from an upstream node. At block 1004, the RAN node determines whether the data packet is received via a common DL tunnel.

If the data packet is received via a common DL tunnel, the RAN node selects a first logical channel ID and G-RNTI at block 1006. At block 1008, the RAN node generates a PDU comprising the first logical channel ID and the data packet. At block 1010, the RAN node generates DCI and a CRC for the DCI to schedule PDSCH transmission of the PDU. At block 1012, the RAN node scrambles the CRC with the G-RNTI to obtain a scrambled CRC.

If the data packet is not received via a common DL tunnel (e.g., if the data packet is received via a UE-specific DL tunnel or via a control plane message), the RAN node selects a second logical channel ID and a C-RNTI at block 1014. At block 1016, the RAN node generates a PDU comprising the second logical channel ID and the data packet. At block 1018, the RAN node generates DCI and a CRC for the DCI to schedule PDSCH transmission of the PDU. At block 1020, the RAN node scrambles the CRC with the C-RNTI to obtain a scrambled CRC.

In any event, after either block 1012 or block 1020, respectively, method 1000A proceeds to block 1022 where the RAN node transmits the DCI and the scrambled CRC on the PDCCH. At block 1024, the RAN node transmits PDSCH transmission of the PDU according to the DCI.

Referring now to fig. 10B, in one example, an example method 1000B for selecting a G-RNTI and a first logical channel or a C-RNTI and a second logical channel for a data packet based on whether the data packet arrived via a first tunnel or a second tunnel may be implemented in a RAN node (e.g., base station 104 or DU 174) of the present disclosure. Method 1000B is substantially similar to method 1000A except that after block 1002, method 1000B does not proceed to block 1004 as with method 1000A, but proceeds to block 1005 where the RAN node determines whether the data packet was received via the first DL tunnel or the second DL tunnel.

If the data packet is received via the first DL tunnel, the RAN node selects a first logical channel ID and G-RNTI at block 1006. At block 1008, the RAN node generates a PDU comprising the first logical channel ID and the data packet. At block 1010, the RAN node generates DCI and a CRC for the DCI to schedule PDSCH transmission of the PDU. At block 1012, the RAN node scrambles the CRC with the G-RNTI to obtain a scrambled CRC.

If the data packet is not received via the second DL tunnel, the RAN node selects a second logical channel ID and a C-RNTI at block 1014. At block 1016, the RAN node generates a PDU comprising the second logical channel ID and the data packet. At block 1018, the RAN node generates DCI and a CRC for the DCI to schedule PDSCH transmission of the PDU. At block 1020, the RAN node scrambles the CRC with the C-RNTI to obtain a scrambled CRC.

Referring now to fig. 11, an example method 1100 for selecting a G-RNTI and a first logical channel or a C-RNTI and a second logical channel for a data packet depending on whether a tunnel through which the data packet arrived has a first or second transport layer configuration may be implemented in a RAN node (e.g., base station 104) of the present disclosure, for example. The method 1100 begins at block 1102, where the RAN node configures a first DL transport layer configuration comprising first transport layer information to receive a packet from an upstream node. At block 1104, the RAN node configures a second DL transport layer configuration including second transport layer information to receive packets from the upstream node. At block 1106, the RAN node receives a DL tunnel packet (e.g., events 518, 524, 526, 538, 544, 546, 564, 566) including the particular transport layer information and the particular data packet from the upstream node. At block 1108, the RAN node determines whether the particular transport layer information from the DL tunnel packet is first transport layer information or second transport layer information. If the particular transport layer information is first transport layer information, method 1100 proceeds to block 1110, which includes blocks 1006, 1008, 1010, 1012, 1022, and 1024 as discussed above with respect to fig. 10A and 10B. If the particular transport layer information is second transport layer information, method 1100 proceeds to block 1112, which includes blocks 1014, 1016, 1018, 1020, 1022, and 1024 as discussed above with respect to fig. 1000A and 1000B.

Referring now to fig. 12, in one example, an example method 1200 for selecting a first logical channel identifier or a second logical channel identifier for a data packet based on whether the data packet is associated with a first quality of service (QoS) flow identifier or a second QoS flow identifier may be implemented in a RAN node (e.g., base station 104 or DU 174) of the present disclosure. The method 1200 begins at block 1202, where the RAN node receives a data packet (e.g., events 518, 524, 526, 538, 544, 546, 564, 566) from an upstream node. Method 1200 may then proceed to block 1250, which includes blocks 1204, 1206, 1208, 1210, 1212, and 1214. At block 1204, the RAN node determines whether the received data packet is associated with a first QoS flow identifier or a second QoS flow identifier.

If the data packet is associated with a first QoS flow identifier, the method 1200 proceeds to block 1206 where the RAN node selects a first logical channel ID. At block 1208, the RAN node generates a PDU comprising a first logical channel ID and a data packet.

If the data packet is associated with a second QoS flow identifier, the method 1200 proceeds to block 1210 where the RAN node selects a second logical channel ID. At block 1212, the RAN node generates a PDU comprising the second logical channel ID and the data packet.

In either case, after block 1208 or block 1212, respectively, the method 1200 proceeds to block 1214, wherein the RAN node transmits the PDU to the plurality of UEs via multicast.

Referring now to fig. 13, in one example, an example method 1300 for determining whether to select a first logical channel identifier or a second logical channel identifier for a data packet based on whether the data packet is associated with a first QoS flow identifier or a second QoS flow identifier or whether a second logical channel is selected for the data packet based on whether a tunnel through which the data packet arrives has a first transport layer configuration or a second transport layer configuration may be implemented in a RAN node (e.g., base station 104) of the present disclosure. The method 1300 begins at block 1302, where a RAN node configures a first DL transport layer configuration comprising first transport layer information to receive a packet from an upstream node. At block 1304, the RAN node configures a second DL transport layer configuration comprising second transport layer information to receive packets from an upstream node. At block 1306, the RAN node receives a DL tunnel packet (e.g., events 518, 524, 526, 538, 544, 546, 564, 566) including the particular transport layer information and the particular data packet from the upstream node. At block 1308, the RAN node determines whether the particular transport layer information from the DL tunnel packet is first transport layer information or second transport layer information. If the particular transport layer information is first transport layer information, method 900 proceeds to block 1310, which includes block 1250 (which in turn includes blocks 1204, 1206, 1208, 1210, 1212, and 1214 as discussed above with respect to fig. 12). If the particular transport layer information is second transport layer information, method 1300 proceeds to block 1312, which includes blocks 812, 814, and 816 as discussed above with respect to fig. 8A and 8B.

In different implementations, the RAN node may select the transmission scheme taking into account any suitable number of factors, and the RAN node may perform blocks 1308, 1310 and 1312 in any suitable order to effectively assign different priorities to the factors.

Referring now to fig. 14, in one example, an example method 1400 for selecting a first logical channel identifier and a G-RNTI or a second logical channel identifier and a G-RNTI for a data packet based on whether the data packet is associated with a first QoS flow identifier or a second QoS flow identifier may be implemented in a RAN node (e.g., base station 104 or DU 174) of the present disclosure. The method 1400 begins at block 1402, where the RAN node receives a data packet from an upstream node. Method 1400 then proceeds to block 1450, which includes blocks 1404, 1406, 1408, 1410, 1412, 1414, 1416, 1418, and 1420. At block 1404, the RAN node determines whether the received data packet is associated with a first QoS flow identifier or a second QoS flow identifier.

If the data packet is associated with a first QoS flow identifier, the method 1400 proceeds to block 1406 where the RAN node selects a first logical channel ID and G-RNTI. At block 1408, the RAN node generates a PDU comprising the first logical channel ID and the data packet.

If the data packet is associated with a second QoS flow identifier, the method 1400 proceeds to block 1410 where the RAN node selects a second logical channel ID and G-RNTI. At block 1412, the RAN node generates a PDU comprising the second logical channel ID and the data packet.

In either case, after block 1408 or 1412, respectively, the method 1400 proceeds to block 1414, where the RAN node generates DCI and a CRC for the DCI to schedule PDSCH transmissions of the PDU. At block 1416, the RAN node scrambles the CRC with the G-RNTI to obtain a scrambled CRC. At block 1418, the RAN node transmits the DCI and the scrambled CRC on the PDCCH. At block 1420, the RAN node transmits PDSCH transmission of the PDU according to the DCI.

Referring now to fig. 15, in one example, an example method 1500 for determining whether to select a first logical channel identifier and a G-RNTI or a second logical channel identifier and a G-RNTI for a data packet or whether to select a second logical channel and a C-RNTI for a data packet based on whether a data packet is associated with a first QoS flow identifier or a second QoS flow identifier or whether a tunnel through which the data packet arrived has a first transport layer configuration or a second transport layer configuration may be implemented in a RAN node (e.g., base station 104) of the present disclosure.

The method 1500 begins at block 1502, where the RAN node configures a first DL transport layer configuration comprising first transport layer information to receive a packet from an upstream node. At block 1504, the RAN node configures a second DL transport layer configuration including second transport layer information to receive packets from an upstream node. At block 1506, the RAN node receives a DL tunnel packet including the specific transport layer information and the specific data packet from the upstream node. At block 1508, the RAN node determines whether the particular transport layer information from the DL tunnel packet is first transport layer information or second transport layer information. If the particular transport layer information is first transport layer information, method 1500 proceeds to block 1510, which includes block 1450 (which in turn includes blocks 1404, 1406, 1408, 1410, 1412, 1414, 1416, 1418, and 1420 as discussed above with respect to FIG. 14). If the particular transport layer information is second transport layer information, method 1500 proceeds to block 1512, which includes blocks 1014, 1016, 1018, 1020, 1022, and 1024 as discussed above with respect to fig. 10A and 10B.

The following example list reflects various implementations explicitly contemplated by the present disclosure:

example 1a method implemented in a node of a Radio Access Network (RAN) for managing transmissions of multicast and/or broadcast services (MBS), the method comprising: receiving, by processing hardware, MBS data packets from an upstream node via a Downlink (DL) tunnel; selecting, by the processing hardware, a multicast scheme for transmitting the MBS data packet to a plurality of UEs based on one or more attributes of the DL tunnel; and transmitting, by the processing hardware, the data packet to the plurality of UEs via a radio interface using the multicast scheme according to the selection.

Example 2. The method of example 1, wherein the selecting comprises: determining that the DL tunnel is a common DL tunnel, the upstream node being configured to transmit, via the node, a single copy of the MBS data packet to the plurality of UEs via the common DL tunnel. Example 3. The method of example 2, wherein: the receiving, the selecting, and the transmitting occur in a first instance; the method further comprises the steps of: in a second example: receiving a second data packet via the UE-specific tunnel; selecting a unicast scheme for transmitting the second data packet to at least one particular UE based on the UE-specific tunnel; and transmitting the second data packet to the at least one particular UE via the radio interface using the unicast scheme.

Example 4. The method of example 1, wherein the selecting comprises: the DL tunnel is determined to be a first DL tunnel of a plurality of DL tunnels configured at the node.

Example 5. The method of example 4, wherein: the receiving, the selecting, and the transmitting occur in a first instance; the method further comprises the steps of: in a second example: receiving a second data packet via a second DL tunnel of a plurality of DL tunnels configured at the node; selecting a unicast scheme for transmitting the second data packet to at least one particular UE based on the second DL tunnel of the plurality of DL tunnels; and transmitting the second data packet to the at least one particular UE via the radio interface using the unicast scheme.

Example 6. The method of example 1, wherein the selecting comprises: the DL tunnel is determined to have a first transport layer configuration of a plurality of transport layer configurations at the node.

Example 7. The method of example 6, wherein: the receiving, the selecting, and the transmitting occur in a first instance; the method further comprises the steps of: in a second example: receiving a second data packet via a second DL tunnel; determining that the second DL tunnel has a second transport layer configuration of the plurality of transport layer configurations at the node; and transmitting the second data packet to at least one particular UE via the radio interface using the unicast scheme.

Example 8 the method of any one of the preceding examples, further comprising: a logical channel identifier is selected based on the one or more attributes of the DL tunnel.

Example 9 the method of example 8, wherein the transmitting comprises: the MBS data packet and the logical channel identifier are included in a Protocol Data Unit (PDU).

Example 10 the method of example 8, wherein the logical channel selected for the MBS data packet is a Multicast Traffic Channel (MTCH).

Example 11 the method of any one of examples 8 to 10, wherein: the logical channel identifier is also selected based on a quality of service (QoS) flow identifier of the MBS data packet.

Example 12 the method of any one of examples 1 to 10, further comprising: a Radio Network Temporary Identifier (RNTI) is selected based on the one or more properties of the DL tunnel.

Example 13. The method of example 11, wherein the RNTI selected for the MBS data packet is a group RNTI (G-RNTI).

Example 14 the method of any one of examples 12 or 13, wherein: the RNTI is also selected based on a QoS flow identifier of the MBS data packet.

Example 15 the method of any one of the preceding examples, wherein: the node is a Distributed Unit (DU) of a distributed base station and the upstream node is a Central Unit (CU) of the distributed base station.

Example 16 the method of any one of examples 1 to 14, wherein: the node is a Distributed Unit (DU) of a distributed base station and the upstream node is a user plane function (CU-UP) of the CU.

Example 17 the method of any one of examples 1 to 14, wherein: the node is a Distributed Unit (DU) of a distributed base station and the upstream node is a control plane function (CU-CP) of the CU.

Example 18 the method of any one of examples 1 to 14, wherein: the node is a base station and the upstream node is a User Plane Function (UPF) of the Core Network (CN).

Example 19 the method of any one of examples 1 to 14, wherein: the node is a base station and the upstream node is an access and mobility management function (AMF) of the CN.

Example 20. A method implemented in a node of a Radio Access Network (RAN) for managing transmission of data packets, the method comprising: receiving, by processing hardware, MBS data packets associated with a quality of service (QoS) flow from an upstream node; selecting, by the processing hardware, a logical channel on a radio interface based on the QoS flow; and broadcasting, by the processing hardware, the MBS data packet to a plurality of UEs on the logical channel.

Example 21 the method of example 20, wherein: receiving the MBS data packet includes receiving the MBS data packet via a DL tunnel; and selecting the logical channel based on the QoS flow is in response to determining that the DL tunnel has a first transport layer configuration of a plurality of transport layer configurations.

Example 22 the method of example 21, wherein the determining further comprises determining that the DL tunnel is a common DL tunnel, the upstream node configured to transmit a single copy of the MBS data packet to the plurality of UEs via the common DL tunnel.

Example 23 the method of any one of examples 20 to 22, further comprising: an RNTI is selected by the processing hardware based on the QoS flow.

Example 24. The method of example 23, wherein selecting the RNTI comprises selecting a G-RNTI.

Example 25. A network node comprising processing hardware and configured to implement the method of any of the preceding examples.

Claims

1. A method performed by a distributed unit, DU, of a distributed base station in a radio access network, RAN, for managing transmissions of a multicast and/or broadcast service, MBS, the method comprising:

Receiving MBS data packets from a central unit CU of the distributed base station via a downlink DL tunnel;

Selecting a multicast scheme for transmitting the MBS data packet to a plurality of UEs based on one or more attributes of the DL tunnel; and

According to the selection, the data packets are transmitted to the plurality of UEs via a radio interface using the multicast scheme.

2. The method of claim 1, wherein the selecting comprises:

Determining that the DL tunnel is a common DL tunnel, the CU being configured to transmit a single copy of the MBS data packet via the DU to the plurality of UEs via the common DL tunnel.

3. The method of claim 2, wherein:

The receiving, the selecting, and the transmitting occur in a first instance;

the method further comprises the steps of: in a second example:

Receiving a second data packet via the UE-specific tunnel;

selecting a unicast scheme for transmitting the second data packet to at least one particular UE based on the UE-specific tunnel; and

The second data packet is transmitted to the at least one particular UE via the radio interface using the unicast scheme.

4. The method of claim 1, wherein the selecting comprises:

The DL tunnel is determined to be a first DL tunnel of a plurality of DL tunnels configured at the DU.

5. The method of claim 4, wherein:

The receiving, the selecting, and the transmitting occur in a first instance;

the method further comprises the steps of: in a second example:

Receiving a second data packet via a second DL tunnel of a plurality of DL tunnels configured at the DU;

selecting a unicast scheme for transmitting the second data packet to at least one particular UE based on the second DL tunnel of the plurality of DL tunnels; and

6. The method of claim 1, wherein the selecting comprises:

The DL tunnel is determined to have a first transport layer configuration of a plurality of transport layer configurations at the DU.

7. The method of claim 6, wherein:

The receiving, the selecting, and the transmitting occur in a first instance;

the method further comprises the steps of: in a second example:

Receiving a second data packet via a second DL tunnel;

determining that the second DL tunnel has a second transport layer configuration of the plurality of transport layer configurations at the DU; and

The second data packet is transmitted to at least one particular UE via the radio interface using the unicast scheme.

8. The method of any of the preceding claims, further comprising:

a logical channel identifier is selected based on the one or more attributes of the DL tunnel.

9. The method of claim 8, wherein the transmitting comprises:

the MBS data packet and the logical channel identifier are included in a protocol data unit PDU.

10. The method of claim 8, wherein the logical channel selected for the MBS data packet is a Multicast Traffic Channel (MTCH).

11. The method of any one of claims 8 to 10, wherein:

the logical channel identifier is selected further based on a quality of service QoS flow identifier of the MBS data packet.

12. The method of any one of claims 1 to 10, further comprising:

A radio network temporary identifier, RNTI, is selected based on the one or more attributes of the DL tunnel.

13. The method of claim 11, wherein the RNTI selected for the MBS data packet is a group RNTI (G-RNTI).

14. The method of any one of claims 12 or 13, wherein:

the RNTI is also selected based on a QoS flow identifier of the MBS data packet.

15. A method performed by a node of a radio access network, RAN, for managing transmission of data packets, the method comprising:

Receiving MBS data packets associated with a quality of service QoS flow from an upstream node;

selecting a logical channel on a radio interface based on the QoS flow; and

The MBS data packet is broadcast to a plurality of UEs on the logical channel.

16. The method of claim 15, wherein:

receiving the MBS data packet includes receiving the MBS data packet via a DL tunnel; and

Selecting the logical channel based on the QoS flow is in response to determining that the DL tunnel has a first transport layer configuration of a plurality of transport layer configurations.

17. The method of claim 16, wherein the determining further comprises determining that the DL tunnel is a common DL tunnel, the upstream node configured to transmit a single copy of the MBS data packet to the plurality of UEs via the common DL tunnel.

18. The method of any of claims 15 to 17, further comprising:

And selecting RNTI based on the QoS flow.

19. The method of claim 18, wherein selecting the RNTI comprises selecting a G-RNTI.

20. A network node configured to implement the method of any of the preceding claims.