Managing multicast data communications

Abstract

A radio access network (RAN) may perform a method for managing security protection for a multicast and / or broadcast service (MBS). The method includes receiving (802) data packets associated with an MBS session from a core network (CN) via a DL tunnel, determining (804) which security protection to apply to the data packets based on an identification of the DL tunnel prior to transmitting the data packets to a plurality of UEs, and transmitting (806) the data packets to the plurality of UEs using the determined security protection. The UE may receive (902) a configuration for establishing a logical channel with the RAN from the RAN, receive (904) data packets associated with the MBS session from the RAN via the logical channel, determine (906) which security protection to apply to the data packets based on the configuration, and apply (908) the determined security protection to the data packets.

Description

[Technical Field]

[0001] The present disclosure relates to wireless communications, and more particularly to managing data communications and security protection for multicast and / or broadcast service (MBS) data and non-MBS data. [Background technology]

[0002] The background discussion provided herein is intended to generally present the context for the present disclosure. The work of the presently named inventors is not admitted, explicitly or implicitly, as prior art to the present disclosure to the extent that the work is described in this Background section, and further, any aspects of the description that may not otherwise qualify as prior art at the time of filing.

[0003] In telecommunications systems, the Packet Data Convergence Protocol (PDCP) sublayer of the radio protocol stack provides services such as user plane data transport, encryption, and integrity protection. For example, the PDCP sublayer defined for the Evolved Universal Terrestrial Radio Access (EUTRA) air interface (see 3GPP specification TS 36.323) and New Radio (NR) (see 3GPP specification TS 38.323) provides protocol data unit (PDU) sequencing in the uplink direction from a user device (also called user equipment or "UE") to a base station and in the downlink direction from a base station to the UE. The PDCP sublayer also provides services for signaling radio bearers (SRBs) to the Radio Resource Control (RRC) sublayer. The PDCP sublayer further provides services for data radio bearers (DRBs) to the Service Data Adaptation Protocol (SDAP) sublayer or to protocol layers such as the Internet Protocol (IP) layer, the Ethernet protocol layer, and the Internet Control Message Protocol (ICMP) layer. Generally speaking, the UE and the 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 the user plane.

[0004] In some scenarios, a UE can simultaneously utilize resources of multiple nodes (e.g., base stations or components of a distributed or 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, cells associated with a base station operating as a master node (MN) define a master cell group (MCG), and cells associated with a base station operating as a secondary node (SN) define a secondary cell group (SCG). The MCG covers a primary cell (PCell) and zero, one, or more secondary cells (SCells), and the SCG covers a primary secondary cell (PSCell) and zero, one, or more SCells. The UE communicates with the MN (via the MCG) and with the SN (via the SCG). In other scenarios, the UE utilizes resources of one base station at a time, i.e., single connectivity (SC). In SC, the UE only communicates with the MN via the MCG. The base station and / or the UE decide when the UE should establish a radio connection with another base station. For example, the base station may decide to hand over the UE to another base station and initiate a handover procedure. In other scenarios, the UE may simultaneously utilize resources of another RAN node (e.g., a base station or a component of a distributed or disaggregated base station) interconnected by a backhaul.

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

[0006] A UE 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) between the RAN node and the UE. The UE may perform a 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 the serving base station to a target cell of a second DU of the same base station, depending on the scenario. In a DC scenario, the UE can perform a PSCell change procedure to change the PSCell. These procedures involve messaging (e.g., RRC signaling and preparation) between the RAN node and the UE. The UE may perform a PSCell change from a PSCell of a serving SN to a target PSCell of a target SN, or from a PSCell of a source DU of a base station to a PSCell of a target DU of the same base station, depending on the scenario. Additionally, the UE may perform a handover or PSCell change within a cell for synchronous reconfiguration.

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

[0008] 5G NR offers both point-to-point (PTP) and point-to-multipoint (PTM) delivery methods for the transmission of MBS packet flows over the air interface. In PTP communication, the RAN node transmits different copies of each MBS data packet to different UEs over the air interface, while in PTM communication, the RAN node transmits a single copy of each MBS data packet to multiple UEs over the air interface. However, in some scenarios, it is unclear how the RAN node applies security protection (e.g., using security algorithms, security keys) to the MBS data packets, if at all. Summary of the Invention [Problem to be solved by the invention]

[0009] A radio access network (RAN) and / or user equipment (UE) may implement the techniques of this disclosure to manage security checks and / or security protection for multicast and / or broadcast services (MBS). For example, a UE may implement the techniques of this disclosure to manage security checks or validation (e.g., decryption and / or integrity protection) for data packets received from a RAN, including data packets associated with multicast and / or broadcast services (MBS).

[0010] Initially, the RAN receives data packets associated with an MBS session from a core network (CN) over a downlink (DL) tunnel. Prior to transmitting the data packets to multiple UEs, the RAN can determine which security check scheme and / or security protection to apply to the data packets based on the identity of the DL tunnel. In one implementation, if the RAN determines that the DL tunnel is a common DL tunnel, the RAN can determine that the data packets should be transmitted to the multiple UEs using multicast or one or more MBS radio bearers (MRBs). In another implementation, if the RAN determines that the DL tunnel is a DL tunnel specific to only one of the multiple UEs, the RAN can determine that the data packets for that UE should be transmitted via unicast or DRBs. In either of these implementations, the RAN can either apply a null security check scheme (e.g., which may include null security protection) to the data packets (effectively refraining from applying a security check scheme and / or security protection to the data packets) or apply a non-null security check scheme and / or non-null security protection to the data packets. The non-null security check scheme and / or the non-null security protection may be individual (ie, unique) to only one of the multiple UEs, or may be common to all of the multiple UEs receiving the data packet.

[0011] Before the UE receives data packets from the RAN on a logical channel, the UE receives a configuration for establishing the logical channel from the RAN. Based on the configuration, the UE can determine which security check scheme and / or security protection to apply to the incoming data packets. In one implementation, if the UE determines from the configuration that the logical channel is a channel dedicated to multicast traffic (e.g., a multicast traffic channel (MTCH)), the UE expects the data packets to be transmitted from the RAN using multicast. In another implementation, if the UE determines from the configuration that the logical channel is not a channel dedicated to multicast traffic (e.g., a dedicated traffic channel (DTCH) or a dedicated control channel (DCCH)), the UE expects the data packets to be received via unicast. In yet another implementation, if the UE determines that the configuration includes a group radio network temporary identifier (G-RNTI), the UE expects the data packets to be transmitted from the RAN using multicast. In any of these implementations, the UE can either apply a null security check scheme (e.g., which may include null security protection) to the data packets (effectively refraining from applying a security check scheme and / or security protection to the data packets) or apply a non-null security check scheme and / or non-null security protection to the data packets. The non-null security check scheme and / or non-null security protection can be specific to the UE or common to the UE and other UEs receiving the data packets. [Means for solving the problem]

[0012] An exemplary embodiment of these techniques is a method in a RAN for managing security protection for an MBS. The method includes receiving, by processing hardware and from a core network (CN) via a downlink (DL) tunnel, data packets associated with an MBS session; determining, by the processing hardware, which security protection to apply to the data packets based on an identification of the DL tunnel prior to transmitting the data packets to multiple UEs; and transmitting, by the processing hardware, the data packets to the multiple UEs using the determined security protection. The security protection may be null security protection or non-null security protection (e.g., UE-specific security protection or common security protection). Another exemplary embodiment of these techniques is a RAN comprising processing hardware and configured to implement the above method.

[0013] Another exemplary embodiment of these techniques is a method in a UE for managing security protection for an MBS. The method includes receiving, by processing hardware and from a radio access network (RAN), a configuration for establishing a logical channel with the RAN; receiving, by the processing hardware and from the RAN via the logical channel, data packets associated with the MBS session; determining, by the processing hardware, which security protection to apply to the data packets based on the configuration; and applying, by the processing hardware, the determined security protection to the data packets. The security protection may be null security protection or non-null security protection (e.g., UE-specific security protection or common security protection). Another exemplary embodiment of these techniques is a UE comprising processing hardware and configured to implement the above method.

[0014] Yet another exemplary embodiment of these techniques is a method in a UE for managing security checks for an MBS, the method including receiving, by processing hardware from a Radio Access Network (RAN), data packets associated with an MBS session, determining, by the processing hardware, what security check scheme to apply to the data packets based on a configuration according to which the data packets were received from the RAN, and processing the data packets according to the determined security check scheme.

[0015] Yet another exemplary embodiment of these techniques is a UE that includes processing hardware (e.g., one or more processors and instructions stored on a non-transitory computer-readable medium) configured to implement the above methods. [Brief explanation of the drawings]

[0016] [Figure 1A] FIG. 1 is a block diagram of an example system in which the techniques of the present disclosure for managing security protection in data communications between a UE and a RAN may be implemented. [Figure 1B] FIG. 1B is a block diagram of any one or more exemplary distributed implementations of base stations of the RAN of FIG. 1A. [Figure 2A] 1B illustrates an example protocol stack that the UE of FIG. 1A may follow when communicating with the base station of FIG. 1A. [Figure 2B] 1B is a block diagram of an example protocol stack that the UE of FIG. 1A may follow when communicating with the DU and CU of the base station. [Figure 3] 1A and 1B are block diagrams illustrating exemplary tunnel architectures for MBS sessions and PDU sessions, respectively. [Figure 4]FIG. 1C is a block diagram illustrating exemplary MRBs and DRBs that may be implemented in the distributed base station of FIG. 1B and that the distributed base station may configure to communicate multicast, broadcast, and / or unicast traffic with UEs. [Figure 5A] 1B is a message sequence diagram of an example method for configuring resources for transmitting MBS data of an MBS session to multiple UEs, which may be implemented in the distributed base station of FIG. [Figure 5B] 1B is a message sequence diagram of another example method for configuring resources for transmitting MBS data of an MBS session to multiple UEs, which may be implemented in the distributed base station of FIG. [Figure 5C] 1B is a message sequence diagram of another example method for configuring resources for transmitting MBS data of an MBS session to multiple UEs, which may be implemented in the base station of FIG. 1A. [Figure 5D] FIG. 5B is a message sequence diagram for a scenario similar to that of FIG. 5A or 5B, but in which the DU does not provide the MBS configuration using an RRC procedure, but rather broadcasts the MBS configuration to multiple UEs via an MBS control channel. [Figure 6A] 1B is a flow diagram of an example method by which the RAN node of FIG. 1A manages security protection of data packets based on whether the data packets are multicast (or broadcast) or unicast to the UE of FIG. 1A. [Figure 6B] 6B is a flowchart of an exemplary method similar to the flowchart of FIG. 6A, but in which the RAN node is part of the distributed base station of FIG. 1B. [Figure 6C] 6B is a flowchart of an exemplary method similar to the flowchart of FIG. 6A, but in which a RAN node manages security protection based on whether a data packet should be transmitted to a UE via an MRB. [Figure 6D] 6C is a flowchart of an exemplary method similar to the flowchart of FIG. 6C, but in which the RAN node is part of the distributed base station of FIG. 1B. [Figure 6E] 6A is a flowchart of an exemplary method in which a RAN node manages security protection based on whether a data packet is received from the CN of FIG. 1A via a common DL tunnel, similar to the flowchart of FIG. 6A. [Figure 6F] 6B is a flowchart of an exemplary method similar to the flowchart of FIG. 6E, but in which the RAN node is part of the distributed base station of FIG. 1B. [Figure 6G] 6B is a flowchart of an example method similar to the flowchart of FIG. 6A, but in which a RAN node manages security protection based on whether a data packet is associated with an MBS session. [Figure 6H] 6B is a flowchart of an exemplary method similar to the flowchart of FIG. 6G, but in which the RAN node is part of the distributed base station of FIG. 1B. [Figure 6I] 10 is a flow diagram of an example method that may be implemented in a UE of the present disclosure for selecting a security check procedure for a received data packet based on whether the data packet is associated with a particular HARQ process. [Figure 6J] 1 is a flow diagram of an example method that may be implemented in a UE of the present disclosure for selecting a security check procedure for a received data packet based on whether a base station transmitted the data packet according to a particular DCI format. [Figure 6K] 1 is a flow diagram of an example method that may be implemented in a UE of the present disclosure for selecting a security check procedure for a received data packet based on whether a base station transmitted the data packet on a semi-persistent scheduling (SPS) multicast radio resource. [Figure 6L] 10 is a flow diagram of an example method that may be implemented in a UE of the present disclosure for selecting a security check procedure for a received data packet based on the type of temporary identifier used by a base station to scramble a CRC for the data packet. [Figure 6M]6B is a flow diagram of an example method similar to that of FIG. 6L, but followed by a UE in comparing a cell RNTI with a group CS RNTI rather than a configured scheduling (CS) RNTI. [Figure 6N] 1 is a flow diagram of an example method that may be implemented in a UE of the present disclosure, selecting a security check procedure for a received data packet based on whether the UE received the data packet according to a multicast configuration or a broadcast configuration. [Figure 6P] 10 is a flow diagram of an example method that may be implemented in a UE of the present disclosure for selecting a security check procedure for a received data packet based on whether a logical channel ID with which the data packet is associated has a particular format. [Figure 6Q] 10 is a flow diagram of an example method that may be implemented in a UE of the present disclosure for selecting a security check procedure for a received data packet based on whether a logical channel ID with which the data packet is associated exceeds a particular predefined value. [Figure 6R] 10 is a flow diagram of an example method that may be implemented in a UE of the present disclosure for selecting a security check procedure for a received data packet based on whether a logical channel ID with which the data packet is associated has a particular value. [Figure 6S] 10 is a flow chart of an example method that may be implemented in a UE of the present disclosure, selecting a security check procedure for a received data packet based on whether the logical channel ID associated with the data packet corresponds to an MRB. [Figure 7A] 1B is a flow diagram of an example method by which the UE of FIG. 1A manages security protection of data packets based on whether the data packets are received over multicast (or broadcast) from the RAN of FIG. 1A or FIG. 1B. [Figure 7B]7B is a flowchart of an example method similar to the flowchart of FIG. 7A, but in which a UE manages security protection based on whether the RAN provides the UE with a Group Radio Network Temporary Identifier (G-RNTI). [Figure 7C] 7B is a flowchart of an example method similar to the flowchart of FIG. 7A, but in which a UE manages security protection based on whether a data packet is received on a multicast traffic channel (MTCH) from the RAN. [Figure 7D] 1 is a flow diagram of an example method for selecting and assigning logical channel identifier values ​​to DRBs and MRBs that may be implemented in a RAN node of the present disclosure. [Figure 7E] 1 is a flow diagram of an example method for selecting and assigning logical channel identifier values ​​for DRBs, multicast MRBs, and broadcast MRBs that may be implemented in a RAN node of the present disclosure. [Figure 8A] 1C is a flow diagram of an example method by which the RAN of FIG. 1A or FIG. 1B manages security protection for an MBS. [Figure 8B] 7D is a flow chart of an exemplary method a base station follows to determine whether a logical channel is associated with an MRB or MBS session. [Figure 8C] 7E is a flowchart of an exemplary method a base station follows to determine whether a logical channel is associated with a multicast MRB, a broadcast MRB, or a DRB. [Figure 9A] 1B is a flow chart of an example method for the UE of FIG. 1A to manage security protection for an MBS. [Figure 9B] 4 is a flow diagram of an example method by which a UE of the present disclosure performs a security check on downlink data packets. DETAILED DESCRIPTION OF THE INVENTION

[0017] Generally speaking, the RAN and / or CN implement the techniques of this disclosure to manage multicast and / or broadcast service (MBS) transmissions. The CN can request a base station to configure, for multiple UEs, a common downlink (DL) tunnel through which the CN can transmit MBS data for an MBS session to the base station. In response to this request, the base station transmits a configuration of the common DL tunnel to the CN. This configuration can include transport layer information such as an Internet Protocol (IP) address and a tunnel identifier (e.g., a tunnel endpoint identifier (TEID)). In addition, generally speaking, the UE of this disclosure implements security checks on downlink data packets, including MBS data packets, based on how the data packets arrive from the RAN.

[0018] Initially, the RAN receives data packets associated with the MBS session from a core network (CN) over a downlink (DL) tunnel. Prior to transmitting the data packets to multiple UEs, the RAN can determine which security check scheme or security protection to apply to the data packets based on the identity of the DL tunnel (e.g., based on whether the DL tunnel is a common DL tunnel or specific to a UE). For example, the RAN can apply a null security check scheme to the data packets (effectively refraining from applying security protection to the data packets, e.g., non-null security protection), or can apply a non-null security check scheme and / or security protection to the data packets, which can be individual (i.e., specific) to only one of the multiple UEs or common to all of the UEs receiving the data packets.

