MANAGING POINT-TO-POINT AND POINT-TO-MULTIPOINT TRANSMISSION

A method in one or more nodes of a radio access network (RAN), for managing multicast and/or broadcast services (MBS) communications, includes transmitting to a user device an MBS radio bearer (MRB) configuration associated with an MRB, implementing a shared packet data convergence protocol (PDCP) entity to transmit first MB S packets to the user device via the MRB and according to the MRB configuration and a first lower layer configuration, and after transmitting the first MB S packets, implementing the shared PDCP entity to transmit second MB S packets to the user device via the MRB and according to a second lower layer configuration and the MRB configuration. The first and second lower layer configurations being different ones of a multicast configuration and a unicast configuration.

FIELD OF THE DISCLOSURE

This disclosure relates to wireless communications and, more particularly, to enabling setup and/or modification of radio resources for point-to-point (PTP) and point-to-multipoint (PTM) communications.

BACKGROUND

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

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

UEs can use several types of SRBs and DRBs. So-called “SRB1” resources carry RRC messages, which in some cases include NAS messages over the dedicated control channel (DCCH), and “SRB2” resources support RRC messages that include logged measurement information or NAS messages, also over the DCCH but with lower priority than SRB1 resources. More generally, SRB1 and SRB2 resources allow the UE and the MN to exchange RRC messages related to the MN and embed RRC messages related to the SN, and can also be referred to as MCG SRBs. “SRB3” resources allow the UE and the SN to exchange RRC messages related to the SN, and can also be referred to as SCG SRBs. Split SRBs allow the UE to exchange RRC messages directly with the MN via lower-layer resources of the MN and the SN. Further, DRBs terminated at the MN and using the lower-layer resources of only the MN can be referred as MCG DRBs, DRBs terminated at the SN and using the lower-layer resources of only the SN can be referred as SCG DRBs, and DRBs terminated at the MN or SN but using the lower-layer resources of both the MN and the SN can be referred to as split DRBs. DRBs terminated at the MN but using the lower-layer resources of only the SN can be referred to as MN-terminated SCG DRBs. DRBs terminated at the SN but using the lower-layer resources of only the MN can be referred to as SN-terminated MCG DRBs.

UEs can perform handover procedures to switch from one cell to another, whether in SC or DC operation. These procedures involve messaging (e.g., RRC signaling and preparation) among RAN nodes and the UE. The UE may handover from a cell of a serving base station to a target cell of a target base station, or from a cell of a first distributed unit (DU) of a serving base station to a target cell of a second DU of the same base station, depending on the scenario. In DC scenarios, UEs can perform PSCell change procedures to change PSCells. These procedures involve messaging (e.g., RRC signaling and preparation) among RAN nodes and the UE. The UE may perform a PSCell change from a PSCell of a serving SN to a target PSCell of a target SN, or from a PSCell of a source DU of a base station to a PSCell of a target DU of the same base station, depending on the scenario. Further, the UE may perform handover or PSCell change within a cell for synchronous reconfiguration.

Base stations that operate according to fifth-generation (5G) New Radio (NR) requirements support significantly larger bandwidth than fourth-generation (4G) base stations. Accordingly, the Third Generation Partnership Project (3GPP) has proposed that for Release 15, user equipment units (UEs) support a 100 MHz bandwidth in frequency range1(FR1) and a 400 MHz bandwidth in frequency range (FR2). Due to the relatively wide bandwidth of a typical carrier in 5G NR, 3GPP has proposed for Release 17 that a 5G NR base station be able to provide multicast and/or broadcast service(s) (MBS) to UEs. MBS can be useful in many content delivery applications, such as transparent IPv4/IPv6 multicast delivery, IPTV, software delivery over wireless, group communications, Internet of Things (IoT) applications, V2X applications, and emergency messages related to public safety, for example.

5G NR provides both point-to-point (PTP) and point-to-multipoint (PTM) delivery methods for the transmission of MBS packet flows over the radio interface. In PTP communications, a RAN node transmits different copies of each MBS data packet to different UEs over the radio interface, while in PTM communications a RAN node transmits a single copy of each MBS data packet to multiple UEs over the radio interface. In some scenarios, however, it is unclear how base stations and UEs should configure and manage PTP and PTM transmissions, and switching between PTP and PTM transmissions.

SUMMARY

User equipment units (UEs) and radio access network (RAN) base stations of this disclosure support the communication of multicast and/or broadcast services (MBS) information via radio resources allocated by the base stations. Generally, a UE can perform a session establishment procedure (e.g., a protocol data unit (PDU) session establishment procedure) with a core network (CN) via a base station of the RAN, after which the base station can use an MBS radio bearer (MRB) associated with the session to transmit (i.e., multicast or unicast) MBS data packets to the UE.

In particular, the base station can configure different downlink radio resources in a cell, or in multiple overlapping cells, in order to broadcast, multicast, and/or unicast MBS data (and associated control information) to one or more UEs. To this end, the base station can configure an MRB to carry MBS information, including MBS data packets and/or associated control information, to a UE. It is understood that, while MBS is an acronym for “multicast and/or broadcast” service(s), in some scenarios a base station can provide MBS packet flows via unicast transmissions. For example, unicast transmissions may be more efficient, and therefore preferred by the CN, in scenarios where very few UEs are utilizing a particular MBS. In some implementations, base stations of this disclosure can also unicast non-MBS data to UEs on dedicated data radio bearers (DRBs), and associated control information, and UEs of this disclosure can transmit non-MBS data to a base station on the uplink.

To prepare for downlink transmissions via an MRB (i.e., to configure an MRB), the base station can transmit an MRB configuration, as well as a multicast configuration and/or a unicast configuration, to the UE. After transmitting the configurations, the base station can use point-to-multipoint (PTM) and/or point-to-point (PTP) transmissions to transmit MBS information to the UE via the MRB. As the terms are used herein, “MRB configurations” are higher layer configurations, while “multicast configurations” and “unicast configurations” are lower layer configurations, relative to each other. For example, MRB configurations may be associated with operations at packet data convergence protocol (PDCP) and service data adaptation protocol (SDAP) layers of a protocol stack, while the multicast and unicast configurations may instead be associated with operations at physical, medium access control (MAC) and/or radio link control (RLC) layers of the protocol stack. As used herein, and unless the context of its use clearly indicates a more specific meaning, the term “configuration” can refer to a full configuration, a delta configuration, or any a subset of configuration parameters (e.g., only the configuration parameters associated with a particular subset of protocol stack layers, etc.).

More specifically, for PTM transmissions, a base station can transmit an MRB configuration and a multicast configuration to multiple UEs, to configure the UEs to receive MBS information via the MRB and the multicast radio resources. The base station then transmits (in this case, multicasts) MBS information via the MRB and multicast radio resources in accordance with the multicast configuration and the MRB configuration, and the UEs receive the MBS information via the MRB and multicast radio resources in accordance with the multicast configuration and the MRB configuration.

For PTP transmissions, a base station can instead transmit an MRB configuration and a unicast configuration to a UE, to configure the UE to receive MBS information via the MRB and the unicast radio resources. The base station then transmits (in this case, unicasts) MBS information via the MRB and unicast radio resources in accordance with the unicast configuration and the MRB configuration, and the UE receives the MBS information via the MRB and unicast radio resources in accordance with the unicast configuration and the MRB configuration.

In some implementations, the base station transmits an MRB configuration for each MBS requested by the UE. For example, the base station may send a UE a PTM MRB configuration for an MBS associated with multicast transmissions, and a separate, PTP MRB configuration for an MBS associated with unicast transmissions.

Additionally or alternatively, in some implementations, the base station sends the UE a new MRB configuration, along with a lower layer configuration (i.e., unicast or multicast configuration), when an MBS (e.g., a PDU session associated with the MBS) changes from multicast to unicast transmissions, or vice versa. In other implementations, the base station does not send the UE a new MRB configuration in this scenario, but does send the UE a new lower layer configuration (e.g., a unicast configuration, if the MBS changes from multicast to unicast). In still other implementations, the base station initially sends the UE an MRB configuration, a multicast configuration, and a unicast configuration when the UE requests an MBS, and thus does not need to send any additional configuration when changing the MBS from multicast to unicast, or vice versa.

In one aspect, a method in one or more nodes of a RAN, for managing MBS communications, comprises transmitting to a user device an MRB configuration associated with an MRB, implementing a shared packet data convergence protocol (PDCP) entity to transmit first MBS packets to the user device via the MRB and according to the MRB configuration and a first lower layer configuration, and after transmitting the first MBS packets, implementing the shared PDCP entity to transmit second MBS packets to the user device via the MRB and according to a second lower layer configuration and the MRB configuration. The first and second lower layer configurations are different ones of a multicast configuration and a unicast configuration.

In another aspect, a method, in a user device communicating with a RAN, for managing MBS communications, comprises receiving from the RAN an MRB configuration associated with an MRB, implementing a shared packet data convergence protocol (PDCP) entity to receive first MBS packets from the RAN via the MRB and according to the MRB configuration and a first lower layer configuration, and after receiving the first MBS packets, implementing the shared PDCP entity to receive second MBS packets from the RAN via the MRB and according to a second lower layer configuration and the MRB configuration. The first and second lower layer configurations are different ones of a multicast configuration and a unicast configuration.

DETAILED DESCRIPTION OF THE DRAWINGS

FIG.1Adepicts an example wireless communication system100in which techniques of this disclosure for managing transmission and reception of multicast and/or broadcast services (MBS) information can be implemented. The wireless communication system100includes user equipment (UEs)102A,102B, as well as base stations104,106A,106B of a radio access network (RAN)105connected to a core network (CN)110. In other implementations or scenarios, the wireless communication system100may instead include more or fewer UEs, and/or more or fewer base stations, than are shown inFIG.1A. The base stations104,106A,106B can be any suitable type, or types, of base stations, such as an evolved node B (eNB), a next-generation eNB (ng-eNB), or a 5G Node B (gNB), for example. As a more specific example, the base station104may be an eNB or a gNB, and the base stations106A and106B may be gNBs.

The base station104supports a cell124, the base station106A supports a cell126A, and the base station106B supports a cell126B. The cell124partially overlaps with both of cells126A and126B, such that the UE102A can be in range to communicate with base station104while simultaneously being in range to communicate with base station106A or106B (or in range to detect or measure signals from both base stations106A and106B). The overlap can make it possible for the UE102A to hand over between cells (e.g., from cell124to cell126A or126B) or base stations (e.g., from base station104to base station106A or106B) before the UE102A experiences radio link failure, for example. Moreover, the overlap allows the various dual connectivity (DC) scenarios discussed below. For example, the UE102A can communicate in DC with the base station104(operating as a master node (MN)) and the base station106A (operating as a secondary node (SN)) and, upon completing a handover to base station106B, can communicate with the base station106B (operating as an MN). As another example, the UE102A can communicate in DC with the base station104(operating as an MN) and the base station106A (operating as an SN) and, upon completing an SN change, can communicate with the base station104(operating as an MN) and the base station106B (operating as an SN). When the UE102A is in DC with the base station104and the base station106A, the base station104operates as a master eNB (MeNB), a master ng-eNB (Mng-eNB), or a master gNB (MgNB), and the base station106A operates as a secondary gNB (SgNB) or a secondary ng-eNB (Sng-eNB).

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

In MBS operation, the UE102A can use an MBS radio bearer (MRB) that at different times terminates at an MN (e.g., the base station104) or an SN (e.g., the base station106A). For example, after handover or SN change to the base station106B, the UE102A can use an MRB that terminates at the base station106B, which can be operating as an MN or SN. In some scenarios, a base station (e.g., the MN or SN) can transmit MBS data over unicast radio resources (i.e., the radio resources dedicated to the UE102A) to the UE102A via the MRB. In other scenarios, the base station (e.g., the MN or SN) can transmit MBS data over multicast radio resources (i.e., the radio resources common to the UE102A and one or more other UEs), or a DL BWP of a cell from the base station to the UE102A via the MRB. The DL BWP can be an initial DL BWP, a dedicated DL BWP, or an MBS DL BWP (i.e., a DL BWP that is specific to MBS, or not for unicast).

The base station104includes processing hardware130, which can include one or more general-purpose processors (e.g., central processing units (CPUs)) and a computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processor(s), and/or special-purpose processing units. The processing hardware130in the example implementation ofFIG.1Aincludes an MBS controller132that is configured to manage or control transmission of MBS information received from the CN110or an edge server. For example, the MBS controller132can 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 hardware130can also include a non-MBS controller134that is configured to manage or control one or more RRC configurations and/or RRC procedures when the base station104operates as an MN or SN during a non-MBS operation.

The base station106A includes processing hardware140, which can include one or more general-purpose processors (e.g., CPUs) and a computer-readable memory storing machine-readable instructions executable on the general-purpose processor(s), and/or special-purpose processing units. The processing hardware140in the example implementation ofFIG.1Aincludes an MBS controller142and a non-MBS controller144, which may be similar to the controllers132and134, respectively, of base station130. While not shown inFIG.1A, the base station106B may include processing hardware similar to the processing hardware130of the base station104and/or the processing hardware140of the base station106A.

The UE102A includes processing hardware150, which can include one or more general-purpose processors (e.g., CPUs) and a computer-readable memory storing machine-readable instructions executable on the general-purpose processor(s), and/or special-purpose processing units. The processing hardware150in the example implementation ofFIG.1Aincludes an MBS controller152that is configured to manage or control reception of MBS information. For example, the UE MBS controller152can 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 hardware150can also include a non-MBS controller154configured to manage or control one or more RRC configurations and/or RRC procedures in accordance with any of the implementations discussed below, when the UE102A communicates with an MN and/or an SN during a non-MBS operation. While not shown inFIG.1A, the UE102B may include processing hardware similar to the processing hardware150of the UE102A.

The CN110may be an evolved packet core (EPC)111or a fifth-generation core (5GC)160, both of which are depicted inFIG.1A. The base station104may be an eNB supporting an S1 interface for communicating with the EPC111, an ng-eNB supporting an NG interface for communicating with the 5GC160, or a gNB that supports an NR radio interface as well as an NG interface for communicating with the 5GC160. The base station106A may be an EUTRA-NR DC (EN-DC) gNB (en-gNB) with an S1 interface to the EPC111, an en-gNB that does not connect to the EPC111, a gNB that supports the NR radio interface and an NG interface to the 5GC160, or a ng-eNB that supports an EUTRA radio interface and an NG interface to the 5GC160. To directly exchange messages with each other during the scenarios discussed below, the base stations104,106A, and106B may support an X2 or Xn interface.

Among other components, the EPC111can include a serving gateway (SGW)112, a mobility management entity (MME)114, and a packet data network gateway (PGW)116. The SGW112is generally configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., and the MME114is configured to manage authentication, registration, paging, and other related functions. The PGW116provides connectivity from a UE (e.g., UE102A or102B) to one or more external packet data networks, e.g., an Internet network and/or an Internet Protocol (IP) Multimedia Subsystem (IMS) network. The 5GC160includes a user plane function (UPF)162and an access and mobility management (AMF)164, and/or a session management function (SMF)166. The UPF162is generally configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., the AMF164is generally configured to manage authentication, registration, paging, and other related functions, and the SMF166is generally configured to manage PDU sessions.

The UPF162, AMF164, and/or SMF166can be configured to support MBS. For example, the SMF166can be configured to manage or control MBS transport, configure the UPF162and/or RAN105for MBS flows, and/or manage or configure one or more MBS sessions or PDU sessions for MBS for a UE (e.g., UE102A or102B). The UPF162is configured to transfer MBS data packets to audio, video, Internet traffic, etc. to the RAN105. The UPF162and/or SMF166can be configured for both non-MBS unicast service and MBS, or for MBS only.

Generally, the wireless communication system100may include any suitable number of base stations supporting NR cells and/or EUTRA cells. More particularly, the EPC111or the 5GC160may be connected to any suitable number of base stations supporting NR cells and/or EUTRA cells. Although the examples below refer specifically to specific CN types (EPC, 5GC) and RAT types (5G NR and EUTRA), in general the techniques of this disclosure can also apply to other suitable radio access and/or core network technologies, such as sixth generation (6G) radio access and/or 6G core network or 5G NR-6G DC, for example.

In different configurations or scenarios of the wireless communication system100, the base station104can operate as an MeNB, an Mng-eNB, or an MgNB, the base station106B can operate as an MeNB, an Mng-eNB, an MgNB, an SgNB, or an Sng-eNB, and the base station106A can operate as an SgNB or an Sng-eNB. The UE102A can communicate with the base station104and the base station106A or106B via the same radio access technology (RAT), such as EUTRA or NR, or via different RATs.

When the base station104is an MeNB and the base station106A is an SgNB, the UE102A can be in EN-DC with the MeNB104and the SgNB106A. When the base station104is an Mng-eNB and the base station106A is an SgNB, the UE102A can be in next generation (NG) EUTRA-NR DC (NGEN-DC) with the Mng-eNB104and the SgNB106A. When the base station104is an MgNB and the base station106A is an SgNB, the UE102A can be in NR-NR DC (NR-DC) with the MgNB104and the SgNB106A. When the base station104is an MgNB and the base station106A is an Sng-eNB, the UE102A can be in NR-EUTRA DC (NE-DC) with the MgNB104and the Sng-eNB106A.