[0019] The UE can determine which security check scheme or security protection to apply to a received data packet based on factors such as the RAN's HARQ process identifier used to transmit the data packet, the format of the DCI over which the data packet was transmitted, the SPS multicast radio resource over which the data packet was transmitted, the temporary identification information used by the RAN to scramble the CRC in the DCI, whether the RAN used a multicast, broadcast, or unicast configuration to transmit the data packet, and the identifier of the logical channel over which the RAN transmitted the data packet. The UE can apply a null security check scheme and / or null security protection to the data packet (effectively refraining from applying security check and / or protection to the data packet) or a non-null security check scheme and / or non-null security protection to the data packet. The non-null security check scheme and / or non-null security protection can be specific to the UE or common to the UE and other UEs receiving the data packet.

[0020] The base station may also configure one or more logical channels toward the UE and / or one or more MRBs associated with the MBS session, and there may be a one-to-one mapping between each logical channel and each MRB. Each MRB may be a broadcast, multicast, or unicast MRB. After receiving MBS data for the MBS session via the common DL tunnel, the base station may determine which security check scheme or security protection to apply to the MBS data, such as a null security check scheme (which may include null security protection) or a non-null security check scheme and / or non-null security protection (e.g., UE-specific security protection or common security protection), and then transmit the (secured) MBS data to one or more UEs participating in the MBS session via one or more logical channels. If the base station determines to apply the null security check scheme and / or null security protection to the MBS data (effectively refraining from applying security check and / or security protection to the MBS data), the UE may receive the original MBS data packet (and therefore does not need to apply security protection to the original MBS data packet). If the base station determines to apply a non-null security check scheme and / or non-null security protection to the MBS data, the UE may receive the secured MBS data packet and then apply the non-null security check scheme and / or non-null security protection to the secured MBS data packet to obtain the original MBS data packet. In some implementations, the base station transmits the MBS data to multiple UEs via a single logical channel. Furthermore, if there are multiple quality of service (QoS) flows for an MBS session, a single logical channel may be associated with multiple QoS flows, or there may be a one-to-one mapping between each QoS flow and each logical channel.

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

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

[0023] In non-MBS (unicast) operation, the UE 102A may use a radio bearer (e.g., a DRB or an SRB) that terminates at the MN (e.g., the base station 104) or the SN (e.g., the base station 106) at different times. For example, after a handover or an SN change to the base station 106, the UE 102A may use a radio bearer (e.g., a DRB or an SRB) that terminates at the base station 106. The UE 102A may apply one or more security keys when communicating on the radio bearer in the uplink (from the UE 102A to a base station, such as the base station 104 or 106) and / or downlink (from the base station to the UE 102A) directions. The UE 102A may perform security protection (e.g., integrity protection and / or encryption) using the security keys (e.g., an integrity key and / or an encryption key), generate secured data packets, and transmit the secured data to the base station over a (first) logical channel (ID) associated with the radio bearer. The base station may receive secured data packets from the UE 102A via a first logical channel (ID) and may use one or more security keys to decrypt and / or perform an integrity check on the secured data packets. Similarly, the base station may use security keys (e.g., integrity keys and / or encryption keys) to perform security (e.g., integrity protection and / or encryption), generate secured data packets, and transmit the secured data packets to the UE 102A via a (second) logical channel (ID) associated with the radio bearer. The UE 102A may receive secured data packets from the base station via a second logical channel and may use one or more security keys to decrypt and / or perform an integrity check on the secured data packets. The first logical channel (ID) and the second logical channel (ID) may be the same logical channel (ID) or different logical channels (IDs).The security keys used by the UE 102A and the base station may be the same or different. If the radio bearer is a DRB, the security key in some implementations is a ciphering key K. UPenc and / or an integrity key K UPint If the radio bearer is an SRB, the security key in some implementations is a ciphering key K RRCenc and / or an integrity key K RRCint In non-MBS operation, the UE 102A transmits data to a base station via a radio bearer on (i.e., within) the uplink (UL) bandwidth portion (BWP) of the cell and / or receives data from the base station via a radio bearer on the downlink (DL) BWP of the cell. The UL BWP may be an initial UL BWP or a dedicated UL BWP, and the DL BWP may be an initial DL BWP or a dedicated DL BWP. The UE 102A may receive paging, system information, public alert messages, or random access responses on the DL BWP. In this non-MBS operation, the UE 102A may be in a connected state. Alternatively, the UE 102A may be in an idle state or an inactive state if the UE 102A supports small data transmission in the idle state or inactive state.

[0024] In MBS operation, the UE 102A may use an MRB terminating at an MN (e.g., base station 104) or an SN (e.g., base station 106) at different times. For example, after a handover or SN change, the UE 102A may use an MRB terminating at the base station 106, which may be operating as an MN or an SN. In some scenarios, the base station (e.g., MN or SN) may transmit MBS data to the UE 102A via the MRB over unicast radio resources (i.e., radio resources dedicated to the UE 102A). In other scenarios, the base station (e.g., MN or SN) may transmit MBS data from the base station to the UE 102A via the MRB over multicast radio resources (i.e., radio resources common to the UE 102A and one or more other UEs) or over a cell's DL BWP. The DL BWP may be an initial DL BWP, an individual DL BWP, or an MBS DL BWP (i.e., a DL BWP specific to the MBS or a DL BWP that is not for unicast). In some scenarios, a base station (e.g., an MN or an SN) can utilize an MRB or DRB to transmit application-level messages, such as security keys, to the UE 102A. The base station can receive security keys from a core network or another base station, or can generate the security keys itself. The base station can apply the security keys when performing security protection on the MBS data (e.g., protecting the integrity of the MBS data and / or encrypting the MBS data) and transmit the encrypted and / or integrity-protected MBS data over radio resources to the UE 102A. Alternatively, the core network can apply the security keys when performing security protection on the MBS data (e.g., protecting the integrity of the MBS data and / or encrypting the MBS data) and transmit the encrypted and / or integrity-protected MBS data to the UE 102A via the base station.Correspondingly, the UE 102A may apply a security key to perform corresponding security protection (e.g., decrypt the MBS data and / or check the integrity of the MBS data) when receiving the MBS data. In other scenarios, the base station may refrain from applying security protection to the MBS data and transmit the MBS data to the UE 102A in its original format. Correspondingly, the UE 102A may omit applying security protection to the MBS data received from the base station.

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

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

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

[0028] The CN 110 may be an evolved packet core (EPC) 111 or a fifth-generation core (5GC) 160, both of which are depicted in FIG. 1A . The base station 104 may be an eNB supporting an S1 interface for communication with the EPC 111, an ng-eNB supporting an NG interface for communication with the 5GC 160, or a gNB supporting an NR air interface as well as an NG interface for communication with the 5GC 160. The base station 106 may be a EUTRA-NR DC (EN-DC) gNB (en-gNB) having an S1 interface with the EPC 111, an en-gNB without connection to the EPC 111, a gNB supporting an NR air interface and an NG interface to the 5GC 160, or an ng-eNB supporting an EUTRA air interface and an NG interface to the 5GC 160. The base stations 104 and 106 may support an X2 or Xn interface to exchange messages directly with each other during the scenarios described below.

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

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

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

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

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

[0034] Although not shown in FIG. 1A , the CN 110 communicatively connects the UE 102A, UE 102B, and / or UE 103 to the MBS network via the RAN 105. The MBS network can provide MBS to the UE 102A, UE 102B, and / or UE 102C for many content distribution applications, such as transparent IPv4 / IPv6 multicast distribution, IPTV, wireless software distribution, group communication, IoT applications, V2X applications, and emergency messages related to public safety. To this end, entities (e.g., servers or server groups) operating within the MBS network support packet exchanges with the UE 102A, UE 102B, and / or UE 103. The packets can carry signaling (such as Session Initiation Protocol (SIP) messages, IP messages, or other suitable messages) as well as data (“or media”) such as text messages, audio, and / or video.

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

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

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

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

[0039] The above description may apply to UEs 102A, 102B, and / or 103.

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

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

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

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

[0044] In some implementations, a base station (e.g., base stations 104, 106) broadcasts or multicasts MBS data packets via one or more MRBs and then receives the MBS data packets via the MRBs. The base station may include the configuration of the MRBs in multicast configuration parameters (which may also be referred to as MBS configuration parameters) described below. In some implementations, the base station broadcasts the MBS data packets via the RLC sublayer 206, the MAC sublayer 204, and the PHY sublayer 202, and correspondingly, the UE receives the MBS data packets using the PHY sublayer 202, the MAC sublayer 204, and the RLC sublayer 206. In such implementations, the base station and the UE may not use the PDCP sublayer 208 and the SDAP sublayer 212 to communicate the MBS data packets. In other implementations, the base station transmits MBS data packets via the PDCP sublayer 208, the RLC sublayer 206, the MAC sublayer 204, and the PHY sublayer 202, and correspondingly, the UE receives the MBS data packets using the PHY sublayer 202, the MAC sublayer 204, the RLC sublayer 206, and the PDCP sublayer 208. In such implementations, the base station and the UE may not use the SDAP sublayer 212 to communicate the MBS data packets. In yet other implementations, the base station transmits MBS data packets via the SDAP sublayer 212, the PDCP sublayer 208, the RLC sublayer 206, the MAC sublayer 204, and the PHY sublayer 202, and correspondingly, the UE receives the MBS data packets using the PHY sublayer 202, the MAC sublayer 204, the RLC sublayer 206, the PDCP sublayer 208, and the SDAP sublayer 212.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0059] Referring to FIG. 5A , the base station 104, implemented as a distributed base station, configures a common tunnel for MBS data in response to a CN requesting resources for an MBS session, and then determines which security protection to apply to the MBS data prior to transmitting the MBS data to the UE 102A and / or UE 102B. After receiving the MBS data, the UE 102A and / or UE 102B can determine which security protection to apply to the MBS data. In scenario 500A, the UE 102A first performs an MBS session join procedure 502 with the CN 110 via the base station 104 to join a particular MBS session. In some scenarios, the UE 102A subsequently performs one or more additional MBS join procedures, with event 502 correspondingly representing the first of multiple MBS join procedures. When the base station 104 configures a common DL tunnel for MBS traffic rather than a UE-specific tunnel, procedures 502 and 586 may be performed in either order. In other words, the base station 104 can configure a common DL tunnel before a single UE joins the MBS session.

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

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

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

[0063] In some implementations, the UE 102A can perform a PDU session establishment procedure with the CN 110 via the base station 104 to perform a (first) MBS session join procedure and establish a PDU session. In the PDU session establishment procedure, the UE 102A can convey a PDU session ID of the PDU session with the CN 110 via the base station 104.

[0064] In some implementations, before performing the (first) MBS session join procedure (event 502), the base station 104 can perform a security activation procedure (e.g., an RRC security mode procedure) with the UE 102A to activate security protection (e.g., integrity protection / integrity check and / or encryption / decryption) for data communications during the MBS session with the UE 102A. In one implementation of the security activation procedure, the base station 104 can send a security activation command message (e.g., a SecurityModeCommand message) to the UE 102A, e.g., over an SRB, and in response, the UE 102A can activate security (e.g., integrity protection and / or encryption) for data communications during the MBS session with the base station 104 and transmit a security activation complete message (e.g., a SecurityModeComplete message) to the base station 104, e.g., over an SRB. In some implementations, the UE 102A can perform the (first) MBS session join procedure after performing the security activation procedure, whereby the (first) MBS session join procedure is protected by security. In other implementations, the UE 102A can perform the (first) MBS session join procedure before performing the security activation procedure.

[0065] Before, during, or after the (first) MBS session join procedure (event 502), the CN 110 can send 504 a (first) CN-BS message to the CU 172 including the first MBS session ID and / or PDU session ID to request the CU 172 to configure resources for the first MBS session. In response to receiving 504 the first CN-BS message, the CU 172 sends 506 a CU-DU message to the DU 174 to request setup of an MBS context and / or a common DL tunnel for the first MBS session. In response to receiving 506 the first CU-DU message, the DU 174 sends 508 a DU-CU message to the CU 172 including a first DU DL transport layer configuration for configuring a common CU-DU DL tunnel for the first MBS session. In some implementations, the CU-DU message is a generic F1AP message or a dedicated F1AP message specifically defined to convey this type of request (e.g., an MBS context setup request message). In some implementations, the DU-CU message of event 508 is a generic F1AP message or a dedicated F1AP message specifically defined for this purpose (e.g., an MBS context setup response message). The CN 110 can additionally include a QoS configuration for the first MBS session. In such a case, the CU 172 can include the QoS configuration in the CU-DU message (event 506).

[0066] The CU 172 sends 510 a first BS-CN message (e.g., an MBS Session Resource Setup Response message) in response to the message of event 504. The CU 172 can include a first MBS session ID and / or a PDU session ID in the first BS-CN message. The first BS-CN message can include a DL transport layer configuration for configuring a common DL tunnel through which the CN 110 transmits MBS data to the CU 172. The DL transport layer configuration includes a transport layer address (e.g., an IP address and / or a TEID) for identifying the common DL tunnel. In some implementations, the CN-BS message of event 504 is a generic NGAP message or a dedicated NGAP message (e.g., an MBS Session Resource Setup Request message) specifically defined to request resources for an MBS session. In some implementations, the BS-CN message of event 510 is a generic NGAP message or a dedicated NGAP message (e.g., an MBS Session Resource Setup Response message) specifically defined to carry resources for an MBS session. In such a case, the CN-BS message of event 504 and the BS-CN message of event 510 may be non-UE specific messages.

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

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

[0069] In the additional MBS session join procedure, if the CN 110 admits the additional MBS session to the UE 102A, the CN 110 can include the additional MBS session ID and, optionally, the QoS configuration for the additional MBS session ID in the first CN-BS message, the second CN-BS message, or an additional CN-BS message similar to the first or second CN-BS message. In such a case, the CU 172 includes, in the first BS-CN message, the second BS-CN message, or an additional BS-CN message similar to the first or second BS-CN message, additional transport layer configurations for the additional MBS session to configure additional common DL tunnels. Each of the transport layer configurations configures a specific common DL tunnel of the common DL tunnel and may be associated with a specific MBS session of the additional MBS session. Alternatively, the CN 110 can perform an additional MBS session resource setup procedure with the CU 172 to obtain the additional transport layer configuration from the CU 172, similar to the single-session MBS session resource setup procedure 586 shown in FIG. 5A. The transport layer configurations may be different to distinguish different common DL tunnels. In particular, any pair of transport layer configurations may have different IP addresses, different DL TEIDs, or different IP addresses and even different DL TEIDs.

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

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

[0072] In some implementations, the second CN-BS message and the second BS-CN message may be a PDU session resource modification request message and a PDU session resource modification response message, respectively.

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

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

[0075] In some implementations, the UE context request message and the UE context response message are a UE context setup request message and a UE context setup response message, respectively. In other implementations, the UE context request message and the UE context response message are a UE context modification request message and a UE context modification response message, respectively.

[0076] After receiving 516 the UE context response message, the CU 172 generates an RRC reconfiguration message including the configuration parameters and one or more MRB configurations and transmits 518 the RRC reconfiguration message to the DU 174. The DU 174 then transmits 520 the RRC reconfiguration message to the UE 102A. The UE 102A then transmits 522 an RRC reconfiguration complete message to the DU 174, which subsequently transmits 523 an RRC reconfiguration complete message to the CU 172.

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

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

[0079] In some implementations, a respective instance of events 512, 514, 516, 518, 519, 520, 522, 523 occurs for each of the UE 102A and the UE 102B. The configuration parameters for the UE 102A and the UE 102B to receive MBS data of the first MBS session may be the same.

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

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

[0082] After receiving the first BS-CN message 510 or the second BS-CN message 519, the CN 110 can transmit 524 MBS data (e.g., one or more MBS data packets) to the CU 172 via a common CN-BS DL tunnel, which then transmits 526 the MBS data to the DU 174 via a common CU-DU tunnel. The DU 174 transmits 528 the MBS data to the UE 102A via one or more logical channels (e.g., multicast or unicast). The UE 102A receives 528 the MBS data via one or more logical channels. For example, the CU 172 receives 524 the MBS data packet, generates a PDCP PDU including the MBS data packet, and transmits 526 the PDCP PDU to the DU 174. The DU 174 then generates a MAC PDU including the logical channel ID and the PDCP PDU, and transmits 528 the MAC PDU to the UE 102A using multicast or unicast. The UE 102A receives 528 the MAC PDU transmitted from the DU 174 using multicast or unicast, extracts the PDCP PDU and logical channel ID from the MAC PDU, identifies the PDCP PDU associated with the MRB, and extracts the MBS data packet from the PDCP PDU.

[0083] In some implementations, after the CN 110 transmits 524 the MBS data to the CU 172, the CU 172 may determine 525 which security protection to apply to the MBS data based on certain criteria prior to transmitting (e.g., multicast or unicast) 528 the MBS data to the UE 102A via the DU 174. For example, if the CU 172 determines that the MBS data packet was received via a common CN-BS DL tunnel, it may decide to apply null security protection, effectively refraining from applying security protection to the received MBS data packet. Additional criteria are described further below with reference to FIGS. 6A-6S. In any event, if the CU 172 determines to apply security protection to the received MBS data packet, the CU 172 may apply at least one security function (e.g., integrity protection and / or encryption) to the MBS data packet to generate a secured MBS data packet. More specifically, when integrity protection is enabled, CU 172 generates a message authentication code for integrity (MAC-I) to protect the integrity of the MBS data packet, whereby the secured MBS data packet includes MBS data and the MAC-I. When encryption is enabled, CU 172 encrypts the MBS data packet to generate an encrypted MBS data packet, whereby the secured MBS data packet is an encrypted MBS data packet. Furthermore, when both integrity protection and encryption are enabled, CU 172 can generate a MAC-I to protect the integrity of the MBS data packet and encrypt the MBS data packet with the MAC-I to generate the encrypted MBS packet and the encrypted MAC-I.

[0084] If the CU 172 decides to refrain from applying security protection to the MBS data packet 525, the CU 172 subsequently transmits the MBS data packet to the DU 174 via a common CU-DU tunnel 526. The DU 174 transmits the MBS data packet to the UE 102A via one or more logical channels (e.g., multicast or unicast) 528. If the CU 172 applies security protection to the MBS data packet 525, obtains a secured MBS data packet, and transmits the secured MBS data packet to the UE 102A via the DU 174 528, the UE 102A can receive the secured MBS data packet and then apply security protection or a security check scheme to the secured MBS data packet 529 to obtain the original MBS data packet. In some implementations, the CU 172 can generate a PDCP PDU including the (secured) MBS data packet and a PDCP sequence number and transmit the PDCP PDU to the DU 174 via the DL tunnel 526. The CU 172 may transmit the PDCP PDU to another DU through another DL tunnel. To simplify the following description, an MBS data packet may represent a PDCP PDU that includes an MBS data packet.

[0085] The DU 174 can transmit the MBS data packets via multicast or unicast. To transmit the MBS data packets via multicast, the DU 174, in some implementations, generates a MAC PDU including the MBS data packets and transmits a multicast transmission including the MAC PDU, as described below 528. To transmit the MBS data packets via unicast, the DU 174, in some implementations, generates a MAC PDU including the MBS data packets and transmits a unicast transmission including the MAC PDU to the UE 102A 528. To transmit or schedule a unicast transmission, the DU 174 can generate downlink control information (DCI), generate a cyclic redundancy check (CRC) for the DCI, and scramble the CRC with a UE-specific ID (e.g., a cell radio network temporary identifier (C-RNTI)) of the UE 102A. The DU 174 transmits the DCI and scrambled CRC on the PDCCH. The UE 102A receives the DCI and scrambled CRC on the PDCCH and receives the unicast transmission according to the DCI. The UE 102A confirms that the DCI or unicast transmission is addressed to the UE 102A according to the ID of the UE 102A. The UE 102A extracts the MBS data packets from the unicast transmission. In the DCI, the DU 174 may include configuration parameters for scheduling the unicast transmission, similar to the DCI for multicast transmission, as described below. In some implementations, the DCI format of the DCI for unicast transmission may be the same as the DCI format of the DCI for multicast transmission. In other implementations, the DCI format of the DCI for unicast transmission may differ from the DCI format of the DCI for multicast transmission.

[0086] In some implementations, the UE 102 may determine 529 which security check scheme and / or security protection to apply to the received MBS data packet based on certain criteria. For example, if the UE 102 determines that the MBS data packet was transmitted from the base station 104 using multicast, the UE 102A may decide to apply a null security check scheme, effectively refraining from applying decryption, integrity verification, or another security check scheme to the received MBS data packet. Additional criteria are described further below with reference to FIGS. 6A-6S. In any case, if the MBS data packet is secured, the UE 102A may extract the MBS data packet from the secured MBS data packet. If the secured MBS data packet is an encrypted MBS data packet, the UE 102A may decrypt the encrypted MBS data packet using an appropriate decryption function and a security key previously provided by the base station 104 to obtain the MBS data. If the secured MBS data packet is an integrity-protected MBS data packet including MBS data and a MAC-I, the UE 102A may determine whether the MAC-I is valid. If the UE 102A verifies that the MAC-I is valid, the UE 102A retrieves the MBS data packet. However, if the UE 102A determines that the MAC-I is invalid, the UE 102A discards the MBS data packet. In some implementations, the UE 102A may maintain a counter that counts the number of invalid MAC-Is received with the MBS data packet. If the counter reaches a certain counter value, the UE 102A may stop receiving MBS data. The UE 102A may receive a configuration from the CU 172 via the DU 174 that predetermines or configures the counter value. In such a case, the UE 102A may perform an RRC connection re-establishment procedure with a CU (e.g., the CU 172 or another CU) via the DU (e.g., the DU 174 or another DU).Alternatively, the UE 102A can perform an MBS session release procedure or a PDU session release procedure with the CN 110 to release or leave the MBS session. Finally, when the secured MBS data packet, along with the encrypted MBS data and the encrypted MAC-I, is both encrypted and integrity protected, the UE 102A can decrypt the encrypted MBS packet and the encrypted MAC-I to obtain the MBS data and the MAC-I. The UE 102A can then verify that the MAC-I is valid for the MBS data. If the UE 102A confirms that the MAC-I is valid, the UE 102A retrieves and processes the MBS data packet. Otherwise, if the UE 102A determines that the MAC-I is invalid, the UE 102A discards the MBS data.

[0087] In some implementations, the DU 174 generates downlink control information (DCI) and a cyclic redundancy check (CRC) scrambled with the ID of the UE 102A (e.g., a cell radio network temporary identifier (C-RNTI) or a group RNTI (G-RNTI)) to transmit the MBS data packet. The DU 174 transmits the DCI and the scrambled CRC to the UE 102A, for example, on a physical downlink control channel (PDCCH). The UE 102A can verify that the MBS data packet is destined for the UE 102A according to the ID of the UE 102. In some implementations, the UE 102 can determine 529 which security protection to apply to the received MBS data packet based on specific criteria. For example, if the UE 102 determines that the MBS data packet was transmitted from the base station 104 using multicast, the UE 102A can decide to apply null security protection and effectively refrain from applying security protection to the received MBS data packet. Additional criteria are further described below with reference to Figures 7A-7E. In any case, if the MBS data packet is secured, the UE 102A can extract the MBS data packet from the secured MBS data packet. If the secured MBS data packet is an encrypted MBS data packet, the UE 102A can decrypt the encrypted MBS data packet using an appropriate decryption function and a security key previously provided by the base station 104 to obtain the MBS data. If the secured MBS data packet is an integrity-protected MBS data packet including MBS data and a MAC-I, the UE 102A can determine whether the MAC-I is valid. If the UE 102A verifies that the MAC-I is valid, the UE 102A extracts the MBS data packet. However, if the UE 102A determines that the MAC-I is invalid, the UE 102A discards the MBS data packet. In some implementations, the UE 102A may maintain a counter that counts the number of invalid MAC-Is received with MBS data packets.When the counter reaches a certain counter value, the UE 102A can stop receiving MBS data. The UE 102A can receive a configuration from the CU 172 via the DU 174 that predetermines or configures the counter value. In such a case, the UE 102A can perform an RRC connection re-establishment procedure with a CU (e.g., the CU 172 or another CU) via the DU (e.g., the DU 174 or another DU). Alternatively, the UE 102A can perform an MBS session release procedure or a PDU session release procedure with the CN 110 to release or leave the MBS session. Finally, when the secured MBS data packet, along with the encrypted MBS data and the encrypted MAC-I, is both encrypted and integrity protected, the UE 102A can decrypt the encrypted MBS packet and the encrypted MAC-I to obtain the MBS data and the MAC-I. The UE 102A can then verify that the MAC-I is valid for the MBS data. If the UE 102A determines that the MAC-I is valid, the UE 102A retrieves and processes the MBS data packet. Otherwise, if the UE 102A determines that the MAC-I is invalid, the UE 102A discards the MBS data.

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

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

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

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

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

[0093] In some implementations, the configuration parameters may or may not include the G-RNTI. The RRC reconfiguration messages for the UEs (e.g., UE 102A and UE 102B) participating in the first MBS session include the same configuration parameters for receiving MBS data of the first MBS session. In some implementations, the RRC reconfiguration messages for the UEs may include the same or different configuration parameters for receiving non-MBS data.

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

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

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

[0097] In some implementations, the CU 172 can include an MBS Session Join Response message in an RRC Reconfiguration message. The UE 102A can include an MBS Session Join Complete message in an RRC Reconfiguration Complete message. Alternatively, the UE 102A can send an UL RRC message including the MBS Session Join Complete message to the CU 172 via the DU 174. The UL RRC message can be a UL Information Transfer message or any suitable RRC message that can include a UL NAS PDU. The CU 172 can include the MBS Session Join Complete message in a second BS-CN message. Alternatively, the CU 172 can send a BS-CN message (e.g., an UPLINK NAS TRANSPORT message) including the MBS Session Join Complete message to the CN 110.

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

[0099] Continuing to refer to FIG. 5A , the UE 102B may perform 530 an MBS session join procedure similar to procedure 502 described above. The UE 102B may perform a PDU session establishment procedure with the CN 110 via the base station 104, as described above. The UE 102B may communicate a PDU session ID with the CN 110 during the PDU session establishment procedure. In some implementations, the PDU session ID of the UE 102B may be the same as the PDU session ID of the UE 102A. In other implementations, the PDU session ID of the UE 102B may be different from the PDU session ID of the UE 102A. The UE 102B may join the same MBS session as the UE 102A by sending an MBS session join request and specifying the same MBS session ID. In this example scenario, the UE 102B joins the MBS session after the base station 104 initiates transmission 528 of MBS data packets to the UE 102A. The CN 110 transmits 532 a CN-BS message to the CU 172 including the MBS Session ID and / or PDU Session ID to indicate that the UE 102B should start receiving MBS data for the MBS session corresponding to the MBS Session ID.

[0100] In some scenarios, the CU 172 or the CN 110 determines that a DL tunnel already exists for the MBS session identified in event 532 and there is no need to perform procedure 586. However, optionally, the CU 172 sends a CU-DU message 534 to the DU 174 to request the setup of an MBS context and / or a common DL tunnel for the first MBS session, and the DU 174 responds 536 with the DU configuration.

[0101] The CU 172 transmits 538 an RRC reconfiguration message to the DU 174, which sends 540 an RRC reconfiguration message to the UE 102B to configure the UE 102B to receive MBS traffic. The RRC reconfiguration message can include or configure the same LCID (value), MRB configuration, and / or RLC bearer configuration as in event 520 when the UEs 102A and 102B operate in the same cell or different cells. Alternatively, when the UEs 102A and 102B operate in different cells, the RRC reconfiguration message can have, for example, different G-RNTI, LCID, and / or RLC bearer configuration. The RRC reconfiguration message can include the same MRB configuration as in event 520 when the UEs 102A and 102B operate in different cells. As illustrated in FIG. 3, CU172 can map data packets arriving via a common CN-BS DL tunnel to one or more MRBs, each corresponding to a common CU-DU DL tunnel and / or a respective logical channel.

[0102] In response to the RRC reconfiguration message of event 540, the UE 102B transmits 542 an RRC reconfiguration complete message (e.g., an RRCReconfigurationComplete message) to the base station 104. Before or after receiving 542 the RRC reconfiguration complete message, the base station 104, in some cases, transmits 539 another BS-CN message to the CN 110, generally similar to event 519. The BS-CN message may, for example, indicate an updated list of UEs associated with the MBS session specified in event 532. After the UE 102B joins 530 the MBS session and obtains the necessary RRC configuration, the CU 172 continues receiving 544 MBS data via a common CN-BS DL tunnel and transmits 546 the MBS data to the DU 174 via a common CU-DU DL tunnel. In some implementations, the DU 174 transmits 548 the MBS data to the UE 102A and the UE 102B using multicast. The UE 102A and the UE 102B may receive 548 the MBS data, similar to event 528. Alternatively, the base station 104 may transmit 548 the MBS data separately to the UE 102A and the UE 102B via unicast.

[0103] Referring now to Figure 5B, scenario 500B is shown, which is generally similar to scenario 500A. However, in scenario 500B, the base station receives a list of UEs participating in the MBS session prior to, rather than before, receiving a request to configure resources for the MBS session. Events in this scenario similar to those described above are labeled with the same reference numbers, and examples and implementations for Figure 5A can be applied to Figure 5B. Differences between the scenarios of Figures 5A and 5B are described below.

[0104] In some implementations, the CU 172 can perform an MBS session resource setup procedure (i.e., events 510 and 504) with the CN 110 in response to receiving 512 the second CN-BS message. In such implementations, the CU 172 transmits 510 a first BS-CN message to the CN 110 in response to receiving 512 the second CN-BS message. The CN 110 then transmits 504 a first CN-BS message to the CU 172 in response to receiving 510 the first BS-CN message. In such a case, the CN 110 may or may not include an MBS session ID (i.e., the first MBS session ID) in the first CN-BS message. The CN 110 can transmit 519 a BS-CN message in response to or after receiving 512 the second CN-BS message or 504 the first CN-BS message. After receiving 512 or in response to receiving the second CN-BS message, after transmitting 510 or in response to transmitting the second BS-CN message, or after receiving 504 or in response to receiving the first CN-BS message, the CU 172 may transmit 506 a CU-DU message to the DU 174.

[0105] Events 512, 510, 504, 506, 508, 514, 516, 518, 519, 520, 522, and 523 are collectively referred to in FIG. 5B as an MBS resource setup and UE-specific MBS session configuration procedure 587. If the CN 110 grants an additional MBS session to the UE 102A in an additional MBS session join procedure, the CN 110 may perform an MBS resource setup and UE-specific MBS session configuration procedure with the base station 104 and the UE 102A, similar to procedure 587. In such a case, the CN 110 may include the additional MBS session ID, and optionally, a QoS configuration for the additional MBS session ID, in the CN-BS message in the MBS resource setup and UE-specific MBS session configuration procedure, similar to the first or second CN-BS message. In such a case, the CU 172 includes additional transport layer configurations for the additional MBS sessions to configure the additional common DL tunnels in the BS-CN message during the MBS resource setup and UE-specific MBS session configuration procedure, similar to the first or second BS-CN message. Each transport layer configuration configures a specific common DL tunnel of the common DL tunnels and may be associated with a specific MBS session of the additional MBS sessions. The transport layer configurations may be different to distinguish between different common DL tunnels. In particular, any pair of transport layer configurations may have different IP addresses, different DL TEIDs, or even different IP addresses and DL TEIDs.

[0106] 5C illustrates an exemplary scenario 500C that is generally similar to scenario 500A. However, in scenario 500C, base station 104 is implemented as a non-distributed base station.

[0107] In scenario 500C, UE 102A first performs 502 an MBS session join procedure with CN 110 via base station 104 to join a particular MBS session. In some scenarios, UE 102A subsequently performs one or more additional MBS join procedures, with event 502 correspondingly being the first of multiple MBS join procedures. Because base station 104 configures a common DL tunnel for MBS traffic rather than a UE-specific tunnel, as described below, procedures 502 and 588 can occur in either order. In other words, base station 104 can configure the common DL tunnel before a single UE joins the MBS session.

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

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

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

[0111] In some implementations, the UE 102A can perform a PDU session establishment procedure with the CN 110 via the base station 104 to establish a PDU session to perform the first MBS session join procedure and / or the additional MBS session join procedure. In the PDU session establishment procedure, the UE 102A can convey a PDU session ID of the PDU session with the CN 110 via the base station 104.

[0112] In some implementations, before performing the (first) MBS session join procedure (event 502), the base station 104 may perform a security activation procedure (e.g., an RRC security mode procedure) with the UE 102A to activate security protection (e.g., integrity protection / integrity check and / or encryption / decryption) for data communications during the MBS session with the UE 102A, which is described above with respect to FIG. 5A.

[0113] Before, during, or after the (first) MBS session join procedure (event 502), the CN 110 can send 504 a (first) CN-BS message to the base station 104 including a first MBS session ID and / or PDU session ID to request the base station 104 to configure resources for the first MBS session. The CN 110 can additionally include a QoS configuration for the first MBS session. In response, the base station 104 can send 510 a (first) BS-CN message (e.g., an MBS Session Resource Setup Response message) including a DL transport layer configuration to the base station 104 for configuring a common DL tunnel over which the CN 110 transmits MBS data. The DL transport layer configuration includes a transport layer address (e.g., an IP address and / or TEID) for identifying the common DL tunnel. The base station 104 can include the first MBS session ID and / or PDU session ID in the first BS-CN message.

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

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

[0116] Events 504 and 510 are collectively referred to as MBS session resource setup procedure 588 in FIG. 5C.

[0117] In the additional MBS session join procedure, if the CN 110 admits an additional MBS session to the UE 102A, the CN 110 can include an additional MBS session ID and / or, optionally, a QoS configuration for the additional MBS session ID in the first or second CN-BS message. In such a case, the base station 104 includes additional transport layer configurations for the additional MBS sessions in the first or second BS-CN message to configure additional common DL tunnels. Each transport layer configuration can configure a specific common DL tunnel of the common DL tunnel and be associated with a specific MBS session of the additional MBS sessions. Alternatively, the CN 110 can perform an additional MBS session resource setup procedure with the base station 104 to obtain the additional transport layer configurations from the base station 104, similar to the single-session MBS session resource setup procedure 588 shown in FIG. 5C. The transport layer configurations can be different to distinguish different common DL tunnels. In particular, any pair of transport layer configurations can have different IP addresses, different DL TEIDs, or even different IP addresses and DL TEIDs.