FIG.1Bdepicts an example, distributed implementation of any one or more of the base stations104,106A,106B. In this implementation, the base station104,106A, or106B includes a central unit (CU)172and one or more distributed units (DUs)174. The CU172includes processing hardware, such as one or more general-purpose processors (e.g., CPUs) and a computer-readable memory storing machine-readable instructions executable on the general-purpose processor(s), and/or special-purpose processing units. For example, the CU172can include some or all of the processing hardware130or140ofFIG.1A.

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

In some implementations, the CU172can include one or more logical nodes (CU-CP(s)172A) that host the control plane part of the Packet Data Convergence Protocol (PDCP) protocol of the CU172and/or the radio resource control (RRC) protocol of the CU172. The CU172can also include one or more logical nodes (CU-UP(s)172B) that host the user plane part of the PDCP protocol and/or service data adaptation protocol (SDAP) protocol of the CU172. The CU-CP(s)172A can transmit non-MBS control information and MBS control information, and the CU-UP(s)172B can transmit non-MBS data packets and MBS data packets, as described herein.

The CU-CP(s)172A can be connected to multiple CU-UPs172B through the E1 interface. The CU-CP(s)172A select the appropriate CU-UP(s)172B for the requested services for the UE102A. In some implementations, a single CU-UP172B can be connected to multiple CU-CPs172A through the E1 interface. A CU-CP172A can be connected to one or more DUs174sthrough an F1-C interface. A CU-UP172B can be connected to one or more DUs174through an F1-U interface under the control of the same CU-CP172A. In some implementations, one DU174can be connected to multiple CU-UPs172B under the control of the same CU-CP172A. In such implementations, the connectivity between a CU-UP172B and a DU174is established by the CU-CP172A using bearer context management functions.

FIG.2illustrates, in a simplified manner, an example protocol stack200according to which a UE (e.g., UE102A or102B) can communicate with an eNB/ng-eNB or a gNB (e.g., one or more of the base stations104,106A,106B). In the example protocol stack200, a PHY sublayer202A of EUTRA provides transport channels to an EUTRA MAC sublayer204A, which in turn provides logical channels to an EUTRA RLC sublayer206A. The EUTRA RLC sublayer206A in turn provides RLC channels to an EUTRA PDCP sublayer208and, in some cases, to an NR PDCP sublayer210. Similarly, an NR PHY202B provides transport channels to an NR MAC sublayer204B, which in turn provides logical channels to an NR RLC sublayer206B. The NR RLC sublayer206B in turn provides RLC channels to an NR PDCP sublayer210. The UE102A, in some implementations, supports both the EUTRA and the NR stack as shown inFIG.2, to support handover between EUTRA and NR base stations and/or to support DC over EUTRA and NR interfaces. Further, as illustrated inFIG.2, the UE102A can support layering of NR PDCP210over EUTRA RLC206A, and an SDAP sublayer212over the NR PDCP sublayer210. Sublayers are also referred to herein as simply “layers.”

The EUTRA PDCP sublayer208and the NR PDCP sublayer210receive packets (e.g., from an IP layer, layered directly or indirectly over the PDCP layer208or210) that can be referred to as service data units (SDUs), and output packets (e.g., to the RLC layer206A or206B) that can be referred to as protocol data units (PDUs). Except where the difference between SDUs and PDUs is relevant, this disclosure for simplicity refers to both SDUs and PDUs as “packets.” The packets can be MBS packets or non-MBS packets. MBS packets may include application content for an MBS service (e.g., IPv4/IPv6 multicast delivery, IPTV, software delivery over wireless, group communications, IoT applications, V2X applications, and/or emergency messages related to public safety), for example. As another example, MBS packets may include application control information for the MBS service.

On a control plane, the EUTRA PDCP sublayer208and the NR PDCP sublayer210can provide SRBs to exchange RRC messages or non-access-stratum (NAS) messages, for example. On a user plane, the EUTRA PDCP sublayer208and the NR PDCP sublayer210can provide DRBs to support data exchange. Data exchanged on the NR PDCP sublayer210may be SDAP PDUs, IP packets, or Ethernet packets, for example.

In scenarios where the UE102A or102B operates in EN-DC with the base station104operating as an MeNB and the base station106A operating as an SgNB, the wireless communication system100can provide the UE102A or102B with an MN-terminated bearer that uses EUTRA PDCP sublayer208, or an MN-terminated bearer that uses NR PDCP sublayer210. The wireless communication system100in various scenarios can also provide the UE102A or102B with an SN-terminated bearer, which uses only the NR PDCP sublayer210. The MN-terminated bearer may be an MCG bearer, a split bearer, or an MN-terminated SCG bearer. The SN-terminated bearer may be an SCG bearer, a split bearer, or an SN-terminated MCG bearer. The MN-terminated bearer may be an SRB (e.g., SRB1 or SRB2) or a DRB. The SN-terminated bearer may be an SRB or a DRB.

In some implementations, a base station (e.g., base station104,106A, or106B) broadcasts MBS data packets via one or more MBS radio bearers (MRB(s)), and in turn the UE102A receives the MBS data packets via the MRB(s). The base station can include configuration(s) of the MRB(s) in multicast configuration parameters (which can also be referred to as MBS configuration parameters) described below. In some implementations, the base station broadcasts the MBS data packets via RLC sublayer206, MAC sublayer204, and PHY sublayer202, and correspondingly, the UE102A uses PHY sublayer202, MAC sublayer204, and RLC sublayer206to receive the MBS data packets. In such implementations, the base station and the UE102A may not use PDCP sublayer208and a SDAP sublayer212to communicate the MBS data packets. In other implementations, the base station transmits the MBS data packets via PDCP sublayer208, RLC sublayer206, MAC sublayer204, and PHY sublayer202, and correspondingly, the UE102A uses PHY sublayer202, MAC sublayer204, RLC sublayer206and PDCP sublayer208to receive the MBS data packets. In such implementations, the base station and the UE102A may not use a SDAP sublayer212to communicate the MBS data packets. In yet other implementations, the base station transmits the MBS data packets via the SDAP sublayer212, PDCP sublayer208, RLC sublayer206, MAC sublayer204, and PHY sublayer202and, correspondingly, the UE102A uses the PHY sublayer202, MAC sublayer204, RLC sublayer206, PDCP sublayer208, and SDAP sublayer212to receive the MBS data packets.

FIGS.3A-3Fdepict alternative, example protocol architectures that a base station (e.g., base station104,106A, and/or106B) may implement for an MRB, whileFIGS.4A-4Fdepict the corresponding/respective protocol architectures that a UE (e.g., UE102A and/or102B) may implement for an MRB. Generally, a protocol layer “entity” (e.g., NR MAC entity304or NR MAC entity404) inFIGS.3A-3F and4A-4Fis an instance that operates a corresponding protocol layer (e.g., NR MAC204B) inFIG.2. The base station can transmit particular configuration parameters for a particular protocol layer entity to the UE. For example, the base station104can transmit to the UE102A MAC configuration parameters for the UE102A to operate the NR MAC entity404,414, or424. The MAC configuration parameters for NR MAC entity404,414, or424may be the same, different, or partly the same and partly different.

Referring first toFIG.3A, in a protocol architecture300A, the base station uses separate entities for PTM (multicast) and PTP (unicast) transmissions associated with the same MBS, at each of the MAC, RLC, PDCP, and SDAP layers. In particular, for multicast transmission of MBS information on a PTM MRB, the base station implements an NR MAC entity304, an NR RLC entity306, an NR PDCP entity310, and (optionally) an SDAP entity312. Conversely, for unicast transmission of MBS information on a PTP MRB, the base station implements a different NR MAC entity314, a different NR RLC entity316, a different NR PDCP entity320, and (optionally) a different SDAP entity322. As indicated inFIG.3A, in an alternative implementation, the base station may use the same NR MAC entity324regardless of whether transmitting on a PTM MRB or a PTP MRB.FIG.4Aindicates the corresponding entities at the UE, in a protocol architecture400A. In particular, for receiving MBS information on a PTM MRB, the UE implements an NR MAC entity404, an NR RLC entity406, an NR PDCP entity410, and (optionally) an SDAP entity412. Conversely, for receiving MBS information on a PTP MRB, the UE implements a different NR MAC entity414, a different NR RLC entity416, a different NR PDCP entity420, and (optionally) a different SDAP entity422. As indicated inFIG.4A, in an alternative implementation, the UE may use the same NR MAC entity424regardless of whether receiving on a PTM MRB or a PTP MRB.

Referring next toFIG.3B, in an alternative protocol architecture300B, the base station uses separate entities for PTM (multicast) and PTP (unicast) transmissions associated with the same MBS at some, but not all, layers. In particular, for multicast transmission of MBS information on a PTM MRB, the base station implements an NR MAC entity304, an NR RLC entity306, an NR PDCP entity310, and an SDAP entity332. Conversely, for unicast transmission of MBS information on a PTP MRB, the base station implements a different NR MAC entity314, a different NR RLC entity316, and a different NR PDCP entity320, but the same SDAP entity332.FIG.4Bindicates the corresponding entities at the UE, in a protocol architecture400B. In particular, for receiving MBS information on a PTM MRB, the UE implements an NR MAC entity404, an NR RLC entity406, an NR PDCP entity410, and an SDAP entity432. Conversely, for receiving MBS information on a PTP MRB, the UE implements a different NR MAC entity414, a different NR RLC entity416, and a different NR PDCP entity420, but the same SDAP entity432.

Referring next toFIG.3C, in an alternative protocol architecture300C, the base station uses the same MRB for both PTM (multicast) and PTP (unicast) transmissions associated with an MBS. However, the base station uses separate lower layer entities. In particular, for multicast transmission of MBS information on the MRB, the base station implements an NR MAC entity304, an NR RLC entity306, an NR PDCP entity330, and (optionally) an SDAP entity332. Conversely, for unicast transmission of MBS information on the MRB, the base station implements a different NR MAC entity314and a different NR RLC entity316, but the same NR PDCP entity330and (optionally) the same SDAP entity332.FIG.4Cindicates the corresponding entities at the UE, in a protocol architecture400C. In particular, for receiving multicast MBS information on the MRB, the UE implements an NR MAC entity404, an NR RLC entity406, an NR PDCP entity430, and (optionally) an SDAP entity432. Conversely, for receiving unicast MBS information on the MRB, the UE implements a different NR MAC entity414and a different NR RLC entity416, but the same NR PDCP entity430and (optionally) the same SDAP entity432.

Referring next toFIG.3D, in an alternative protocol architecture300D, the base station again uses the same MRB for both PTM (multicast) and PTP (unicast) transmissions associated with an MBS. However, the base station only uses separate MAC layer entities. In particular, for multicast transmission of MBS information on the MRB, the base station implements an NR MAC entity304, an NR RLC entity326, an NR PDCP entity330, and (optionally) an SDAP entity332. Conversely, for unicast transmission of MBS information on the MRB, the base station implements a different NR MAC entity314, but the same NR RLC entity326, the same NR PDCP entity330, and (optionally) the same SDAP entity332.FIG.4Dindicates the corresponding entities at the UE, in a protocol architecture400D. In particular, for receiving multicast MBS information on the MRB, the UE implements an NR MAC entity404, an NR RLC entity426, an NR PDCP entity430, and (optionally) an SDAP entity432. Conversely, for receiving unicast MBS information on the MRB, the UE implements a different NR MAC entity414, but the same NR RLC entity426, the same NR PDCP entity430, and (optionally) the same SDAP entity432.

Referring next toFIG.3E, in an alternative protocol architecture300E, the base station again uses the same MRB for both PTM (multicast) and PTP (unicast) transmissions associated with an MBS. However, the base station only uses separate RLC layer entities. In particular, for multicast transmission of MBS information on the MRB, the base station implements an NR MAC entity324, an NR RLC entity306, an NR PDCP entity330, and (optionally) an SDAP entity332. Conversely, for unicast transmission of MBS information on the MRB, the base station implements a different NR RLC entity316, but the same NR MAC entity324, the same NR PDCP entity330, and (optionally) the same SDAP entity332.FIG.4Eindicates the corresponding entities at the UE, in a protocol architecture400E. In particular, for receiving multicast MBS information on the MRB, the UE implements an NR MAC entity424, an NR RLC entity406, an NR PDCP entity430, and (optionally) an SDAP entity432. Conversely, for receiving unicast MBS information on the MRB, the UE implements a different NR RLC entity416, but the same NR MAC entity424, the same NR PDCP entity430, and (optionally) the same SDAP entity432.

Referring next toFIG.3F, in an alternative protocol architecture300F, the base station again uses the same MRB for both PTM (multicast) and PTP (unicast) transmissions associated with an MBS. In this implementation, however, the base station shares entities at each layer. In particular, for both multicast and unicast transmissions of MBS information on the MRB, the base station implements an NR MAC entity324, an NR RLC entity326, an NR PDCP entity330, and (optionally) an SDAP entity332.FIG.4Findicates the corresponding entities at the UE, in a protocol architecture400F. In particular, for receiving both multicast and unicast MBS information on the MRB, the UE implements an NR MAC entity424, an NR RLC entity426, an NR PDCP entity430, and (optionally) an SDAP entity432.

FIGS.5A-8Care messaging diagrams of example implementations and scenarios in which a base station, CN, and UE communicate MBS information. Generally speaking, events inFIGS.5A-8Cthat may be similar are labeled with similar reference numbers (e.g., event550A may be similar to event550B,650A,650B,650C,750A,750B,850A,850B,850C, etc.), with differences discussed below where appropriate. With the exception of the differences shown in the figures and discussed below, any of the alternative implementations discussed with respect to a particular event (e.g., for messaging and processing) may apply to events labeled with similar reference numbers in other figures.

In particular,FIGS.5A-5Care messaging diagrams of example implementations and scenarios in which a UE requests different MBSs associated with multicast and unicast transmissions (respectively),FIGS.6A-6Care messaging diagrams of example implementations and scenarios in which a UE requests an MBS that is initially associated with multicast transmission, but changes to unicast transmission,FIGS.7A and7Bare messaging diagrams of example implementations and scenarios that are similar toFIGS.5A and5B, but in which the base station is a distributed base station, andFIGS.8A-8Care messaging diagrams of example implementations and scenarios that are similar toFIGS.6A-6C, but in which the base station is a distributed base station.

Referring first to the scenario500A shown inFIG.5A, the UE102A initially transmits502A to the base station (BS)104a first PDU Session Establishment Request message for establishing a first PDU session for a first MBS. To indicate that the UE102A is requesting an MRB for receiving MBS information, the UE102A in some implementations includes a flag or other indication in the first PDU Session Establishment Request message. For example, the flag may be a data network name (DNN) field that is set to “MBS” or corresponds to an MBS service. In another example, the flag or indication may be an MBS flag. The CN110can include an indication in the first PDU Session Establishment Accept message to grant the UE102A the ability to receive MBS for the first PDU session. If the CN110determines that the UE102A is not a valid UE to receive MBS (e.g., the UE102A does not subscribe to MBS), the CN110can exclude the indication in the first PDU Session Establishment Accept message. Thus, the UE102A does not receive MBS for the first PDU session. However, the UE102may receive non-MBS services for the first PDU session. In this case, a DNN may be common for unicast services and MBS. For example, the UE102may set the same DNN (i.e., set to a name other than “MBS”) for the first PDU session in the first PDU Session Establishment Request message and in a third PDU Session Establishment Request message for a third PDU session for non-MBS service(s) (as discussed below). The UE102does not include the flag or indication in the third PDU Session Establishment Request message.

In still other implementations, the first PDU Session Establishment Request message is an MBS-specific variant of a PDU Session Establishment Request message. In some implementations, before event502A, the UE102A initially operates in an idle state or an inactive state (e.g., an RRC_IDLE or RRC_INACTIVE state), or more generally in a state in which there is no active radio connection between the UE102A and the base station104. Alternatively, the UE102A initially operates in an RRC_CONNECTED state, or more generally in a state in which there is an active radio connection between the UE102A and the base station104.

The base station104in turn sends504A the first PDU Session Establishment Request message to the CN110(e.g., AMF164and/or SMF166). In some implementations, the base station104sends504A to the CN110a BS-to-CN interface message (e.g., an NG interface message, an INITIAL UE MESSAGE, or an UPLINK NAS TRANSPORT message) that includes the first PDU Session Establishment Request message.

In response to the first PDU Session Establishment Request message, the CN110sends506A a first PDU Session Establishment Accept message to the base station104, which in turn sends508A the first PDU Session Establishment Accept message to the UE102A. In some implementations, the CN110sends506A to the base station104a first CN-to-BS interface message (e.g., an NG interface message or a PDU SESSION RESOURCE SETUP REQUEST message) that includes the first PDU Session Establishment Accept message.

Collectively, events502A,504A,506A, and508A form a first PDU session establishment procedure550A.

During or after the first PDU session establishment procedure550A, the base station104generates a first RRC reconfiguration message including multicast configuration parameters, and also including a PTM MRB configuration for a PTM MRB associated with the first PDU session. The base station104can generate the first RRC reconfiguration message after (e.g., in response to) receiving the first CN-to-BS interface message at event506A or an additional interface message from the CN110(e.g., an NG interface message or a PDU SESSION RESOURCE MODIFY REQUEST message). The base station104then transmits510A the first RRC reconfiguration message to the UE102A. In some implementations, the base station104can include the first PDU Session Establishment Accept message in the first RRC reconfiguration message that the base station104transmits at event510A. In other implementations, the base station104transmits a downlink (DL) RRC message that includes the first PDU Session Establishment Accept message to the UE102A at event508A. The DL RRC message can be a DLlnformationTransfer message, an RRC reconfiguration message, or any suitable RRC message that can include a NAS PDU.

In some implementations, the base station104includes an MRB identity in the PTM MRB configuration in order to indicate the PTM MRB. Moreover, the base station104may include an identity of the first PDU session in the PTM MRB configuration. Thus, the UE102A can determine that the PTM MRB is associated with the first PDU session based on the MRB and PDU session identities in the PTM MRB configuration.

In response to the first RRC reconfiguration message that the base station104transmits at event510A, the UE102A sends512A the base station104a first RRC reconfiguration complete message. In some implementations, after sending510A the first RRC reconfiguration message or receiving512A the first RRC reconfiguration complete message, the base station104sends the CN110a first interface message (e.g., a PDU SESSION RESOURCE SETUP RESPONSE message or a PDU SESSION RESOURCE MODIFY RESPONSE message) to confirm that the base station104has configured radio resources for the UE102A for the first PDU session (or an associated quality of service (QoS) flow, as described below).

In some implementations, the CN110can determine that the UE102A has been configured with radio resources for the first PDU session based on a BS-to-CN interface message (not shown inFIG.5A) received from the base station104. At some time thereafter, the CN110may send515A MBS data packets of the first MBS to the base station104, which in turn sends516A the MBS data packets of the first MBS to the UE102A via the PTM MRB and multicast radio resources. The UE102A receives516A the MBS data packets of the first MBS using the PTM MRB configuration and multicast configuration that the UE102A received at event510A. In cases involving a group of UEs (e.g., the UE102A,102B, and/or one or more other UEs), the CN110may in some implementations send515A MBS data packets of the particular MBS service (i.e., the first MBS) to the base station104irrespective of whether the UE102A has been configured with radio resources for the first PDU session. In these implementations, after receiving515A the MBS data packets from the CN110, the base station104transmits (i.e., multicasts)516A the MBS data packets to the group of UEs via the PTM MRB on multicast radio resources in accordance with the multicast configuration.

In some implementations and/or scenarios, the CN110and/or base station104transmits (515A and/or516A) to the base station104and/or the UE102A the MBS data packets on a first QoS flow. That is, the CN110associates the MBS data packets with a first QoS profile of the first QoS flow, where the first QoS profile includes a first plurality of QoS parameters. The CN110and the base station104can enforce the first QoS profile on transmissions of the MBS data packets at events515A and516A, respectively. In some implementations, the CN110can indicate the first QoS profile in the first CN-to-BS interface message (at event506A) or an additional CN-to-BS interface message. The base station104may then determine to configure the PTM MRB configuration and multicast configuration based on the first QoS profile. In other implementations, the CN110can include the first PDU session identity in the first CN-to-BS interface message (at event506A) or an additional CN-to-BS interface message, and the base station104may determine the PTM MRB configuration and multicast configuration based on the first PDU session identity. In still other implementations, the CN110can include a first QoS flow identity of the first QoS flow in the first CN-to-BS interface message (at event506A) or an additional CN-to-BS interface message, and the base station104may determine the PTM MRB configuration and multicast configuration based on the first QoS flow identity.

In some implementations where the base station104and UE102A use the protocol architectures ofFIGS.3A and4A, the PTM MRB configuration sent by the base station104at event510A includes PDCP configuration parameters. The base station104can configure a first NR PDCP entity (e.g., the NR PDCP entity310inFIG.3A) in accordance with the PDCP configuration parameters, and the UE102A can configure a second NR PDCP entity (e.g., the NR PDCP entity410inFIG.4A) in accordance with the PDCP configuration parameters. The base station104(e.g., the first NR PDCP entity) transmits516A PDCP PDUs including the MBS data packets in accordance with the PDCP configuration parameters, and the UE102A (e.g., the second NR PDCP entity) receives516A the PDCP PDUs in accordance with the PDCP configuration parameters.

In some of these implementations, the PTM MRB configuration does not include SDAP configuration parameters. In other implementations, however, the PTM MRB configuration additionally includes SDAP configuration parameters. In these implementations, the base station104can configure a first SDAP entity (e.g., the SDAP entity312inFIG.3A) in accordance with the SDAP configuration parameters, and the UE102A can configure a second SDAP entity (e.g., the SDAP entity412inFIG.4A) in accordance with the SDAP configuration parameters. If the base station104configures the SDAP header in the SDAP configuration parameters, the base station104(e.g., the first SDAP entity) generates SDAP PDUs including the MBS data packets in accordance with the SDAP configuration parameters. Then the base station104(e.g., the first NR PDCP entity) generates PDCP PDUs including the SDAP PDUs, and transmits516A the PDCP PDUs to the UE102A in accordance with the PDCP configuration parameters. The UE102A (e.g., the second NR PDCP entity) receives516A the PDCP PDUs and processes the PDCP PDUs to obtain the SDAP PDUs, in accordance with the PDCP configuration parameters. The UE102A (e.g., the second SDAP entity) then processes the SDAP PDUs to obtain the MBS data packets in accordance with the SDAP configuration parameters.

In some implementations, the multicast configuration includes PHY configuration parameters, MAC configuration parameters, and/or RLC configuration parameters. The base station104can configure a first NR MAC entity (e.g., the NR MAC entity304or324inFIG.3A) in accordance with the MAC configuration parameters, and configure a first NR RLC entity (e.g., the NR RLC entity306inFIG.3A) in accordance with the RLC configuration parameters. Similarly, the UE102A can configure a second NR MAC entity (e.g., the NR MAC entity404or424inFIG.4A) in accordance with the MAC configuration parameters, and configure a second NR RLC entity (e.g., the NR RLC entity406ifFIG.4A) in accordance with the RLC configuration parameters. Thus, the base station104(e.g., the first NR RLC entity) transmits516A RLC PDUs including the PDCP PDUs to the UE102A in accordance with the RLC configuration parameters, and the UE102A (e.g., the second NR RLC entity) receives516A the RLC PDUs including the PDCP PDUs, and processes the RLC PDUs to obtain the PDCP PDUs, in accordance with the RLC configuration parameters. Similarly, the base station104(e.g., the first NR MAC entity) transmits516A MAC PDUs including the RLC PDUs to the UE102A in accordance with the MAC configuration parameters, and the UE102A (e.g., the second NR MAC entity) receives516A the MAC PDUs including the RLC PDUs, and processes the MAC PDUs to obtain the RLC PDUs, in accordance with the MAC configuration parameters. In some implementations, the base station104can include the PTM MRB identity in the RLC configuration parameters, and the UE102A can associate the second NR PDCP entity with the second NR RLC entity in accordance with the PTM MRB identity.

In some implementations, the base station104can transmit a separate RRC reconfiguration message, with each message including both the PTM MRB configuration and the multicast configuration, to each of a group of UEs (e.g., the UE102A, UE102B, and/or one or more other UEs not shown inFIGS.1A and5A), at event510A. In other implementations, the base station104can broadcast at least one RRC message including the PTM MRB configuration and multicast configuration at event510A. Thus, some of a group of UEs in an idle or inactive state can receive the RRC reconfiguration message(s) to obtain the PTM MRB configuration and multicast configuration. After receiving the PTM MRB configuration and multicast configuration, each UE in the group of UEs receives (i.e., event516A or a corresponding event for a different UE) the MBS data packets on the same multicast radio resources from the base station104, using the PTM MRB configuration and multicast configuration. In some implementations, the RRC message(s) can be one or more system information blocks (SIB s) or one or more MBS-specific RRC messages.

In some implementations, the multicast configuration for the UE102A to receive MBS data packets on multicast radio resources may include a radio network temporary identifier (RNTI). A group of the UEs or the UE102A can use the RNTI to receive, on a physical downlink control channel (PDCCH), a downlink control information (DCI) with a cyclic redundancy check (CRC) scrambled with the RNTI and is assigned a physical downlink shared channel (PDSCH) in accordance with the DCI. The PDSCH can carry a partial MBS data packet and/or one or more full MBS data packet. In some implementations, the RNTI can be a group RNTI (G-RNTI) or an MBS-specific RNTI (MBS-RNTI). In some implementations, the configuration parameters, e.g., for the UE102A to receive MBS data packets on the common radio resources, may include a DL BWP configuration that configures an MBS DL BWP.

Before or after the first PDU session establishment procedure550A, the UE102A and CN110(via the base station104) can perform a second PDU session establishment procedure518A for a second MBS, similar to the first PDU session establishment procedure550A. During or after the second PDU session establishment procedure518A, the base station104can transmit520A to the UE102A a second RRC reconfiguration message including a unicast configuration and a PTP MRB configuration configuring a PTP MRB for the UE102A. In response to the second RRC reconfiguration message received at event520A, the UE102A can transmit522A a second RRC reconfiguration complete message to the base station104.

In some implementations, after event520A and possibly also after event522A, the base station104sends a second BS-to-CN interface message (e.g., a PDU SESSION RESOURCE SETUP RESPONSE message or a PDU SESSION RESOURCE MODIFY RESPONSE message) to the CN110to confirm that the base station104has configured radio resources for the UE102A for the second PDU session. After receiving the second BS-to-CN interface message, the CN110sends531A MBS data packets of the second MBS to the base station104, which in turn sends532A the MBS data packets of the second MBS to the UE102A via the PTP MRB and unicast radio resources (i.e., radio resources dedicated to the UE102A alone) in accordance with the PTP MRB configuration and unicast configuration. The UE102A receives532A the MBS data packets of the second MBS via the PTP MRB on the unicast radio resources using the PTP MRB configuration and unicast configuration.

In some implementations where the base station104and UE102A use the protocol architectures ofFIGS.3A and4A, the PTP MRB configuration sent by the base station104at event520A includes PDCP configuration parameters. The base station104can configure a third PDCP entity (e.g., the NR PDCP entity320inFIG.3A) in accordance with the PDCP configuration parameters, and the UE102A can configure a fourth PDCP entity (e.g., the NR PDCP entity420inFIG.4A) in accordance with the PDCP configuration parameters. The base station104(e.g., the third NR PDCP entity) transmits532A PDCP PDUs including the MBS data packets in accordance with the PDCP configuration parameters, and the UE102A (e.g., the fourth NR PDCP entity) receives532A the PDCP PDUs in accordance with the PDCP configuration parameters.

In some of these implementations, the PTP MRB configuration does not include SDAP configuration parameters. In other implementations, however, the PTP MRB configuration additionally includes SDAP configuration parameters. In these implementations, the base station104can configure a third SDAP entity (e.g., the SDAP entity322inFIG.3A) in accordance with the SDAP configuration parameters, and the UE102A can configure a fourth PDCP entity (e.g., the SDAP entity422inFIG.4A) in accordance with the SDAP configuration parameters. If the base station104configures the SDAP header in the SDAP configuration parameters, the base station104(e.g., the third SDAP entity) generates SDAP PDUs including the MBS data packets in accordance with the SDAP configuration parameters. Then the base station104(e.g., the third NR PDCP entity) generates PDCP PDUs including the SDAP PDUs and transmits532A the PDCP PDUs to the UE102A in accordance with the PDCP configuration parameters. The UE102A (e.g., the fourth NR PDCP entity) receives532A the PDCP PDUs and processes the PDCP PDUs to obtain the SDAP PDUs, in accordance with the PDCP configuration parameters. The UE102A (e.g., the fourth SDAP entity) then processes the SDAP PDUs to obtain the MBS data packets in accordance with the SDAP configuration parameters.

In some implementations, the unicast configuration includes PHY configuration parameters, MAC configuration parameters, and/or RLC configuration parameters. The base station104can configure a first NR MAC entity (e.g., the NR MAC entity314or324inFIG.3A) in accordance with the MAC configuration parameters, and configure a first NR RLC entity (e.g., the NR RLC entity316) in accordance with the RLC configuration parameters. Similarly, the UE102A can configure a second NR MAC entity (e.g., the NR MAC entity414or424) in accordance with the MAC configuration parameters, and configure a second NR RLC entity (e.g., the NR RLC entity416inFIG.4A) in accordance with the RLC configuration parameters. Thus, the base station104(e.g., the first NR RLC entity) transmits532A RLC PDUs including the PDCP PDUs to the UE102A in accordance with the RLC configuration parameters, and the UE102A (e.g., the second NR RLC entity) receives532A the RLC PDUs including the PDCP PDUs, and processes the RLC PDUs to obtain the PDCP PDUs, in accordance with the RLC configuration parameters. Similarly, the base station104(e.g., the first NR MAC entity) transmits532A MAC PDUs including the RLC PDUs to the UE102A in accordance with the MAC configuration parameters, and the UE102A (e.g., the second NR MAC entity) receives532A the MAC PDUs including the RLC PDUs, and processes the MAC PDUs to obtain the RLC PDUs, in accordance with the MAC configuration parameters. In some implementations, the base station104can include the PTP MRB identity in the RLC configuration parameters, and the UE102A can associate the second NR PDCP entity with the second NR RLC entity in accordance with the PTP MRB identity.

In some implementations and/or scenarios, the CN110and/or base station104transmit (531A and/or532A) to the base station104and/or the UE102A the MBS data packets on a second QoS flow. That is, the CN110associates the MBS data packets with a second QoS profile of the second QoS flow, where the second QoS profile includes a second plurality of QoS parameters. The CN110and the base station104enforce the second QoS profile on transmissions of the MBS data packets at events531A and532A, respectively. In some implementations, the CN110can indicate the second QoS profile in a second CN-to-BS interface message (e.g., NG interface message or PDU SESSION RESOURCE SETUP

REQUEST message) during the second PDU session establishment procedure518A, similar to indicating the first QoS profile in the first CN-to-BS interface message at event506A of the first PDU session establishment procedure550A. In other implementations, the CN110can indicate the second QoS profile in an additional CN-to-BS interface message (e.g., a PDU SESSION RESOURCE MODIFY REQUEST message) that the CN110sends to the base station104after the second PDU session establishment procedure518A. In either case, the base station104may then determine to configure the PTP MRB configuration and unicast configuration parameters based on the second QoS profile. In other implementations, the CN110can include the second PDU session identity in the second CN-to-BS interface message, or in another CN-to-BS interface message, and the base station104may determine the PTP MRB configuration and unicast configuration based on the second PDU session identity. In still other implementations, the CN110can include a second QoS flow identity of the second QoS flow in the second CN-to-BS interface message (or other CN-to-BS interface message), and the base station104may determine the PTP MRB configuration and unicast configuration based on the second QoS flow identity.

In some implementations, the first RRC reconfiguration message that the base station104transmits510A to the UE102A can include one or more MBS-specific information elements (IE(s)) indicating the parameters of the multicast configuration. In some implementations, the base station104configures the UE102A to use an RLC unacknowledged mode (UM) for the PTM MRB in the RLC configuration parameters of the multicast configuration. In other implementations, the second RRC reconfiguration message that the base station104transmits520A to the UE102A can include a CellGroupConfigIE indicating the parameters of the unicast configuration. In some implementations, the base station104configures the UE102A to use an RLC acknowledged mode (AM) for the PTP MRB in the RLC configuration parameters of the unicast configuration.

Before, during, or after the PDU session establishment procedures550A and/or518A, the UE102A in some implementations and scenarios can perform a third PDU session establishment procedure with the base station104and the CN110(e.g., AMF164and/or SMF166or another AMF and/or SMF), which may be similar to the first PDU session establishment procedure550A. In the third PDU session establishment procedure, the UE102A transmits to the CN110, via the base station104, a third PDU Session Establishment Request message for establishing a third PDU session for one or more non-MBS (unicast) services. In response, the CN110sends a third PDU Session Establishment Accept message to the UE102A via the base station104. For example, the one or more unicast services may be a voice call, a video call, or an Internet service (e.g., a service for email, navigation, social media, streaming, gaming, web browsing, etc.). To indicate that the UE102A is requesting a unicast service, the UE102A in some implementations may include a flag or other indication in the third PDU Session Establishment Request message. For example, the flag or indication may be a data network name (DNN) field set to “internet” or “ims” or corresponding to a unicast service. In other implementations, the third PDU Session Establishment Request message is a unicast-specific PDU Session Establishment Request message. In still other implementations, the UE102A indicates that a non-MBS unicast service is requested by excluding the MBS flag from the third PDU Session Establishment Request message.