[0118] In some implementations, the CN 110 may indicate a list of UEs participating in the first MBS session in the CN-BS message of event 504. In other implementations, the CN 110 may send 512 another second CN-BS message to the base station 104 indicating a list of UEs participating in the first MBS session. The CN 110 may include the first MBS session ID and / or PDU session ID in the second CN-BS message. The base station 104 may send 519 a second BS-CN message to the CN 110 in response to the second CN-BS message 512. In such a case, the second CN-BS message and the second BS-CN message may be non-UE-specific messages. For example, the list of UEs includes UE 102A and / or UE 102B. To indicate the list of UEs, the CN 110 may include a list of (CN UE interface ID, RAN UE interface ID) pairs, each identifying a specific one of the UEs. For example, the list of pairs includes a first pair of (first CN UE interface ID and first RAN UE interface ID) identifying the UE 102A and a second pair of (second CN UE interface ID, second RAN UE interface ID) identifying the UE 102B. In some implementations, the "CN UE interface ID" may be an "AMF UE NGAP ID" and the "RAN UE interface ID" may be a "RAN UE NGAP ID." In other implementations, the CN 110 may include a list of UE IDs, each identifying a specific one UE in the set of UEs. In some implementations, the CN 110 may assign UE IDs in a NAS procedure (e.g., a registration procedure) that the CN 110 performs with specific UEs and transmit each of the UE IDs to a specific one of the UEs. For example, the list of UE IDs may include a first UE ID of the UE 102A and a second UE ID of the UE 102B. In some implementations, the UE ID is an S-Temporary Mobile Subscriber Identity (S-TMSI) (e.g., 5G-S-TMSI).

[0119] In another implementation, the CN 110 may send 512 a second CN-BS message to the base station 104 indicating that the UE 102A will join the first MBS session. The CN 110 may include the first MBS session ID and / or PDU session ID in the second CN-BS message. The second CN-BS message may be a UE-specific message for the UE 102A. In response to receiving 512 the second CN-BS message, the base station 104 may send 519 a second BS-CN message to the CN 110. The base station 104 may include the first MBS session ID and / or PDU session ID in the second BS-CN message. The CN 110 may include an MBS session join response message for the UE 102A in the second CN-BS message. The base station 104 may include the first CN UE interface ID and the first RAN UE interface ID in the second CN-BS message. Alternatively, the base station 104 can include the first UE ID in the second CN-BS message. In such an implementation, the CN 110 can send an additional CN-BS message to the base station 104 (not shown) indicating that the UE 102B (only) will join the first MBS session. The additional CN-BS message can be a UE-specific message for the UE 102B. The CN 110 can include an MBS session join response message for the UE 102B in the additional CN-BS message. The CN 110 can include a second CN UE interface ID and a second RAN UE interface ID in the additional CN-BS message. Alternatively, the CN 110 can include the second UE ID in the additional CN-BS message. The base station 104 can send an additional BS-CN message to the CN 110 (not shown) in response to the additional CN-BS message.

[0120] In some implementations, the second CN-BS message and the BS-CN message may be a PDU session resource modification request message and a PDU session resource modification response message, respectively.

[0121] In some implementations, the base station 104 can include the DL transport layer configuration in the second BS-CN message and / or the additional BS-CN message. In other words, the base station 104 can send the same DL transport layer configuration in a BS-CN message in response to a CN-BS message indicating multiple UEs participating in the same MBS session. In such implementations, the CN 110 can blend the MBS resource setup procedure 588 and the second and / or additional CN-BS and BS-CN messages into a single procedure.

[0122] In some implementations, the base station 104 can perform an MBS resource setup procedure 588 with the CN 110 in response to receiving the second CN-BS message. In such implementations, the base station 104 transmits a first BS-CN message to the CN 110 in response to receiving the second CN-BS message. The CN 110 then transmits a first CN-BS message to the base station 104 in response to the first BS-CN message. In such a case, the CN 110 may or may not include an MBS Session ID (i.e., the first MBS Session ID) in the first CN-BS message.

[0123] If the base station 104 performs the MBS resource setup procedure 588 with the CN 110 to establish a common DL tunnel for the first MBS session, the base station 104 may refrain from including the DL transport layer configuration for the first MBS session in the second BS-CN message. In such a case, the CN 110 may refrain from including the UL transport layer configuration for the first MBS session in the second CN-BS message.

[0124] After performing 588 the MBS session resource setup procedure or receiving 512 the second CN-BS message, the base station 104 generates an RRC reconfiguration message (e.g., an RRCReconfiguration message) including configuration parameters for the UE 102A that will receive the MBS data of the first MBS session. The base station 104 then transmits 520 the RRC reconfiguration message to the UE 102A. In response, the UE 102A transmits 522 an RRC reconfiguration complete message (e.g., an RRCReconfigurationComplete message) to the base station 104. The base station 104 can send 519 the second BS-CN message to the CN 110 before or after receiving the RRC reconfiguration complete message.

[0125] After receiving the first BS-CN message 510 or the second BS-CN message 519, the CN 110 can transmit 524 the MBS data to the base station 104, which then transmits (e.g., multicast or unicast) the MBS data to the UE 102A via one or more logical channels 528. The UE 102A receives 528 the MBS data via one or more logical channels. For example, the base station 104 receives 524 the MBS data packet, generates a PDCP PDU including the MBS data packet, generates a MAC PDU including the logical channel ID and the PDCP PDU, and transmits the MAC PDU to the UE 102A 528. The UE 102A receives 528 the MAC PDU, extracts the PDCP PDU and logical channel ID from the MAC PDU, identifies the PDCP PDU associated with the MRB, and extracts the MBS data packet from the PDCP PDU.

[0126] In some implementations, after the CN 110 transmits 524 the MBS data to the base station 104, the base station 104 can determine 525 what security protection to apply to the MBS data prior to transmitting (e.g., multicast or unicast) 528 the MBS data to the UE 102A, similar to the manner described above with respect to Figure 5A. If the base station 104 applies 525 security protection to the MBS data packet, obtains a secured MBS data packet, and transmits 528 the secured MBS data packet to the UE 102A, the UE 102A can receive the secured MBS data packet and then apply security protection 529 to the secured MBS data packet to obtain the original MBS data packet, similar to the manner described above with respect to Figure 5A.

[0127] In some implementations, the configuration parameters may include one or more MRB configurations configuring one or more MRBs associated with the first MBS session. The configuration parameters may also include one or more RLC bearer configurations, each associated with a specific MRB. Each of the MRB configurations may include an MRB ID, a PDCP configuration, the first MBS session ID, a PDCP reestablishment indication (e.g., reestablishPDCP), and / or a PDCP recovery indication (e.g., recoveryPDCP). In some implementations, the PDCP configuration may be a PDCP-Config IE for the DRB. In some implementations, the RLC bearer configuration may be an RLC-BearerConfig IE. In some implementations, the RLC bearer configuration may include a logical channel (LC) ID for configuring a logical channel. In some implementations, the configuration parameters or the MRB configuration may include a logical channel configuration (e.g., a LogicalChannelConfig IE) for configuring the logical channel. In some implementations, the RLC bearer configuration may include an MRB ID.

[0128] In some implementations, the base station 104 can configure an MRB as a DL-only RB in the MRB configuration. For example, the base station 104 can refrain from including UL configuration parameters in the PDCP configuration in the MRB configuration to configure the MRB as a DL-only RB. The base station 104 can include only DL configuration parameters in the MRB configuration, for example, as described above. In such a case, the base station 104 configures the UE 102A not to transmit UL PDCP data PDUs to the base station 104 over the MRB by excluding UL configuration parameters for the MRB in the PDCP configuration in the MRB configuration. In another example, the base station 104 refrains from including UL configuration parameters in the RLC bearer configuration. In such a case, the base station 104 configures the UE 102A not to transmit control PDUs to the base station 104 over logical channels by excluding UL configuration parameters from the RLC bearer configuration.

[0129] If the base station 104 includes UL configuration parameters in the RLC bearer configuration, the UE 102A may transmit control PDUs (e.g., PDCP control PDUs and / or RLC control PDUs) to the base station 104 via logical channels using the UL configuration parameters. For example, the base station 104 may configure the UE to receive MBS data using a (de-)compression protocol (e.g., a Robust Header Compression (ROHC) protocol). In this case, when the base station 104 receives 524 an MBS data packet from the CN 110, it compresses the MBS data packet using the compression protocol to obtain a compressed MBS data packet and transmits 528 a PDCP PDU including the compressed MBS data packet to the UE 102A. When the UE 102A receives the compressed MBS data packet, it decompresses the compressed MBS data packet using the (de-)compression protocol to obtain the original MBS data packet. In such a case, the UE 102A may transmit, via a logical channel to the base station 104, a PDCP control PDU that includes header compression protocol feedback (e.g., interspersed ROHC feedback) for the operation of the header (de)compression protocol.

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

[0131] In some implementations, the configuration parameters for receiving MBS data of the first MBS session include one or more logical channel (LC) IDs for configuring one or more logical channels. In some implementations, the logical channel may be a DTCH. In other implementations, the logical channel may be an MTCH. In some implementations, the configuration parameters may or may not include a G-RNTI. An RRC reconfiguration message for a UE (e.g., UE 102A and UE 102B) participating in the first MBS session includes the same configuration parameters for receiving MBS data of the first MBS session. In some implementations, the RRC reconfiguration message for the UE may include the same or different configuration parameters for receiving non-MBS data.

[0132] In some implementations, the base station 104 can include an MBS session join response message in an RRC reconfiguration message that the base station 104 transmits 520 to the UE 102A. The UE 102A can include an MBS session join complete message in an RRC reconfiguration complete message of event 522. Alternatively, the UE 102A can send an UL RRC message including an MBS session join complete message to the base station 104. The UL RRC message can be a UL information transfer message or any suitable RRC message that can include an UL NAS PDU. The base station 104 can include the MBS session join complete message in a second BS-CN message. Alternatively, the base station 104 can send a BS-CN message (e.g., an UPLINK NAS TRANSPORT message) to the CN 110 that includes the MBS session join complete message to the CN 110.

[0133] In another implementation, the base station 104 transmits a DL RRC message including an MBS Session Join Response message to the UE 102A. The DL RRC message may be a DL Information Transfer message, another RRC Reconfiguration message, or any suitable RRC message that may include a DL NAS PDU. The UE 102A may send a UL RRC message including an MBS Session Join Complete message to the base station 104. The UL RRC message may be a UL Information Transfer message, another RRC Reconfiguration Complete message, or any suitable RRC message that may include a DL NAS PDU.

[0134] Continuing to refer to FIG. 5C , the UE 102B may perform 530 an MBS session join procedure similar to procedure 502 described above. The UE 102B may perform a PDU session establishment procedure with the CN 110 via the base station 104, as described above. The UE 102B may communicate a PDU session ID with the CN 110 during the PDU session establishment procedure. The UE 102B may join the same MBS session as the UE 102A by sending an MBS session join request and specifying the same MBS session ID. In this example scenario, the UE 102B joins the MBS session after the base station 104 initiates transmission 528 of MBS data packets to the UE 102A. The CN 110 transmits 532 a CN-BS message to the base station 104 including the MBS session ID and / or PDU session ID to indicate that the UE 102B should begin receiving MBS data for the MBS session corresponding to the MBS session ID. In some implementations, the PDU session IDs of the UE 102A and the UE 102B may be the same (value). In other implementations, the PDU session IDs of the UE 102A and the UE 102B may be different (values).

[0135] The base station 104 or the CN 110 determines that a DL tunnel already exists for the MBS session identified in event 532 and that there is no need to perform procedure 588. The base station 104 transmits 540 an RRC reconfiguration message to the UE 102B, configuring the UE 102B to receive MBS traffic. The RRC reconfiguration message may include the same LCID (value), MRB configuration, and RLC bearer configuration as in event 520 when the UEs 102A and 102B operate in the same cell. When the UEs 102A and 102B operate in different cells, the RRC reconfiguration message may have, for example, different G-RNTI, LCID, and / or RLC bearer configuration. The RRC reconfiguration message may include the same MRB configuration as in event 520 when the UEs 102A and 102B operate in different cells. As illustrated in FIG. 3, the base station 104 can map data packets arriving via the common DL tunnel to one or more MRBs, each corresponding to a respective logical channel.

[0136] In response to the RRC reconfiguration message of event 540, the UE 102B transmits 542 an RRC reconfiguration complete message (e.g., an RRCReconfigurationComplete message) to the base station 104. Before or after receiving 542 the RRC reconfiguration complete message, the base station 104, in some cases, sends 539 another BS-CN message to the CN 110, generally similar to event 519. The BS-CN message may, for example, indicate an updated list of UEs associated with the MBS session specified in event 532. After the UE 102B joins 530 the MBS session and obtains 540 the necessary RRC configuration, the base station 104 continues to receive 544 MBS data via the common DL tunnel. In some implementations, the base station 104 transmits 548 the MBS data to the UE 102A and the UE 102B using multicast. The UE 102A and the UE 102B can receive 548 the MBS data, similar to event 528. Alternatively, the base station 104 may transmit the MBS data separately to the UE 102A and the UE 102B via unicast.

[0137] In some implementations, after the CN 110 transmits 544 the MBS data to the base station 104, the base station 104 may determine 545 what security protection to apply to the MBS data prior to transmitting 548 (e.g., multicast or unicast) the MBS data to the UE 102B, similar to event 525. If the base station 104 applies 545 security protection to the MBS data packet, obtains a secured MBS data packet, and transmits 548 the secured MBS data packet to the UE 102B, the UE 102B may receive the secured MBS data packet and then apply 549 security protection to the secured MBS data packet, similar to event 529, to obtain the original MBS data packet.

[0138] Referring now to Figure 5D, scenario 500D is shown, which is generally similar to scenarios 500A, 500B, and 500C. Events in this scenario similar to those described above are labeled with the same reference numbers, and examples and implementations for Figures 5A, 5B, and 5C can be applied to Figure 5D. Differences between the scenarios of Figures 5A, 5B, 5C, and 5D are described below.

[0139] In scenario 500D, base station 104 broadcasts a particular MBS session (e.g., identified by a (third) MBS session ID). Base station 104 may also multicast the MBS session, as described with respect to FIG. 5A. UE 102 (i.e., (each of) UE 102A and / or 102B) may first perform 503 a (third) MBS session join procedure with CN 110 via base station 104 to join the MBS session, similar to event 502 of FIG. 5A. Alternatively, UE 102 does not perform an MBS session join procedure to receive (MBS data of) the third MBS session.

[0140] The CN 110 and base station 104 perform an MBS resource setup procedure 585 to establish a (first) common CN-BS DL tunnel and a (first) common CU-DU DL tunnel for transmitting MBS data for the third MBS session, similar to event 586 in FIG. 5A . Before, during, or after the MBS resource setup procedure 585, the DU 174 transmits (e.g., broadcasts) 567 system information (e.g., one or more system information blocks (SIBs)) including an MBS control channel (MCCH) configuration on one or more cells (e.g., cell 124 and / or other cells operated by the DU 174). In some implementations, the base station DU 174 can transmit 567 the system information periodically. The DU 174 transmits (e.g., broadcasts) 569 at least one MBS configuration over the MCCH configured by the MCCH configuration.

[0141] In some implementations, the MCCH configuration includes configuration parameters such as a window start slot, a window duration, a modification period, and / or a repetition period and offset. The window duration indicates the duration (i.e., the MCCH transmission window, for example, in units of (consecutive) slots), starting from the slot indicated by the window start slot, during which the transmission of MCCH information (i.e., the transmission of the MBS configuration via the MCCH) can be scheduled. The modification period defines a periodically occurring boundary, i.e., a radio frame for which SFN mod modification period=0. The content of different transmissions of MCCH information can only differ if there is at least one such boundary between them. The repetition period and offset parameters define the length and offset of the MCCH repetition period. The transmission of MCCH information is scheduled in a radio frame for which the system frame number (SFN) mod repetition period length is the repetition period offset.

[0142] In some implementations, the MBS configuration includes an MBS session information list, which includes a list of MBS session information IEs (i.e., information related to one or more MBS sessions, including a third MBS session). For example, the MBS session information IE includes an MBS session ID, a G-RNTI, an MRB configuration, an RLC configuration, and / or DRX information. The MBS session ID identifies the MBS session, the G-RNTI is used to schedule transmission of MBS data for the MBS session, the MRB configuration configures one or more broadcast MRBs, the RLC configuration configures RLC parameters for the MRBs, and the DRX information configures DRX-related parameters for transmission of MBS data for the MBS session. Each MRB configuration can configure an MRB. For example, the MRB configuration includes a PDCP configuration for the MRB. In scenario 500C, the MBS session information IE in the list includes a third MBS session ID, an MRB configuration configuring one or more MRBs for the third MBS session, a G-RNTI used by DU174 to schedule transmission of MBS data for the MRB or the third MBS session, an RLC configuration for the MRB, and / or DRX information configuring DRX-related parameters for transmission of MBS data for the MRB or the third MBS session.