In some implementations, the CN110can indicate a third QoS profile in a third CN-to-BS interface message (e.g., an NG interface message or a PDU SESSION RESOURCE SETUP REQUEST message) during the third PDU session establishment procedure, similar to indicating the first QoS profile in the first CN-to-BS interface message or the second QoS profile. The base station104may determine a DRB configuration and a second unicast configuration for exchanging data packets of the unicast service(s) on a DRB between the UE102A and base station104based on the third QoS profile. In other implementations, the CN110can include the third PDU Session identity in the third CN-to-BS interface message, the base station104may determine to configure the DRB configuration and second unicast configuration parameters based on the third PDU Session identity. In yet other implementations, the CN110can include a third QoS flow identity of the third QoS flow in the third CN-to-BS interface message, the base station104may determine the DRB MRB configuration and second unicast configuration based on the third QoS flow identity.

During or after the third PDU session establishment procedure, the base station104may transmit a third RRC reconfiguration message that includes the DRB configuration for the DRB and the second unicast configuration. In response, the UE102A may transmit a third RRC reconfiguration complete message to the base station104. In some implementations, after receiving the third RRC reconfiguration complete message, the base station104sends a third BS-to-CN interface message (e.g., a PDU SESSION RESOURCE SETUP RESPONSE message) to the CN110to confirm that the base station104has configured radio resources for the UE102A for the third PDU session. After receiving the third BS-to-CN interface message, the CN110sends data packets of the unicast service(s) to the base station104, which in turn transmits the data packets of the unicast service(s) to the UE102A via the DRB and the second unicast radio resources (i.e., radio resources dedicated to the UE102A alone) in accordance with the DRB configuration and the second unicast configuration.

In some implementations, the second unicast configuration includes PHY configuration parameters, MAC configuration parameters, and/or RLC configuration parameters configuring unicast radio resources. In accordance with the second unicast configuration, the base station104can assign unicast radio resources for data packets of the unicast service(s) to a particular UE (e.g., the UE102A). That is, the unicast radio resources can be dedicated only to one particular UE. The base station104transmits data packets of the unicast service(s) on dedicated resources and the DRB to the particular UE, and the particular UE transmits data packets of the unicast service(s) on dedicated resources and the DRB to the base station104.

In some implementations, the third RRC reconfiguration message can include a CellGroupConfigIE indicating the configuration parameters. The base station104can indicate that the DRB is associated with the third PDU session in the third RRC reconfiguration message. For example, the DRB configuration can include a PDU session identity of the third PDU session. In some implementations, the base station104configures the UE102A to use an RLC AM or UM for the DRB in the RLC configuration parameters of the unicast configuration.

In some implementations, the UE102A and CN110can perform a first PDU session release procedure via the base station104, to release the first PDU session after the second PDU session establishment procedure518A. In the first PDU session release procedure, the CN110sends a first PDU Session Release Command message to the UE102A via the base station104to release the first PDU session. In response, the UE102A sends a first PDU Session Release Complete message to the CN110via the base station104. In one implementation, the UE102A sends a first PDU Session Release Request message to the CN110via the base station104after (e.g., in response to) the second PDU establishment procedure518A, to initiate the first PDU session release procedure. In response, the CN110sends the first PDU Session Release Command message to the UE102A via the base station104to release the first PDU session. In an alternative implementation, the UE102A does not send a PDU Session Release Request message to the CN110via the base station104to initiate the first PDU session release procedure. In this latter implementation, the CN110initiates the first PDU session release procedure after (e.g., in response to) performing the second PDU session establishment procedure518A. In response to a fourth CN-to-BS interface message (e.g., a PDU Session Resource Release Command message) in the first PDU session release procedure, the base station104can send a fourth RRC reconfiguration message to the UE102A to release the PTM MRB configuration and multicast configuration. The UE102A releases the PTM MRB configuration and multicast configuration in response to the fourth RRC reconfiguration message. After releasing the PTM MRB configuration and multicast configuration, the UE102A no longer receives MBS data packets of the first MBS.

In other implementations, the UE102A and CN110do not perform a PDU session release procedure to release the first PDU session after the second PDU session establishment procedure518A. In one of these implementations, the UE102A may decide to stop receiving MBS data packets via the PTM MRB to save battery power. In another of these implementations, the UE102A may continue receiving MBS data packets via the PTM MRB and multicast radio resources while receiving MBS data packets via the PTP MRB and unicast radio resources. In some implementations and scenarios, the UE102A may receive MBS data packets via the PTM MRB and PTP MRB in parallel because the UE102A operates as a hotspot device. For example, the UE102A may present information associated with a first MBS to a user via a physical display device (and/or a speaker, etc.) of the UE102A, and forward data packets of a second MBS to another device. In another example, the UE102A may forward data packets of a first MBS to a first device and forward MBS data packets of a second MBS to a second device. In still another example, the UE102A may present information associated with a first MBS in a first display area, and present information associated with a second MBS on a second display area. In this latter example, the UE102A may have two physical display devices (e.g., screens) corresponding to the two display areas. Alternatively, the UE102A may present both display areas on a single physical display device.

In some implementations, the UE102A and CN110can perform a second PDU session release procedure via the base station104to release the second PDU session. In some scenarios and/or implementations, the UE102A and CN110can perform the second PDU session release procedure in response to switching from receiving the second MBS to receiving the first MBS. In the second PDU session release procedure, the CN110sends a second PDU Session Release Command message to the UE102A via the base station104to release the second PDU session. In response, the UE102A sends a second PDU Session Release Complete message to the CN110via the base station104. In one implementation, the UE102A sends a second PDU Session Release Request message to the CN110via the base station104to initiate the second PDU session release procedure. In response, the CN110sends the second PDU Session Release Command message to the UE102A via the base station104to release the second PDU session. In an alternative implementation, the UE102A does not send a PDU Session Release Request message to the CN110via the base station104to initiate the second PDU session release procedure, and the CN110instead initiates the second PDU session release procedure. In response to a fourth CN-to-BS interface message (e.g., a PDU Session Resource Release Command message) in the second PDU session release procedure, the base station104can send a fourth RRC reconfiguration message to the UE102A to release the PTP MRB configuration and unicast configuration. In response to the fourth RRC reconfiguration message, the UE102A releases the PTP MRB configuration and unicast configuration, and transmits a fourth RRC reconfiguration complete message to the base station104. After releasing the PTP MRB configuration and unicast configuration, the UE102A no longer receives MBS data packets of the first MBS.

In other implementations, the UE102A and CN110do not perform a PDU session release procedure to release the second PDU session. In one of these implementations, the UE102A may decide to stop receiving MBS data packets via the PTP MRB to save battery power. In another of these implementations, the UE102A may continue receiving MBS data packets via the PTP MRB and unicast radio resources while receiving MBS data packets via the PTM MRB and multicast radio resources, as described above.

In some implementations, the MBS data packets can be IP packets, TCP/IP packets, UDP/IP packets, Real-Time Transport Protocol (RTP)/UDP/IP packets or RTP/TCP/IP packets.

FIG.5Billustrates a scenario500B similar to the scenario500A ofFIG.5A, but in which the UE102A and CN110do not perform a PDU session establishment procedure to establish a PDU session for the second MBS. Initially, in the scenario500B, the UE102A and CN110perform a PDU session establishment procedure550B to establish a PDU session for at least a first MBS via the base station104. The procedure550B may be similar to event550A ofFIG.5A. During or after the PDU session establishment procedure550B, the base station104sends510B the UE102A an RRC reconfiguration message that includes a PTM MRB configuration and a multicast configuration (e.g., similar to event510A). The UE102A responds by sending512B the base station104an RRC reconfiguration complete message (e.g., similar to event512B). Thereafter, the CN110sends515B the base station104MBS data packets of the first MBS (e.g., similar to event515A), which the UE102A receives516B from the base station104via multicast radio resources in accordance with the PTM MRB configuration and multicast configuration (e.g., similar to event516A).

Later in time, and instead of requesting the establishment of a second PDU session (as in scenario500A), the UE102A generates an MBS request message to request a second MBS, and sends521B the MBS request message to the base station104. In the scenario500B, the second MBS, like the first MBS, is supported by the initial PDU session. In response, the base station104sends523B the MBS request message to the CN110. In some implementations, the MBS request message can be a NAS message, a Session Initiation Protocol (SIP) message, or an HTTP message. In other implementations, the UE102A transmits521B and the base station104forwards/transmits523B an IP packet, a TCP packet, or a UDP packet that includes the MBS request message. After (e.g., in response to) receiving523B the MBS request message, the CN110sends524B a CN-to-BS interface message (e.g., an NG interface message or a PDU SESSION RESOURCE MODIFY REQUEST message) to the base station104. The CN-to-BS interface message may be similar to the additional CN-to-BS interface message described above forFIG.5A.

After (e.g., in response to) receiving524B the CN-to-BS interface message, the base station104transmits520B an RRC reconfiguration message to the UE102A. The RRC reconfiguration message includes a PTP MRB configuration and a unicast configuration. Event520B may be similar to event520A ofFIG.5A. In response, the UE102A transmits522B an RRC reconfiguration complete message to the base station104(e.g., similar to event522A). After transmitting520B the RRC reconfiguration message and/or after receiving the522B the RRC reconfiguration complete message, the base station104sends526B a BS-to-CN interface message to confirm that the base station104has configured radio resources for the UE102A for the PDU session or the second MBS. After receiving526B the BS-to-CN interface message, the CN110sends531B MBS data packets of the second MBS to the base station104, which in turn sends532B the MBS data packets of the second MBS to the UE102A via the PTP MRB and unicast radio resources in accordance with the PTP MRB configuration and unicast configuration. The UE102A receives532B the MBS data packets of the second MBS via the PTP MRB on the unicast radio resources using the PTP MRB configuration and unicast configuration.

FIG.5Cillustrates a scenario500C similar to the scenario500B ofFIG.5B. WhereasFIG.5Billustrates a scenario500B in which the first (earlier-requested) MBS is associated with PTM/multicast transmission and the second (later-requested) MBS is associated with PTP/unicast transmission, however,FIG.5Cillustrates a scenario500C in which the first MBS is associated with PTP/unicast transmission and the second MBS is associated with PTM/multicast transmission. It is understood that, just asFIG.5Cshows the reverse order relative toFIG.5B, the order of scenario500A inFIG.5Amay also be reversed, such that the first (earlier-requested) MBS is associated with PTP/unicast transmission and the second (later-requested) MBS is associated with PTM/multicast transmission.

In the scenario500C, the UE102A and CN110initially perform a PDU session establishment procedure550C to establish a PDU session for at least a first MBS via the base station104. The procedure550C may be similar to event550A or518A ofFIG.5A. During or after the PDU session establishment procedure550C, the base station104sends520C the UE102A an RRC reconfiguration message that includes a PTP MRB configuration and a unicast configuration (e.g., similar to event520A). The UE102A responds by sending522C the base station104an RRC reconfiguration complete message (e.g., similar to event522A). Thereafter, the CN510sends531C the base station104MBS data packets of the first MBS (e.g., similar to event531A), which the UE102A receives532C from the base station104via unicast radio resources in accordance with the PTP MRB configuration and unicast configuration (e.g., similar to even532A).

Later in time, the UE102A generates an MBS request message to request a second MBS, and transmits521C the MBS request message to the base station104. In response, the base station104sends523C the MBS request message to the CN110. The MBS request message may be similar to the message sent at events521B and523B. After (e.g., in response to) receiving523C the MBS request message, the CN110sends524C a CN-to-BS interface message (e.g., an NG interface message or PDU SESSION RESOURCE MODIFY REQUEST message) to the base station104. The interface message may be similar to the message sent at event524C.

After (e.g., in response to) receiving524C the CN-to-BS interface message, the base station104transmits510C an RRC reconfiguration message to the UE102A. The RRC reconfiguration message includes a PTM MRB configuration and a multicast configuration. Event510C may be similar to event510A ofFIG.5A. In response, the UE102A transmits512C an RRC reconfiguration complete message to the base station104(e.g., similar to event512A). After transmitting510C the RRC reconfiguration message and/or receiving512C the RRC reconfiguration complete message, the base station104sends526C a BS-to-CN interface message to confirm that the base station104has configured radio resources for the UE102A for the PDU session or the second MBS (e.g., similar to event526B). After receiving526C the BS-to-CN interface message, the CN110sends515C MBS data packets of the second MBS to the base station104, which in turn sends516C the MBS data packets of the second MBS to the UE102A via the PTM MRB and multicast radio resources, in accordance with the PTM MRB configuration and multicast configuration. The UE102A receives532B the MBS data packets of the second MBS via the PTM MRB on the multicast radio resources using the PTM MRB configuration and multicast configuration.

As noted above,FIGS.6A-6Care messaging diagrams of example implementations and scenarios in which the UE102A requests an MBS that is initially associated with multicast transmission, but at some point changes (e.g., at the direction of the CN110) to unicast transmission. It is understood that the order of multicast/unicast configuration and transmission in the scenarios shown inFIGS.6A-6Cmay be reversed, such that the CN110and base station104initially provide MBS data packets via unicast transmission and then later provide MBS data packets via multicast transmission.

Referring first toFIG.6A, in a scenario600A, the UE102A and CN110initially perform a PDU session establishment procedure650A to establish a PDU session for an MBS via the base station104. The procedure650A may be similar to event550A ofFIG.5A. During or after the PDU session establishment procedure650A, the base station104generates a first RRC reconfiguration message including a multicast configuration and a PTM MRB configuration for a PTM MRB associated with the PDU session. The base station104then sends610A the first RRC reconfiguration message to the UE102A (e.g., similar to event510A). The UE102A responds by transmitting612A an RRC reconfiguration complete message to the base station104(e.g., similar to event512A). Thereafter, the CN110sends615A the base station104MBS data packets (e.g., similar to event515A), which the UE102A receives616A from the base station104via multicast radio resources in accordance with the PTM MRB configuration and multicast configuration (e.g., similar to event516A).

Later in time, the CN110determines634A to request that the base station104reconfigure radio resources for the PDU session from multicast to unicast. In some implementations, the CN110determines634A to do so based on the number of existing PDU sessions (for different UEs) for the MBS. If the number of existing PDU sessions for the MBS is below a predetermined threshold number, the CN110in response sends624A the base station104a CN-to-BS interface message requesting that the base station104reconfigure radio resources from multicast to unicast for the PDU session. If the number of existing PDU sessions for the MBS is not below the threshold number, the CN110in response does not request the base station104to reconfigure radio resources from multicast to unicast for the PDU session (i.e., event624A is omitted). The CN-to-BS interface message may be an NG interface message or a PDU SESSION RESOURCE MODIFY REQUEST message, for example.

In some implementations, the CN110can include a PDU session identity of the PDU session in the CN-to-BS interface message of event624A, and indicates or includes a QoS profile or QoS flow identity (e.g., similar to the second QoS profile or second QoS flow identity discussed in connection withFIG.5A) to request the base station104to reconfigure radio resources from multicast to unicast for the PDU session. Thus, the base station104can determine a PTP MRB configuration and unicast configuration for the PDU session based on the QoS profile or QoS flow identity, and send620A the UE102A an RRC reconfiguration message including the PTP MRB configuration and unicast configuration (e.g., similar to event520A). In other implementations, the base station104does not determine the PTP MRB configuration or unicast configuration for the PDU session based on QoS profile or QoS flow identity.

After receiving620A the RRC reconfiguration message620A, the UE102A sends622A the base station104an RRC reconfiguration complete message (e.g., similar to event522A). At some point thereafter, the CN110sends631A MBS data packets to the base station104(e.g., similar to event531A), which in turn sends632A the MBS data packets to the UE102A via the PTP MRB and unicast radio resources in accordance with the PTP MRB configuration and unicast configuration (e.g., similar to event532A). The UE102A receives632A the MBS data packets via the PTP MRB on the unicast radio resources using the PTP MRB configuration and unicast configuration.

In alternative implementations, the base station104can determine to reconfigure radio resources from multicast to unicast for the PDU session without receiving a CN-to-BS interface message requesting the reconfiguration (e.g., autonomously determine to reconfigure to unicast radio resources). In response to the determination, the base station104transmits620A the RRC reconfiguration message to the UE102A. In some of these implementations, the base station104determines to do so based on the number of existing PDU sessions (for different UEs) for the MBS. If the number of existing PDU sessions for the MBS is below a predetermined threshold number, the base station104determines to reconfigure radio resources from multicast to unicast for the PDU session. If the number of existing PDU sessions for the MBS is not below the threshold number, the base station104instead determines not to reconfigure radio resources from multicast to unicast for the PDU session (i.e., event620A is omitted).