[0143] In some implementations, the DU 174 can transmit 567 the system information in response to performing the MBS resource setup procedure 585. In some implementations, the CU 172 generates the system information and transmits the system information to the DU 174. In other implementations, the DU 174 generates the system information.

[0144] In some implementations, the DU 174 can transmit 569 (or initiate) the MBS configuration in response to performing 585 the MBS resource setup procedure. In some implementations, the base station DU 174 can periodically transmit 569 the MBS configuration. In some implementations, the CU 172 generates the MBS configuration and transmits the MBS configuration to the DU 174. In other implementations, the DU 174 generates the MBS configuration. In yet other implementations, the CU 172 generates a portion (first portion) of the MBS configuration, and the DU 174 generates a portion (second portion) of the MBS configuration (i.e., the remaining portion of the MBS configuration). Details of these different implementations are described below.

[0145] In some implementations, the CU 172 may transmit a CU-DU message to the DU 174, the CU-DU message including configuration parameters for the third MBS session, such as a third MBS session ID, a QoS configuration, a DRX cycle configuration, an MRB ID of the MRB, and / or a PDCP configuration of the MRB. In some implementations, the DU 174 may generate an MBS session information IE according to the configuration parameters. In some implementations, the DU 174 may generate at least a portion of the MBS session information IE, for example, according to preconfigured values. For example, the DU 174 may generate an MRB configuration including a PDCP configuration, an MRB ID, and / or the third MBS session ID received from the CU 172. Alternatively, the DU 174 may generate an MRB configuration including a PDCP configuration, an MRB ID, and / or the third MBS session ID using preconfigured values. In some implementations, the DU 174 may not include an MRB ID in the MRB configuration. The DU 174 may generate an RLC configuration (e.g., including an MRB ID) for the MRB, for example, according to the QoS configuration and / or the MRB ID. Alternatively, the DU 174 may generate the RLC configuration using pre-configured RLC parameters. The DU 174 may assign a logical channel ID for the MRB and include the logical channel ID in the MBS session information IE or the RLC configuration. In another example, the DU 174 may generate DRX information that configures a DRX cycle according to a DRX cycle configuration received from the CU 172. Alternatively, the DU 174 may determine the DRX cycle according to, for example, the QoS configuration received from the CU 172. In yet another example, the DU 174 may assign a G-RNTI and associate the G-RNTI with a third MBS session ID.In such a case, the DU 174 may generate the MBS session information and an MBS configuration (e.g., an MBS broadcast configuration message) including the MBS session information and transmit 569 the MBS configuration over the MCCH on one or more cells. In some implementations, the CU-DU message may be the CU-DU message of the MBS resource setup procedure 585, similar to event 506. In other implementations, the CU-DU message may be a (second) message other than the CU-DU message of the MBS resource setup procedure 585.

[0146] In other implementations, the DU 174 can transmit a DU-CU message including the RLC bearer configuration, DRX information, and G-RNTI to the CU 172. In such implementations, the CU 172 generates an MRB configuration including a PDCP configuration, an MRB ID, and / or a third MBS session ID. After receiving the DU-CU message, the CU 172 generates MBS session information and an MBS configuration (e.g., an MBS broadcast configuration message) including the MBS session information for (each of) one or more cells. The CU 172 then transmits a CU-DU message including the MBS configuration to the DU 174. After receiving the MBS configuration from the CU 172, the DU 174 transmits the MBS configuration via the MCCH 569. In some implementations, the CU 172 can send a CU-DU message to the DU 174 to request the DU 174 to transmit the DU-CU message. In such a case, the DU 174 transmits the DU-CU message to the CU 172 in response to the CU-DU message.

[0147] In some implementations, the DU 174 can transmit the DU-CU message of procedure 585 to the CU 172 after transmitting 567 the system information and / or transmitting 569 the MBS configuration, similar to event 508. In other implementations, the DU 174 can transmit the DU-CU message to the CU 172 before transmitting 567 the system information and / or transmitting 569 the MBS configuration.

[0148] After the MBS resource setup procedure 585, the CN 110 transmits 575 MBS data of the third MBS session to the CU 172 via the first common CN-BS DL tunnel. Subsequently, the CU 172 transmits 577 the MBS data to the DU 174 via the first common CU-DU DL tunnel according to the PDCP configuration in the MBS configuration 569. The DU 174 then transmits (i.e., broadcasts) 579 the MBS data according to the MBS configuration 569 (e.g., via a logical channel identified by a logical channel ID and / or using an RLC configuration and / or G-RNTI). The UE 102 receives 579 the MBS data according to the MBS configuration 569. For example, the CU 172 receives 575 an MBS data packet, generates a PDCP PDU including the MBS data packet according to the PDCP configuration, and transmits 577 the PDCP PDU to the DU 174 via the first common CU-DU DL tunnel. The DU 174 then generates a MAC PDU including the logical channel ID and the PDCP PDU and transmits the MAC PDU to the UE 102 using the G-RNTI 579. The UE 102 receives the MAC PDU using the G-RNTI 579, extracts the PDCP PDU and the logical channel ID from the MAC PDU, identifies the PDCP PDU associated with the MRB, and extracts the MBS data packets from the PDCP PDU according to the PDCP configuration. In some implementations, a UE 102 operating in a connected state (e.g., an RRC_CONNECTED state), an inactive state (e.g., an RRC_INACTIVE state), or an idle state (e.g., an RRC_IDLE state) receives the MBS data 579.

[0149] In some implementations, the CU 172 may apply null security protection, as described above, to the MBS data received by the CU 172 at event 575. In such a case, the UE 102 may also apply null security protection, as described above, to the MBS data received by the UE 102 at event 579.

[0150] Next, some example scenarios or implementations related to managing security protection involving some components of Figures 1A and 1B will now be described with reference to Figures 6A through 9B. For simplicity, "multicast" in these figures refers to both multicast and broadcast. These methods may be performed by processing hardware, for example, one or more processors executing a set of instructions stored on a non-transitory computer-readable medium.

[0151] Referring initially to FIG. 6A , in scenario 600A, a node of a RAN (e.g., RAN 105) in block 602 initially receives (e.g., at events 524, 544) a data packet from a CN (e.g., CN 110) for multiple UEs (e.g., UE 102A, UE 102B, UE 103). The data packet may be, for example, an IP packet, an Ethernet packet, or a NAS PDU. More generally, the data packet may be either an MBS data packet or a non-MBS data packet. The RAN node may be any one of the base stations described in FIG. 1A (e.g., base station 104, base station 106). Each of the multiple UEs may be operating in a connected state (e.g., RRC_CONNECTED state), an inactive state (e.g., RRC_INACTIVE state), or an idle state (e.g., RRC_IDLE state). In some implementations, prior to receiving the data packet, the RAN node may provide the CN with a transport layer configuration including a first transport layer address (e.g., an IP address) and a first DL tunnel ID that identifies the DL tunnel. The CN may provide the RAN node with a second transport layer address and a second DL tunnel ID along with the data packet to indicate the DL tunnel through which the CN will transmit the data packet. For example, the CN may generate a tunnel packet including the second transport layer address, the second DL tunnel ID along with the data packet, and transmit the tunnel packet to the RAN node.

[0152] In block 604, the RAN node determines whether the data packet should be multicast to multiple UEs. In some implementations, the RAN node can determine whether the CN provided the data packet to the RAN node via a common DL tunnel to determine whether the data packet should be multicast to multiple UEs. If the RAN node determines that the data packet was received via a common DL tunnel, the RAN node can determine that the data packet should be multicast to multiple UEs. If the RAN node determines that the data packet was received via a DL tunnel specific to only a particular UE (e.g., UE 102A and not UE 103), the RAN node can determine that the data packet should be unicast to UE 102A. In some implementations, to determine whether the CN provided the data packet to the RAN node via a common DL tunnel, the RAN node can compare the second transport layer address and the second DL tunnel ID with the first transport layer address and the first DL tunnel ID described above. If the RAN node sets the first DL tunnel ID to the identification information of a common DL tunnel and the RAN node determines that the second transport layer address and the second DL tunnel ID match the first transport layer address and the first DL tunnel ID, respectively, the RAN node can determine that the CN provided the data packet to the RAN node via the common DL tunnel.If the RAN node sets the first DL tunnel ID to the identification information of a common DL tunnel and the RAN node determines that the second transport layer address and the second DL tunnel ID do not match the first transport layer address and the first DL tunnel ID, respectively, the RAN node can determine that the CN provided the data packet to the RAN node via a DL tunnel specific to a particular UE instead of the common DL tunnel.

[0153] Depending on whether the data packet is multicast to multiple UEs, the RAN node may determine which security check scheme and / or security protection to apply to the data packet (e.g., at events 525, 545). If the RAN node determines in block 604 that the data packet is to be multicast to multiple UEs, the RAN node may apply a first security check scheme to the data packet in block 606. In one implementation, the first security check scheme may include or be null security protection, so that the RAN node effectively refrains from applying security protection to the data packet in block 606 and provides the original data packet to the multiple UEs. In another implementation, the first security check scheme may include or be non-null security protection (e.g., common security protection). In this implementation, the RAN node may use the same (i.e., common) security algorithm and the same security key (e.g., security key for one or more MRB or MBS sessions) for the data packet that it transmits to the multiple UEs when applying the first security protection. In some implementations, the RAN node can send the same security key to each of multiple UEs or send the same parameters to each of multiple UEs to derive security keys using UE-specific security protection. The multiple UEs have UE-specific security keys for applying their respective UE-specific security protections. The RAN node can then transmit the data packet (i.e., either the original data packet or the secured data packet) to the UE in block 608. On the other hand, if the RAN node determines in block 604 that the data packet should be unicast to a specific UE, the RAN node can apply a second security protection to the data packet in block 610.In one implementation, the second security protection may be a non-null security protection specific to a particular UE (i.e., a UE-specific security protection). In some cases, the UE-specific security protection may be a null security protection if the RAN node does not require security protection to be applied to the data packet. The RAN node may then transmit the secured data packet to the particular UE in block 612.

[0154] 6B, scenario 600B is similar to scenario 600A in blocks 602, 604, 606, and 610. The RAN node in scenario 600A may be, for example, the base station 104, while the RAN node in scenario 600B is, for example, a CU (e.g., CU 172) of the base station 104. After the RAN node applies a first security protection to the data packet in block 606, the RAN node may transmit the data packet (i.e., either the original data packet or the secured data packet) to one or more DUs (e.g., DU 174) of the base station 104 in block 609. After the RAN node applies the second security protection to the data packet in block 610, the RAN node may transmit the secured data packet in block 613 to another RAN node, such as a DU (e.g., DU 174) of base station 104, another CU (e.g., CU 172) of another base station (e.g., base station 106), or another base station (e.g., base station 106).

[0155] Referring to FIG. 6C, scenario 600C is similar to scenario 600A except for block 604. While the RAN node in scenario 600A determines whether a data packet should be multicast to multiple UEs in block 604, the RAN node in scenario 600C determines whether the data packet should be transmitted to multiple UEs via an MRB in block 605. In some implementations, the RAN node may determine whether the CN provided the data packet to the RAN node via a common DL tunnel to determine whether the data packet should be transmitted to multiple UEs via an MRB. If the RAN node determines that it received the data packet via a common DL tunnel, it may determine that the data packet should be transmitted to multiple UEs via an MRB and proceed to blocks 606 and 608 as described above. If the RAN node determines that it received the data packet via a DL tunnel specific to only a specific UE, it may determine that the data packet should be transmitted to a specific UE via a DRB and proceed to blocks 610 and 612 as described above. In some implementations, the RAN node may set an MRB ID that identifies an MRB to a value different from a DRB ID that identifies a DRB, so as to distinguish an MRB from a DRB.

[0156] 6D, scenario 600D is similar to scenario 600C in blocks 602, 605, 606, and 610. The RAN node in scenario 600C may be, for example, the base station 104, while the RAN node in scenario 600D is, for example, a CU (e.g., CU 172) of the base station 104. After the RAN node applies the first security protection to the data packet in block 606, the RAN node may transmit the data packet (i.e., either the original data packet or the secured data packet) to one or more DUs (e.g., DU 174) of the base station 104 in block 609. After the RAN node applies the second security protection to the data packet in block 610, the RAN node may transmit the secured data packet in block 613 to another RAN node, such as a DU (e.g., DU 174) of base station 104, another CU (e.g., CU 172) of another base station (e.g., base station 106), or another base station (e.g., base station 106).

[0157] Referring to FIG. 6E, scenario 600E is similar to scenario 600A except for block 604. While the RAN node in scenario 600A determines whether a data packet should be multicast to multiple UEs in block 604, the RAN node in scenario 600E determines whether the CN provided the data packet to the RAN node via a common DL tunnel in block 603. As described above with respect to FIG. 6A, the RAN node may determine that the CN provided the data packet via a common DL tunnel if the second transport layer address and the second DL tunnel ID match the first transport layer address and the first DL tunnel ID, respectively. If there is no match, the RAN node may determine that the CN provided the data packet via a UE-specific DL tunnel. If the RAN node determines in block 603 that it received the data packet via a common DL tunnel, the RAN node may proceed to blocks 606 and 608 as described above. If the RAN node determines in block 603 that the data packet was received via a DL tunnel specific to only a particular UE instead of a common DL tunnel, the RAN node may proceed to blocks 610 and 612, as described above.

[0158] 6F, scenario 600F is similar to scenario 600E in blocks 602, 605, 603, and 610. The RAN node in scenario 600E may be, for example, the base station 104, while the RAN node in scenario 600F is, for example, a CU (e.g., CU 172) of the base station 104. After the RAN node applies the first security protection to the data packet in block 606, the RAN node may transmit the data packet (i.e., either the original data packet or the secured data packet) to one or more DUs (e.g., DU 174) of the base station 104 in block 609. After the RAN node applies the second security protection to the data packet in block 610, the RAN node may transmit the secured data packet in block 613 to another RAN node, such as a DU (e.g., DU 174) of base station 104, another CU (e.g., CU 172) of another base station (e.g., base station 106), or another base station (e.g., base station 106).

[0159] Referring to FIG. 6G, scenario 600G is similar to scenario 600A except for block 604. While the RAN node in scenario 600A determines whether a data packet should be multicast to multiple UEs in block 604, the RAN node in scenario 600G determines whether the data packet is associated with an MBS session in block 607. In some implementations, the RAN node may determine whether the CN provided the data packet to the RAN node via a common DL tunnel to determine whether the data packet is associated with an MBS session. If the RAN node determines that it received the data packet via a common DL tunnel, it may determine that the data packet is associated with an MBS session and may proceed to blocks 606 and 608 as described above. If the RAN node determines that it received the data packet via a DL tunnel specific to only a particular UE, it may determine that the data packet is not associated with an MBS session in block 607. For example, the RAN node may determine that the data packet is associated with a PDU session (i.e., not an MBS session) or that the data packet is included in a control message (e.g., an NGAP message) received on a control plane interface (e.g., NG-C) and therefore cannot be associated with an MBS session. The RAN node then proceeds to blocks 610 and 612 as described above.

[0160] 6H, scenario 600H is similar to scenario 600G in blocks 602, 607, 606, and 610. The RAN node in scenario 600G may be, for example, the base station 104, while the RAN node in scenario 600H is, for example, a CU (e.g., CU 172) of the base station 104. After the RAN node applies the first security protection to the data packet in block 606, the RAN node may transmit the data packet (i.e., either the original data packet or the secured data packet) to one or more DUs (e.g., DU 174) of the base station 104 in block 609. After the RAN node applies the second security protection to the data packet in block 610, the RAN node may transmit the secured data packet in block 613 to another RAN node, such as a DU (e.g., DU 174) of base station 104, another CU (e.g., CU 172) of another base station (e.g., base station 106), or another base station (e.g., base station 106).

[0161] Referring now to FIG. 6I, a UE, such as UE 102A, UE 102B, or UE 103, may implement method 600I. In block 620, the UE initially receives a data packet from a RAN node over a (first) logical channel (e.g., at events 528, 529, 548). The data packet may be a PDCP SDU, an IP packet, an Ethernet packet, or a NAS PDU, which may or may not be secured by the RAN, for example. More generally, the data packet may be either an MBS data packet or a non-MBS data packet. The RAN node may be any one of the base stations described in FIG. 1A (e.g., base station 104, base station 106) or a CU of any one of the base stations (e.g., CU 172). The UE may be operating in a connected state (e.g., RRC_CONNECTED state), an inactive state (e.g., RRC_INACTIVE state), or an idle state (e.g., RRC_IDLE state). In some implementations, prior to receiving the data packet, the RAN node can provide the UE with a configuration for establishing a logical channel over which the UE will receive the data packet. The configuration can include a logical channel identification (ID) (value) that identifies the logical channel. In some implementations, the UE receives a MAC PDU from the RAN node in block 620 that includes the logical channel ID (value) and the data packet, indicating that the UE will receive the data packet over the logical channel.