In some implementations, the base station104can indicate, in the RRC reconfiguration message of event620A, that the UE102A is to release the PTM MRB configuration and/or multicast configuration. In response to the RRC reconfiguration message or the indication therein, the UE102A releases the PTM MRB configuration and/or multicast configuration. In some implementations, in response to the RRC reconfiguration message, the UE102A releases the SDAP entity412(if existing), the NR PDCP entity410, the NR RLC entity406, and the NR MAC entity404(if existing). If the UE102A uses the NR MAC entity424instead of the NR MAC entity404, the UE102A reconfigures the NR MAC entity424to release the multicast configuration parameters in response to the RRC reconfiguration message. Even if the base station104indicates that the UE102A is to release the PTM MRB configuration and/or multicast configuration in the RRC reconfiguration message at event620A, however, the base station104does not release the SDAP entity312(if existing), the NR PDCP entity310, the NR RLC entity306, and the NR MAC entity304(if existing), because those entities may still be used to multicast to other UEs (e.g., the UE102B and/or one or more other UEs). In scenarios where the base station104indicates that the UE102A is to release the multicast configuration in the RRC reconfiguration message at event620A, and where the base station104uses the NR MAC entity324instead of the NR MAC entity304, the base station104does not reconfigure the NR MAC entity324to release the multicast configuration. The base station104may, however, release the SDAP entity312(if existing), the NR PDCP entity310, the NR RLC entity306, and the NR MAC entity304(if existing), or reconfigure the NR MAC entity324to release the multicast configuration, if the number of PDU sessions for the MBS is zero, or if the base station104receives a request from the CN110to stop multicasting the MBS.

FIG.6Billustrates a scenario600B similar to the scenario600A ofFIG.6A, but in which the base station104does not need to reconfigure the MRB when changing from multicast to unicast radio resources for the MBS. Initially, the UE102A and CN110perform a PDU session establishment procedure650B to establish a PDU session for an MBS via the base station104. The procedure650A may be similar to event550A or650A. During or after the PDU session establishment procedure650B, the base station104generates a first RRC reconfiguration message including an MRB configuration and a multicast configuration, and sends611B the RRC reconfiguration message to the UE102A. The RRC reconfiguration message of event611B may be similar to that of events510A and610A, but the MRB configuration is not specific to only PTM transmissions.

The UE102A responds by sending612B an RRC reconfiguration complete message to the base station104(e.g., similar to events512A and612A). Thereafter, the CN110sends615B the base station104MBS data packets (e.g., similar to event515A and615A), which the UE102A receives617B from the base station104via multicast radio resources in accordance with the MRB configuration and multicast configuration (e.g., similar to events516A and616A, but without a PTM-specific MRB).

In some implementations where the base station104and UE102A use the protocol architectures ofFIGS.3B and4B, respectively, the MRB configuration includes PDCP configuration parameters. The base station104can configure a first NR PDCP entity (e.g., the NR PDCP entity310inFIG.3B) in accordance with the PDCP configuration parameters, and the UE102A can configure a second NR PDCP entity (e.g., the NR PDCP entity410inFIG.4B) in accordance with the PDCP configuration parameters. The base station104(e.g., the first NR PDCP entity) then transmits617B PDCP PDUs including the MBS data packets in accordance with the PDCP configuration parameters, and the UE102A (e.g., the second NR PDCP entity410) receives617B the PDCP PDUs in accordance with the PDCP configuration parameters.

The MRB configuration may also include PDCP configuration parameters in other implementations where the base station104and UE102A use the protocol architectures of any one ofFIGS.3C-3Fand any corresponding one of4C-4F, respectively. The base station104can configure a first NR PDCP entity (e.g., the NR PDCP entity330in any ofFIGS.3C-3F) in accordance with the PDCP configuration parameters, and the UE102A can configure a second NR PDCP entity (e.g., the NR PDCP entity430in any ofFIGS.4C-4F) in accordance with the PDCP configuration parameters. The base station104(e.g., the first NR PDCP entity) then transmits617B PDCP PDUs including the MBS data packets (without SDAP headers) in accordance with the PDCP configuration parameters, and the UE102A (e.g., the second NR PDCP entity) receives617B the PDCP PDUs in accordance with the PDCP configuration parameters.

In some implementations where the base station104and UE102A use the protocol architectures of any one ofFIGS.3B-3Fand any corresponding one ofFIGS.4B-4F, respectively, the MRB configuration can additionally include SDAP configuration parameters. The base station104can configure a first SDAP entity (e.g., the SDAP entity332in any ofFIGS.3B-3F) in accordance with the SDAP configuration parameters. The UE102A can configure a second SDAP entity (e.g., the SDAP entity432in any ofFIGS.4B-4F) in accordance with the SDAP configuration parameters. Alternatively, the MRB configuration does not include SDAP configuration parameters. In this case, the UE102A (e.g., the second NR PDCP entity) receives617B the PDCP PDUs, and processes the PDCP PDUs to obtain the MBS data packets, in accordance with the PDCP configuration parameters. If the base station104configures the SDAP header in the SDAP configuration parameters, the base station104generates SDAP PDUs including the MBS data packets in accordance with the SDAP configuration parameters. Thereafter, the base station104(e.g., the first NR PDCP entity) generates PDCP PDUs including the SDAP PDUs, and transmits617B the PDCP PDUs to the UE102A in accordance with the PDCP configuration parameters. The UE102A (e.g., the second NR PDCP entity) receives617B the PDCP PDUs, and processes the PDCP PDUs to obtain the SDAP PDUs, in accordance with the PDCP configuration parameters. The UE102A (e.g., the second SDAP entity) processes the SDAP PDUs to obtain the MBS data packets in accordance with the SDAP configuration parameters.

In some implementations, the multicast configuration includes PHY configuration parameters, MAC configuration parameters, and/or RLC configuration parameters. The base station104can configure a first NR MAC entity (e.g., the NR MAC entity304in any ofFIGS.3B-3Dand the NR MAC entity324inFIG.3E or3F) in accordance with the MAC configuration parameters, and configure a first NR RLC entity (e.g., the NR RLC entity306in any ofFIG.3B,3C, or3E or the NR RLC entity326inFIG.3D or3F) in accordance with the RLC configuration parameters. Similarly, the UE102A can configure a second NR MAC entity (e.g., the NR MAC entity404in any ofFIGS.4B-4Dand the NR MAC entity424inFIG.4E or4F) in accordance with the MAC configuration parameters, and configure a second NR RLC entity (e.g., the NR RLC entity406in any ofFIG.4B,4C, or4E or the NR RLC entity426inFIG.3D or3F) in accordance with the RLC configuration parameters. Thus, the base station104(e.g., the first NR RLC entity) transmits617B RLC PDUs including the PDCP PDUs to the UE102A in accordance with the RLC configuration parameters, and the UE102A (e.g., the second NR RLC entity) receives617B the RLC PDUs including the PDCP PDUs, and processes the RLC PDUs to obtain the PDCP PDUs, in accordance with the RLC configuration parameters. Similarly, the base station104(e.g., the NR MAC entity304or324) transmits617B MAC PDUs including the RLC PDUs to the UE102A in accordance with the MAC configuration parameters, and the UE102A (e.g., the NR RLC entity404) receives617B the MAC PDUs including the RLC PDUs, and processes the MAC PDUs to obtain the RLC PDUs, in accordance with the MAC configuration parameters. In some implementations, the base station104can include an MRB identity of the MRB in the RLC configuration parameters, and the UE102A can associate the second NR PDCP entity with the second NR RLC entity in accordance with the MRB identity.

In some implementations, the base station104can transmit a separate RRC reconfiguration message, with each message including both the MRB configuration and the multicast configuration, to each of a group of UEs (e.g., UE102A, UE102B, and/or one or more other UEs not shown inFIG.1AandFIG.6B), at event611B. In other implementations, the base station104can broadcast at least one RRC message including the MRB configuration and multicast configuration at event611B. Thus, some of a group of UEs in an idle or inactive state can receive the RRC reconfiguration message(s) to obtain the MRB configuration and multicast configuration. After receiving the MRB configuration and multicast configuration, each UE in the group of UEs receives (i.e., event617B or a corresponding event for a different UE) the MBS data packets on the same multicast radio resources from the base station104, using the MRB configuration and multicast configuration. In some implementations, the RRC message(s) can be SIB s or one or more MBS-specific RRC messages.

Later in time, the CN110determines634B to request that the base station104reconfigure radio resources for the PDU session from multicast to unicast. In some implementations, the CN110determines634B to do so based on the number of existing PDU sessions (for different UEs) for the MBS. If the number of existing PDU sessions for the MBS is below a predetermined threshold number, the CN110in response sends624B the base station104a CN-to-BS interface message requesting that the base station104reconfigure radio resources from multicast to unicast for the PDU session. If the number of existing PDU sessions for the MBS is not below the threshold number, the CN110in response does not request the base station104to reconfigure radio resources from multicast to unicast for the PDU session (i.e., event624B is omitted). The CN-to-BS interface message may be an NG interface message or a PDU SESSION RESOURCE MODIFY REQUEST message, for example.

In some implementations, the CN110can include a PDU session identity of the PDU session in the CN-to-BS interface message of event624B, and indicates or includes a QoS profile or a QoS flow identity (e.g., similar to the second QoS profile or second QoS flow identity described in connection withFIG.5A) to request the base station104to reconfigure radio resources from multicast to unicast for the PDU session. Thus, the base station104can determine a unicast configuration for the MRB based on the QoS profile or QoS flow identity, and send621B the UE102A an RRC reconfiguration message including the unicast configuration. In other implementations, the base station104does not determine the unicast configuration for the PDU session based on QoS profile or QoS flow identity.

After receiving621B the RRC reconfiguration message, the UE102A sends622B the base station104an RRC reconfiguration complete message (e.g., similar to event522A). At some point thereafter, the CN110sends631B MBS data packets to the base station104(e.g., similar to event531A), which in turn sends633B the MBS data packets to the UE102A via the MRB and unicast radio resources in accordance with the MRB configuration (of event611B) and unicast configuration (of event621B). The UE102A receives633B the MBS data packets via the MRB on the unicast radio resources using the MRB configuration and unicast configuration.

In alternative implementations, the base station104can determine to reconfigure radio resources from multicast to unicast for the MRB without receiving a CN-to-BS interface message requesting the reconfiguration (e.g., autonomously determine to reconfigure to unicast radio resources). In response to the determination, the base station104transmits621B the RRC reconfiguration message to the UE102A. In some of these implementations, the base station104determines to do so based on the number of existing PDU sessions (for different UEs) for the MBS. If the number of existing PDU sessions for MBS the is below a predetermined threshold number, the base station104determines to reconfigure radio resources from multicast to unicast for the MRB. If the number of existing PDU sessions for MBS the is not below the threshold number, the base station104determines not to reconfigure radio resources from multicast to unicast for the MRB.

The base station104may or may not include an MRB configuration in the RRC reconfiguration message at event621B. In some implementations where the base station104and UE102A use the protocol architectures of any one ofFIGS.3C-3Fand any corresponding one ofFIGS.4C-4F, respectively, the base station104does not include an MRB configuration in the RRC reconfiguration message at event621B, and the UE102A and base station104do not use SDAP to communicate MBS data packets at event633B. In such implementations, the base station104(e.g., the first NR PDCP entity) transmits633B PDCP PDUs including the MBS data packets (without SDAP headers) in accordance with the PDCP configuration parameters, and the UE102A (e.g., the second NR PDCP entity) receives633B the PDCP PDUs, and processes the PDCP PDUs to obtain the MBS data packets, in accordance with the PDCP configuration parameters.

In other of these implementations where the base station104does not include an MRB configuration in the RRC reconfiguration message at event621B, but where the UE102A and base station104use SDAP to communicate MBS data packets at event617B, the base station104generates SDAP PDUs including the MBS data packets in accordance with the SDAP configuration parameters. The base station104(e.g., the first NR PDCP entity) then generates PDCP PDUs including the SDAP PDUs and transmits633B the PDCP PDUs to the UE102A in accordance with the PDCP configuration parameters. The UE102A (e.g., the second NR PDCP entity) receives633B the PDCP PDUs, and processes the PDCP PDUs to obtain the SDAP PDUs, in accordance with the PDCP configuration parameters. The UE102A (e.g., the second SDAP entity) processes the SDAP PDUs to obtain the MBS data packets in accordance with the SDAP configuration parameters.

In some implementations, the base station104can continue PDCP sequence numbering to subsequently assign PDCP sequence numbers for the PDCP PDUs (or the SDAP PDUs or MBS data packets) that the base station104transmits at event633B. For example, the base station104may assign PDCP sequence number N for the last PDCP PDU, and include the PDCP sequence number N in the last PDCP PDU at event617B. The base station104may then assign PDCP sequence number N+1 in the first PDCP PDU at event633B, where N is an integer greater than zero. In such implementations, the UE102A also continues PDCP sequence numbering to receive633B the PDCP PDUs. If the UE102A receives the last PDCP PDU with PDCP sequence number L (e.g., L<=1V), and if a PDCP sequence number in the first PDCP PDU the UE102A receives at event633B is M (where M is an integer greater than N), the UE102A can send a PDCP status report to the base station104to prompt the base station104to retransmit missing PDCP PDUs with PDCP sequence numbers (L+1), . . . , (M−1). In some implementations, the base station104retransmits the missing PDCP PDUs after (e.g., in response to) receiving the PDCP status report. In other implementations, the base station104retransmits a portion of the missing PDCP PDUs after (e.g., in response to) receiving the PDCP status report. In still other implementations, the base station104ignores the PDCP status report (e.g., the base station104does not retransmit any of the missing PDCP PDUs regardless of what the report indicates). In another alternative implementation, the UE102A ignores missing PDCP PDUs with PDCP sequence numbers (L+1), . . . , (M−1), without sending the PDCP status report.

In other implementations, the base station104reinitializes PDCP sequence numbering for the PDCP PDUs (or the SDAP PDUs or MBS data packets) that the base station104transmits at event633B. For example, the base station104may assign PDCP sequence number N for the last PDCP PDU, and include the PDCP sequence number N in the last PDCP PDU at event617B. The base station104can then assign PDCP sequence number 0 in the first PDCP PDU at event633B. In such implementations, the UE102A also reinitializes PDCP sequence numbering to receive633B the PDCP PDUs. If a PDCP sequence number in the first PDCP PDU the UE102A receives at event633B is M>0, the UE102A can send a PDCP status report to the base station104to prompt the base station104to retransmit missing PDCP PDUs with PDCP sequence number 0, . . . , (M−1). In some implementations the base station104retransmits the missing PDCP PDUs after (e.g., in response to) receiving the PDCP status report. In other implementations, the base station104retransmits a portion of the missing PDCP PDUs after (e.g., in response to) receiving the PDCP status report. In still other implementations, the base station104ignores the PDCP status report (e.g., the base station104does not retransmit any of the missing PDCP PDUs regardless of what the report indicates). In another alternative implementation, the UE102A ignores missing PDCP PDUs with PDCP sequence numbers 0, . . . , (M−1), without sending the PDCP status report.

In some implementations where the base station104and UE102A use the protocol architectures ofFIGS.3B and4B, respectively, the base station104can include, in the RRC reconfiguration message of event621B, a second MRB configuration including second PDCP configuration parameters. The base station104can configure a third NR PDCP entity (e.g., the NR PDCP entity320inFIG.3B) in accordance with the second PDCP configuration parameters, and the UE102A can configure a fourth NR PDCP entity (e.g., the NR PDCP entity420inFIG.4B) in accordance with the second PDCP configuration parameters. If the base station104configures the SDAP configuration parameters in the first MRB configuration, and if the second MRB configuration configures the UE102A to continue applying the SDAP configuration parameters in the first MRB configuration, the base station104generates SDAP PDUs including the MBS data packets in accordance with the SDAP configuration parameters. The base station104(e.g., the third NR PDCP entity) then generates PDCP PDUs including the SDAP PDUs, and transmits633B the PDCP PDUs to the UE102A in accordance with the second PDCP configuration parameters. The UE102A (e.g., the fourth NR PDCP entity) receives633B the PDCP PDUs, and processes the PDCP PDUs to obtain the SDAP PDUs, in accordance with the second PDCP configuration parameters. The UE102A (e.g., the second SDAP entity) processes the SDAP PDUs to obtain the MBS data packets in accordance with the SDAP configuration parameters. If the base station104configures second SDAP configuration parameters in the second MRB configuration, the UE102A and base station104update the SDAP configuration parameters in the first MRB configuration in accordance with the second SDAP configuration parameters. In this case, the base station104(e.g., the first SDAP entity) generates SDAP PDUs including the MBS data packets in accordance with the updated SDAP configuration parameters. The base station104(e.g., the third NR PDCP entity) can then generate PDCP PDUs including the SDAP PDUs, and transmit633B the PDCP PDUs to the UE102A in accordance with the second PDCP configuration parameters. The UE102A (e.g., the fourth NR PDCP entity) receives633B the PDCP PDUs, and processes the PDCP PDUs to obtain the SDAP PDUs, in accordance with the second PDCP configuration parameters. The UE102A (e.g., the second SDAP entity) processes the SDAP PDUs to obtain the MBS data packets in accordance with the updated SDAP configuration parameters.

In some implementations where the base station104and UE102A use the protocol architectures of any one ofFIGS.3B-3Fand any corresponding one ofFIGS.4B-4F, respectively, the unicast configuration includes PHY configuration parameters, MAC configuration parameters, and/or RLC configuration parameters. The base station104can configure a third NR MAC entity (e.g., the NR MAC entity314in any ofFIGS.3B-3D), or reconfigure the first NR MAC entity (e.g., the NR MAC entity324inFIG.3E or3F), in accordance with the MAC configuration parameters. If the unicast configuration does not include MAC configuration parameters, the base station104may or may not reconfigure the first NR MAC entity to transmit633B MBS data packets via unicast transmission. The base station104can configure a third NR RLC entity (e.g., the NR RLC entity316inFIG.3B,3C, or3E), or reconfigure the first NR RLC entity (e.g., the NR RLC entity326inFIG.3D or3F), in accordance with the RLC configuration parameters. If the unicast configuration parameters do not include RLC configuration parameters, the base station104may or may not reconfigure the first NR RLC entity to transmit633B MBS data packets via unicast transmission.

Similarly, the UE102A can configure a fifth NR MAC entity (e.g., the NR MAC entity414in any ofFIGS.4B-4D), or reconfigure the second NR MAC entity (e.g., the NR MAC entity424inFIG.4E or4F), in accordance with the MAC configuration parameters. If the unicast configuration parameters do not include MAC configuration parameters, the UE102A may or may not reconfigure the second NR MAC entity to receive633B MBS data packets via unicast transmission. The UE102A can configure a fourth NR RLC entity (e.g., the NR RLC entity416in any ofFIG.4B,4C, or4E), or reconfigure the second NR RLC entity (e.g., the NR RLC entity426inFIG.4D or4F), in accordance with the RLC configuration parameters. If the unicast configuration parameters do not include RLC configuration parameters, the UE102A may or may not reconfigure the second NR RLC entity to transmit633B MBS data packets via unicast transmission. The base station104(e.g., the third or first NR RLC entity) then transmits633B RLC PDUs including the PDCP PDUs to the UE102A in accordance with the RLC configuration parameters, and the UE102A (e.g., the fourth or second NR RLC entity) receives633B the RLC PDUs including the PDCP PDUs, and processes the RLC PDUs to obtain the PDCP PDUs, in accordance with the RLC configuration parameters. Similarly, the base station104(e.g., the third or first NR MAC entity) transmits633B MAC PDUs including the RLC PDUs to the UE102A in accordance with the MAC configuration parameters, and the UE102A (e.g., the fourth or second NR MAC entity) receives633B the MAC PDUs including the RLC PDUs, and processes the MAC PDUs to obtain the RLC PDUs, in accordance with the MAC configuration parameters. In some implementations, the base station104can include the MRB identity in the RLC configuration parameters, and the UE102A can associate the second or fourth NR PDCP entity with the second or fourth NR RLC entity based on the MRB identity.

In some implementations where the base station104and UE102A use the protocol architectures of any one ofFIGS.3B-3Fand any corresponding one ofFIGS.4B-4F, respectively, the base station104can indicate in the RRC reconfiguration message of event621B that the UE102A is to release the multicast configuration of event611B. In response to the RRC reconfiguration message or the indication therein, the UE102A releases the multicast configuration. In some implementations, the UE102A releases the NR RLC entity406and NR MAC entity404(if existing) in response to the RRC reconfiguration message. If the UE102A uses the NR MAC entity424instead of the NR MAC entity404, the UE102A reconfigures the NR MAC entity424to release the multicast configuration parameters in response to the RRC reconfiguration message. If the base station104indicates in the RRC reconfiguration message at event621B that the UE102A is to release the multicast configuration, the base station104does not release the NR RLC entity306and NR MAC entity304(if existing). If the base station104indicates in the RRC reconfiguration message at event621B that the UE102A is to release the multicast configuration, but the base station104uses the NR MAC entity324instead of the NR MAC entity304, the base station104does not reconfigure the NR MAC entity324to release the multicast configuration.

FIG.6Cillustrates a scenario600C similar to the scenario600A ofFIG.6A, but in which the base station104does not need to reconfigure the MRB or lower-layer radio resources when changing from multicast to unicast radio resources for the MBS. Initially, the UE102A and CN110perform a PDU session establishment procedure650C to establish a PDU session for an MBS via the base station104. The procedure650C may be similar to event550A or650A. During or after the PDU session establishment procedure650C, the base station104generates a first RRC reconfiguration message including an MRB configuration, a multicast configuration, and a unicast configuration, and sends609C the RRC reconfiguration message to the UE102A. The RRC reconfiguration message of event609C may be similar to that of events510A and610A, but the MRB configuration is not specific to only PTM transmissions, and the message includes both multicast and unicast configurations. The MRB configuration, multicast configuration, and unicast configuration may be similar to any of the MRB configurations, multicast configurations, and unicast configurations discussed above in connection with other messaging diagrams.

The UE102A responds by sending612C an RRC reconfiguration complete message to the base station104(e.g., similar to events512A and612A). Thereafter, the CN110sends615C the base station104MBS data packets (e.g., similar to event515A and615A), which the UE102A receives617C from the base station104via multicast radio resources in accordance with the MRB configuration and multicast configuration (e.g., similar to events516A and616A, but without a PTM-specific MRB).

At a later time, the base station104(autonomously, or based on a message from the CN110) determines to begin transmitting the MBS data packets on the MRB using unicast radio resources instead of the original multicast radio resources. Thereafter, as the CN110continues to send631C MBS data packets to the base station104, the base station sends633C the MBS data packets to the UE102A on the MRB using unicast radio resources, in accordance with the MRB configuration and unicast configuration that were included in the RRC reconfiguration message of event609C. The UE102A receives633C the MBS data packets on the MRB using the unicast radio resources, in accordance with the MRB configuration and unicast configuration.

As noted above,FIGS.7A and7Bare messaging diagrams of example implementations and scenarios that are similar toFIGS.5A and5B, but in which the base station104is a distributed base station with a CU172and at least one DU174. It is understood that the order of multicast/unicast configuration and transmission in the scenarios shown inFIGS.7A and7Bmay be reversed (e.g., similar to scenario500C ofFIG.5C), such that base station140transmits data packets of the first MBS using unicast radio resources and transmits data packets of the second MBS using multicast radio resources.

Referring first toFIG.7A, in a scenario700A, the UE102A and the CN110initially perform a PDU session establishment procedure750A to establish a first PDU session for a first MBS via the base station104. The procedure750A may be similar to procedure550A ofFIG.5A, but with additional messaging between the CU172and DU174as needed, with the DU174performing radio communications with the UE102A and the CU172communicating with the CN110via an interface (e.g., an Si or NG interface).

After the procedure750A, the CU172can send752A a CU-to-DU message to the DU174to request a multicast configuration. In response, the DU174generates a multicast configuration, which may be similar to the multicast configuration discussed above in connection withFIG.5A, and sends754A a DU-to-CU message including the multicast configuration to the CU172. After (e.g., in response to) event754A, the CU172generates a PTM MRB configuration for the first MBS, which may be similar to the PTM MRB configuration discussed above in connection withFIG.5A, and sends756A a CU-to-DU message including an RRC reconfiguration message to the DU174. The RRC reconfiguration message, in turn, includes the multicast configuration and the PTM MRB configuration. In some implementations, the CU-to-DU message752A is a UE Context Setup Request message, a UE Context Modification Request message, or an MBS-specific message (e.g., F1AP message). In some implementations, the CU-to-DU message754A is a UE Context Setup Response message, a UE Context Modification Response message, a UE Context Modification Required message, or an MBS-specific message (e.g., F1AP message). In some implementations, the CU-to-DU message756A is a DL RRC Message Transfer message or a UE Context Modification Request message. In some implementations, the CU-to-DU message758A is a UL RRC Message Transfer message or a UE Context Modification Response message.

The DU174then sends710A the RRC reconfiguration message including the multicast configuration and PTM MRB configuration to the UE102A, and the UE102A responds by sending712A the DU174an RRC reconfiguration complete message. After (e.g., in response to) event712A, the DU174sends758A the CU172a DU-to-CU message that includes the RRC reconfiguration complete message. At some time thereafter, the CN110may send715A MBS data packets of the first MBS to the CU172(e.g., similar to event515A). The CU172sends716A-1the MBS data packets to the DU174, which in turn sends716A-2the MBS data packets to the UE102A via the PTM MRB and multicast radio resources (e.g., similar to event516A). The UE102A receives716A-2the MBS data packets of the first MBS using the PTM MRB configuration and multicast configuration that the UE102A received at event710A.

At some time during or after event716A-1and/or716A-2, the UE102A and CN110(via the base station104) can perform a second PDU session establishment procedure718A for a second MBS (e.g., similar to the procedure750A but for a different MBS, and similar to procedure518A but with messaging between the CU172and DU174as needed). During or after the second PDU session establishment procedure718A, the CU172sends760A the DU174a CU-to-DU message to request a unicast configuration. In response, the DU174generates a unicast configuration, which may be similar to the unicast configuration discussed above in connection withFIG.5A, and sends762A a DU-to-CU message including the unicast configuration to the CU172. After (e.g., in response to) event762A, the CU172generates a PTP MRB configuration for the second MBS, which may be similar to the PTP MRB configuration discussed above in connection withFIG.5A, and sends764A a CU-to-DU message including an RRC reconfiguration message to the DU174. The RRC reconfiguration message, in turn, includes the unicast configuration and the PTP MRB configuration.

The DU174then sends720A the RRC reconfiguration message including the unicast configuration and PTP MRB configuration to the UE102A, and the UE102A responds by sending722A the DU174an RRC reconfiguration complete message. After (e.g., in response to) event722A, the DU174sends766A the CU172a DU-to-CU message that includes the RRC reconfiguration complete message. At some time thereafter, the CN110may send731A MBS data packets of the second MBS to the CU172(e.g., similar to event531A). The CU172sends732A-1the MBS data packets to the DU174, which in turn sends732A-2the MBS data packets to the UE102A via the PTP MRB and unicast radio resources (e.g., similar to event532A). The UE102A receives732A-2the MBS data packets of the second MBS using the PTP MRB configuration and unicast configuration that the UE102A received at event720A. Example implementations of the CU-to-DU messages760A,762A,764A, and766A are similar to the example implementations of CU-to-DU messages752A,754A,756A, and758A, respectively.

FIG.7Billustrates a scenario700B similar to the scenario700A ofFIG.7A, but in which (similar to the scenario500B) the UE102A and CN110do not perform a PDU session establishment procedure to establish a PDU session for the second MBS. Initially, in the scenario700B, the UE102A and CN110perform a PDU session establishment procedure750B to establish a PDU session for at least a first MBS via the base station104. The procedure750B may be similar to event550B ofFIG.5B, but with additional messaging between the CU172and DU174as needed, with the DU174performing radio communications with the UE102A and the CU172communicating with the CN110via an interface (e.g., an Si or NG interface).

After the procedure750B, the CU172can send752B a CU-to-DU message to the DU174to request a multicast configuration. In response, the DU174generates a multicast configuration, which may be similar to the multicast configuration discussed above in connection withFIG.5A, and sends754B a DU-to-CU message including the multicast configuration to the CU172. After (e.g., in response to) event754B, the CU172generates a PTM MRB configuration for the first MBS, which may be similar to the PTM MRB configuration discussed above in connection withFIG.5A, and sends756B a CU-to-DU message including an RRC reconfiguration message to the DU174. The RRC reconfiguration message, in turn, includes the multicast configuration and the PTM MRB configuration.

The DU174then sends710B the RRC reconfiguration message including the multicast configuration and PTM MRB configuration to the UE102A, and the UE102A responds by sending712B the DU174an RRC reconfiguration complete message. After (e.g., in response to) event712B, the DU174sends758B the CU172a DU-to-CU message that includes the RRC reconfiguration complete message. At some time thereafter, the CN110may send715B MBS data packets of the first MBS to the CU172(e.g., similar to event515A). The CU172sends716B-1the MBS data packets to the DU174, which in turn sends716B-2the MBS data packets to the UE102A via the PTM MRB and multicast radio resources (e.g., similar to event516A). The UE102A receives716B-2the MBS data packets of the first MBS using the PTM MRB configuration and multicast configuration that the UE102A received at event710B.

Later in time, and instead of requesting the establishment of a second PDU session (as in scenario700A), the UE102A generates an MBS request message to request a second MBS, and sends721B-1the MBS request message to the DU174. The DU174then sends721B-2the MBS request message to the CU172. In the scenario700B, the second MBS, like the first MBS, is supported by the initial PDU session. In response to receiving721B-2the MBS request message, the base station104forwards/sends723B the MBS request message to the CN110. The MBS request message may be similar to the MBS request message described above in connection withFIG.5B. After (e.g., in response to) receiving723B the MBS request message, the CN110sends724B a CN-to-BS interface message (e.g., an NG interface message or a PDU SESSION RESOURCE MODIFY REQUEST message) to the CU172. The CN-to-BS interface message may be similar to the additional CN-to-BS interface message described above forFIG.5A.

After (e.g., in response to) receiving724B the CN-to-BS interface message, the CU172sends760B a CU-to-DU message to the DU174, to request a unicast configuration. In response, the DU174generates a unicast configuration, which may be similar to the unicast configuration discussed above in connection withFIG.5A, and sends762B a DU-to-CU message including the unicast configuration to the CU172. After (e.g., in response to) event762B, the CU172generates a PTP MRB configuration for the second MBS, which may be similar to the PTP MRB configuration discussed above in connection withFIG.5A, and sends764B a CU-to-DU message including an RRC reconfiguration message to the DU174. The RRC reconfiguration message, in turn, includes the unicast configuration and the PTP MRB configuration.

The DU174then sends720B the RRC reconfiguration message including the unicast configuration and PTP MRB configuration to the UE102A, and the UE102A responds by sending722B the DU174an RRC reconfiguration complete message. After (e.g., in response to) event722B, the DU174sends766B the CU172a DU-to-CU message that includes the RRC reconfiguration complete message. At some time thereafter, the CN110may send731B MBS data packets of the second MBS to the CU172(e.g., similar to event531A). The CU172sends732B-1the MBS data packets to the DU174, which in turn sends732B-2the MBS data packets to the UE102A via the PTP MRB and unicast radio resources (e.g., similar to event532A). The UE102A receives732B-2the MBS data packets of the second MBS using the PTP MRB configuration and unicast configuration that the UE102A received at event720B.

As noted above,FIGS.8A-8Care messaging diagrams of example implementations and scenarios that are similar toFIGS.6A-6C, but in which the base station104is a distributed base station with a CU172and at least one DU174. It is understood that the order of multicast/unicast configuration and transmission in the scenarios shown inFIGS.8A-8Cmay be reversed, such that the CN110and base station104initially provide MBS data packets via unicast transmission and then later provide MBS data packets via multicast transmission.

Referring first toFIG.8A, in a scenario800A, the UE102A and CN110initially perform a PDU session establishment procedure850A to establish a PDU session for an MBS via the base station104(including the CU172and DU174). The procedure850A may be similar to event550A ofFIG.5A, but with additional messaging between the CU172and DU174as needed, with the DU174performing radio communications with the UE102A and the CU172communicating with the CN110via an interface (e.g., an Si or NG interface).

After the procedure850A, the CU172can send852A a CU-to-DU message to the DU174to request a multicast configuration. In response, the DU174generates a multicast configuration, which may be similar to the multicast configuration discussed above in connection withFIG.5A, and sends854A a DU-to-CU message including the multicast configuration to the CU172. After (e.g., in response to) event854A, the CU172generates a PTM MRB configuration for the MBS, which may be similar to the PTM MRB configuration discussed above in connection withFIG.5A, and sends856A a CU-to-DU message including an RRC reconfiguration message to the DU174. The RRC reconfiguration message, in turn, includes the multicast configuration and the PTM MRB configuration.

The DU174then sends810A the RRC reconfiguration message including the multicast configuration and PTM MRB configuration to the UE102A, and the UE102A responds by sending812A the DU174an RRC reconfiguration complete message. After (e.g., in response to) event812A, the DU174sends858A the CU172a DU-to-CU message that includes the RRC reconfiguration complete message. At some time thereafter, the CN110may send815A MBS data packets of the MBS to the CU172(e.g., similar to event515A). The CU172sends816A-1the MBS data packets to the DU174, which in turn sends816A-2the MBS data packets to the UE102A via the PTM MRB and multicast radio resources (e.g., similar to event516A). The UE102A receives816A-2the MBS data packets using the PTM MRB configuration and multicast configuration that the UE102A received at event810A.

Later in time, the CN110determines834A to request that the base station104reconfigure radio resources for the PDU session from multicast to unicast. In some implementations, the CN110determines834A to do so based on the number of existing PDU sessions (for different UEs) for the MBS. If the number of existing PDU sessions for the MBS is below a predetermined threshold number, the CN110in response sends824A the CU172a CN-to-BS interface message requesting that the base station104reconfigure radio resources from multicast to unicast for the PDU session. If the number of existing PDU sessions for the MBS is not below the threshold number, the CN110in response does not request the base station104to reconfigure radio resources from multicast to unicast for the PDU session (i.e., event824A is omitted). The CN-to-BS interface message may be an NG interface message or a PDU SESSION RESOURCE MODIFY REQUEST message, for example.