[0162] In some implementations, a logical channel (ID) may be associated with a radio bearer (RB) (ID). The RB (ID) may be an MRB (ID), a DRB (ID), or an SRB (ID). The UE may receive an RB configuration from the RAN, including an RB ID that configures the RB, similar to events 520 and 540. In some implementations, the logical channel may be an MTCH, a DTCH, or a DCCH, which is associated with an MRB, a DRB, or an SRB, respectively. If the logical channel ID is associated with an MRB, the UE determines that it has received the data packet over the MTCH. If the logical channel ID is not associated with an MRB, the UE determines that it has received the data packet but not over the MTCH. In some implementations, if the logical channel ID is associated with a DRB, the UE determines that it has received the data packet over the DTCH, and if the logical channel ID is associated with an SRB, the UE determines that it has received the data packet over the DCCH.

[0163] In some implementations, the MRB(ID) can be a multicast, broadcast, or unicast MRB(ID). In some implementations, the logical channel can be a multicast MTCH, a broadcast MTCH, or a unicast MTCH associated with a multicast MRB, a broadcast MRB, or a unicast MRB, respectively. In the case of a multicast MRB, the RAN can, in some implementations, configure the UE to a second logical channel (ID) associated with the multicast MRB, similar to events 520 and 540. The second logical channel can be a (multicast) MTCH or a DTCH. In the case of a unicast MRB, the RAN can configure the UE to a DTCH associated with the unicast MRB instead of a (unicast) MTCH. In this case, the first logical channel ID configures the DTCH.

[0164] In block 624A, the UE determines whether it has received a data packet using a particular HARQ process (number). Depending on whether the UE has received the data packet via the particular HARQ process, the UE can determine which security protection to apply to the data packet (e.g., at events 529, 549). If the UE determines in block 624A that it has received the data packet using a particular HARQ process (number), the UE can apply a corresponding first security protection to the data packet in block 626. In one implementation, the first security protection can be a null security protection, which effectively allows the UE to refrain from applying security protection to the data packet in block 626 and simply receive the data packet in its original form from the RAN node. In another implementation, the first security protection can be a non-null security protection, such as a common security protection. In this implementation, when the UE applies the first security protection to a data packet previously secured by a RAN node, the UE can use a common security key (e.g., a security key for one or more MRB or MBS sessions) to obtain the original data packet. On the other hand, if the UE determines in block 624A that it has received the data packet using a specific HARQ process (number), the UE can apply a corresponding second security protection to the data packet in block 628. Generally, the second security protection differs from the first security protection at least in terms of the security key used. The security algorithm used in the second security protection can be the same as or different from that used in the first security protection. In one implementation, the second security protection can be a non-null security protection specific to the UE (i.e., a UE-specific security protection).In this implementation, the UE may use a UE-specific security key (e.g., the integrity key and / or encryption key described above) when applying a second security protection to the data packet previously secured by the RAN to obtain the original data packet. If the RAN does not require security protection to be applied to the data packet, in some cases, the UE-specific security protection may be null security protection. Following either block 626 or 628, the UE may process the original data packet in block 630.

[0165] In some implementations, the UE may receive (or attempt to receive) the DCI and a scrambled CRC of the DCI on a PDCCH from the RAN to receive the data packet. In some implementations, the UE may verify the scrambled CRC by using the C-RNTI and the DCI. If the UE verifies that the scrambled CRC is valid, the UE receives the dynamic scheduling unicast transmission according to the DCI and extracts the data packet from the dynamic scheduling unicast transmission at block 620. In some implementations, the UE may receive (or attempt to receive) the DCI and a scrambled CRC of the DCI on a PDCCH from the RAN to receive the data packet. In some implementations, the UE may verify the scrambled CRC by using the G-RNTI and the DCI. If the UE verifies that the scrambled CRC is valid, the UE receives the dynamic scheduling multicast transmission according to the DCI and extracts the data packet from the dynamic scheduling multicast transmission at block 620. In some implementations, the UE may receive (or attempt to receive) the DCI and a scrambled CRC of the DCI on the PDCCH from the RAN before receiving the data packet in block 620. The UE may verify the scrambled CRC by using the CS-RNTI and the DCI. If the UE verifies that the scrambled CRC is valid, the UE may activate an SPS unicast radio resource and periodically receive an SPS unicast transmission on the SPS unicast radio resource in accordance with the DCI. The UE extracts the data packet from the SPS unicast transmission. In such implementations, the UE may receive an SPS unicast transmission on the SPS unicast radio resource in accordance with the DCI and extract the data packet from the SPS unicast transmission in block 620. In other implementations, the UE may receive (or attempt to receive) the DCI and a scrambled CRC of the DCI on the PDCCH from the RAN before receiving the data packet in block 620.The UE may verify the scrambled CRC by using the G-CS-RNTI and the DCI. If the UE verifies that the scrambled CRC is valid, the UE may (decide to) activate an SPS multicast radio resource and periodically receive data packets on the SPS multicast radio resource in accordance with the DCI. In such an implementation, the UE may receive an SPS multicast transmission on the SPS multicast radio resource in accordance with the DCI and extract the data packets from the SPS multicast transmission in block 620.

[0166] In some implementations, the DCI includes an HARQ process number. The UE associates an HARQ process with the HARQ process number and receives a transmission including a MAC PDU using the HARQ process according to the DCI. If the HARQ process number in the DCI is the specific HARQ process number of block 624A, the UE determines that it has received the data packet using the specific HARQ process (number). In some implementations, the UE receives a dynamic scheduling multicast transmission or an SPS multicast transmission using the specific HARQ process (number) of block 624A.

[0167] If the HARQ process number in the DCI is not a specific HARQ process number in block 624A, the UE determines that the data packet was received without using a specific HARQ process (number). For example, the specific HARQ process number is the first HARQ process number. If the HARQ process number in the DCI is the first HARQ process number, the UE applies first security protection to the data packet. If the HARQ process number in the DCI is the second HARQ process number, the UE applies second security protection to the data packet.

[0168] 6J, scenario 600J is similar to scenario 600I except for block 624A. While the UE in scenario 600I determines in block 624A whether it received a data packet transmitted by a RAN node using a particular HARQ process (number), the UE in scenario 600J determines in block 624B whether it received a data packet in block 620 according to a particular DCI format. If the UE determines in block 624B that it received a data packet according to the particular DCI format, flow proceeds to block 626. If the UE determines in block 624B that it received a data packet not according to the particular DCI format, flow proceeds to block 628.

[0169] To receive the data packet, the UE may receive (or attempt to receive) the DCI and a scrambled CRC of the DCI on the PDCCH from the RAN, as described above. If the DCI format of the DCI is the specific DCI format of block 624B, the UE determines that it has received the data packet according to the specific DCI format. If the DCI format of the DCI is not the specific DCI format of block 624B, the UE determines that it has received the data packet without according to the specific DCI format. For example, the specific DCI format is a first DCI format. If the DCI format of the DCI is the first DCI format, the UE applies first security protection to the data packet. If the DCI format of the DCI is a second DCI format, the UE applies second security protection to the data packet. In some implementations, the DCI format of the DCI scheduling unicast transmission and the DCI format of the DCI scheduling multicast transmission may be the first DCI format and the second DCI format, respectively.

[0170] Referring to FIG. 6K, scenario 600K is similar to scenario 600I except for block 624A. While the UE in scenario 600I determines in block 624A whether it received a data packet transmitted by a RAN node using a particular HARQ process (number), the UE in scenario 600K determines in block 624C whether it received a data packet on an SPS multicast radio resource in block 620. In some implementations, the UE may determine whether the configuration provided by the RAN to establish a logical channel includes a G-CS-RNTI that the UE uses to access the data packet. If the UE determines in block 624C that it received a data packet on an SPS multicast radio resource, the UE may proceed to blocks 626 and 630, as described above. If the UE determines in block 624C that it received a data packet not on an SPS multicast radio resource, the UE may proceed to blocks 628 and 630, as described above. For example, if the UE can receive the data packet from the RAN on a unicast radio resource (e.g., a dynamic scheduling or SPS unicast radio resource) as described above, the UE determines that it received the data packet but not on an SPS multicast radio resource. In some scenarios and implementations, if the UE determines that it received the data packet on a dynamic scheduling multicast radio resource as described above, the UE may proceed to blocks 626 and 630, as described above.

[0171] Referring to FIG. 6L, scenario 600L is similar to scenario 600I except for block 624A. While the UE in scenario 600I determines in block 624A whether it has received a data packet transmitted by a RAN node using a particular HARQ process (number), the UE in scenario 600L determines in block 624D whether it has received a data packet in block 620 according to a DCI whose cyclic redundancy check (CRC) is scrambled by the G-CS-RNTI or the CS-RNTI. If the UE determines in block 624D that it has received a data packet according to a DCI whose CRC is scrambled by the G-CS-RNTI, the UE may proceed to blocks 626 and 630, as described above. If the UE determines in block 624D that it has received a data packet according to a DCI whose CRC is scrambled by the CS-RNTI, the UE may proceed to blocks 628 and 630, as described above.

[0172] Referring to FIG. 6M, scenario 600M is similar to scenario 600I except for block 624A. While the UE in scenario 600I determines in block 624A whether it has received a data packet transmitted by a RAN node using a particular HARQ process (number), the UE in scenario 600M determines in block 624E whether it has received a data packet in block 620 according to a DCI whose cyclic redundancy check (CRC) is scrambled by the G-CS-RNTI or the C-RNTI. If the UE determines in block 624E that it has received a data packet according to a DCI whose CRC is scrambled by the G-CS-RNTI, the UE may proceed to blocks 626 and 630, as described above. If the UE determines in block 624E that it has received a data packet according to a DCI whose CRC is scrambled by the C-RNTI, the UE may proceed to blocks 628 and 630, as described above.

[0173] Referring to FIG. 6N, scenario 600N is similar to scenario 600I except for block 624A. In scenario 600N, "multicast" does not refer to both multicast and broadcast. While the UE in scenario 600I determines in block 624A whether it received a data packet transmitted by a RAN node using a particular HARQ process (number), the UE in scenario 600N determines in block 624F whether it received a data packet in block 620 according to a multicast configuration or a broadcast configuration. If the UE determines in block 624F that it received a data packet according to a multicast configuration or a broadcast configuration, the UE may proceed to blocks 626 and 630 as described above. If the UE determines in block 624F that it received a data packet without according to either a multicast configuration or a broadcast configuration, the UE may proceed to blocks 628 and 630 as described above. For example, the UE received a data packet according to a unicast configuration.

[0174] In some implementations, the UE can receive a multicast configuration in an RRC reconfiguration message from the RAN, similar to the configuration parameters in the DU configuration of events 520 and 540. The multicast configuration includes configuration parameters for receiving MBS data multicast by the RAN. For example, the multicast configuration includes an RLC bearer configuration and / or an MRB configuration. The RLC bearer configuration may be associated with the MRB configuration. In some implementations, the UE can receive an MCCH message from the RAN, similar to the MBS configuration of event 569, including a broadcast configuration. The broadcast configuration includes configuration parameters for receiving MBS data broadcast by the RAN. For example, the broadcast configuration includes an RLC bearer configuration and may or may not include an MRB configuration. In some implementations, the UE can receive a unicast configuration in an RRC reconfiguration message from the RAN. The unicast configuration includes configuration parameters for receiving non-MBS data unicast by the RAN. For example, the unicast configuration includes an RLC bearer configuration and / or a DRB configuration. The RLC bearer configuration may be associated with the DRB configuration.

[0175] Referring to FIG. 6P, scenario 600P is similar to scenario 600I except for block 624A. While the UE in scenario 600I determines whether it has received a data packet transmitted by a RAN node using a particular HARQ process (number) in block 624A, the UE in scenario 600P determines whether it has received a logical channel ID for a logical channel that conforms to a particular format in block 624G. If the UE determines in block 624G that it has received a logical channel ID that conforms to a particular format, the UE may proceed to blocks 626 and 630, as described above. If the UE determines in block 624G that it has received a subordinate logical channel ID that does not conform to a particular format, the UE may proceed to blocks 628 and 630, as described above.

[0176] As described above, the UE receives a MAC PDU from the RAN in block 620, the MAC PDU including a logical channel ID and a data packet. If the UE retrieves the logical channel ID according to a particular format (e.g., a first format), the UE determines that the UE has received a logical channel ID according to the particular format, and the UE proceeds to blocks 626 and 630. For example, the first format is a one-octet extended logical channel ID (eLCID) format. If the UE retrieves the logical channel ID according to a second format, the UE determines that the UE has received a logical channel ID that does not according to the particular format, and the UE proceeds to blocks 628 and 630. For example, the second format is an LCID format (e.g., not a one-octet eLCID format).

[0177] Referring to FIG. 6Q, scenario 600Q is similar to scenario 600I except for block 624A. While the UE in scenario 600I determines whether it received a data packet transmitted by a RAN node using a particular HARQ process (number) in block 624A, the UE in scenario 600Q determines whether a logical channel ID value of a logical channel is greater than a predetermined value in block 624H. For example, the predetermined value may be 63. If the UE determines in block 624H that the logical channel ID value is greater than the predetermined value, the UE may proceed to blocks 626 and 630, as described above. If the UE determines in block 624H that the logical channel ID value is less than or equal to the predetermined value, the UE may proceed to blocks 628 and 630, as described above.

[0178] 6R, scenario 600R is similar to scenario 600I except for block 624A. While the UE in scenario 600I determines whether it received a data packet transmitted by a RAN node using a particular HARQ process (number) in block 624A, the UE in scenario 600R determines whether the logical channel ID value of the logical channel is a particular value (i.e., a particular logical channel ID value) in block 624I. If the UE determines that the logical channel ID value is a particular value in block 624I, the UE may proceed to blocks 626 and 630, as described above. If the UE determines that the logical channel ID value is not a particular value in block 624I, the UE may proceed to blocks 628 and 630, as described above.

[0179] Prior to receiving the data packet at block 620, the UE may receive a first RRC message from the RAN including a first configuration including a particular value (i.e., a first value). Prior to receiving the data packet at block 620, the UE may receive a second RRC message from the RAN including a second configuration including a second value (i.e., a second logical channel ID value) for configuring a second logical channel. As described above, the UE receives a MAC PDU including the logical channel ID value and the data packet at block 620. If the logical channel ID value is the first value, the UE proceeds to blocks 626 and 630. If the logical channel ID value is the second value, the UE proceeds to blocks 628 and 630. In some implementations, the first RRC message and the second RRC message are the same message (e.g., an RRC reconfiguration message). In other implementations, the first RRC message and the second RRC message are different messages. For example, the first RRC message and the second RRC message may be an RRC Reconfiguration message and an RRC Setup message, respectively. In another example, the first RRC message and the second RRC message may be an RRC Reconfiguration message. In yet another example, the first RRC message and the second RRC message may be an RRC Reconfiguration message and an RRC Restart message, respectively.

[0180] Referring to FIG. 6S, scenario 600S is similar to scenario 600I except for block 624A. While the UE in scenario 600I determines whether it has received a data packet transmitted by a RAN node using a particular HARQ process (number) in block 624A, the UE in scenario 600S determines whether the logical channel (ID) is associated with the MRB(ID) in block 624J. If the UE determines in block 624J that the logical channel (ID) is associated with the MRB(ID), the UE may proceed to blocks 626 and 630, as described above. If the UE determines in block 624J that the logical channel (ID) is not associated with the MRB(ID), the UE may proceed to blocks 628 and 630, as described above. For example, the UE determines in block 624J that the logical channel (ID) is associated with a DRB or an SRB.

[0181] The logical channel can be a DTCH, MTCH, or DOCH. In some implementations, the logical channel can be a DTCH associated with an MRB or DRB. In other implementations, the logical channel can be an MTCH associated with an MRB (e.g., a multicast MRB or a broadcast MRB). The MTCH can be a multicast MTCH or a broadcast MTCH associated with a multicast MRB or a broadcast MRB, respectively. In yet other implementations, the logical channel can be a DCCH associated with an SRB.

[0182] Prior to receiving the data packet at block 620, the UE may receive a first RRC message from the RAN including a first configuration including a first logical channel ID (value) configuring a first logical channel associated with the MRB(ID). Prior to receiving the data packet at block 620, the UE may receive a second RRC message from the RAN including a second configuration including a second logical channel ID (value) configuring a second logical channel associated with the DRB(ID) or SRB(ID). If the UE receives the data packet via the first logical channel, the UE proceeds to blocks 626 and 630. If the UE receives the data packet via the second logical channel, the UE proceeds to blocks 628 and 630. In some implementations, the first RRC message and the second RRC message are the same message (e.g., an RRC reconfiguration message). In other implementations, the first RRC message and the second RRC message are different messages. For example, the first RRC message and the second RRC message may be an RRC setup message and an RRC reconfiguration message, respectively. In another example, the first RRC message and the second RRC message may be an RRC reconfiguration message.