After (e.g., in response to) event824A, the CU172sends860A the DU174a CU-to-DU message to request a unicast configuration. In response, the DU174generates a unicast configuration, which may be similar to the unicast configuration discussed above in connection withFIG.5A, and sends862A a DU-to-CU message including the unicast configuration to the CU172. After (e.g., in response to) event862A, the CU172generates a PTP MRB configuration for the MBS, which may be similar to the PTP MRB configuration discussed above in connection withFIG.5A, and sends864A a CU-to-DU message including an RRC reconfiguration message to the DU174. The RRC reconfiguration message, in turn, includes the unicast configuration and the PTP MRB configuration.

The DU174then sends820A the RRC reconfiguration message including the unicast configuration and PTP MRB configuration to the UE102A, and the UE102A responds by sending822A the DU174an RRC reconfiguration complete message. After (e.g., in response to) event822A, the DU174sends866A the CU172a DU-to-CU message that includes the RRC reconfiguration complete message. At some time thereafter, the CN110may send831A MBS data packets to the CU172(e.g., similar to event531A). The CU172sends832A-1the MBS data packets to the DU174, which in turn sends832A-2the MBS data packets to the UE102A via the PTP MRB and unicast radio resources (e.g., similar to event532A). The UE102A receives832A-2the MBS data packets using the PTP MRB configuration and unicast configuration that the UE102A received at event820A.

Example implementations of the CU-to-DU messages852A,854A,856A, and858A are similar to the example implementations of CU-to-DU messages752A,754A,756A, and758A, respectively. Example implementations of the CU-to-DU messages860A,862A,864A, and866A are similar to the example implementations of CU-to-DU messages752A,754A,756A, and758A, respectively.

FIG.8Billustrates a scenario800B similar to the scenario800A ofFIG.8A, but in which the base station104does not need to reconfigure the MRB when changing from multicast to unicast radio resources for the MBS. Initially, the UE102A and CN110perform a PDU session establishment procedure850B to establish a PDU session for an MBS via the base station104(including the CU172and DU174). The procedure850B may be similar to event550A ofFIG.5A, but with additional messaging between the CU172and DU174as needed, with the DU174performing radio communications with the UE102A and the CU172communicating with the CN110via an interface (e.g., an Si or NG interface).

After the procedure850B, the CU172can send852B a CU-to-DU message to the DU174to request a multicast configuration. In response, the DU174generates a multicast configuration, which may be similar to the multicast configuration discussed above in connection withFIG.5A, and sends854B a DU-to-CU message including the multicast configuration to the CU172. After (e.g., in response to) event854B, the CU172generates an MRB configuration for the MBS, which may be similar to the MRB configuration discussed above in connection withFIG.5A or6B, and sends856B a CU-to-DU message including an RRC reconfiguration message to the DU174. The RRC reconfiguration message, in turn, includes the multicast configuration and the MRB configuration.

The DU174then sends810B the RRC reconfiguration message including the multicast configuration and MRB configuration to the UE102A, and the UE102A responds by sending812B the DU174an RRC reconfiguration complete message. After (e.g., in response to) event812B, the DU174sends858B the CU172a DU-to-CU message that includes the RRC reconfiguration complete message. At some time thereafter, the CN110may send815B MBS data packets of the MBS to the CU172(e.g., similar to event515A). The CU172sends817B-1the MBS data packets to the DU174, which in turn sends817B-2the MBS data packets to the UE102A via the MRB and multicast radio resources (e.g., similar to event617B). The UE102A receives817B-2the MBS data packets using the MRB configuration and multicast configuration that the UE102A received at event810B.

Later in time, the CN110determines834B to request that the base station104reconfigure radio resources for the PDU session from multicast to unicast. In some implementations, the CN110determines834B to do so based on the number of existing PDU sessions (for different UEs) for the MBS. If the number of existing PDU sessions for the MBS is below a predetermined threshold number, the CN110in response sends824B the CU172a CN-to-BS interface message requesting that the base station104reconfigure radio resources from multicast to unicast for the PDU session. If the number of existing PDU sessions for the MBS is not below the threshold number, the CN110in response does not request the base station104to reconfigure radio resources from multicast to unicast for the PDU session (i.e., event824B is omitted). The CN-to-BS interface message may be an NG interface message or a PDU SESSION RESOURCE MODIFY REQUEST message, for example.

After (e.g., in response to) event824B, the CU172sends860B the DU174a CU-to-DU message to request a unicast configuration. In response, the DU174generates a unicast configuration, which may be similar to the unicast configuration discussed above in connection withFIG.5A, and sends862B a DU-to-CU message including the unicast configuration to the CU172. After (e.g., in response to) event862B, the CU172generates an RRC reconfiguration message including the unicast configuration, and sends864B the RRC reconfiguration message to the DU174in another CU-to-DU message. The DU174then sends820B the RRC reconfiguration message including the unicast configuration to the UE102A, and the UE102A responds by sending822B the DU174an RRC reconfiguration complete message. After (e.g., in response to) event822B, the DU174sends866B the CU172a DU-to-CU message that includes the RRC reconfiguration complete message. At some time thereafter, the CN110may send831B MBS data packets to the CU172(e.g., similar to event531A). The CU172sends833B-1the MBS data packets to the DU174, which in turn sends833B-2the MBS data packets to the UE102A via the MRB and unicast radio resources (e.g., similar to event633B). The UE102A receives833B-2the MBS data packets using the MRB configuration and unicast configuration that the UE102A received at event820B.

FIG.8Cillustrates a scenario800C similar to the scenario800A ofFIG.8A, but in which the base station104does not need to reconfigure the MRB or lower-layer radio resources when changing from multicast to unicast radio resources for the MBS. Initially, the UE102A and CN110perform a PDU session establishment procedure850C to establish a PDU session for an MBS via the base station104(including the CU172and DU174). The procedure850C may be similar to event550A ofFIG.5A, but with additional messaging between the CU172and DU174as needed, with the DU174performing radio communications with the UE102A and the CU172communicating with the CN110via an interface (e.g., an Si or NG interface).

After the procedure850C, the CU172can send852C a CU-to-DU message to the DU174to request a multicast configuration. In other implementations and/or scenarios, the CU-to-DU message requests both multicast and unicast configurations. In either implementation/scenario, the DU174responds to event852C by generating both a multicast configuration and a unicast configuration, which may be similar to the multicast and unicast configurations discussed above in connection withFIG.5A, and sends854C a DU-to-CU message including the multicast and unicast configurations to the CU172. After (e.g., in response to) event854C, the CU172generates an MRB configuration for the MBS, which may be similar to the MRB configuration discussed above in connection withFIG.5A or6B, and sends856C a CU-to-DU message including an RRC reconfiguration message to the DU174. The RRC reconfiguration message, in turn, includes the multicast configuration, the unicast configuration, and the MRB configuration.

The DU174then sends810C the RRC reconfiguration message including the multicast configuration, the unicast configuration, and the MRB configuration to the UE102A, and the UE102A responds by sending812C the DU174an RRC reconfiguration complete message. After (e.g., in response to) event812C, the DU174sends858C the CU172a DU-to-CU message that includes the RRC reconfiguration complete message. At some time thereafter, the CN110may send815C MBS data packets of the MBS to the CU172(e.g., similar to event515A). The CU172sends817C-1the MBS data packets to the DU174, which in turn sends817C-2the MBS data packets to the UE102A via the MRB and multicast radio resources (e.g., similar to event617B). The UE102A receives817C-2the MBS data packets using the MRB configuration and multicast configuration that the UE102A received at event810C.

At a later time, the CU172(autonomously, or based on a message from the CN110) determines to begin transmitting the MBS data packets on the MRB using unicast radio resources instead of the original multicast radio resources. Thereafter, as the CN110continues to send831C MBS data packets to the base station104, the base station sends833C-1the MBS data packets to the UE102A on the MRB using unicast radio resources, in accordance with the MRB configuration and unicast configuration that were included in the RRC reconfiguration message of event810C. The UE102A receives833C the MBS data packets on the MRB using the unicast radio resources, in accordance with the MRB configuration and unicast configuration.

FIGS.9-21are flow diagrams depicting various example methods according to the techniques disclosed herein, which may be implemented, for example, in the wireless communication system100ofFIG.1A. While the below description refers to specific components of the wireless communication system100(e.g., UE102A and base station104), the methods may instead be performed by components other than those shown inFIG.1A.

FIGS.9and10are flow diagrams of example methods for managing multicast and unicast MBS communications from the perspective of the UE102A and the perspective of one or more nodes of the RAN105(e.g., the base station104, or specifically the DU174and/or CU172, etc.), respectively.

Referring first toFIG.9, an example method900may be performed by the UE102A or, in some implementations/scenarios, collectively by a group of UEs. At block902of the method900, the UE102A receives (510A,510B,510C,610A,710A,710B, or810A) from the RAN105a first MRB configuration associated with a PTM MRB. At block904, and after block902, the UE102A receives (516A,516B,516C,616A,716A-2, or816A-2) first MBS packets from the RAN105via the PTM MRB and according to the first MRB configuration.

At block906, the UE102A receives (520A,520B,520C,620A,720A,720B, or820A) from the RAN105a second MRB configuration associated with a PTP MRB. At block908, and after block906, the UE102A receives (532A,532B,532C,632A,732A-2,732B-2, or832A-2) second MBS packets from the RAN105via the PTP MRB and according to the second MRB configuration.

In some scenarios, blocks906and908may occur before blocks902and904.

Referring next toFIG.10, an example method1000may be performed by one or more nodes of the RAN105(e.g., the base station104). At block1002of the method1000, the one or more RAN nodes transmit (510A,510B,510C,610A,710A,710B, or810A) to the UE102A a first MRB configuration associated with a PTM MRB. At block1004, and after block1002, the RAN node(s) transmit (516A,516B,516C,616A,716A-2, or816A-2) first MBS packets to the UE102A via the PTM MRB and according to the first MRB configuration.

At block1006, the RAN node(s) transmit (520A,520B,520C,620A,720A,720B, or820A) to the UE102A a second MRB configuration associated with a PTP MRB. At block1008, and after block1006, the RAN node(s) transmit (532A,532B,532C,632A,732A-2,732B-2, or832A-2) second MBS packets to the UE102A via the PTP MRB and according to the second MRB configuration.

In some scenarios, blocks1006and1008may occur before blocks1002and1004.

FIGS.11and12are flow diagrams of additional example methods for managing multicast and unicast MBS communications from the perspective of the UE102A and the perspective of one or more nodes of the RAN105(e.g., the base station104, or specifically the DU174and/or CU172, etc.), respectively.

Referring first toFIG.11, a method1100is performed by the UE102. At block1102, the UE102A receives (610A,611B,611C,810A,810B, or810C) from the RAN105a first MRB configuration associated with a first MRB, and a first lower layer configuration (i.e., unicast or multicast configuration). At block1104, and after block1102, the UE102A receives (616A,617B,617C,816A-2,817B-2, or817C-2) first MBS packets from the RAN105via the first MRB and according to the first MRB configuration and the first lower layer configuration. At block1106, and after block1104, the UE102A receives (632A,633B,633C,832A-2,833B-2, or833C-2) second MBS packets from the RAN via either the first MRB or a second MRB, and according to a second lower layer configuration (i.e., multicast configuration if the first lower layer configuration was unicast, or unicast configuration if the first lower layer configuration was multicast) and either the first or second MRB configuration.

Referring next toFIG.12, a method1200is performed by one or more nodes of the RAN105(e.g., the base station104). At block1202, the RAN node(s) transmit610A,611B,611C,810A,810B, or810C to the UE102A a first MRB configuration associated with a first MRB and a first lower layer (multicast or unicast) configuration. At block1204, the RAN node(s) transmit (616A,617B,617C,816A-2,817B-2, or817C-2) to the UE102A first MBS packets via the first MRB and according to the first MRB configuration and the first lower layer configuration. At block1206, the RAN node(s) transmit (632A,633B,633C,832A-2,833B-2, or833C-2) second MBS packets to the UE102A via either the first MRB or a second MRB, and according to a second lower layer configuration (i.e., multicast configuration if the first lower layer configuration was unicast, or unicast configuration if the first lower layer configuration was multicast) and either the first or second MRB configuration.

FIGS.13-20Bare flow diagrams of example methods for managing multicast and unicast MBS communications from the perspective of CU172or DU174, according to various implementations and/or scenarios. It is understood that the order of multicast-then-unicast may be reversed from what is shown in any ofFIGS.13-20B, in other scenarios and/or other implementations.

Referring first toFIG.13, a method1300is performed by the CU172. At block1302, the CU172transmits (752A,752B,852A, or852B) to the DU174a first CU-to-DU message to request a multicast configuration for the UE102A. At block1304, the CU172receives (754A,754B,854A, or854B) from the DU174a first DU-to-CU message including a multicast configuration for the UE102A in response to the first CU-to-DU message. At block1306, the CU172transmits (756A/710A,756B/710B,856A/810A, or856B/810B) a first message including the multicast configuration to the UE102A via the DU174. At block1308, the CU172transmits (760A,760B,860A, or860B) to the DU174a second CU-to-DU message to request a unicast configuration for the UE102A. At block1310the CU172receives (762A,762B,862A, or862B) from the DU174a second DU-to-CU message including a unicast configuration for the UE102A, in response to the second CU-to-DU message. At block1312, the CU172transmits (764A/720A,764B/720B,864A/820A, or864B/820B) a second message including the unicast configuration to the UE102A via the DU174.

Referring next toFIG.14, a method1400is performed by the DU174. At block1402, the DU174transmits (754A,754B,854A, or854B) to the CU172a first DU-to-CU message including a multicast configuration for the UE102A (e.g., in response to a request message from the CU172). At block1404, the DU174multicasts (710A,710B,810A, or810B) MBS packets to the UE102A and one or more other UEs according to the multicast configuration. At block1406, the DU174transmits (762A,762B,862A, or862B) to the CU172a second DU-to-CU message including a unicast configuration for the UE102A (e.g., in response to another request message from the CU172). At block1408, the DU174unicasts (720A,720B,820A, or820B) MBS packets to the UE102A according to the unicast configuration.

Referring next toFIG.15, a method1500is performed by the CU172. At block1502, the CU172transmits (852C) to the DU174a CU-to-DU message to request unicast and multicast configurations for the UE102A. At block1504, the CU172receives (854C) from the DU174a DU-to-CU message including unicast and multicast configurations for the UE102A, in response to the CU-to-DU message. In other implementations, the message transmitted at block1502only explicitly requests one type of configuration (unicast or multicast), or does not explicitly indicate a type of configuration, but the CU172responds with both unicast and multicast configurations regardless. At block1506, the CU172transmits (856C/810C) a message including the unicast and multicast configurations to the UE102A via the DU174.

Referring next toFIG.16, a method1600is performed by the DU174. At block1602, the DU174transmits (854C) to the CU172a first DU-to-CU message including unicast and multicast configurations for the UE102A (e.g., in response to a request message from the CU172). At block1604, the DU174multicasts (817C-2) MBS packets to the UE102A and one or more other UEs in accordance with the multicast configuration. At block1606, the DU174unicasts (833C-2) MBS packets (for the same MBS) in accordance with the unicast configuration.

Referring next toFIG.17, a method1700is performed by the DU174. At block1702, the DU174receives (752A,760A,752B,760B,752C,852A,860A,852B,860B, or852C) from the CU172a CU-to-DU message requesting radio resources for the UE102A. At block1704, the DU174determines whether the CU-to-DU message requests radio resources for multicast communications, unicast communications, or both. If multicast, the DU174transmits (754A,754B,854A, or854B) to the CU172a DU-to-CU message including a multicast configuration for the UE102A, at block1706. If unicast, the DU174transmits (762A,762B,862A, or862B) to the CU172a DU-to-CU message including a unicast configuration for the UE102A, at block1708. If both multicast and unicast, the DU174transmits (854C) to the CU172a DU-to-CU message including both multicast and unicast configurations for the UE102A, at block1710.

Referring next toFIG.18, a method1800is performed by the DU174. At block1802, the DU174receives (752A,760A,752B,760B,752C,852A,860A,852B,860B, or852C) from the CU172a CU-to-DU message requesting radio resources for the UE102A. At block1804, the DU174determines whether the CU-to-DU message indicates or includes a first, second, or third QoS profile for the MRB. If the first QoS profile, the DU174transmits (754A,754B,854A, or854B) to the CU172a DU-to-CU message including a multicast configuration for the UE102A, at block1806. If the second QoS profile, the DU174transmits (762A,762B,862A, or862B) to the CU172a DU-to-CU message including a unicast configuration for the UE102A, at block1808. If the third QoS profile, the DU174transmits (854C) to the CU172a DU-to-CU message including both multicast and unicast configurations for the UE102A, at block1810.