[0183] The UE may receive multiple data packets from the RAN via different logical channels and perform example methods 600I-600S for each of the data packets as described above.

[0184] 7A-7C, generally speaking, the RAN nodes in FIGS. 6A-6H determine which security protection to apply to a data packet, while the UEs in FIGS. 7A-7C similarly determine which security protection to apply after receiving a data packet (i.e., either the original data packet or the secured data packet) from the RAN node. Generally speaking, if the RAN node applies security protection (e.g., encryption, integrity protection) to the data packet, the UE performs corresponding security protection (e.g., decryption, integrity check) to retrieve the original data packet. If the RAN node refrains from applying security protection to the data packet, the UE does not need to perform any corresponding security protection.

[0185] Referring initially to FIG. 7A , in scenario 700A, a UE (e.g., one of UE 102A, UE 102B, or UE 103) initially receives a data packet from a RAN node (e.g., at events 528, 548) over a logical channel in block 702. The data packet may be an IP packet, an Ethernet packet, or a NAS PDU, which may or may not be secured by the RAN, for example. More generally, the data packet may be either an MBS data packet or a non-MBS data packet. The RAN node may be any one of the base stations described in FIG. 1A (e.g., base station 104, base station 106) or a CU of any one of the base stations (e.g., CU 172). The UE may be operating in a connected state (e.g., an RRC_CONNECTED state), an inactive state (e.g., an RRC_INACTIVE state), or an idle state (e.g., an RRC_IDLE state). In some implementations, prior to receiving a data packet, the RAN node can provide the UE with a configuration for establishing a logical channel over which the UE will receive the data packet. The configuration can include, for example, identification information indicating that the logical channel is an MTCH or other type of logical channel (e.g., a DTCH or DCCH).

[0186] In block 704, the UE determines whether it has received a data packet transmitted by a RAN node using multicast. In some implementations, to determine whether it has received a data packet transmitted by a RAN node using multicast, the UE can determine whether a configuration received from the RAN node indicates that the logical channel is an MTCH or another type of logical channel (e.g., a DTCH or a DCCH). For example, the configuration includes a logical channel ID (value) that identifies the logical channel. If the logical channel ID is associated with an MRB, the logical channel is an MTCH. If the logical channel ID is associated with a DRB, the logical channel is a DTCH. If the logical channel ID is associated with an SRB, the logical channel is a DCCH. In some implementations, if the UE determines that it has received a data packet via an MTCH, the UE can determine that it has received a data packet transmitted from a RAN node using multicast and that the data packet is not secured by the RAN node (e.g., the RAN node has applied null security protection to the data packet). In other implementations, if the UE determines that it received a data packet over an MTCH, the UE may determine that it received a data packet transmitted from a RAN node using multicast and that the data packet has been secured by the RAN node (e.g., the RAN node has applied non-null security protection, such as common security protection, to the data packet). If the UE determines that it received a data packet over another type of logical channel (e.g., a DTCH or DCCH), the UE may determine that it received a data packet over unicast and that the data packet has been secured by the RAN node (e.g., the RAN node has applied non-null security protection, such as UE-specific security protection, to the data packet).

[0187] The UE receives a MAC PDU from a RAN node in block 702, the MAC PDU including a logical channel ID and a data packet. If the logical channel ID is associated with an MRB, the UE determines that the data packet has been received over an MTCH. If the logical channel ID is not associated with an MRB, the UE determines that the data packet has been received not over an MTCH. In some implementations, if the logical channel ID is associated with a DRB, the UE determines that the data packet has been received over a DTCH, and if the logical channel ID is associated with an SRB, the UE determines that the data packet has been received over a DCCH.

[0188] Depending on whether the UE has received a data packet transmitted by a RAN node using multicast, the UE may determine which security protection to apply to the data packet (e.g., at events 529, 549). If the UE determines in block 704 that it has received a data packet transmitted by a RAN node using multicast, the UE may apply a corresponding first security protection to the data packet in block 706. In one implementation, the first security protection may be a null security protection, so that, in effect, the UE may refrain from applying security protection to the data packet in block 706 and simply receive the data packet in its original form from the RAN node. In another implementation, the first security protection may be a non-null security protection, such as a common security protection. In this implementation, when the UE applies the first security protection to a data packet previously secured by a RAN node, the UE may use a common security key (e.g., a security key of one or more MRB or MBS sessions) to obtain the original data packet. On the other hand, if the UE determines in block 704 that it has received a data packet transmitted by a RAN node using unicast, the UE may apply a corresponding second security protection to the data packet in block 708. Generally, the second security protection differs from the first security protection at least in terms of the security key used. The security algorithm used in the second security protection may be the same as or different from that used in the first security protection. In one implementation, the second security protection may be a non-null security protection specific to the UE (i.e., a UE-specific security protection). In this implementation, the UE may use a UE-specific security key (e.g., the integrity key and / or encryption key described above) when applying the second security protection to a data packet previously secured by a RAN node to obtain the original data packet.In some cases, the UE-specific security protection may be null security protection if the RAN node does not require security protection to be applied to the data packet. Following either block 706 or 708, the UE may process the original data packet in block 710.

[0189] Referring to FIG. 7B, scenario 700B is similar to scenario 700A except for blocks 702 and 704. While the UE in scenario 700A determines whether it has received a data packet transmitted by a RAN node using multicast in block 704, the UE in scenario 700B determines whether it has received a data packet in block 702 according to a DCI whose cyclic redundancy check (CRC) is scrambled by a G-RNTI or a C-RNTI in block 705. In some implementations, the UE may determine whether a configuration provided by the RAN to establish a logical channel includes a G-RNTI that the UE uses to access the data packet. If the configuration includes the G-RNTI, the scrambled CRC may be verified by using the G-RNTI and the DCI. If the UE verifies that the scrambled CRC is valid, the UE may receive (or determine to receive) the data packet in block 702 by accessing the data packet using the DCI. Regardless of whether the configuration includes or excludes the G-RNTI, the UE can verify the scrambled CRC by using the unique C-RNTI that is already known by the UE and the DCI. If the UE verifies that the scrambled CRC is valid, the UE can receive (determine to receive) the data packet by using the DCI in block 702. If the UE determines that it has received the data packet according to the DCI whose CRC is scrambled by the G-RNTI, the UE can proceed to blocks 706 and 710 as described above. If the UE determines that it has received the data packet according to the DCI whose CRC is scrambled by the C-RNTI, the UE can proceed to blocks 708 and 710 as described above.

[0190] Referring to FIG. 7C, scenario 700C is similar to scenario 700A except for block 704. While the UE in scenario 700A determines whether it has received a data packet transmitted by a RAN node using multicast in block 704, the UE in scenario 700C determines whether the logical channel on which the data packet was received is an MTCH in block 703. As described above with respect to FIG. 7A, the UE may determine whether the configuration received from the RAN node indicates that the logical channel is an MTCH or another type of logical channel (e.g., a DTCH, or possibly a DCCH). If the UE determines that it has received the data packet on an MTCH, the UE may proceed to blocks 706 and 710, as described above. If the UE determines that it has received the data packet on another type of logical channel (e.g., a DTCH or a DCCH), the UE may proceed to blocks 708 and 710, as described above.

[0191] 7D , a RAN (e.g., RAN 105, base station 104, base station 106, DU 174) can implement an example method 700D for managing logical channels for conveying MBS data and non-MBS data. Method 700 begins at block 722, where the RAN reserves a first set of logical channel ID values ​​for at least one MRB. At block 724, the RAN reserves a second set of logical ID values ​​for at least one DRB. At block 726, the RAN selects a first logical channel ID value for the MRB from the first set to configure a first logical channel (ID) associated with the MRB. At block 728, the RAN transmits at least one first message, each message including the first logical channel ID value, to at least one first UE (e.g., events 520, 540, 569). In block 730, the RAN transmits at least one first MAC PDU via multicast to at least one first UE, each MAC PDU including a data packet and a first logical channel ID (e.g., events 528, 548, 579). In block 732, the RAN selects a second logical channel ID value for the MRB from the second set to configure a second logical channel (ID) associated with the DRB. In block 734, the RAN transmits a second message including the second logical channel ID value to the second UE. In block 736, the RAN transmits the second MAC PDU including the data packet and the second logical channel ID value to the second UE via unicast.

[0192] In some implementations, the data packets in the second MAC PDU may be IP packets, Ethernet packets, or application packets for a unicast service that the second UE runs. For example, the unicast service may be a web browsing service, Gmail, YouTube, Facebook, WhatsApp, Instant Gram, or Netflix.

[0193] In some implementations, the at least one first UE may include a second UE. In other implementations, the at least one first UE does not include a second UE. In some implementations, the at least one first message and the second message may be an RRC reconfiguration message and / or an RRC restart message.

[0194] In some implementations, the first set includes at least one first logical channel ID value, and the second set includes at least one second logical channel ID value that is different from the at least one first logical channel ID value. In some implementations, the at least one first logical channel ID value is greater than the at least one second logical channel ID value. For example, the first set includes integer values ​​greater than 63 and less than 309, and the second set includes integer values ​​greater than 4 and less than 64 or 33. In another example, the first set includes integer values ​​greater than 63 and less than 72, 80, 88, 96, 104, 112, 120, or 128, and the second set includes integer values ​​greater than 4 and less than 64 or 33. In yet another example, the first set includes integer values ​​greater than 244, 252, 260, 268, 276, 284, 292 or 300 and less than 309, and the second set includes values ​​greater than 4 and less than 64 or 33.

[0195] In other implementations, the first set and the second set include different values ​​greater than 4 and less than a predetermined value N, where N is, for example, greater than 4 and less than 33. In such implementations, the RAN can partition or divide the values ​​5, ..., the predetermined values ​​into a first set and a second set. For example, the first set includes values ​​X, ..., 32, where X is an integer greater than 6 and less than 33, and the second set includes values ​​5, ..., (X-1).

[0196] In some implementations, the RAN can generate a first logical channel ID field / IE to include a first logical channel ID value and include the first logical channel ID field / IE in the first message. Similarly, the RAN can generate a second logical channel ID field / IE to include a second logical channel ID value and include the second logical channel ID field / IE in the second message. In some implementations, the first and second logical channel ID fields / IEs are different fields / IEs. For example, the first logical channel ID field can be a logicalChannelIdentity-Ext(-r17), logicalChannelIdentityExt(-r17), eLogicalChannelIdentity(-r17), or extLogicalChannelIdentity(-r17) field, and the second logical channel ID field can be a logicalChannelIdentity field. In another example, the first logical channel ID IE can be a LogicalChannelIdentity-Ext(-r17), LogicalChannelIdentityExt(-r17), ELogicalChannelIdentity(-r17), or ExtLogicalChannelIdentity(-r17) IE, and the second logical channel ID field can be a LogicalChannelIdentity IE. In other implementations, the first and second logical channel ID fields / IEs are different instances of the same field / IE. For example, the field can be a logicalChannelIdentity, logicalChannelIdentity-Ext(-r17), logicalChannelIdentityExt(-r17), eLogicalChannelIdentity(-r17), or extLogicalChannelIdentity(-r17) field.In another example, the IE may be a LogicalChannelIdentity, LogicalChannelIdentity-Ext(-r17), LogicalChannelIdentityExt(-r17), ELogicalChannelIdentity(-r17), or ExtLogicalChannelIdentity(-r17) IE.

[0197] In some implementations, the RAN generates a (first) mapping value representing the first logical channel ID value in block 730. In such implementations, the RAN includes the mapping value in place of the first logical channel ID value in the first MAC PDU. In some implementations, the RAN can further include in the first MAC PDU an indication indicating the presence of the mapping value. The indication can be a specific logical channel ID value. For example, the specific logical channel ID value can be a predetermined logical channel ID value (e.g., 34). Thus, when the UE receives the first MAC PDU, the UE (e.g., MAC 204B) can determine the presence of the mapping value according to the indication and obtain the first logical channel ID value from the mapping value. In some implementations, the RAN may not include an indication in the second MAC PDU. In such a case, when the UE receives the first MAC PDU, the UE (e.g., MAC 204B) can determine the presence of the mapping value according to the indication.

[0198] In some implementations, the mapping value may be one of the numbers 0, 1, ..., 244 that map to logical channel ID values ​​64, 65, ..., 308, respectively. For example, the mapping value may be one of the numbers 0, 1, ..., M that map to logical channel ID values ​​64, 65, ..., 64+M, respectively, where M may be 7, 15, 23, 31, 39, 47, 55, 63. In this example, the RAN refrains from using the numbers M+1, ..., 244 and logical channel ID values ​​(65+M), ..., 308 for the mapping value and the first set, respectively. In yet another example, the mapping value may be one of the values ​​(181+N), 182, ..., 244 that map to logical channel ID values ​​(245+N), 246, ..., 308, respectively, where N=0, 8, 16, 24, 32, 48, 56. In this example, the RAN refrains from using the numbers 0, ..., (180+N) and logical channel ID values ​​64, ..., (244+N) for the mapping values ​​and the first set, respectively.

[0199] An advantage of splitting the logical channel ID values ​​into different sets for MRBs and DRBs is that it simplifies the implementation of the RAN. Without method 700D, each time the RAN is requested to configure logical channels (IDs) for an MRB for multiple UEs (e.g., a first UE), the RAN must check which logical channel ID values ​​are assigned to the multiple UEs.

[0200] Referring to FIG. 7E, scenario 700E is similar to scenario 700D, except that multicast and broadcast are described separately in scenario 700E. Method 700E begins at block 721, where the RAN reserves a first set of logical channel ID values ​​for at least one multicast MRB. At block 725, the RAN reserves a third set of logical channel ID values ​​for at least one broadcast MRB. At block 727, the RAN selects first logical channel ID values ​​for the multicast MRB from the first set. At block 728, the RAN transmits at least one first message, each including the first logical channel ID value, to at least one first UE (e.g., events 520, 540). At block 738, the RAN selects a third logical channel ID value for the broadcast MRB from the third set to configure a third logical channel (ID) associated with the broadcast MRB. At block 740, the RAN transmits at least one third message, each message including the third logical channel ID value, to at least one third UE (e.g., event 569). At block 742, the RAN transmits the data packet and a third MAC PDU including the third logical channel ID value via unicast to at least one third UE (e.g., event 579).

[0201] In some implementations, the at least one first UE may include the second UE. In other implementations, the at least one first UE does not include the second UE. In some implementations, the at least one third UE may include the second UE. In other implementations, the at least one third UE does not include the second UE. In some implementations, the at least one first UE and the at least one third UE may include the same UE and / or different UEs.

[0202] In some implementations, the third set includes at least one third logical channel ID value that is different from the at least one first logical channel ID value and the at least one second logical channel ID value. In some implementations, the at least one third logical channel ID value is greater than the at least one second logical channel ID value. For example, the third set includes values ​​greater than 63 and less than 309, and the second set includes integer values ​​greater than 4 and less than 64 or 33. In another example, the third set includes integer values ​​greater than 63 and less than 72, 80, 88, 96, 104, 112, 120, or 128, and the second set includes integer values ​​greater than 4 and less than 64 or 33. In yet another example, the third set includes values ​​greater than 244, 252, 260, 268, 276, 284, 292, or 300 and less than 309, and the second set includes integer values ​​greater than 4 and less than 64 or 33.

[0203] In other implementations, the first set, the second set, and the third set include different values ​​greater than 4 and less than a predetermined value N, where N is, for example, greater than 4 and less than 33. In such implementations, the RAN can divide the values ​​5, ..., the predetermined value into the first set, the second set, and the third set. For example, the first and third sets include values ​​X, ..., 32, where X is an integer greater than 6 and less than 33. In such a case, the second set includes values ​​5, ..., (X-1).

[0204] In some implementations, the RAN may generate a third logical channel ID field / IE to include a third logical channel ID value and include the third logical channel ID field / IE in the third message. In some implementations, the third and second logical channel ID fields / IEs are different fields / IEs. For example, the third logical channel ID field may be a logicalChannelIdentity-Ext(-r17), logicalChannelIdentityExt(-r17), eLogicalChannelIdentity(-r17), or extLogicalChannelIdentity(-r17) field, and the second logical channel ID field may be a logicalChannelIdentity field. In another example, the first logical channel ID IE can be a LogicalChannelIdentity-Ext(-r17), LogicalChannelIdentityExt(-r17), ELogicalChannelIdentity(-r17), or ExtLogicalChannelIdentity(-r17) IE, and the second logical channel ID field can be a LogicalChannelIdentity IE. In other implementations, the third and second logical channel ID fields / IEs are different instances of the same field / IE. For example, the field can be a logicalChannelIdentity, logicalChannelIdentity-Ext(-r17), logicalChannelIdentityExt(-r17), eLogicalChannelIdentity(-r17), or extLogicalChannelIdentity(-r17) field.In another example, the IE may be a LogicalChannelIdentity, LogicalChannelIdentity-Ext(-r17), LogicalChannelIdentityExt(-r17), ELogicalChannelIdentity(-r17), or ExtLogicalChannelIdentity(-r17) IE.