Referring next toFIG.19, a method1900is performed by the CU172. At block1902, the CU172receives (724B,824A, or824B) from the CN110a CN-to-BS message requesting radio resources for the UE102A. At block1904, the CU172determines whether the CN-to-BS message indicates or includes a first, second, or third QoS profile for the MRB. If the first QoS profile, the CU172transmits to the DU174a CU-to-DU message to request a multicast configuration for the UE102A, at block1906. If the second QoS profile, the CU172transmits (760B,860A, or860B) to the DU174a CU-to-DU message to request a unicast configuration for the UE102A, at block1908. If the third QoS profile, the CU172transmits to the DU174a CU-to-DU message to request both multicast and unicast configurations for the UE102A, at block1910.

Referring next toFIG.20A, a method2000is performed by the CU172. At block2002, the CU172receives (724B,824A, or824B) from the CN110a CN-to-BS message requesting radio resources for the UE102A. At block2004, the CU172determines whether the CN-to-BS message requests radio resources for a first, second, or third PDU session. If the first PDU session, the CU172transmits to the DU174a CU-to-DU message to request a multicast configuration for the UE102A, at block2006. If the second PDU session, the CU172transmits (760B,860A, or860B) to the DU174a CU-to-DU message to request a unicast configuration for the UE102A, at block2008. If the third PDU session, the CU172transmits to the DU174a CU-to-DU message to request both multicast and unicast configurations for the UE102A, at block2010.

Referring next toFIG.20B, a method2020is performed by the CU172. At block2022, the CU172receives (724B,824A, or824B) from the CN110a CN-to-BS message requesting radio resources for the UE102A. At block2024, the CU172determines whether the CN-to-BS message requests radio resources for a first or second PDU session. If the first PDU session, the CU172transmits (760B,860A, or860B) to the DU174a CU-to-DU message to request a unicast configuration for the UE102A, at block2024. If the second PDU session, the CU172determines whether the CN-to-BS message indicates or includes a first or a second QoS profile, at block2025. If the first QoS profile, the CU172transmits to the DU174a CU-to-DU message to request a multicast configuration for the UE102A, at block2026. If the second QoS profile, the CU172transmits to the DU174a CU-to-DU message to request both unicast and multicast configurations for the UE102A, at block2030.

FIG.21is a flow diagram of an example method2100for managing lower layer configurations associated with an MRB at the DU174. At block2102, the DU174receives from the CU172a CU-to-DU message to release the MRB for the UE102A. In response to the CU-to-DU message, the DU174releases (at block2104) a unicast configuration associated with the MRB, but retains (at block2106) a multicast configuration associated with the MRB. In this manner, the DU174can continue to multicast to other UEs (i.e., other than the UE102A) using the same multicast configuration.

The following list of aspects reflects a variety of the embodiments explicitly contemplated by the present disclosure.

Aspect 1. A method in one or more nodes of a radio access network (RAN), for managing multicast and/or broadcast services (MBS) communications, the method comprising: transmitting a first MBS radio bearer (MRB) configuration associated with a point-to-multipoint MRB to a plurality of user devices; transmitting first MBS packets to the plurality of user devices via the point-to-multipoint MRB and according to the first MRB configuration; transmitting a second MRB configuration associated with a point-to-point MRB to a user device of the plurality of user devices; and transmitting second MBS packets to the user device via the point-to-point MRB and according to the second MRB configuration.

Aspect 2. The method of aspect 1, further comprising: transmitting to the plurality of user devices a multicast configuration, wherein transmitting the first MBS packets via the point-to-multipoint MRB is according to both the first MRB configuration and the multicast configuration; and transmitting to the user device a unicast configuration, wherein transmitting the second MBS packets via the point-to-point MRB is according to both the second MRB configuration and the unicast configuration.

Aspect 3. The method of aspect 2, comprising: transmitting to the plurality of user devices a first radio resource control (RRC) message, wherein the first RRC message includes the first MRB configuration and the multicast configuration; and transmitting to the user device a second RRC message, wherein the second RRC message includes the second MRB configuration and the unicast configuration.

Aspect 4. The method of aspect 2 or 3, wherein: the first and second MRB configurations are associated with operations at a first one or more layers of a protocol stack; and the multicast and unicast configurations are associated with operations at a second one or more layers of the protocol stack, the first one or more layers being above the second one or more layers in the protocol stack.

Aspect 5. The method of aspect 4, wherein: the first one or more layers include packet data convergence protocol (PDCP) and service data adaptation protocol (SDAP) layers; and the second one or more layers include medium access control (MAC) and radio link control (RLC) layers.

Aspect 6. The method of any one of aspects 2-5, further comprising, at a distributed unit of a base station of the RAN: transmitting a first message to a central unit of the base station, the first message including the multicast configuration; in response to the first message, receiving from the central unit a second message including the first MRB configuration; transmitting a third message to the central unit, the third message including the unicast configuration; and in response to the third message, receiving from the central unit a fourth message including the second MRB configuration, wherein transmitting the first MRB configuration and transmitting the multicast configuration is in response to receiving the second message, and wherein transmitting the second MRB configuration and transmitting the unicast configuration is in response to receiving the fourth message.

Aspect 7. The method of aspect 6, further comprising: determining, at the distributed unit, to provide unicast and/or multicast radio resources to the user device based on an indication, received from the central unit, of one or both of (i) a quality of service associated with the first MRB, and (ii) a protocol data unit (PDU) session associated with the first MRB.

Aspect 8. The method of any one of aspects 1-7, wherein transmitting first MBS packets to the plurality of user devices includes broadcasting the first MRB packets.

Aspect 9. The method of any one of aspects 1-8, wherein transmitting the first MRB configuration to the plurality of user devices includes broadcasting the first MRB configuration.

Aspect 10. The method of any one of aspects 1-9, further comprising: before transmitting the first MRB configuration, receiving from the user device a message requesting a first MBS, wherein the point-to-multipoint MRB is associated with the first MBS.

Aspect 11. The method of aspect 10, further comprising: before transmitting the second MRB configuration, receiving from the user device a message requesting a second MBS, wherein the point-to-point MRB is associated with the second MBS.

Aspect 12. The method of aspects 11, further comprising: in response to receiving the message requesting the first MBS, sending a first message to a core network; in response to sending the first message, receiving a second message from the core network; in response to receiving the message requesting the second MBS, sending a third message to the core network; and in response to sending the third message, receiving a fourth message from the core network, wherein transmitting the first MRB configuration is in response to receiving the second message, and wherein transmitting the second MRB configuration is in response to receiving the fourth message.

Aspect 13. The method of aspect 11 or 12, wherein the message requesting the first MBS is a message requesting establishment of a first protocol data unit (PDU) session supporting at least the first MBS.

Aspect 14. The method of aspect 13, wherein the message requesting the second MBS is a message requesting establishment of a second PDU session supporting the second MBS.

Aspect 15. The method of aspect 13, wherein: the first PDU session supports the first MBS and the second MBS; and the message requesting the second MBS does not request another PDU session.

Aspect 16. The method of aspect 10, wherein the message requesting the first MBS is a message requesting establishment of a protocol data unit (PDU) session supporting at least the first MBS, the method further comprising: after transmitting the first MBS packets, receiving from a core network a message indicating that the PDU session is to be reconfigured to use unicast radio resources, wherein transmitting the second MRB configuration is in response to receiving the message indicating that the PDU session is to be reconfigured.

Aspect 17. The method of any one of aspects 1-16, wherein transmitting the first MRB configuration occurs after transmitting the second MRB configuration and after transmitting at least some of the second MBS packets.

Aspect 18. The method of any one of aspects 1-17, wherein transmitting the first MBS packets includes transmitting some of the first MBS packets before transmitting the second MRB configuration, and transmitting other of the first MBS packets after transmitting the second MRB configuration.

Aspect 19. A method in one or more nodes of a radio access network (RAN), for managing multicast and/or broadcast services (MBS) communications, the method comprising: transmitting to a user device (i) a first MBS radio bearer (MRB) configuration associated with a first MRB and (ii) a first lower layer configuration; transmitting first MBS packets to the user device via the first MRB and according to the first MRB configuration and the first lower layer configuration; and after transmitting the first MBS packets, transmitting second MBS packets to the user device via either the first MRB or a second MRB, and according to a second lower layer configuration and either the first MRB configuration or a second MRB configuration, the first and second lower layer configurations being different ones of a multicast configuration and a unicast configuration.

Aspect 20. The method of aspect 19, wherein: the first MRB configuration is associated with operations at a first one or more layers of a protocol stack; and the first and second lower layer configurations are associated with operations at a second one or more layers of the protocol stack, the first one or more layers being above the second one or more layers in the protocol stack.

Aspect 21. The method of aspect 20, wherein: the first one or more layers include packet data convergence protocol (PDCP) and service data adaptation protocol (SDAP) layers; and the second one or more layers include medium access control (MAC) and radio link control (RLC) layers.

Aspect 22. The method of any one of aspects 19-21, further comprising, at a distributed unit of a base station of the RAN: transmitting a first message to a central unit of the base station, the first message including the first lower layer configuration; in response to the first message, receiving from the central unit a second message including the first MRB configuration; transmitting a third message to the central unit, the third message including the second lower layer configuration; and in response to the third message, receiving from the central unit a fourth message, wherein transmitting the first MRB configuration and the first lower layer configuration is in response to receiving the second message, and wherein transmitting the transmitting the second lower layer configuration is in response to receiving the fourth message.

Aspect 23. The method of aspect 22, further comprising: determining, at the distributed unit, to provide unicast and/or multicast radio resources to the user device based on an indication, received from the central unit, of one or both of (i) a quality of service associated with the first MRB, and (ii) a protocol data unit (PDU) session associated with the first MRB.

Aspect 24. The method of any one of aspects 19-23, further comprising: after transmitting the first MBS packets and before transmitting the second MBS packets, transmitting the second lower layer configuration to the user device.

Aspect 25. The method of aspect 24, wherein: transmitting the second lower layer configuration further includes transmitting the second MRB configuration to the user device; and transmitting the second MBS packets is according to the second lower layer configuration and the second MRB configuration.

Aspect 26. The method of aspect 25, further comprising: before transmitting the first MRB configuration and the first lower layer configuration, receiving from the user device a message requesting establishment of a protocol data unit (PDU) session supporting at least the first MBS; and after transmitting the first MBS packets, receiving from a core network a message indicating that the PDU session is to be reconfigured, wherein transmitting the second lower layer configuration and the second MRB configuration is in response to receiving the message indicating that the PDU session is to be reconfigured.

Aspect 27. The method of any one of aspects 19-26, wherein transmitting the first MRB configuration and the first lower layer configuration further includes transmitting the second lower layer configuration to the user device.

Aspect 28. The method of aspect 27, wherein transmitting the first MRB configuration, the first lower layer configuration, and the second lower layer configuration to the user device includes transmitting to the user device a radio resource control (RRC) message that includes the first MRB configuration, the first lower layer configuration, and the second lower layer configuration.

Aspect 29. The method of any one of aspects 19-28, wherein the method occurs during a single protocol data unit (PDU) session associated with the user device.

Aspect 30. The method of any one of aspects 19-29, wherein either transmitting the first MBS packets or transmitting the second MBS packets includes broadcasting the first MRB packets.

Aspect 31. The method of any one of aspects 19-30, wherein transmitting the first MRB configuration includes broadcasting the first MRB configuration.

Aspect 32. One or more nodes of a random access network (RAN), the one or more nodes comprising hardware and being configured to perform the method of any one of aspects 1-31.

Aspect 33. A method, in a user device communicating with a radio access network (RAN), for managing multicast and/or broadcast services (MBS) communications, the method comprising: receiving from the RAN a first MBS radio bearer (MRB) configuration associated with a point-to-multipoint MRB; receiving first MBS packets from the RAN via the point-to-multipoint MRB and according to the first MRB configuration; receiving from the RAN a second MRB configuration associated with a point-to-point MRB; and receiving second MBS packets from the RAN via the point-to-point MRB and according to the second MRB configuration.

Aspect 34. The method of aspect 33, further comprising: receiving from the RAN a multicast configuration, wherein receiving the first MBS packets via the point-to-multipoint MRB is according to both the first MRB configuration and the multicast configuration; and receiving from the RAN a unicast configuration, wherein receiving the second MBS packets via the point-to-point MRB is according to both the second MRB configuration and the unicast configuration.

Aspect 35. The method of aspect 34, comprising: receiving from the RAN a first radio resource control (RRC) message, wherein the first RRC message includes the first MRB configuration and the multicast configuration; and receiving from the RAN a second RRC message, wherein the second RRC message includes the second MRB configuration and the unicast configuration.

Aspect 36. The method of aspect 34 or 35, wherein: the first and second MRB configurations are associated with operations at a first one or more layers of a protocol stack; and the multicast and unicast configurations are associated with operations at a second one or more layers of the protocol stack, the first one or more layers being above the second one or more layers in the protocol stack.

Aspect 37. The method of aspect 36, wherein: the first one or more layers include packet data convergence protocol (PDCP) and service data adaptation protocol (SDAP) layers; and the second one or more layers include medium access control (MAC) and radio link control (RLC) layers.

Aspect 38. The method of any one of aspects 33-37, further comprising: before receiving the first MRB configuration, transmitting to the RAN a message requesting a first MBS, wherein the point-to-multipoint MRB is associated with the first MBS; and before receiving the second MRB configuration, transmitting to the RAN a message requesting a second MBS, wherein the point-to-point MRB is associated with the second MBS.

Aspect 39. The method of aspect 38, wherein the message requesting the first MBS is a message requesting establishment of a first protocol data unit (PDU) session supporting at least the first MBS.

Aspect 40. The method of aspect 39, wherein the message requesting the second MBS is a message requesting establishment of a second PDU session supporting the second MBS.

Aspect 41. The method of aspect 39, wherein: the first PDU session supports the first MBS and the second MBS; and the message requesting the second MBS does not request another PDU session.

Aspect 42. The method of any one of aspects 33-41, wherein receiving the first MRB configuration occurs after receiving the second MRB configuration and after receiving at least some of the second MBS packets.

Aspect 43. The method of any one of aspects 33-42, wherein receiving the first MBS packets includes receiving some of the first MBS packets before receiving the second MRB configuration, and receiving other of the first MBS packets after receiving the second MRB configuration.

Aspect 44. A method, in a user device communicating with a radio access network (RAN), for managing multicast and/or broadcast services (MBS) communications, the method comprising: receiving from the RAN (i) a first MBS radio bearer (MRB) configuration associated with a first MRB and (ii) a first lower layer configuration; receiving first MBS packets from the RAN via the first MRB and according to the first MRB configuration and the first lower layer configuration; and after receiving the first MBS packets, receiving second MBS packets from the RAN via either the first MRB or a second MRB, and according to a second lower layer configuration and either the first MRB configuration or a second MRB configuration, the first and second lower layer configurations being different ones of a multicast configuration and a unicast configuration.

Aspect 45. The method of aspect 44, wherein: the first MRB configuration is associated with operations at a first one or more layers of a protocol stack; and the first and second lower layer configurations are associated with operations at a second one or more layers of the protocol stack, the first one or more layers being above the second one or more layers in the protocol stack.

Aspect 46. The method of aspect 45, wherein: the first one or more layers include packet data convergence protocol (PDCP) and service data adaptation protocol (SDAP) layers; and the second one or more layers include medium access control (MAC) and radio link control (RLC) layers.

Aspect 47. The method of any one of aspects 44-46, further comprising: after receiving the first MBS packets and before receiving the second MBS packets, receiving the second lower layer configuration from the RAN.

Aspect 48. The method of aspect 47, wherein: receiving the second lower layer configuration further includes receiving the second MRB configuration from the RAN; and receiving the second MBS packets is according to the second lower layer configuration and the second MRB configuration.

Aspect 49. The method of aspect 48, further comprising: before receiving the first MRB configuration and the first lower layer configuration, transmitting to the RAN a message requesting establishment of a protocol data unit (PDU) session supporting at least the first MBS.

Aspect 50. The method of any one of aspects 44-46, wherein receiving the first MRB configuration and the first lower layer configuration further includes receiving the second lower layer configuration from the RAN.

Aspect 51. The method of aspect 50, wherein receiving the first MRB configuration, the first lower layer configuration, and the second lower layer configuration from the RAN includes receiving from the RAN a radio resource control (RRC) message that includes the first MRB configuration, the first lower layer configuration, and the second lower layer configuration.

Aspect 52. The method of any one of aspects 44-51, wherein the method occurs during a single protocol data unit (PDU) session associated with the user device.

Aspect 53. A user device comprising hardware and being configured to perform the method of any one of aspects 33-52.

The following additional considerations apply to the foregoing discussion.

A user device in which the techniques of this disclosure can be implemented (e.g., the UE102A or102B) can be any suitable device capable of wireless communications such as a smartphone, a tablet computer, a laptop computer, a mobile gaming console, a point-of-sale (POS) terminal, a health monitoring device, a drone, a camera, a media-streaming dongle or another personal media device, a wearable device such as a smartwatch, a wireless hotspot, a femtocell, or a broadband router. Further, the user device in some cases may be embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS). Still further, the user device can operate as an internet-of-things (IoT) device or a mobile-internet device (MID). Depending on the type, the user device can include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

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

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