[0205] In some implementations, the RAN generates a (second) mapping value representing the first logical channel ID value in block 742. In such implementations, the RAN includes the mapping value in the third MAC DU instead of directly including the third logical channel ID value. In some implementations, the RAN can further include an indication in the third MAC PDU indicating the presence of the mapping value. This indication can be a specific logical channel ID value (e.g., 34). Example and implementation forms of the second mapping value are similar to the first mapping value described with respect to FIG. 7D.

[0206] Referring now to FIG. 8A, a RAN (eg, RAN 105, base station 104, base station 106, CU 172) can implement an example method 800A for managing security protection for an MBS.

[0207] In block 802, the RAN receives data packets associated with an MBS session (eg, an event or block 524, 544, 602) from a CN (eg, CN 110) via a DL tunnel.

[0208] In block 804, prior to transmitting a data packet to multiple UEs (e.g., UE 102A, UE 102B, UE 103), the RAN determines which security protection to apply to the data packet based on the DL tunnel's identification information (e.g., TEID, IP address) (e.g., events or blocks 525, 545, 603, 604, 605, 607). In some implementations, when the RAN determines that the DL tunnel's identification information indicates that the DL tunnel is a common DL tunnel, the RAN can apply null security protection, thereby effectively refraining from applying security protection to the data packet. In other implementations, when the RAN determines that the DL tunnel's identification information indicates that the DL tunnel is a common DL tunnel, the RAN can apply non-null security protection, such as common security protection, to the data packet. In yet other implementations, when the RAN determines that the DL tunnel's identification information indicates that the DL tunnel is a UE-specific DL tunnel, the RAN can apply non-null security protection, such as UE-specific security protection, to the data packet. In some cases, the UE-specific security protection may be null security protection if the RAN does not require security protection to be applied to the data packets.

[0209] In block 806, the RAN transmits data packets to multiple UEs using the security protection determined in block 804 (eg, events or blocks 526, 528, 546, 548, 608, 609, 612, 613).

[0210] Referring to Figure 8B, a RAN (e.g., RAN 105, base station 104, base station 106, DU 174) can implement an example method 800B for managing logical channels for carrying MBS data and non-MBS data. Method 800B is similar to method 700D. The examples and implementations described with respect to Figure 7D can also be applied to Figure 8B.

[0211] Method 800B begins at block 822, where the RAN reserves a first set of logical channel ID values ​​for at least one MRB. At block 824, the RAN reserves a second set of logical ID values ​​for at least one DRB. At block 826, the RAN determines to configure a logical channel. At block 828, the RAN determines whether the logical channel is associated with an MRB or an MBS session. When the RAN determines that the logical channel is associated with an MRB or an MBS session, flow proceeds to block 830. At block 830, the RAN selects a first logical channel ID value for the MRB from the first set. At block 832, the RAN transmits at least one first message, each including the first logical channel ID value, to at least one first UE (e.g., events 520, 540, 569). In block 834, the RAN transmits at least one first MAC PDU via multicast to the at least one first UE, each MAC PDU including the data packet and the first logical channel ID (eg, events 528, 548, 579).

[0212] Otherwise, when the UE determines in block 808 that the logical channel is not associated with an MRB or an MBS session (e.g., the logical channel is associated with an SRB, DRB, or PDU session), the flow proceeds to block 836. In block 836, the RAN selects a second logical channel ID value for the DRB from the second set. In block 838, the RAN transmits a second message including the second logical channel ID value to the second UE. In block 840, the RAN transmits a second MAC PDU including the data packet and the second logical channel ID value to the second UE via unicast.

[0213] Referring to FIG. 8C, method 800C is similar to methods 800A, 700D, and 700E. The examples and implementations described with respect to FIGS. 7D and 7E can also be applied to FIG. 8C. Method 800C begins at block 821, where the RAN reserves a first set of logical channel ID values ​​for at least one multicast MRB. Optionally, at block 824, the RAN may reserve a second set of logical ID values ​​for at least one DRB. At block 825, the RAN reserves a third set of logical ID values ​​for at least one broadcast MRB. At block 826, the RAN determines to configure a logical channel. At block 829, the RAN determines whether the logical channel is associated with a multicast MRB, a broadcast MRB, or a DRB. When the RAN determines that the logical channel is associated with a multicast MRB, flow proceeds to blocks 831, 832, and 834. In block 831, the RAN selects a first logical channel ID value for the multicast MRB from the first set. In block 832, the RAN transmits at least one first message, each including the first logical channel ID value, to at least one first UE (e.g., events 520, 540). In block 834, the RAN transmits at least one first MAC PDU, each including a data packet and the first logical channel ID, via multicast to the at least one first UE (e.g., events 528, 548).

[0214] In block 829, when the UE determines that the logical channel is associated with a DRB, the flow proceeds to blocks 836, 838, and 840. In block 829, when the UE determines that the logical channel is associated with a broadcast MRB, the flow proceeds to blocks 842, 844, and 846. In block 842, the RAN selects a third logical channel ID value for the broadcast MRB from the third set. In block 844, the RAN transmits at least one third message, each including the third logical channel ID value, to at least one third UE. In block 846, the RAN transmits at least one third MAC PDU, each including a data packet and the third logical channel ID value, to the at least one third UE via broadcast.

[0215] Referring to FIG. 9A, a UE (eg, UE 102A, UE 102B, UE 103) may implement an example method 900A for managing security protection for an MBS.

[0216] In block 902, the UE receives a configuration from a RAN (eg, RAN 105, base station 104, base station 106, CU 172) to establish a logical channel with the RAN (eg, event 520).

[0217] In block 904, the UE receives data packets associated with the MBS session from the RAN over a logical channel (eg, events or blocks 528, 548, 702).

[0218] In block 906, the UE determines which security protection to apply to the data packets based on the configuration (e.g., events or blocks 529, 549, 703, 704, 705). In some implementations, when the UE determines that the configuration includes logical channel identification information indicating that the logical channel is an MTCH, the UE can apply null security protection, thereby effectively refraining from applying security protection to the data packets. In other implementations, when the UE determines that the configuration includes logical channel identification information indicating that the logical channel is an MTCH, the UE can apply non-null security protection, such as common security protection, to the data packets. In yet other implementations, when the UE determines that the configuration includes logical channel identification information indicating that the logical channel is not an MTCH (e.g., a DTCH or DCCH instead), the UE can apply non-null security protection, such as UE-specific security protection, to the data packets. In some cases, the UE-specific security protection can be null security protection if the RAN does not require security protection to be applied to the data packets.

[0219] In block 908, the UE applies the security protection determined in block 906 to the data packet (eg, event or block 529, 549, 706, 708).

[0220] Referring to FIG. 9B, a UE (eg, UE 102A, UE 102B, UE 103) may implement an example method 900B for managing security protection for an MBS.

[0221] In block 914, the UE receives data packets associated with the MBS session from the RAN over a logical channel (e.g., events or blocks 528, 548, 579, 620). In some implementations, the UE receives a configuration from the RAN to be used to receive the data packets (e.g., events or blocks 520, 540, 567, 569).

[0222] In block 916, the UE selects a first security check scheme from a plurality of security check schemes to apply to the data packet based on the configuration in which the data packet was received from the RAN 914 (e.g., events or blocks 529, 549, 624A-624J). In some implementations, when the UE determines that the configuration includes logical channel identification information indicating that the logical channel is an MTCH, the UE can select a security check scheme (e.g., the first security check scheme) that includes null security protection, thereby effectively refraining from applying security protection to the data packet. In other implementations, when the UE determines that the configuration includes logical channel identification information indicating that the logical channel is an MTCH, the UE can select a security check scheme (e.g., the first security check scheme) that includes non-null security protection, such as common security protection, to the data packet. In yet another implementation, when the UE determines that the configuration includes logical channel identification information indicating that the logical channel is not an MTCH (e.g., a DTCH or DCCH instead), the UE may select a security check scheme (e.g., a first security check scheme) that includes non-null security protection, such as UE-specific security protection, for the data packets. In some cases, the UE-specific security protection may be null security protection if the RAN does not require security protection to be applied to the data packets.

[0223] In block 918, the UE applies the first security check scheme selected in block 916 to the data packet (eg, event or block 529, 549, 626, 628).

[0224] The following additional considerations apply to the preceding discussion.

[0225] In some implementations, "message" is used, but this can be replaced with "information element (IE)". In some implementations, "IE" is used, but this can be replaced with "field". In some implementations, "configuration" can be replaced with "some configuration" or "configuration parameter". In some implementations, "MBS" can be replaced with "multicast" or "broadcast".

[0226] A user device (e.g., UE 102A, 102B, UE 103) in which the techniques of this disclosure may be implemented may be any suitable device capable of wireless communication, such as a smartphone, a tablet computer, a laptop computer, a mobile 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. Furthermore, a user device may, in some cases, be integrated into an electronic system such as a vehicle head unit or an advanced driver assistance system (ADAS). Still further, a user device may operate as an Internet of Things (IoT) device or a mobile / internet device (MID). Depending on the type, a user device may include one or more general-purpose processors, computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

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

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

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

[0230] 100 Wireless Communication System 102A, 102B, 102C, 103 User Equipment (UE) 104, 106 base station 105 Radio Access Network (RAN) 110 Core Network (CN) 111 Evolved Packet Core (EPC) 112 Serving Gateway (SGW) 114 Mobility Management Entity (MME) 116 Packet Data Network Gateway (PGW) 124 cells 126 cells 130 Processing Hardware 130 base station 132 MBS Controller 134 Non-MBS Controller 140 Processing Hardware 142 MBS Controller 144 Non-MBS Controller 150 Processing Hardware 152 MBS Controller 154 Non-MBS Controller 160 5th Generation Core (5GC) 162 User Plane Function (UPF) 164 Access and Mobility Management (AMF) 166 Session Management Facility (SMF) 172 Central Unit (CU) 172A CU-CP 172B CU-UP 174 Distributed Unit (DU) 174A / 174B DU 200 Protocol Stack 202 PHY sublayer 202A PHY sublayer 202B NR PHY 204 MAC sublayer 204A EUTRA MAC sublayer 204B NR MAC sublayer 206 RLC sublayer 206A EUTRA RLC sublayer 206B NR RLC sublayer 208 EUTRA PDCP sublayer 210 NR PDCP sublayer 212 SDAP Sublayer 214 RRC 250 Wireless Protocol Stack 302A MBS Session 302B MBS Session 304A PDU Session 312A and 312B Tunnels 314A MRB 314A-1, 314A-2, ..., 314A-N Radio Bearers 314B MRB 314B-1, 314B-2,..., 314B-N MRB 316 Flow 316A, 316B, ..., 316L QoS Flows 322A UE-specific DL tunnel and / or UE-specific DL tunnel 324A DRB 324A-1, 324A-2,..., 324-N DRB 402 MRB 402A MRB 402B MRB 404 DRB 404A DRB 404B DRB 412A DL Tunnel 412B DL ​​Tunnel 413A UL Tunnel 413B UL Tunnel 422A DL Logical Channel 422B DL ​​logical channel 423A UL Logical Channels 423B UL logical channels 432 DL Tunnel 432A UE-specific DL tunnel 432B UE-specific DL tunnel 433A UE-specific UL tunnel 433B UE-specific UL tunnel 442A DL Logical Channel 442B DL ​​logical channel 443A UL Logical Channels 443B UL logical channel 500A Scenario 500B Scenario 500C Scenario 500D Scenario 502 Events 504 Events 506 Events 508 Events 510 Events 512 Second CN-BS Message 512, 514, 516, 518, 519, 520, 522, 523, 532 events 524, 544 events 569 MBS Configuration 586 MBS Session Resource Setup Procedure 588 MBS Session Resource Setup Procedure 600A Scenario 600B Scenario 600C Scenario 600D Scenario 600E Scenario 600F Scenario 600G Scenario 600H Scenario 600I Scenario 600J Scenario 600K Scenario 600L scenario 600M Scenario 600N Scenario 600P scenario 600Q Scenario 600R Scenario 600S Scenario 700A Scenario 700B Scenario 700C Scenario 700D method 700E Scenario 800A Method 800B method 800C method 900A Method 900B method

Claims

1. 1. A method in a Radio Access Network (RAN) for managing security protection for multicast and / or broadcast services (MBS), performed by processing hardware, comprising: receiving, by the RAN, a data packet from a core network (CN) via a downlink (DL) data tunnel; Prior to transmitting the data packet to a plurality of UEs, determining, by the RAN, based on the identification information of the DL data tunnel, whether the data packet should be transmitted to the plurality of UEs by using multicast or unicast; When the data packet is to be transmitted to the plurality of UEs by using multicast, transmitting, by the RAN, the data packet to the plurality of UEs using a first security protection of a plurality of security protections; and when the data packet is to be transmitted by using unicast, transmitting, by the RAN, the data packet to one UE of the plurality of UEs using a second security protection of the plurality of security protections.

2. The identification information indicates that the DL data tunnel is common to the plurality of UEs or that the DL data tunnel is specific to only one UE among the plurality of UEs; The method of claim 1 , wherein the first security protection is a null security protection or a non-null security protection.

3. The method described in claim 2, wherein the non-null security protection is a common security protection.

4. determining that the data packet should be transmitted to the plurality of UEs by using multicast; determining that the data packets should be transmitted to the plurality of UEs via MBS Radio Bearers (MRBs); or The method according to claim 1 , further comprising at least one of the steps of: determining that the data packet is associated with an MBS session.

5. determining that the data packet should be transmitted to the one UE of the plurality of UEs using unicast; or The method according to any one of claims 1 to 3, further comprising the step of determining that the data packet should be transmitted to the one UE of the plurality of UEs via a Data Radio Bearer (DRB).

6. the step of transmitting the data packet to the plurality of UEs or to the one UE of the plurality of UEs includes a step of transmitting, by a first node of the RAN, the data packet to the plurality of UEs or to the one UE of the plurality of UEs via a second node of the RAN; the first node is one of a first central unit (CU) in a first distributed base station included in the RAN or a first base station; 4. The method according to claim 1, wherein the second node is one of a distributed unit (DU) in the distributed base station, a second CU in a second distributed base station, or a second base station.

7. 4. A RAN including processing hardware and configured to perform the method of any one of claims 1 to 3.

8. 1. A method in a user equipment (UE) for managing security checks for multicast and / or broadcast services (MBS), performed by processing hardware, comprising: receiving, by the UE, a data packet from a Radio Access Network (RAN), wherein the data packet is received by the RAN from a Core Network (CN) via a Downlink (DL) data tunnel; selecting, by the UE, a first security check scheme to be applied to the data packet from a plurality of security check schemes when the data packet is received from the RAN via multicast; selecting, by the UE, a second security check scheme to be applied to the data packet from the plurality of security check schemes when the data packet is received from the RAN via unicast; processing the data packet in accordance with a selected security checking scheme; The method, wherein whether the data packet should be received by the UE via multicast or unicast is determined based on the identification information of the DL data tunnel.

9. The step of selecting the first security check scheme comprises: selecting a null security scheme, such that the UE refrains from applying any security keys and thereby implements a null security check; or 10. The method of claim 8, comprising selecting a non-null security scheme such that the UE applies a security key to the received data packet.

10. The method of claim 1, wherein the security key comprises a common security key associated with a multicast and / or broadcast service (MBS) or a UE-specific security key assigned to the UE; or 10. The method of claim 9, wherein the security key is associated with at least one of a decryption procedure or an integrity check procedure.

11. receiving, by the UE, from the RAN, a configuration for establishing a logical channel with the RAN; and determining whether the data packet is received from the RAN via multicast or unicast based on the configuration.

12. The configuration includes a Group Radio Network Temporary Identifier (G-RNTI), identification information indicating that the logical channel is a Multicast Traffic Channel (MTCH), or identification information indicating that the logical channel is a Dedicated Traffic Channel (DTCH) or a Dedicated Control Channel (DCCH), The method of claim 11 , wherein the first security check scheme comprises a null security protection or a non-null security protection.

13. The method of claim 12, wherein the non-null security protection is a common security protection.

14. 13. The method of claim 12, wherein the configuration includes identification information indicating that the logical channel is the DTCH or the DCCH, and wherein selecting the first security check scheme based on the configuration includes selecting the first security check scheme based on the identification information.

15. 12. The method of claim 11, wherein determining whether the data packet is received from the RAN via multicast or unicast based on the configuration comprises determining that the data packet is transmitted from the RAN using unicast.

16. receiving the data packet from the RAN includes receiving the data packet using a Cell Radio Network Temporary Identifier (C-RNTI) associated with the UE; The method of claim 11 , wherein the second security scheme comprises null security protection or non-null security protection.

17. The method described in claim 16, wherein the non-null security protection is UE-specific security protection.

18. 18. A UE including processing hardware and configured to perform the method of any one of claims 8 to 17.

Images