Managing multicast discontinuous reception configuration

Abstract

A distributed unit (DU) of a distributed base station operating in a radio access network (RAN) may implement a method for managing discontinuous reception (DRX) of multicast and broadcast service (MBS) sessions. The method comprises: (i) receiving, by processing hardware, information related to configuring DRX for the MBS session from a CU of the distributed base station; (ii) generating, by the processing hardware, a DRX configuration for a user equipment (UE) participating in the MBS session based at least on the information relating to configuring DRX; and (iii) transmitting, by the processing hardware, the DRX configuration to the UE.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to and the benefit of the filing date of provisional U.S. patent application No. 63 / 359,824, entitled “MANAGING DISCONTINUOUS RECEPTION CONFIGURATION,” filed on July 9, 2022. The entire contents of the provisional application are hereby expressly incorporated herein by reference. Technical Field

[0003] The present disclosure relates to wireless communications and, more particularly, to implementing one or more multicast and / or broadcast services (MBS). Background Art

[0004] The background description provided herein is for the purpose of generally presenting the context of the present disclosure. The work of the presently named inventors (to the extent that it is described in this background section) and aspects of the specification that otherwise may not be considered prior art at the time of filing are neither explicitly nor implicitly admitted to be prior art to the present disclosure.

[0005] Base stations operating according to the fifth generation (5G) new radio (NR) requirements support significantly larger bandwidths than fourth generation (4G) base stations. Therefore, the third generation partnership project (3GPP) has proposed that for release 15, the user equipment unit (UE) supports 100 MHz bandwidth in frequency range 1 (FR1) and 400 MHz bandwidth in frequency range 2 (FR2). The 5G NR system implements resource-efficient delivery of multicast / broadcast services (MBS). For broadcast communication services, the same service and the same specific content data are provided to all UEs in a geographic area at the same time (i.e., all UEs in the broadcast service area are authorized to receive data). The base station delivers broadcast communication services to the UE using a broadcast session. The UE can receive broadcast communication services in the RRC_IDLE, RRC_INACTIVE, and RRC_CONNECTED states.

[0006] For multicast communication services, the same service and the same specific content data are provided simultaneously to a set of dedicated UEs (i.e., not all UEs in the multicast service area are authorized to receive data). The base station delivers the multicast communication service to the UE using a multicast session. 5G NR provides point-to-point (PTP) and point-to-multipoint (PTM) delivery methods for the transmission of MBS packet streams over the radio interface. In PTP communication, the RAN node sends different copies of each MBS data packet to different UEs over the radio interface. On the other hand, in PTM communication, the RAN node sends a single copy of each MBS data packet to multiple UEs over the radio interface according to a discontinuous reception (DRX) cycle.

[0007] DRX is a feature of IoT or MTC devices for reducing power consumption. Using the DRX mechanism, a user device can enter a sleep mode for a specific period (e.g., an off-duration period) and then wake up to monitor DL ​​signals from a base station after the off-duration period (e.g., an on-duration period). The DRX cycle defines the time interval between two consecutive periods when the UE wakes up. However, in some scenarios, it is unclear how the base station should configure DRX so that one or more UEs receive MBS data via multicast communication. Summary of the invention

[0008] The DU manages discontinuous reception (DRX) of a multicast and broadcast service (MBS) session. The DU receives information related to configuring DRX from the CU, which may include the DRX cycle length and other such DRX configuration parameters. The DU then uses the received information related to configuring DRX to generate a DRX configuration for the UE participating in the MBS session. Depending on the implementation, the DU may generate a multicast DRX configuration and / or a unicast DRX configuration based on the received information corresponding to configuring DRX. Therefore, in some implementations, the DU generates a unicast DRX configuration whose DRX cycle is consistent with the DRX cycle of the multicast DRX configuration. In further implementations, the DU generates a multicast DRX configuration and / or a unicast DRX configuration based on additional factors such as whether the UE is configured with an MRB or a DRB and whether the UE has been configured with a multicast DRX configuration.

[0009] The CU similarly manages DRX for MBS sessions. Specifically, the CU generates information corresponding to configuring DRX using information such as QoS flow configuration for use by the DU. In various implementations, the CU receives the QoS flow configuration from the CN as part of an MBS activation command, receives the QoS flow configuration from the CN as part of an MBS update or message, or has pre-configured the QoS flow configuration at the CU. In some implementations, the CU may generate information corresponding to configuring DRX to include information such as the DRX cycle length, and send the information to the DU so that the DU generates a multicast and / or unicast DRX configuration.

[0010] An example embodiment of these techniques is a method for managing DRX for an MBS session, the method being implemented in a DU of a distributed base station operating in a RAN. The method includes: receiving, by processing hardware, information related to configuring DRX for an MBS session from a CU of the distributed base station; generating, by processing hardware, a DRX configuration for a UE participating in the MBS session based at least on the information related to configuring DRX; and sending, by processing hardware, the DRX configuration to the UE.

[0011] Another example embodiment of these techniques is a method for managing DRX for an MBS session, the method being implemented in a CU of a distributed base station operating in a RAN. The method includes: receiving, by processing hardware, an indication of activating an MBS session from a CN; determining, by processing hardware, information related to configuring DRX for the MBS session; and sending, by processing hardware, information related to configuring DRX to a DU of the RAN. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1A is a block diagram of an example system in which the disclosed techniques for managing DRX for MBS sessions may be implemented;

[0013] Figure 1B The centralized unit (CU) and the distributed unit (DU) can be Figure 1A A block diagram of an example base station operating in a system of FIG.

[0014] Figure 2A is a block diagram of an example protocol stack, Figure 1A The UE can use the protocol stack to Figure 1A Communicate with the base station;

[0015] Figure 2B is a block diagram of an example protocol stack, Figure 1A The UE can communicate with the DU and CU of the base station according to the protocol stack;

[0016] Figure 3 is a block diagram of an example tunnel architecture for an MBS session and a PDU session;

[0017] Figure 4 is a block diagram of an example tunnel architecture for MRB and DRB;

[0018] Figure 5A Among them Figure 1A and / or Figure 1B A message transfer diagram of an example scenario in which a distributed base station manages transmission of a DRX cycle configuration of an MBS session to a UE within the distributed base station;

[0019] Figure 5B is with Figure 5A A message passing diagram for an example scenario similar to the scenario of , but in which the CU is pre-configured with information corresponding to configuring DRX;

[0020] Figure 5C is with Figure 5A A message passing diagram for an example scenario similar to the scenario of , but where the CU sends a request for information corresponding to configuring DRX and subsequently receives the information;

[0021] Figure 5D is with Figure 5A Message passing diagram for an example scenario similar to the scenario of , but wherein the CU receives an update from the CN including information corresponding to configuring DRX;

[0022] Figure 5E is with Figure 5A A message passing diagram of an example scenario similar to the scenario of , but in which the CU receives information corresponding to configuring DRX from the CN before performing the MBS session configuration procedure;

[0023] Fig. 5F is with Figure 5A A message passing diagram for an example scenario similar to the scenario of , but where a distributed base station manages multiple MBS sessions for multiple UEs;

[0024] Fig. 6A is a timing diagram of an example scenario, where the OnDuration is shortened by a DRX command, and the OnDuration of a unicast DRX cycle and the OnDuration of a multicast DRX cycle of a UE in an MBS session do not overlap;

[0025] Figure 6B is with Fig. 6A A timing diagram of an example scenario similar to the scenario of , but in which the on-duration of the unicast DRX cycle and the on-duration of the multicast DRX cycle overlap;

[0026] Figure 7 is a flow chart of an example method implemented in a DU for generating and sending a multicast resource configuration and a multicast DRX configuration for an MBS session;

[0027] Figure 8is a flow chart of an example method implemented in a CU for performing a multicast context procedure with a DU to obtain a multicast DRX configuration;

[0028] Fig. 9 is a flow chart of an example method implemented in a DU for determining how to generate a unicast DRX configuration based on whether the UE is configured with an MBS DRX cycle;

[0029] Fig.10 is a flow chart of an example method implemented in a DU for generating a multicast DRX configuration and a unicast DRX configuration and sending the multicast DRX configuration and the unicast DRX configuration to a first UE and optionally a second UE;

[0030] Fig.11A is a flow chart of an example method implemented in a DU for determining whether to generate and send a multicast DRX configuration based on whether a UE is configured with an MRB;

[0031] Fig. 11B is implemented in DU and Fig.11A A flowchart of an example method similar to the method of , but wherein the determination is based on whether the UE is configured with an MRB or a DRB;

[0032] Fig. 12A is a flow chart of an example method implemented in a DU for receiving a multicast DRX cycle configuration and a unicast DRX cycle configuration and generating a multicast DRX configuration and a unicast DRX configuration based on the received multicast and unicast DRX cycle configurations, respectively;

[0033] Fig. 12B is implemented in DU and Fig. 12A A flowchart of an example method similar to the method of , but wherein the multicast and unicast DRX configurations are based on the same DRX cycle configuration;

[0034] Fig.13A is a flow chart of an example method implemented in a CU for communicating with a DU to send a multicast DRX cycle configuration and a unicast DRX cycle configuration and to receive a multicast DRX configuration and a unicast DRX configuration;

[0035] Fig. 13B is implemented in CU with Fig.13A A flowchart of an example method similar to the method of , but wherein the CU sends a single DRX cycle configuration to the DU for generating multicast and unicast DRX configurations;

[0036] Fig.14 is a flow chart of an example method implemented in a DU for managing DRX for an MBS; and

[0037] Fig.15is a flow chart of an example method implemented in a CU for managing DRX for an MBS. DETAILED DESCRIPTION

[0038] Figure 1A An example wireless communication system 100 is depicted that can implement the disclosed techniques for managing the transmission and reception of multicast and / or broadcast service (MBS) information. The wireless communication system 100 includes user equipment (UE) 102A, 102B, and 103 and 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 include more than Figure 1A More or fewer UEs and / or more or fewer base stations are shown. For example, base stations 104, 106 can be one or more base stations of any suitable type, such as an evolved node B (eNB), a next generation eNB (ng-eNB), or a 5G Node B (gNB).

[0039] Base station 104 supports cell 124, and base station 106 supports cell 126. Cell 124 partially overlaps with cell 126, so that UE 102A can be within the range of communicating with base station 104 while being within the range of communicating with base station 106 (or within the range of detecting or measuring a signal from base station 106). For example, the overlap may make it possible for UE 102A to switch between cells (e.g., from cell 124 to cell 126) or between base stations (e.g., from base station 104 to base station 106) before UE 102A experiences a radio link failure. In addition, the overlap allows various dual connectivity (DC) scenarios. For example, UE 102A may communicate with base station 104 (operating as a master node (MN)) and base station 106 (operating as a secondary node (SN)) in DC.

[0040] In non-MBS (unicast) operation, the UE 102A may use radio bearers (e.g., DRBs or SRBs) that terminate at different times at the MN (e.g., base station 104) or SN (e.g., base station 106). For example, after handover to the base station 106 or a SN change to the base station, the UE 102A may use radio bearers (e.g., DRBs or SRBs) that terminate at the base station 106. When communicating on the radio bearers in the uplink (from the UE 102A to the base station) and / or downlink (from the base station to the UE 102A) direction, the UE 102A may apply one or more security keys. In non-MBS operation, the UE 102A sends data to the base station via the radio bearers on the uplink (UL) bandwidth part (BWP) of the cell (i.e., within), and / or receives data from the base station via the radio bearers on the downlink (DL) BWP of the cell. The UE 102A may receive paging, system information, public warning messages, or random access responses on the DL BWP.

[0041] In MBS operation, the UE 102A may use an MBS radio bearer (MRB) that terminates at a MN (e.g., base station 104) or a SN (e.g., base station 106) at different times. For example, after a handover or SN change, the UE 102A may use an MRB that terminates at a base station 106 operating as a MN or a SN. In some scenarios, the base station (e.g., MN or SN) may send 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 send MBS data to the UE 102A via the MRB over multicast radio resources (i.e., radio resources shared by the UE 102A and one or more other UEs) or a DL BWP of a cell from the base station. The DL BWP may be an initial DL BWP, a dedicated DL BWP, or an MBS DL BWP (i.e., a DL BWP specific to MBS or not used for unicast).

[0042] The base station 104 includes processing hardware 130, which may include one or more general-purpose processors (e.g., central processing units (CPUs)) and computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and / or special-purpose processing units. Figure 1AIn an example implementation of the present invention, the processing hardware 130 includes an MBS controller 132 configured to manage or control the transmission of MBS information received from the CN 110 or an edge server. For example, the MBS controller 132 can be configured to support radio resource control (RRC) configurations, procedures, and messaging associated with MBS processes, and / or other operations associated with those configurations and / or procedures (including HARQ processes), as discussed below. In some implementations, the processing hardware 130 also includes 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 a MN or SN during non-MBS operation.

[0043] The base station 106 includes processing hardware 140, which in some implementations includes one or more general-purpose processors (e.g., CPUs) and computer-readable memory storing machine-readable instructions executable on the general-purpose processors, and / or special-purpose processing units. Figure 1A In an example implementation, processing hardware 140 includes an MBS controller 142 and a non-MBS controller 144, which may be similar to controllers 132 and 134 of base station 130, respectively. Figure 1A Not shown, but in further implementations, RAN 105 includes additional base stations having processing hardware similar to processing hardware 130 of base station 104 and / or processing hardware 140 of base station 106.

[0044] The UE 102A includes processing hardware 150, which in some implementations includes one or more general-purpose processors (e.g., CPUs) and computer-readable memory storing machine-readable instructions executable on the general-purpose processors, and / or special-purpose processing units. Figure 1A In an example implementation, the processing hardware 150 includes an MBS controller 152 that is configured to manage or control the reception of MBS information. For example, the UE MBS controller 152 may be configured to support RRC configurations, procedures, and messaging associated with MBS processes, and / or other operations associated with those configurations and / or procedures (including HARQ processes), as discussed below. In a further implementation, the processing hardware 150 also includes a non-MBS controller 154 that is configured to manage or control one or more RRC configurations and / or RRC procedures in accordance with any of the implementations discussed below when the UE 102A is communicating with the MN and / or SN during non-MBS operation. Although Figure 1A Not shown, but in further implementations, UEs 102B and 103 include processing hardware similar to processing hardware 150 of UE 102A.

[0045] In some implementations, CN 110 is an evolved packet core (EPC) 111 or a fifth generation core (5GC) 160, both of which are Figure 1A 160. Depending on the implementation, the base station 104 is an eNB supporting an S1 interface for communicating with the EPC 111, an ng-eNB supporting an NG interface for communicating with the 5GC 160, or a gNB supporting an NR radio interface as well as an NG interface for communicating with the 5GC 160. In other implementations, the base station 106 is an EUTRA-NR DC (EN-DC) gNB (en-gNB) with an S1 interface to the EPC 111, an en-gNB not connected to the EPC 111, a gNB supporting an NR radio interface and an NG interface to the 5GC 160, or an ng-eNB supporting an EUTRA radio interface and an NG interface to the 5GC 160. In some implementations, in order to exchange messages directly with each other during the scenarios discussed below, the base stations 104 and 106 support an X2 or Xn interface.

[0046] Among other components, the EPC 111 may also 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 deliver user plane packets associated with audio 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 a connection from a UE (e.g., UE 102A or 102B) to one or more external packet data networks (e.g., an Internet network and / or an Internet Protocol (IP) Multimedia Subsystem (IMS) network). The 5GC 160 includes a user plane function (UPF) 162 and an access and mobility management (AMF) 164, and / or a session management function (SMF) 166. UPF 162 is generally configured to pass user plane packets associated with audio calls, video calls, Internet traffic, etc., AMF 164 is generally configured to manage authentication, registration, paging and other related functions, and SMF 166 is generally configured to manage PDU sessions.

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

[0048] Generally, in some implementations, the wireless communication system 100 includes any suitable number of base stations supporting NR cells and / or EUTRA cells. More specifically, in further implementations, the EPC 111 or the 5GC 160 is connected to any suitable number of base stations supporting NR cells and / or EUTRA cells. For example, although the examples below specifically relate to specific CN types (EPC, 5GC) and RAT types (5G NR and EUTRA), in general, the techniques of the present disclosure may also be applicable to other suitable radio access technologies and / or core network technologies, such as sixth generation (6G) radio access and / or 6G core network or 5G NR-6G DC.

[0049] Figure 1B An example distributed implementation of any one or more of base stations 104 and 106 is depicted. In this implementation, base station 104 or 106 includes a central unit (CU) 172 and one or more distributed units (DUs) 174. CU 172 includes processing hardware, such as one or more general-purpose processors (e.g., CPUs) and computer-readable memory storing machine-readable instructions executable on the general-purpose processors, and / or special-purpose processing units. For example, CU 172 may include Figure 1A Some or all of the processing hardware 130 or 140.

[0050] Each of the DUs 174 also includes processing hardware including one or more general purpose processors (e.g., CPUs) and computer readable memory storing machine readable instructions executable on the one or more general purpose processors, and / or a dedicated processing unit. For example, the processing hardware may include: a media access control (MAC) controller configured to manage or control one or more MAC operations or procedures (e.g., random access procedures); and a radio link control (RLC) controller configured to manage or control one or more RLC operations or procedures when a base station (e.g., base station 104) operates as a MN or SN. In a further implementation, the processing hardware also includes a physical (PHY) layer controller configured to manage or control one or more PHY layer operations or procedures.

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

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

[0053] Figure 2AAn example protocol stack 200 is shown in a simplified manner, according to which a UE (e.g., UE 102A, 102B, or 103) communicates with an eNB / ng-eNB or gNB (e.g., one or more of base stations 104, 106). In the example 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 in turn 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 in turn provides RLC channels to the NR PDCP sublayer 210. In some implementations, the UE 102A supports both EUTRA and NR stacks, such as Figure 2A As shown, switching between EUTRA and NR base stations is supported and / or DC on EUTRA and NR interfaces is supported. Figure 2A As shown, in some implementations, the UE 102A supports layering of NR PDCP 210 on EUTRA RLC 206A, and layering of SDAP sublayer 212 on NR PDCP sublayer 210. Sublayers are also referred to herein simply as "layers."

[0054] The EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 receive packets called service data units (SDUs) (e.g., from an IP layer layered directly or indirectly on the PDCP layer 208 or 210) and output packets called protocol data units (PDUs) (e.g., to the RLC layer 206A or 206B). Except where the difference between SDUs and PDUs is relevant, for simplicity, the present disclosure refers to both SDUs and PDUs as "packets." Depending on the implementation, the packets may be MBS packets or non-MBS packets. In some implementations, for example, the MBS packets include application content for MBS services (e.g., IPv4 / IPv6 multicast delivery, IPTV, wireless software delivery, group communication, IoT applications, V2X applications, and / or emergency messages related to public safety). As another example, the MBS packets include application control information for the MBS services.

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

[0056] In some implementations, a base station (e.g., base station 104, 106) broadcasts MBS data packets via one or more MBS radio bearers (MRBs), and UE 102A, 102B, or 103 in turn receives the MBS data packets via the MRBs. The base station may include the configuration of the MRBs in the multicast configuration parameters (which may also be referred to as MBS configuration parameters) described below. In some implementations, the base station broadcasts the MBS data packets via the RLC sublayer 206, the MAC sublayer 204, and the PHY sublayer 202, and correspondingly, the UE 102A receives the MBS data packets using the PHY sublayer 202, the MAC sublayer 204, and the RLC sublayer 206. In some such implementations, the base station and the UE 102A, 102B, or 103 do not use the PDCP sublayer 208 and the SDAP sublayer 212 to transmit the MBS data packets. In other implementations, the base station sends the 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 102A, 102B, or 103 receives the MBS data packets using the PHY sublayer 202, the MAC sublayer 204, the RLC sublayer 206, and the PDCP sublayer 208. In some such implementations, the base station and the UE 102A, 102B, or 103 do not use the SDAP sublayer 212 to transmit the MBS data packets. In other implementations, the base station sends MBS data packets via the SDAP sublayer 212, the PDCP sublayer 208, the RLC sublayer 206, the MAC sublayer 204, and the PHY sublayer 202, and correspondingly, the UE 102A, 102B, or 103 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.

[0057] Figure 2B An example protocol stack 250 is shown in a simplified manner that is used by the UE 102A, 102B, or 103 to communicate with a DU (eg, DU 174) and a CU (eg, CU 172). Figure 2A The radio protocol stack 200 is functionally split, as represented by Figure 2B204B, NR MAC 204B, and NR PHY 202B) are delegated to the DU. To support the connection to the 5GC, the NR PDCP 210 provides DRBs to the SDAP 212 and SRBs to the RRC 214.

[0058] refer to Figure 3 In some implementations, the MBS session 302A includes a tunnel 312A with endpoints at the CN 110 and the base station 104 / 106. For example, the MBS session 302A corresponds to a session ID, such as a temporary mobile group identifier (TMGI). For example, the MBS data includes IP packets, TCP / IP packets, UDP / IP packets, real-time transport protocol (RTP) / UDP / IP packets, or RTP / TCP / IP packets.

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

[0060] In some implementations, tunnel 312A operates at a transport layer or sublayer, for example, on a user datagram protocol (UDP) protocol layered on an Internet protocol (IP). As a more specific example, tunnel 312A is associated with a general packet radio system (GPRS) tunnel protocol (GTP). In a further implementation, for example, tunnel 312A corresponds to a specific IP address (e.g., an IP address of a base station 104 / 106) and a specific tunnel endpoint identifier (TEID) (e.g., assigned by base station 104 / 106). More generally, tunnel 312A may have any suitable transport layer configuration. In some implementations, CN 110 specifies an IP address and a TEID address in a header of a tunnel packet including an MBS data packet, and sends the tunnel packet downstream to base station 104 / 106 via tunnel 312A (i.e., the header may include an IP address and / or a TEID). For example, the header may include an IP header and a GTP header including an IP address and a TEID, respectively. In such examples, the base stations 104 / 106 may then use the IP address and / or TEID accordingly to identify data packets propagating via the tunnel 312A.

[0061] like Figure 3 As shown, the base station 104 / 106 maps the traffic in the tunnel 312A to N radio bearers 314A-1, 314A-2, ..., 314A-N, which are configured as MBS radio bearers or MRBs depending on the implementation, where N≥1. In some implementations, each MRB may correspond to a corresponding logical channel. As discussed 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 NRRLC sublayer. For example, each of the MRBs 314A may correspond to a corresponding MBS traffic channel (MTCH). In a further implementation, the base station 104 / 106 and the CN 110 also maintain another MBS session 302B, which similarly includes a tunnel 312B corresponding to the MRBs 314B-1, 314B-2, ..., 314B-N, where N≥1. In some such implementations, each of the MRBs 314B corresponds to a respective logical channel.

[0062] In some implementations, for each of tunnels 312A, 312B, etc., the MBS traffic includes one or more quality of service (QoS) flows. For example, the MBS traffic on tunnel 312B includes a set of flows 316, which includes QoS flows 316A, 316B, ..., 316L. In addition, depending on the implementation, the logical channels of the MRB support a single QoS flow or multiple QoS flows. Figure 3In the example configuration of , 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.

[0063] In various scenarios, CN 110 assigns different types of MBS services to different QoS flows. In some such implementations, for example, flows with relatively higher QoS values ​​correspond to audio packets, while flows with relatively lower QoS values ​​correspond to video packets. As another example, flows with relatively higher QoS values ​​correspond to I-frames or complete images used in video compression, while flows with relatively lower QoS values ​​correspond to P-frames or predicted pictures that only include changes to I-frames.

[0064] Continue to refer Figure 3 In some implementations, the base station 104 / 106 and the CN 110 maintain one or more PDU sessions to support unicast traffic between the CN 110 and a specific UE. Depending on the implementation, the PDU session 304A includes a UE-specific DL tunnel and / or a UE-specific UL tunnel 322A corresponding to one or more DRBs 324A (such as DRBs 324A-1, 324A-2, ..., 324A-N). Each of the DRBs 324A may correspond to a corresponding logical channel such as a dedicated traffic channel (DTCH).

[0065] Reference now Figure 4 In some implementations, when the base station 104 / 106 is a distributed base station, the CU 172 and the DU 174A / 174B establish a tunnel for downlink data and / or uplink data associated with the MRB or DRB. For example, the MRB 314A-1 discussed above may be implemented as an MRB 402A that connects the CU 172 to multiple UEs, such as UEs 102A and 102B. In a further implementation, the MRB 402A includes a DL tunnel 412A that connects the CU 172 and the DU 174A / 174B and a DL logical channel 422A corresponding to the DL tunnel 412A. In a specific implementation, the DU 174A / 174B maps the downlink traffic received via the DL tunnel 412A to the DL logical channel 422A, which is, for example, an MTCH or a DTCH. In some implementations, DL tunnel 412A is a common DL tunnel via which CU 172 sends MBS data packets to multiple UEs. In other implementations, DL tunnel 412A is a UE-specific DL tunnel via which CU 172 sends MBS data packets to a specific UE.

[0066] In a further implementation, the MRB 402A further 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 is, for example, a DTCH. In some implementations, the DU 174A / 174B maps the uplink traffic received via the UL logical channel 423A to the UL tunnel 413A.

[0067] Depending on the implementation, tunnels 412A and 413A operate at a transport layer or sublayer of the F1-U interface. As a more specific example, CU 172 and DU 174A / 174B use F1-U for user plane services, and tunnels 412A and 413A are associated with the GTP-U protocol layered on UDP / IP, where IP is layered on appropriate data link and physical (PHY) layers. In addition, in at least some cases, MRB 402 and / or DRB 404 additionally support control plane services. More specifically, in some implementations, CU 172 and DU 174A / 174B exchange F1-AP messages via an F1-C interface that relies on a stream control transmission protocol (SCTP) layered on IP, where, similar to F1-U, IP is layered on appropriate data link and PHY layers.

[0068] Similarly, depending on the implementation, MRB 402B includes DL tunnel 412B and / or UL tunnel 413B. In some implementations, DL tunnel 412B corresponds to DL logical channel 422B, and UL tunnel 413B corresponds to UL logical channel 423B.

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

[0070] Similarly, depending on the implementation, the DRB 404B includes a UE-specific DL tunnel 432B corresponding to a DL logical channel 442B, and a UE-specific UL tunnel 433B corresponding to a UL logical channel 443B.

[0071] Next, Figure 5A An example scenario 500A for establishing an MBS session is shown. The base station 104 includes a DU 174, a CU-CP 172A, and a CU-UP 172B. Note that the scenario 500A may also be applicable to an integrated CU that is not split into a CP functional node and a UP functional node.

[0072] UE 102 (e.g., Figure 1A UE 102A) initially performs 502 an MBS session join procedure with CN 110 via base station 104 to join a first MBS session. In some implementations, the MBS session join procedure does not involve CU-CP 172A. In some scenarios, UE 102 subsequently performs additional one or more MBS join procedures, and event 502 is correspondingly the first MBS join procedure of multiple MBS join procedures. Since base station 104 configures a common DL tunnel for MBS services (rather than a UE-specific tunnel as discussed below), processes 502 and 592A described below may occur in any order. In other words, base station 104 may configure the common DL tunnel even before a single UE joins the first MBS session.

[0073] To perform the MBS session join procedure, in some implementations, UE 102 sends an MBS session join request message to CN 110 via base station 104. In response, CN 110 sends an MBS session join response message to UE 102 via base station 104 to authorize UE 102 to access the first MBS session. In some implementations, UE 102 includes a first MBS session ID (e.g., session ID 1) of the first MBS session in the MBS session join request message. In some cases, CN 110 includes the first MBS session ID in the MBS session join response message. In some implementations, UE 102 sends an MBS session join complete message to CN 110 via base station 104 in response to the MBS session join response message.

[0074] In some implementations, the MBS session join request message, the MBS session join response message, and the MBS session join complete message are 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 are NAS messages, such as 5G Mobility Management (5GMM) messages or 5G Session Management messages (5GSM). In the case of 5GSM messages, UE 102 sends a (first) UL container message including an MBS session join request message to CN 110 via base station 104; CN 110 sends a DL container message including an MBS session join response message to UE 102 via base station 104; and UE 102 sends a (second) UL container message including an MBS session join complete message to CN 110 via base station 104. Depending on the implementation, these container messages are 5GMM messages. In some implementations, the MBS session join request message, the MBS session join response message, and the MBS session join complete message are respectively a PDU session modification request message, a PDU session modification command message, and a PDU session modification complete message. To simplify the following description, the terms MBS session join request message, MBS session join response message, and / or MBS session join complete message may represent corresponding container messages, or corresponding messages without containers.

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

[0076] In some implementations, before, during, or after the first MBS session joining process (event 502), CN 110 sends 504 a first CN to BS message (e.g., a multicast session activation request message) including the first MBS session ID to CU-CP 172A to request CU-CP 172A to configure or activate resources for the first MBS session (i.e., multicast (MBS) session).

[0077] In some implementations, the CN 110 includes a first MBS Quality of Service (QoS) flow configuration for the first MBS session in a first CN to BS message. In further implementations, the first MBS QoS flow configuration configures MBS QoS flows 1, ..., M associated with the first MBS session. M is an integer greater than zero. In some implementations, the first MBS QoS flow configuration includes MBS QoS flow identifiers 1, ..., M and / or MBS QoS flow level QoS parameters 1, ..., M for the MBS QoS flows 1, ..., M associated with the first MBS session, respectively. In further implementations, each of the MBS QoS flow configurations 1, ..., M includes an MBS QoS flow identifier and an MBS QoS flow level QoS parameters for a specific MBS QoS flow.

[0078] In some implementations, CN 110 includes first slice information indicating a network slice for the first MBS session in the first CN to BS message. For example, the first slice information may be single network slice selection assistance information (S-NSSAI) identifying a particular network slice. In other implementations, CN 110 does not include slice information (e.g., S-NSSAI) in the first CN to BS message. In some such cases, the first MBS session uses a default network slice.

[0079] In some implementations, CN 110 includes first MBS area information (e.g., MBS service area IE) that configures or indicates the MBS area of ​​the first MBS session in the first CN to BS message. In the case where the first MBS session is a location-dependent multicast session, the first MBS area information includes a tuple list {MBS area session ID IE, MBS service area information IE}. In the case where the first MBS session is a location-dependent multicast session, the first MBS area information includes an MBS area service information IE. The MBS service area information IE in the first MBS area information includes a cell identifier list and / or a tracking area identifier (TAI) list. In some implementations, the cell identifier is a cell global identifier (CGI). In other implementations, CN 110 does not include the MBS area information (e.g., MBS service area IE) in the first CN to BS message.

[0080] After receiving 504 the first CN to BS message, CU-CP 172A sends 560 a first CP to UP message (e.g., an MC bearer context establishment request message) to CU-UP 172B to request resources for the first MBS session. In some implementations, CU-CP 172A determines to configure one or more MRBs for the first MBS session or MBS QoS flow 1, ..., M. In response to the determination, CU-CP 172A generates an MRB establishment configuration to request resources for one or more MRBs. CU-CP 172A includes the first MBS session ID, MRB establishment configuration, and / or second MBS QoS flow configuration of the first MBS session in the first CP to UP message. In some implementations, CU-CP 172A generates a second MBS QoS flow configuration based on the first MBS QoS flow configuration. For example, the second MBS QoS flow configuration is the same as the first MBS QoS flow configuration. In another example, the second MBS QoS flow configuration is similar to the first MBS QoS flow configuration. In a further implementation, the second MBS QoS flow configuration includes QoS parameters for an MBS QoS flow associated with the first MBS session. In some implementations, for example, the QoS parameters 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 size.

[0081] In some implementations, the CU-CP 172A includes the second MBS QoS flow configuration (e.g., MBS QoS flow information to be established and / or MRB QoS IE, or QoS-Flow-QoS- Parameter-List and / or QoSFlowLevelQoSParameters IE) in the MRB setup configuration (e.g., MCMRBSetupConfigurationIE). In some implementations, the MRB setup configuration includes one or more MRB setup configuration items (e.g., MCMRBSetupConfiguration-Item IE). In some implementations, each of the MRB setup configuration items includes an MRB ID, an MRB configuration parameter (e.g., PDCP configuration and / or SDAP configuration) and / or a specific MBS QoS flow configuration in the second MBS QoS flow configuration of a specific MRB. In some implementations, the PDCP configuration includes a UL PDCP sequence number size configuration, a DL PDCP sequence number size configuration and / or an RLC mode configuration (e.g., acknowledgement mode or unacknowledgement mode). In some implementations, the SDAP configuration includes a default DRB configuration (eg, DefaultDRB IE), a SDAP UL header configuration (eg, SDAP-Header-UL), and / or a SDAP DL header configuration (eg, SDAP-Header-DL).

[0082] In some implementations, the second MBS QoS flow configuration includes QoS parameters required for each MBS QoS flow associated with the MRB. In some implementations, the second MBS QoS flow configuration includes MBS QoS flow identifiers 1, ..., M and / or MBS QoS flow level QoS parameters 1, ..., M for MBS QoS flows 1, ..., M associated with the first MBS session, respectively. MBS QoS flow identifiers 1, ..., M identify MBS QoS flows 1, ..., M, respectively. For example, the MRB establishment configuration includes MRB establishment configuration items 1, ..., N for MRBs 1, ..., N, respectively. M is an integer greater than zero. In the MRB establishment configuration, the CU-CP 172A may configure a mapping or association between MBS QoS flows 1, ..., M and MRBs 1, ..., N, where N is an integer and M>=N>0. In some implementations, the CU-CP 172A associates or maps a specific QoS flow to only a specific MRB. In other words, CU-CP 172A avoids associating or mapping a specific QoS flow to two MRBs. In some implementations, for MRB X in MRBs 1, ..., N, MRB establishment configuration item X includes a specific MBS QoS flow configuration of MRB ID X, PDCP configuration X, SDAP configuration X, and / or a second MBS QoS flow configuration, where 1 <= X <= N.

[0083] MCMRBSetupConfiguration is a sequence of SIZE(1..maxnoofMRBs) of MCMRBSetupConfiguration-Item. Table 1 below describes the MRB setup configuration items:

[0084] MCMRB creates configuration items sequence mrb-ID MRB-ID sdap-config SDAP-Configuration mbs-pdcp-config PDCP-Configuration qoS-Flow-QoS-Parameter-List QoS-Flow-QoS-Parameter-List qoSFlowLevelQoSParameters (optional) QoSFlowLevelQoSParameters iE-Extensions (optional) ProtocolExtensionContainer {{MCMRBSetupConfiguration-Item-ExtIEs}}

[0085] Table 2 below describes another MRB setup configuration, where the CU-CP 172A omits SDAP-Configuration:

[0086] MCMRB creates configuration items sequence mrb-ID MRB-ID mbs-pdcp-config PDCP-Configuration qoS-Flow-QoS-Parameter-List QoS-Flow-QoS-Parameter-List QoSFlowLevelQoSParameters (optional) QoSFlowLevelQoSParameters iE-Extensions (optional) ProtocolExtensionContainer {{MCMRBSetupConfiguration-Item-ExtIEs}}

[0087] In some cases where CU-CP 172A receives the first slice information from CN 110, for example, in the first CN to BS message, CU-CP 172A includes the first slice information in the first CP to UP message to indicate that the first MBS session uses the specific network slice indicated by the first slice information. In some cases where CU-CP 172A does not receive the slice information from CN 110 (for example, in the first CN to BS message), CU-CP 172A includes the preconfigured slice information in the first CP to UP message to indicate that the specific network slice is used for the first MBS session. Alternatively, in some such cases, CU-CP 172A omits the slice information from the first CP to UP message to indicate that the first MBS session uses a default network slice.

[0088] In some cases where CU-CP 172A receives the first MBS region information from CN 110 (e.g., in the first CN to BS message), CU-CP 172A includes the first MBS region information in the first CP to UP message. In some cases where CU-CP 172A does not receive the MBS region information from CN 110, for example, in the first CN to BS message, CU-CP 172A includes the preconfigured MBS region information in the first CP to UP message. Alternatively, in some such cases, CU-CP 172A omits the MBS region information from the first CP to UP message. In some cases where CU-CP 172A receives the first MBS region information from CN 110 (e.g., in the first CN to BS message), CU-CP 172A retrieves the MBS region session ID from the first MBS region information and includes the MBS region session ID in the first CP to UP message. In some further such cases, CU-CP 172A avoids including the MBS service area information IE in the first CP to UP message. In some cases where CU-CP 172A does not receive MBS region information from CN 110, for example in the first CN to BS message, CU-CP 172A includes the preconfigured MBS region session ID in the first CP to UP message. Alternatively, in some such cases, CU-CP 172A omits the MBS region session ID from the first CP to UP message.

[0089] In response to the first CP to UP message, CU-UP 172B establishes or configures resources for the MRB and sends 562 a first UP to CP message (e.g., an MC bearer context setup response message). In some implementations, CU-UP 172B configures resources for each MRB based on corresponding MRB configuration parameters and / or a specific MBS QoS flow configuration in the second MBS QoS flow configuration. In some implementations, CU-CP 172A configures resources for the MRB, the MBS QoS flow, and / or the first MBS session based on the first slice information. In some implementations, CU-UP 172B establishes and / or configures PDCP entities 1, ..., N according to PDCP configurations 1, ..., N of MRB or MRB ID 1, ..., N, respectively. In other implementations, for each of PDCP configurations 1, ..., N, CU-UP 172B ignores or discards a portion of the PDCP configuration and establishes and / or configures the PDCP entity according to the rest of the PDCP configuration. In one implementation, the CU-UP 172B ignores or discards the UL PDCP sequence number size configuration, and establishes and / or configures the PDCP entity according to the DL PDCP sequence number size configuration and / or the RLC mode. In another implementation, the CU-UP 172B ignores or discards the UL PDCP sequence number size configuration and the RLC mode, and establishes and / or configures the PDCP entity according to the DL PDCP sequence number size configuration.

[0090] In some implementations, CU-UP 172B establishes and / or configures SDAP entities 1, ..., N according to SDAP configurations 1, ..., N of MRB or MRB ID 1, ..., N, respectively. In other implementations, for each of SDAP configurations 1, ..., N, CU-UP 172B ignores or discards a portion of the SDAP configuration, and establishes and / or configures the SDAP entity according to the rest of the SDAP configuration. In one implementation, CU-UP 172B ignores or discards the default DRB configuration and the SDAP UL header configuration, and establishes and / or configures the SDAP entity according to the SDAP DL header configuration. In another implementation, CU-UP 172B ignores or discards the default DRB configuration, and establishes and / or configures the SDAP entity according to the SDAP UL header configuration and the SDAP DL header configuration. In yet other implementations, CU-UP 172B ignores or discards the entire SDAP configuration because CU-UP 172B determines not to use SDAP to send MBS data for the first MBS session.

[0091] In some implementations, CU-UP 172B includes a first CU transport layer configuration in a first UP to CP message to configure a common CN to BS DL tunnel for a first MBS session. In some implementations, the first CU transport layer configuration includes a CU transport layer address (e.g., an IP address and / or TEID) for identifying the first common CN to BS DL tunnel. In other implementations, the first CU transport layer configuration is MC bearer context NG-U TNL information at NG-RAN IE. In some implementations, CU-CP 172A includes a first CU-CP MBS E1AP ID in a first CP to UP message to identify the first MBS session on the E1 interface between CU-CP 172A and CU-UP 172B. In some implementations, CU-UP 172B includes a first CU-UPMBS E1AP ID in a first UP to CP message to identify the first MBS session on the E1 interface between CU-CP 172A and CU-UP 172B. In a further implementation, the CU-UP 172B includes the first CU-CP MBS E1AP ID in the first UP to CP message.

[0092] Events 560 and 562 in Figure 5A It is collectively referred to as the MC bearer context establishment process.

[0093] After receiving 504 the first CN-to-BS message (e.g., in response to receiving 504 the first CN-to-BS message), the CU-CP 172A sends 506 a first CU-to-DU message (e.g., a multicast context setup request message) to the DU 174 to request the establishment of a multicast context and / or a common DL tunnel for the first MBS session. Figure 4 and accompanying text. CU-CP 172A determines to configure one or more MRBs for a first MBS session or MBS QoS flows 1, ..., M. In response to the determination, CU-CP 172A generates an MRB to perform setup configuration of resources for requesting one or more MRBs. In some implementations, the first CU to DU message includes information related to configuring DRX for a UE 102 participating in the MBS session, such as a first MBS session ID, an MRB for performing setup configuration, and / or a third MBS QoS flow configuration for the first MBS session. In a further implementation, the information related to configuring DRX in the first CU to DU message includes DRX-specific information, such as a DRX cycle length, an on-duration period length, and the like.

[0094] In some implementations, the CU-CP 172A includes the first slice information in the first CU to DU message to indicate that the first MBS session uses a specific network slice indicated by the first slice information. In some implementations, the MRBs used to perform the establishment configuration include MRB IDs, each MRB ID identifies an MRB, and the DU 174 configures resources (e.g., PHY, MAC, and / or RLC resources) for the MRB. In some implementations, the MRB ID included in the first CU to DU message is the same as the MRB ID included in the first CP to UP message. In some implementations, the CU-CP 172A generates a third MBS QoS flow configuration based on the first MBS QoS flow configuration. For example, the third MBS QoS flow configuration is the same as the first MBS QoS flow configuration. In another example, the third MBS QoS flow configuration is similar to the first MBS QoS flow configuration. In some implementations, the CU-CP 172A includes the CU MBS F1 AP ID in the first CU-to-DU message to identify the first MBS session on the F1 interface between the CU-CP 172A and the DU 174 .

[0095] In the case where CU-CP 172A receives first slice information (e.g., S-NSSAI) associated with the first MBS session from CN 110, for example in a first CN to BS message, CU-CP 172A includes the first slice information in a first CU to DU message similar to the first CP to UP message described above to indicate that a specific network slice is used for the first MBS session. Therefore, similar embodiments apply to the first CU to DU message.

[0096] In some cases where CU-CP 172A receives the first MBS region information from CN 110, for example in a first CN to BS message, CU-CP 172A includes the first MBS region information in a first CU to DU message similar to the first CP to UP message described above. Therefore, similar embodiments apply to the first CU to DU message.

[0097] In response to receiving 506 the first CU-to-DU message, the DU 174 establishes or configures resources (e.g., multicast context and / or PHY, MAC, RLC, and / or tunnel resources) for the MRB and sends 508 a first DU-to-CU message (e.g., a multicast context setup response message) to the CU-CP 172A. In some implementations, the DU 174 establishes and / or configures a MAC entity for the MRB. In some implementations, the DU 174 establishes and / or configures RLC entities 1, ..., N for the MRBs or MRB IDs 1, ..., N, respectively. In some implementations, the DU 174 includes a first DU transport layer configuration in the first DU-to-CU message to configure a common CU-to-DU DL tunnel for a first MBS session (e.g., for an MRB identified by one of the MRB IDs). In further implementations, the DU 174 includes additional DU transport layer configurations in the first DU-to-CU message to configure additional common CU-to-DU DL tunnels for additional MRBs identified by additional MRBIDs in the MRB IDs. In some implementations, DU 174 includes an MRB ID associated with the first DU transport layer configuration and / or the additional DU transport layer configuration in the first DU to CU message. For example, each of the MRB IDs is associated with a specific DU transport layer configuration. In some implementations, each of the first DU transport layer configuration and / or the additional DU transport layer configuration includes a DU transport layer address (e.g., an IP address and / or a TEID). In some implementations, each of the first DU transport layer configuration and / or the additional DU transport layer configuration is MRBF1-U TNL information at the DU IE.

[0098] Events 506 and 508 in Figure 5A In some implementations, the multicast context establishment process and the MC bearer context establishment process occur in parallel. In other implementations, the multicast context establishment process occurs after the MC bearer context establishment process, or vice versa.

[0099] In some implementations, DU 174 sends 510 a second DU to CU message (e.g., a multicast distribution setup request message) to CU-CP 172A after receiving 506 the first CU to DU message or sending 508 the first DU to CU message. In some implementations, DU 174 includes the first DU transport layer configuration and / or the additional DL transport layer configuration in the second DU to CU message instead of the first DU to CU message. In some implementations, DU 174 includes the MRB ID associated with the first DU transport layer configuration and / or the additional DU transport layer configuration in the second DU to CU message instead of the first DU to CU message. Therefore, in further implementations, the first DU to CU message does not include the DU transport layer configuration. In some implementations, in response to the second DU to CU message, CU-CP 172A sends 516 a second CU to DU message (e.g., a multicast distribution setup response message) to DU 174. In some implementations, the second CU-to-DU message is similar to the first CU-to-DU message sent by CU 172 in event 506. Events 510 and 516 are Figure 5A It is collectively referred to as the multicast distribution establishment process.

[0100] After receiving 504 the first CN to BS message, receiving 562 the first UP to CP message, receiving 508 the first DU to CU message, or receiving 510 the second DU to CU message, CU-CP 172A sends 512 a first BS to CN message (e.g., a distribution setup request message) to CN 110. In some implementations, CU-CP 172A sends 512 the first BS to CN message to CN 110 before receiving 508 the first DU to CU message or receiving 510 the second DU to CU message. In some implementations, CU-CP 172A includes the first CU transport layer configuration in the first BS to CN message. Thus, in some such implementations, CN 110 sends MBS data to CU-UP 172B via the first public CN to BS DL tunnel, as described below for event 532. In some implementations, CU-CP 172A includes the first MBS session ID in the first BS to CN message. In some implementations, CN 110 sends 514 a second CN to BS message (e.g., a distribution setup response message) to CU-CP 172A in response to the first BS to CN message. In some implementations, CN 110 includes a first CN transport layer configuration in the second CN to BS message. The first CN transport layer configuration includes at least one CN transport layer address (e.g., an IP address) for identifying a first public CN to BS DL tunnel. In some implementations, at least one transport layer address includes an IP source address and / or an IP multicast address. In some implementations, the first CN transport layer configuration includes a TEID at / of CN 110. In some implementations, CN 110 includes a fourth MBS QoS flow configuration for the first MBS session in the second CN to BS message. In some implementations, the fourth MBS QoS flow configuration is similar to the first MBS QoS flow configuration.

[0101] After receiving 514 the second CN to BS message, CU-CP 172A sends 564 a second CP to UP message (e.g., an MC bearer context modification request message) to CU-UP 172B. In some implementations, CU-CP 172A includes the MRB ID, the first DU transport layer configuration, the additional DU transport layer configuration, and / or the first CN transport layer configuration in the second CP to UP message. In response to receiving the second CP to UP message of event 564, CU-UP 172B sends 566 a second UP to CP message (e.g., an MC bearer context modification response message). In some implementations, CU-UP 172B includes the MRB ID and / or the second CU transport layer configuration in the second UP to CP message. In some implementations, the second CU transport layer configuration includes a CU transport layer address (e.g., an IP address) for identifying the first common DU to CU UL tunnel. The second CU transport layer configuration may additionally include a TEID of / at CU-UP172B. In some implementations, the second CU transport layer configuration is the same as the first CU transport layer configuration. In other implementations, the second CU transport layer configuration is different from the first CU transport layer configuration. In some implementations, CU-CP 172A includes the second CU transport layer configuration in the second CU to DU message and sends 516 the second CU to DU message to DU 174 in response to the second DU to CU message of event 510. After receiving 566 the second UP to CP message or sending 516 the second CU to DU message, CU-CP 172A sends 518 the second BS to CN message (e.g., a multicast session activation response message) to CN 110 in response to the first CN to BS message. Alternatively, CU-CP 172A sends 518 the second BS to CN message to CN 110 before receiving 566 the second UP to CP message or sending 516 the second CU to DU message. For example, after receiving 504 the first CN to BS message, receiving 562 the first UP to CP message, receiving 510 the second DU to CU message, or receiving 514 the second CN to BS message, the CU-CP 172A sends 518 a second BS to CN message to the CN 110 .

[0102] In some implementations, CU-CP 172A includes the fourth MBS QoS flow configuration in the MC bearer context modification request message. In some such implementations, CU-UP 172B modifies or reconfigures the resources of the MRB based on the fourth MBS QoS flow configuration. In some implementations, CU-UP 172B determines whether to modify or reconfigure the resources of the MRB based on the fourth MBS QoS flow configuration. For example, if the resources of the MRB at event 562 can still meet the fourth MBS QoS flow configuration, CU-UP 172B does not modify or reconfigure the resources of the first MRB. Otherwise, CU-UP 172B modifies or reconfigures the resources of the MRB based on the fourth MBS QoS flow configuration. In some implementations, CU-UP 172B determines whether to modify or reconfigure the resources of a specific MRB among the MRBs based on the fourth MBS QoS flow configuration.

[0103] Events 504, 560, 562, 506, 508, 510, 512, 514, 564, 566, 516, and 518 are Figure 5A The messages in process 592A may be MBS session-associated messages, ie, messages associated with the first session rather than a specific UE (eg, UE 102A).

[0104] In some implementations, CU-CP 172A includes a multicast DRX cycle request in the first CU to DU message of event 506 to request DU 174 to configure a multicast DRX cycle for the first MBS session. In some implementations, the first multicast DRX cycle request includes information related to configuring DRX, such as the required multicast DRX cycle length. In some implementations, the first multicast DRX cycle request is an IE (e.g., a DRX cycle IE or a multicast DRX cycle IE) of the first CU to DU message. In other implementations, CU-CP 172A sends (not shown) an additional CU to DU message (e.g., a multicast context modification request message) including the multicast DRX cycle request to DU 174. In response, DU 174 sends (not shown) an additional DU to CU message to CU-CP 172A. In some implementations, CU-CP 172A additionally or alternatively includes the multicast DRX cycle request in the second CU to DU message of event 516, as described above.

[0105] In some implementations, CN 110 sends 520 a third CN-to-BS message to CU-CP 172A, the third CN-to-BS message indicating (only) that UE 102 (e.g., UE 102A) joins the first MBS session. In some implementations, CN 110 may include a first MBS session ID and / or an MBS QoS flow identifier that respectively identifies the first MBS session and the MBS QoS flow associated with the first MBS session in the third CN-to-BS message. In response to the third CN-to-BS message, CU-CP 172A may send 527 a third BS-to-CN message to CN 110. After receiving the third CN-to-BS message (e.g., in response to receiving the third CN-to-BS message), CU-CP 172A may send 522 a UE context request message of UE 102 (e.g., UE 102A) to DU 174. In some implementations, CU-CP 172A may include information related to the configured DRX of UE 102, such as the DRX cycle length and / or the MRB ID in the UE Context Request message, as described above. In some implementations, CU-CP 172A determines the MRB ID based on the first MBS session ID and / or the MBS QoS flow identifier received in the third CN to BS message. In some implementations, CU-CP 172A does not include the first MBS session ID in the UE Context Request message.

[0106] In response to the UE context request message of event 522, DU 174 sends 524 to CU-CP 172A a UE context response message including configuration parameters of UE 102A to receive MBS data for the first MBS session via the MRB. Some or all of the configuration parameters may be associated with the MRB and / or the MRB ID. In some implementations, DU 174 generates a DU configuration (i.e., a first DU configuration) to include configuration parameters (i.e., a first plurality of configuration parameters), and includes the DU configuration in the UE context response message. In some implementations, the DU configuration may be a CellGroupConfig IE. In other implementations, the DU configuration may be an MBS-specific IE. In some implementations, the configuration parameters configure one or more logical channels (LCs) of the MRB. 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 specific logical channel in the one or more logical channels.

[0107] In some implementations, the third CN to BS message and the third BS to CN message are a PDU session resource modification request message and a PDU session resource modification response message, respectively. In other implementations, the third CN to BS message and the third BS to CN message are a PDU session resource establishment request message and a PDU session resource establishment response message, respectively. In some implementations, the third CN to BS message and the third BS to CN message are UE-associated messages, that is, the messages are associated with a specific UE (e.g., UE 102A, 102B, or 103).

[0108] In some implementations, the UE context request message and the UE context response message are respectively a UE context establishment request message and a UE context establishment response message. In some alternative implementations, the UE context request message and the UE context response message are respectively a UE context establishment request message and a UE context modification request message. In some such implementations, the DU 174 sends a UE context establishment response message to the CU-CP 172A in response to the UE context establishment request message, and the CU-CP 172A sends a UE context modification confirmation message to the DU 174 in response to the UE context modification request message. In other implementations, the UE context request message and the UE context response message are respectively a UE context modification request message and a UE context modification response message. In some alternative implementations, the UE context request message and the UE context response message are respectively a UE context modification request message and a UE context modification request message. In some such implementations, the DU 174 sends a UE context modification response message to the CU-CP 172A in response to the UE context modification request message, and the CU-CP 172A sends a UE context modification confirmation message to the DU 174 in response to the UE context modification request message.

[0109] In some implementations, CU-CP 172A may perform a (UE-specific) bearer context procedure with CU-UP 172B for UE 102 (e.g., UE 102A) after receiving the third CN to BS message (e.g., in response to receiving the third CN to BS message). In the bearer context procedure, CU-CP 172A sends a bearer context request message to CU-UP 172B to request to establish or modify a (unicast) bearer context for UE 102. In response, CU-UP 172B establishes or modifies a (unicast) bearer context for UE 102 and sends a bearer context modification response message to CU-CP 172A. In other implementations, CU-CP 172A avoids performing a (UE-specific) bearer context procedure with CU-UP 172B for UE 102 after receiving the third CN to BS message. In some implementations, the bearer context procedure is a bearer context establishment procedure defined in section 8.3.1 in 3GPP specifications 37.483 or 38.463. In such a case, the bearer context request message and the bearer context setup message are respectively a bearer context setup request message and a bearer context setup response message. In other implementations, the bearer context procedure is a bearer context modification procedure defined in section 8.3.2 of 3GPP specification 37.483 or 38.463. In such a case, the bearer context request message and the bearer context setup message are respectively a bearer context modification request message and a bearer context modification response message.

[0110] After receiving 524 the UE context response message or performing 502 the MBS session join procedure with the CN 110 and the UE 102, the CU-CP 172A generates an RRC reconfiguration message (e.g., an RRCReconfiguration message) including configuration parameters and one or more MRB configurations (i.e., a first MRB configuration), and sends 526 the RRC reconfiguration message to the DU 174. The DU 174 in turn sends 528 the RRC reconfiguration message to the UE 102 (e.g., UE 102A). The UE 102 then sends 530 an RRC reconfiguration complete message to the DU 174, which in turn sends 531 an RRC reconfiguration complete message (e.g., an RRCReconfigurationComplete message) to the CU-CP 172A.

[0111] Events 520, 522, 524, 526, 527 (discussed below), 528, 530, and 531 are Figure 5A594. CN 110 and / or CU-CP 172A performs process 594 for each UE (e.g., UE 102A and UE 102B) that joins the first MBS session. Depending on the implementation, process 594 occurs before, after, or overlaps with process 592A.

[0112] In some implementations, DU 174 sends (not shown) a third DU to CU message including a portion of the configuration parameters of UE 102 to CU-CP 172A after sending 524 the UE context response message, instead of including all the configuration parameters in the UE context response message of event 524. Depending on the implementation, the portion of the configuration parameters includes the configuration as described herein. In such a case, similar to events 526, 528, after sending 526 RRC reconfiguration message or receiving 531 RRC reconfiguration complete message, CU-CP 172A sends a second RRC reconfiguration message including a portion of the configuration parameters to UE 102 via DU 174. In response, similar to events 530, 531, UE 102 sends a second RRC reconfiguration complete message to CU-CP 172A via DU 174. Depending on the implementation, the third DU to CU message is a UE context modification request message or a UE context modification response message. In some implementations, CU-CP 172A sends a third CU-to-DU message similar to the UE context request message of event 522 to DU 174 to trigger transmission of the third DU-to-CU message.

[0113] In some implementations, the CU-CP 172A generates a PDCP PDU including an RRC reconfiguration message and sends 526 a CU-to-DU message including the PDCP PDU to the DU 174. In such implementations, the DU 174 retrieves the PDCP PDU from the CU-to-DU message and sends 528 the PDCP PDU to the UE 102 via the RLC layer 206B, the MAC layer 204B, and / or the PHY layer 202B. The UE 102 receives 528 the PDCP PDU from the DU 174 via the PHY layer 202B, the MAC layer 204B, and / or the RLC layer 206B. In some implementations, the UE 102 generates a PDCP PDU including an RRC reconfiguration complete message and sends 530 the PDCP PDU to the DU 174 via the RLC layer 206B, the MAC layer 204B, and / or the PHY layer 202B. The DU 174 receives 522 the PDCP PDU from the UE 102 via the PHY layer 202B, the MAC layer 204B and / or the RLC layer 206B, and sends 531 a DU-to-CU including the PDCP PDU to the CU-CP 172A. The CU-CP 172A retrieves the PDCP PDU from the DU-to-CU message and retrieves the RRC reconfiguration complete message from the PDCP PDU.

[0114] In some implementations, the CU-CP 172A sends 527 a third BS to CN message to the CN 110 in response to the third CN to BS message 520. Depending on the implementation, the CU-CP 172A sends 527 the third BS to CN message to the CN 110 before or after receiving 531 the RRC reconfiguration complete message and / or receiving 524 the UE context response message. The CU-CP 172A may include the first CN UE interface ID and the first RAN UE interface ID in the third BS to CN message. In some implementations, the CN 110 assigns a first CN UE interface ID that identifies the UE 102 (e.g., UE 102A), and the CU-CP 172A assigns a first RAN UE interface ID that identifies the UE 102 (e.g., UE 102A). In some implementations, the “CN UE interface ID” is the “AMF UE NGAP ID” and the “RAN UE interface ID” is the “RAN UE NGAP ID”.

[0115] After receiving 518 the second BS-to-CN message or receiving 527 the third BS-to-CN message, the CN 110 (e.g., (MB-)UPF 162) sends 532 MBS data (e.g., one or more MBS data packets) for the first MBS session to the CU-UP 172B via the first common CN-to-BS DL tunnel (i.e., according to the first CU transport layer configuration and / or the first CN transport layer configuration). In some implementations, the CN 110 generates tunnel packets, each of which includes a specific MBS data packet, to send the MBS data packets via the first common CN-to-BS DL tunnel. In a header of each of the tunnel packets, the CN 110 sets the source IP address, the target IP address, and the TEID to the IP address in the first CN transport layer configuration, the IP address in the first CU transport layer configuration, and the TEID in the first CU transport layer configuration, respectively. In such implementations, the IP address in the first CN transport layer configuration, the IP address in the first CU transport layer configuration, and the TEID in the first CU transport layer configuration identify the first common CN-to-BSDL tunnel.

[0116] When CU-UP 172B receives 532 MBS data for the first MBS session from CN 110, CU-UP 172B in turn sends 534 the MBS data to DU 174 via the first common CU-to-DU tunnel and / or additional common CU-to-DU DL tunnels (i.e., according to the first and / or additional DU transport layer configurations). In some cases where the MBS data is associated with some MBS QoS flows identified by the MBS QoS flow identifiers, CU-UP 172B determines which common CU-to-DU DL tunnel to use to send the MBS data to DU 174 based on one or some MBS QoS flow identifiers. For example, when CU-UP 172B receives a first MBS data packet associated with a first MBS QoS flow identifier among the MBS QoS flow identifiers from CN 110, CU-UP 172B sends the first MBS data packet to DU 174 via the first common CU-to-DU DL tunnel. When CU-UP 172B receives a second MBS data packet associated with a second one of the MBS QoS flow identifiers from CN 110, CU-UP 172B sends the second MBS data packet to DU 174 via one of the additional common CU-to-DU tunnels.

[0117] In some implementations, CU-UP 172B generates tunnel packets, each of which includes a specific MBS data packet, to send the MBS data packets via a first common CU to DU tunnel and / or an additional common CU to DU DL tunnel similar to the CN to BS tunnel described in more detail above. In the event that CU-UP 172B sends one of the tunnel packets via the additional common CU to DU tunnel, CU-UP 172B sets parameters similar to event 532 above using the DU and CU transport layers instead of the CU and CN transport layers.

[0118] When the DU 174 receives 534 the MBS data from the CU-UP 172B, the DU 174 transmits (eg, multicasts or unicasts) 536 the MBS data to the UE 102 via one or more logical channels. Figure 4 and accompanying text. The UE 102 receives 536 MBS data via one or more logical channels. For example, the CU-UP 172B may receive 532 MBS data packets, generate a PDCP PDU including the MBS data packets, and send 534 the PDCP PDU to the DU 174. In turn, the DU 174 generates a MAC PDU including an LCID and a PDCP PDU, and sends 536 the MAC PDU to the UE 102 via multicast or unicast. The UE 102 receives 536 the MAC PDU via multicast or unicast, retrieves the PDCP PDU and the LCID from the MAC PDU, identifies the PDCP PDU associated with the MRB based on the LCID, and retrieves the MBS data packets from the PDCP PDU based on the PDCP configuration within the MRB configuration. In some implementations, the DU 174 sends 536 MBS data or the MAC PDU to the UE 102 via one or more multicast transmissions (e.g., dynamic or SPS multicast transmissions), as described above. In some such cases, UE 102 receives 536 MBS data or MAC PDUs from DU 174 via one or more multicast transmissions, as described above.

[0119] In some implementations, CU-CP 172A requests DU 174 to configure a UE-specific CU to DU DL tunnel for UE 102 in a UE context request message at event 522. In some implementations, CU-CP 172A includes a CU transport layer configuration in the UE context request message to request a UE-specific CU to DU DL tunnel for UE 102. The CU transport layer configuration includes a CU transport layer address (e.g., an IP address) for identifying the UE-specific CU to DU DL tunnel. In a further implementation, the CU transport layer configuration includes a TEID of / at CU-UP 172B. In response, DU 174 includes a DU transport layer configuration for configuring a UE-specific CU to DU DL tunnel in a UE context response message. The DU transport layer configuration includes a DU transport layer address (e.g., an IP address and / or TEID). Depending on the implementation, after receiving 524 the UE context response message, CU-CP 172A sends a bearer context modification request message including the DU transport layer configuration to CU-UP 172B, and in response, CU-UP 172B sends a bearer context modification response message to CU-CP 172A. In a further implementation, CU-UP 172B later sends 534 MBS data to DU 174 via a UE-specific CU-to-DU DL tunnel.

[0120] In some implementations, the configuration parameters also include one or more RLC bearer configurations, each RLC bearer configuration being associated with a specific MRB. Each of the MRB configurations includes 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 is a PDCP-Config IE for DRB. In some implementations, the RLC bearer configuration is an RLC-BearerConfig IE. In some implementations, the RLC bearer configuration may include a logical channel ID for configuring a logical channel. In some implementations, the logical channel is a (multicast) MBS traffic channel (MTCH). In other implementations, the logical channel is a dedicated traffic channel (DTCH). In some implementations, the configuration parameters include a logical channel configuration (e.g., LogicalChannelConfig IE) for configuring a logical channel. In some implementations, the RLC bearer configuration includes an MRB ID.

[0121] In some implementations, CU-CP 172A configures the MRB as a DL-only RB in the MRB configuration. For example, CU-CP 172A avoids including the UL configuration parameter configuration in the PDCP configuration within the MRB configuration to configure the MRB as a DL-only RB. In some implementations, CU-CP 172A includes only the DL configuration parameters in the MRB configuration (e.g., as described above). In such a case, CU-CP 172A configures UE 102 to not send UL PDCP data PDUs to DU 174 and / or CU-CP 172A via MRB by excluding the UL configuration parameters for MRB in the PDCP configuration in the MRB configuration. In another example, DU 174 avoids including the UL configuration parameters in the RLC bearer configuration. In such a case, DU 174 configures UE 102 to not send control PDUs to base station 104 via logical channels by excluding the UL configuration parameters from the RLC bearer configuration.

[0122] In the case where DU 174 includes the UL configuration parameters in the RLC bearer configuration, UE 102 sends a control PDU (e.g., a PDCP control PDU and / or an RLC control PDU) to DU 174 via a logical channel using the UL configuration parameters. In some implementations where the control PDU is a PDCP control PDU, DU 174 sends the PDCP control PDU to CU-UP 172B. For example, CU-CP 172A configures the UE to receive MBS data using a (de)compression protocol (e.g., a Robust Header Compression (ROHC) protocol). In some such cases where CU-UP 172B receives 532 MBS data packets from CN 110, CU-UP 172B compresses the MBS data packets using a compression protocol to obtain compressed MBS data packets, and sends 534 a PDCP PDU including the compressed MBS data packets to DU 174 via a first or additional common CU to DU DL tunnel. In turn, DU 174 sends (e.g., multicast or unicast) 536 the PDCP PDU to UE 102 via the logical channel. When UE 102 receives 536 the PDCP PDU via the logical channel, UE 102 retrieves the compressed MBS data packet from the PDCP PDU. UE 102 decompresses the compressed MBS data packet using a (de)compression protocol to obtain the original MBS data packet. In some such cases, UE 102 sends a PDCP control PDU to DU 174 via the logical channel, the PDCP control PDU including header compression protocol feedback (e.g., interspersed ROHC feedback) for the operation of the header (de)compression protocol. DU 174 in turn sends the PDCP control PDU to CU-UP 172B via the UL tunnel.

[0123] In some implementations, the UL tunnel is a first common DU to CU tunnel configured in a first DU transport layer configuration and a second CU transport layer configuration. For example, an IP address in the first DU transport layer configuration and an IP address and a TEID in the second CU transport layer configuration identify the first common DU to CU tunnel. In other implementations, the UL tunnel is specific to UE 102 (e.g., UE 102A). In some implementations, CU-CP 172A may include a CU transport layer configuration for configuring a UE-specific UL tunnel in a UE context request message. The CU transport layer configuration includes a CU transport layer address (e.g., an Internet Protocol (IP) address) and a TEID for identifying a UE-specific UL tunnel. In some implementations, DU 174 includes a DU transport layer configuration for configuring a UE-specific UL tunnel in a UE context response message. The DU transport layer configuration includes a DU transport layer address (e.g., an IP address and / or a TEID). For example, an IP address in the DU transport layer configuration and an IP address and a TEID in the CU transport layer configuration identify a first common UL tunnel.

[0124] In some implementations, the MRB configuration may be an MRB-ToAddMod IE including an MRB ID (e.g., mrb-Identity or MRB-Identity). The MRB ID identifies a specific MRB in the MRB. In some implementations where the CU-CP 172A has configured the DRB to the UE 102 for unicast data communication, the CU-CP 172A sets one or more of the MRB IDs to a value different from the DRB ID of the DRB. In some such cases, the UE 102 and the CU-CP 172A may distinguish whether the RB is an MRB or a DRB based on the RBID of the RB. In other implementations, the CU-CP 172A sets one or more of the MRB IDs to a value that may be the same as the DRB ID. In some such cases, the UE 102 and the CU-CP 172A may distinguish whether the RB is an MRB or a DRB based on the RBID of the RB and the RRC IE that configures the RB. For example, the DRB configuration for configuring the DRB is a DRB-ToAddMod IE including a DRB identity (e.g., drb-Identity or DRB-Identity) and a PDCP configuration. Therefore, if the UE 102 receives the DRB-ToAddMod IE for configuring the RB, the UE 102 can determine that the RB is a DRB, and if the UE 102 receives the MRB-ToAddMod IE for configuring the RB, it is determined that the RB is an MRB. Similarly, if the CU-CP 172A sends the DRB-ToAddMod IE for configuring the RB to the UE 102, the CU-CP 172A determines that the RB is a DRB, and if the CU-CP 172A sends the MRB-ToAddMod IE for configuring the RB to the UE 102, it is determined that the RB is an MRB.

[0125] In some implementations, the configuration parameters for receiving MBS data for the first MBS session include one or more logical channel IDs for configuring one or more logical channels. In some implementations, the logical channel is a DTCH. In other implementations, the logical channel is an MTCH.

[0126] In some implementations, the configuration parameters include dynamically scheduled multicast configuration parameters for the UE 102 to receive 536 multicast transmissions, each multicast transmission including MBS data or a specific portion of the MBS data for the first MBS session. In some implementations, the dynamically scheduled multicast configuration parameters include at least one of the configuration parameters as described in detail below.

[0127] In some implementations, the configuration parameters include a group radio network temporary identifier (G-RNTI), an MBS-specific RNTI. DU 174 dynamically schedules each multicast transmission for UE 102, including a specific MAC PDU, by generating a DCI, scrambling a cyclic redundancy check (CRC) of the DCI with the G-RNTI, and sending the DCI and the scrambled CRC on the PDCCH. The MAC PDU includes an MBS data packet or a portion of an MBS data packet. UE 102 receives the DCI and the scrambled CRC on the PDCCH and verifies the scrambled CRC with the G-RNTI. For each multicast transmission, after UE 102 verifies that the (scrambled) CRC is valid, UE 102 receives the multicast transmission according to the corresponding DCI and retrieves a specific MAC PDU from the multicast transmission. In this case, each multicast transmission is a dynamically scheduled multicast transmission used in the following description. In some implementations, each DCI includes configuration parameters for configuring the dynamically scheduled multicast radio resources that schedule the corresponding multicast transmission. In some implementations, the configuration parameters may include at least one of the following parameters. The configuration parameters of each DCI may include the same values ​​and / or different values ​​of the following configuration parameters: (i) frequency domain resource assignment, (ii) time domain resource assignment, (iii) virtual resource block (VRB) to physical resource block (PRB) mapping, (iv) modulation and coding scheme (MCS), (v) new data indicator, (vi) redundancy version, (vii) HARQ process number, (viii) downlink assignment index, and / or (ix) PUCCH resource indicator.

[0128] In some implementations, the configuration parameters include a HARQ codebook (ID) indicating a HARQ confirmation (ACK) codebook index for a corresponding HARQ ACK codebook for a dynamically scheduled multicast transmission received by UE 102. DU 174 uses the HARQ codebook (ID) to receive the HARQ ACK. In some cases where the configuration parameters do not include the HARQ codebook (ID), UE 102 and DU 174 use the HARQ codebook (ID) for unicast transmission. In some implementations, UE 102 receives the HARQ codebook (ID) for unicast transmission in the DU configuration from DU 174. In other implementations, similar to events 516, 518, and 520, UE 102 receives the HARQ codebook (ID) for unicast transmission in another DU configuration from DU 174.

[0129] In some implementations, the configuration parameters include a PUCCH resource configuration that indicates HARQ resources on the PUCCH where the UE 102 sends HARQ feedback (e.g., HARQ ACK and / or negative ACK (NACK)) for the dynamically scheduled multicast transmission. In some cases where the configuration parameters do not include a PUCCH resource configuration, the UE 102 and the DU 174 transmit the HARQ feedback using the PUCCH resource configuration for unicast transmissions.

[0130] In some implementations, the configuration parameters include a HARQ NACK-only indication that configures the UE 102 to send a HARQ negative ACK (NACK) only for dynamically scheduled multicast transmissions that the UE 102 receives from the DU 174 and from which the UE 102 fails to obtain a transport block. In some implementations, the UE 102 fails to obtain a transport block because the UE 102 fails a cyclic redundancy check (CRC) for the transport block or the UE 102 does not receive the dynamically scheduled multicast transmission. Based on the indication, the UE 102 avoids sending a HARQ ACK to the DU 174 for dynamically scheduled multicast transmissions that the UE 102 successfully receives and from which the UE 102 obtains a transport block. In some cases where the configuration parameters do not include the indication, the UE 102 sends a HARQ ACK to the DU 174 for dynamically scheduled multicast transmissions that the UE 102 successfully receives and from which the UE 102 obtains a transport block.

[0131] In some implementations, the configuration parameters include a HARQ ACK / NACK indication that configures the UE 102 to send a HARQ NACK for a dynamically scheduled multicast transmission. In such implementations, the UE 102 fails to obtain a transport block, and the UE 102 is configured to send a HARQ ACK for a dynamically scheduled multicast transmission that the UE 102 successfully receives and from which the UE 102 obtains a transport block. In the event that the configuration parameters do not include the indication, the UE 102 refrains from sending a HARQ ACK to the DU 174 for a dynamically scheduled multicast transmission that the UE 102 successfully receives and from which the UE 102 obtains a transport block. In some such cases, the UE 102 sends a HARQ NACK to the DU 174 for only the dynamically scheduled multicast transmission in which the UE 102 fails to obtain a transport block.

[0132] In some implementations, the configuration parameters include a HARQ ACK indication that configures the UE 102 to send a HARQ ACK for dynamically scheduled multicast transmissions that the UE 102 successfully received and from which the UE 102 obtained a transport block. In the event that the configuration parameters do not include the indication, the UE 102 refrains from sending a HARQ ACK to the DU 174 for dynamically scheduled multicast transmissions in which the UE 102 successfully obtained a transport block. In some such cases, the UE 102 sends a HARQ NACK to the DU 174 for dynamically scheduled multicast transmissions in which only the UE 102 failed to obtain a transport block. In some implementations, the DU 174 includes at least one of a HARQ NACK indication, a HARQ ACK / NACK indication, and / or a HARQ ACK indication.

[0133] In some implementations, the configuration parameters include a modulation and coding scheme (MCS) configuration that indicates an MCS table that the DU 174 uses to send dynamically scheduled multicast transmissions and the UE 102 uses to receive dynamically scheduled multicast transmissions. For example, the MCS table can be an MCS table defined in 3GPP specification 38.214 (e.g., a low SE 64QAM table indicated 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 the MCS configuration in the DU configuration, the UE 102 and the DU 174 apply an MCS table predefined in the 3GPP specification 38.214. For example, the predefined MCS table can be, for example, a 256QAM table or a 64QAM table indicated in Table 5.1.3.1-2 of the specification 38.214, respectively, or a non-low SE 64QAM table indicated in Table 5.1.3.1-1. In some cases where DU 174 does not include the MCS configuration in the DU configuration, UE 102 and DU 174 apply the MCS table for unicast transmission to receive dynamically scheduled multicast transmissions from DU 174. In some implementations, DU 174 includes a PDSCH configuration (e.g., PDSCH-Config) that configures the MCS table for unicast transmission in the DU configuration. In other implementations, similar to events 516, 518, and 520, DU 174 sends another DU configuration including the PDSCH configuration to UE 102.

[0134] In some implementations, the configuration parameters include an aggregation factor, which is the number of repetitions for the dynamically scheduled multicast transmission. In some such implementations, the DU 174 sends (i.e., multicasts) multiple repetitions of the dynamically scheduled multicast transmission according to the aggregation factor, and the UE 102 receives the repetitions based on the aggregation factor. In some cases where the DU 174 does not include the aggregation factor in the DU configuration, the UE 102 applies the aggregation factor for unicast transmissions. In some implementations, the DU 174 includes the aggregation factor for unicast transmissions to the UE 102 in the DU configuration. In other implementations, similar to events 516, 518, and 520, the DU 174 sends another DU configuration to the UE 102 that includes the aggregation factor for unicast transmissions.

[0135] The RRC reconfiguration message for the UE joining the first MBS session includes the same configuration parameters for receiving MBS data for the first MBS session.In some implementations, the RRC reconfiguration message for the UE includes the same or different configuration parameters for receiving non-MBS data.

[0136] In some implementations, the configuration parameters may include at least one semi-persistent scheduling (SPS) multicast configuration for the UE 102 to receive 536 MBS data for the first MBS session. Each of the at least one SPS multicast configuration may include at least one of the following parameters for SPS multicast transmission.

[0137] In some implementations, the configuration parameters include a group configured scheduling radio network temporary identifier (G-CS-RNTI), which is used to activate or release the SPS multicast radio resources. The DU 174 activates the SPS multicast radio resources for the UE 102 by generating an SPS multicast radio resource activation command (i.e., DCI), scrambling the CRC of the DCI with the G-CS-RNTI, and sending the DCI and the scrambled CRC on the PDCCH. After activating the SPS multicast radio resources, the DU 174 periodically sends multicast transmissions on the SPS multicast radio resources based on the DCI similar to the above-mentioned G-RNTI, but for the SPS radio resources.

[0138] In some implementations, the configuration parameters include a periodicity element indicating a periodicity of the SPS multicast radio resources.

[0139] In some implementations, the configuration parameters include a number of HARQ processes indicating the number of HARQ processes used to transmit SPS multicast transmissions. The DU 174 uses at most the number of HARQ processes to send SPS multicast transmissions, and the UE 102 uses at most the number of HARQ processes to receive SPS multicast transmissions.

[0140] In some implementations, the configuration parameters include SPS multicast radio resources and HARQ codebook IDs for transmissions, as described above with respect to dynamic scheduling. In some implementations, the configuration parameters include a HARQ process ID offset that indicates an offset used when deriving a HARQ process ID for DU 174 to send SPS multicast transmissions and for UE 102 to receive SPS multicast transmissions.

[0141] In some implementations, similar to the parameters described above for dynamic scheduling, the configuration parameters include PUCCH resource configuration, HARQ NACK indication only, HARQ ACK / NACK indication, HARQ ACK indication, aggregation factor, and / or MCS configuration for SPS multicast transmission.

[0142] In some implementations, the configuration parameters include a first multicast DRX configuration (eg, DRX-ConfigPTM-r17 IE) that configures the first multicast DRX operation. The first multicast DRX configuration includes at least one of the following first multicast DRX parameters.

[0143] In some implementations, the multicast DRX configuration includes an on-duration length (value), which is the length of the on-duration of the first multicast DRX cycle. In some implementations. In some implementations, the on-duration length is the drx-onDurationTimerPTM field in the DRX-ConfigPTM-r17 IE.

[0144] In a further implementation, the multicast DRX configuration includes a DRX slot offset that specifies an offset to the first slot (i.e., the starting slot) of the on-duration, e.g., a delay before the start of the on-duration. In some implementations, the DRX offset is the drx-SlotOffsetPTM field in the DRX-ConfigPTM-r17 IE.

[0145] In still further implementations, the multicast DRX configuration includes a DRX inactivity timer (value), which is a duration after a PDCCH opportunity where the DCI indicates a new DL multicast transmission. In some implementations, the DRX inactivity timer value is included in the drx-InactivityTimerPTM field in the DRX-ConfigPTM-r17 IE.

[0146] In yet a further implementation, the multicast DRX configuration includes a DRX cycle length, which is the length of the first multicast DRX cycle. The DRX cycle length specifies a regular repetition of an OnDuration and a subsequent inactive period (eg, OffDuration).

[0147] In a further implementation, the multicast DRX configuration includes a DRX cycle start offset that defines the subframe at which the first multicast DRX cycle starts. In some implementations, the DRX cycle length and the DRX cycle start offset are combined into a composite configuration (e.g., the drx-LongCycleStartOffsetPTM field in the DRX-ConfigPTM-r17 IE). In some such implementations, if [(SFN × 10) + subframe number] modulo (drx-LongCycle-PTM) = drx-StartOffset-PTM, then the UE 102 starts the drx-onDurationTimerPTM timer after drx-SlotOffsetPTM from the start of the subframe.

[0148] In still further implementations, the multicast DRX configuration includes a DRX retransmission timer (value) for multicast, which defines a maximum duration until a DL multicast retransmission is received. In some implementations, the timer value is included in the drx-RetransmissionTimerDL-PTM field in the DRX-ConfigPTM-r17 IE.

[0149] In yet further implementations, the multicast DRX configuration includes a DRX HARQ round trip time (RTT) timer (value) for multicast that defines the minimum duration before a DL multicast assignment for which the UE 102A expects a HARQ retransmission. In some implementations, the timer value is included in the drx-HARQ-RTT-TimerDL-PTM field in the DRX-ConfigPTM-r17 IE.

[0150] In some implementations, DU 174 generates the first multicast DRX configuration based on the QoS configuration parameters for the first MBS session. In other implementations, DU 174 generates the first multicast DRX configuration based on the MBS service characteristics for the first MBS session. In still other implementations, DU 174 generates the first multicast DRX configuration based on the QoS configuration parameters and the MBS service characteristics for the first MBS session.

[0151] In yet other implementations, DU 174 generates a first multicast DRX configuration based on the MBS ID. In some such implementations, the MBS ID is a first MBS session ID. In a further implementation, the MBS ID is an MRB ID of an MRB associated with a first MBS session (ID). In some such implementations, DU 174 is preconfigured with a list of MBS IDs, each MBS ID being associated with a specific multicast DRX configuration. When DU 174 receives the MBS ID in the first CU to DU message of event 506 or the UE context request message of event 522, DU 174 looks up the list with the MBS ID to identify or determine a specific preconfigured multicast DRX configuration. Then, DU 174 generates a first multicast DRX configuration based on the preconfigured multicast DRX configuration. For example, the first multicast DRX configuration may be the same as the preconfigured multicast DRX configuration.

[0152] In some implementations, CU-CP 172A indicates or configures information related to configuring DRX, such as an expected value for at least one of the first multicast DRX parameters, in one of the CU to DU messages of process 592A (e.g., a message of event 506 or 516). In a further implementation, CU-CP 172A includes the expected value in the UE context request message of event 506. In other implementations, CU-CP 172A includes the expected value in a CU to DU message associated with the UE (e.g., a message of event 522 or a third CU to DU message). In such a case, DU 174 uses the expected value of at least one of the first multicast DRX parameters. In some implementations, the first multicast DRX parameter includes a DRX cycle length. If CU-CP 172A does not provide an expected value for a specific multicast DRX parameter in the first multicast DRX parameter, DU 174 determines the value of the specific multicast DRX parameter based on the QoS parameters, MBS service characteristics, and / or MBS ID as described above.

[0153] In some implementations, CU-CP 172A determines whether to configure multicast DRX operation for the MBS session. If CU-CP 172A determines to configure multicast DRX operation for the MBS session, CU-CP 172A includes the expected value for the multicast DRX parameter (e.g., similar to the first multicast DRX parameter) in a CU-to-DU message sent by CU-CP 172A to DU 174. DU 174 generates an MBS DRX configuration for the multicast DRX operation in response to receiving the CU-to-DU message, the CU-to-DU message including the expected value for the multicast DRX parameter. For example, CU-CP 172A determines to configure the first multicast DRX operation for the first MBS session. In response to the determination, CU-CP 172A includes the expected value for the first multicast DRX parameter in the first CU-to-DU message of event 506. DU 174 generates the first MBS DRX configuration in response to receiving the first CU-to-DU message. If CU-CP 172A determines that multicast DRX operation is not configured for the MBS session, CU-CP 172A avoids including the expected value for the multicast DRX parameter in a CU-to-DU message sent by CU-CP 172A to DU 174. DU 174 avoids generating an MBS DRX configuration for the MBS session in response to receiving a CU-to-DU message that excludes the expected value for the multicast DRX parameter. For example, CU-CP 172A determines that multicast DRX operation is not configured for the first MBS session. In response to the determination, CU-CP 172A avoids including the expected value for the multicast DRX parameter in the first CU-to-DU message of event 506. DU 174 avoids generating an MBS DRX configuration for the first MBS session in response to receiving the first CU-to-DU message that excludes the expected value for the multicast DRX parameter.

[0154] UE 102 and DU 174 perform a first multicast DRX operation according to the first multicast DRX configuration. In some implementations, UE 102 and DU 174 transmit 536 MBS data according to the first multicast DRX configuration. For example, DU 174 sends 536 a multicast transmission including MBS data to UE 102 in a time slot within the on-duration in at least one instance of the first multicast DRX cycle. UE 102 receives 536 a multicast transmission from DU 174 in a time slot within the on-duration in at least one instance of the first multicast DRX cycle.

[0155] In some implementations, the first multicast DRX configuration is associated with a G-RNTI or a G-CS-RNTI. The UE 102 uses a MAC entity (e.g., MAC 204B), a G-RNTI or a G-CS-RNTI to non-continuously monitor the PDCCH from the DU 174 according to the first multicast DRX operation and the active time, as described below. The active time includes the time when the drx-onDurationTimerPTM, drx-InactivityTimerPTM or drx-RetransmissionTimerDL-PTM of the G-RNTI or G-CS-RNTI runs. In a further implementation, if the MAC 204B is configured with a DRX HARQ RTT timer value for unicast, the UE 102 starts the drx-HARQ-RTT-TimerDL. Similarly, in an implementation in which the drx-Retransmission TimerDL timer is configured and started, the UE 102 stops the drx-Retransmission TimerDL. If the UE 102 receives a DRX command MAC control element in a transmission of a DCI scheduled on a PDCCH addressed by a G-RNTI or a G-CS-RNTI, the UE 102 stops the drx-onDurationTimerPTM timer for DRX of the G-RNTI.

[0156] Therefore, in some implementations, if the UE 102 receives a MAC PDU according to a configured downlink multicast assignment, if HARQ feedback is enabled, the UE 102 starts a HARQ RTT timer (e.g., drx-HARQ-RTT-TimerDL-PTM timer) for the corresponding HARQ process in the first symbol after the corresponding transmission carrying the DL HARQ feedback ends. Additionally or alternatively, if the MAC entity is configured with a DRX HARQ RTT timer value for unicast, the UE 102 starts a HARQ RTT timer (e.g., drx-HARQ-RTT-TimerDL timer) for the corresponding HARQ process in the first symbol after the corresponding transmission carrying the DL HARQ feedback ends. Then, in a further implementation, the UE 102 stops a retransmission timer (e.g., drx-RetransmissionTimerDL-PTM timer) for the corresponding HARQ process. Additionally or alternatively, if drx-RetransmissionTimerDL is configured and started, the UE 102 stops the drx-RetransmissionTimerDL timer for the corresponding HARQ process. In a further implementation, if the HARQ RTT timer (e.g., drx-HARQ-RTT-TimerDL-PTM timer) expires and if the data of the corresponding HARQ process is not successfully decoded, the UE 102 starts a retransmission timer (e.g., drx-RetransmissionTimerDL-PTM timer) for the corresponding HARQ process in the first symbol after the HARQ RTT timer (e.g., drx-HARQ-RTT-TimerDL-PTM timer) expires.

[0157] In addition, in a further implementation, if the MAC entity is in the active time of the G-RNTI or G-CS-RNTI, the UE 102 monitors the PDCCH of this G-RNTI or G-CS-RNTI (e.g., as specified in 3GPP specification 38.213). In a further implementation, if the PDCCH indicates a DL multicast transmission, if HARQ feedback is enabled, the UE 102 starts a HARQ RTT timer (e.g., drx-HARQ-RTT- TimerDL-PTM timer and / or drx-HARQ-RTT-TimerDL timer) for the corresponding HARQ process in the first symbol after the corresponding transmission carrying the DL HARQ feedback ends. In a further implementation, the UE 102 additionally or alternatively stops a retransmission timer (e.g., drx-RetransmissionTimerDL-PTM timer and / or drx-RetransmissionTimerDL timer) for the corresponding HARQ process. If the PDCCH indicates a new multicast transmission for the G-RNTI or G-CS-RNTI, the UE 102 starts or restarts an inactivity timer (eg, a drx-InactivityTimerPTM timer) in the first symbol after the end of PDCCH reception.

[0158] DU 174 may perform early termination of the on-duration in a specific instance of the first multicast DRX cycle by sending a DRX command to UE 102. To send the DRX command to UE 102, DU 174 generates a MAC PDU including a DRX command and a subheader of the DRX command. To schedule multicast transmission of the MAC PDU, DU 174 generates a DCI, generates a CRC of the DCI, and scrambles the CRC using a G-RNTI or a G-CS-RNTI. DU 174 sends the DCI and the scrambled CRC on the PDCCH and sends a multicast transmission based on the DCI. After receiving the DCI and the scrambled CRC, UE 102 verifies whether the scrambled CRC is valid. In some implementations, if UE 102 verifies that the scrambled CRC is valid, UE 102 receives or attempts to receive the multicast transmission based on the DCI. Then, UE 102 decodes the multicast transmission based on the DCI to obtain a MAC PDU, and retrieves the DRX command from the MAC PDU. Otherwise, if the UE 102 verifies that the scrambled CRC is invalid, the UE 102 avoids receiving or attempting to receive the multicast transmission according to the DCI. In other implementations, the UE 102 receives the multicast transmission according to the DCI before verifying the scrambled CRC. If the UE 102 verifies that the scrambled CRC is valid, the UE 102 decodes or attempts to decode the multicast transmission to obtain the MAC PDU according to the DCI and retrieve the DRX command from the MAC PDU. Otherwise, if the UE 102 verifies that the scrambled CRC is invalid, the UE 102 avoids decoding or attempting to decode the multicast transmission according to the DCI.

[0159] In some implementations, CU-CP 172A includes the MBS session join response message in the RRC reconfiguration message. UE 102 may include the MBS session join completion message in the RRC reconfiguration completion message. Alternatively, UE 102 sends a UL RRC message including the MBS session join completion message to CU-CP 172A via DU 174. The UL RRC message may be a ULInformationTransfer message or any suitable RRC message that may include a UL NAS PDU. In some implementations, CU-CP 172A includes the MBS session join completion message in a second BS to CN message. Alternatively, CU-CP 172A sends a BS to CN message (e.g., an uplink NAS transport message) including the MBS session join completion message to CN 110.

[0160] In other implementations, the CU-CP 172A sends a DL RRC message including an MBS session join response message to the UE 102. The DL RRC message may be a DL Information Transfer message, another RRC reconfiguration message, or any suitable RRC message that may include a DL NAS PDU. The UE 102 sends a UL RRC message including an MBS session join complete message to the CU-CP 172A via the DU 174. The UL RRC message may be a UL Information Transfer message, another RRC reconfiguration complete message, or any suitable RRC message that may include a UL NAS PDU.

[0161] Events 532, 534, and 536 are Figure 5A It is collectively referred to as the MBS session data transmission process 596.

[0162] In some cases where CU-CP 172A does not receive slice information from CN 110, CU-CP 172A includes the preconfigured slice information in the first CP to UP message of event 560. In some cases where CU-CP 172A does not receive slice information from CN 110, CU-CP 172A includes the preconfigured slice information in the first CU to DU message of event 506.

[0163] Figure 5B Shown with Figure 5A Example scenario 500B is similar to scenario 500A shown in FIG. 500B. In scenario 500B, CN 110 sends 503 a first CN to BS message (e.g., a multicast session activation request message) including a first MBS session ID to CU-CP 172A to request CU-CP 172A to configure or activate resources for the first MBS session (i.e., a multicast (MBS) session). In this scenario, CN 110 does not include the MBS QoS flow configuration for the first MBS session in the first CN to BS message. Therefore, CU-CP 172A generates a second MBS QoS flow configuration based on the preconfigured MBS QoS flow configuration. For example, the second MBS QoS flow configuration is the same as the preconfigured MBS QoS flow configuration. In another example, the second MBS QoS flow configuration is similar to the preconfigured MBS QoS flow configuration.

[0164] In some implementations, the CU-CP 172A is pre-configured with a pre-configured MBS QoS flow configuration before receiving the first CN to BS message. In other implementations, the CU-CP 172A receives the pre-configured MBS QoS flow configuration from an operation, administration, and maintenance (OAM) node before receiving the first CN to BS message. The examples or implementations described for the first MBS QoS flow configuration may be applied to the pre-configured MBS QoS flow configuration.

[0165] Events 503, 560, 562, 506, 508, 510, 512, 514, 564, 566, 516, and 518 are Figure 5B This is collectively referred to as the MBS session resource establishment process 592B.

[0166] Figure 5C Shown are FIG. 5A to FIG. 5B Example scenario 500C is similar to scenario 500A-B shown in FIG. 500C. In scenario 500C, CN 110 includes the first MBS QoS flow configuration in the second CN to BS message at event 514. In this case, CN 110 does not include the first MBS QoS flow configuration in the first CN to BS message. After receiving the second CN to BS message, CU-CP 172A sends 560 the first CP to UP message and sends 506 the first CU to DU message to CU-UP 172B and DU 174, respectively. In other words, CU-CP 172A delays sending the first CP to UP message and the first CU to DU message (e.g., delays performing the MC bearer context establishment procedure and the multicast context establishment procedure) until the first MBS QoS flow configuration or the second CN to BS message is received.

[0167] Events 503, 512, 514, 560, 562, 506, 508, 510, 564, 566, 516, and 518 are Figure 5C It is collectively referred to as the MBS session resource establishment process 592C.

[0168] In some implementations, CN 110 includes the first slice information in the second CN to BS message at event 514. In some such cases, CN 110 does not include the first slice information in the first CN to BS message. In some implementations, CN 110 includes the first MBS area information in the second CN to BS message at event 514. In some such cases, CN 110 does not include the first MBS area information in the first CN to BS message.

[0169] Figure 5D Shown are FIG. 5A to FIG. 5CExample scenario 500D similar to the scenarios 500A-C shown in FIG. 500D. In scenario 500D, after sending 503 the first CN to BS message, CN 110 sends 505 a fourth CN to BS message (e.g., a multicast session update request message) including the first MBS session ID and the first MBS QoS flow configuration to CU-CP 172A. After receiving the fourth CN to BS message, CU-CP 172A sends 560 the first CP to UP message and sends 506 the first CU to DU message to CU-UP 172B and DU 174, respectively. In other words, CU-CP 172A delays sending the first CP to UP message and the first CU to DU message (e.g., delays performing the MC bearer context establishment procedure and the multicast context establishment procedure) until the first MBS QoS flow configuration or the fourth CN to BS message is received. In some implementations, CU-CP 172A sends 519 a fourth BS to CN message (e.g., a multicast session update response message) to CN 110 in response to the fourth CN to BS message.

[0170] In some implementations, the CU-CP 172A sends 519 a fourth BS-to-CN message to the CN 110 after receiving 503 the first CN-to-BS message. In other implementations, the CU-CP 172A sends 518 the second BS-to-CN message to the CN 110 before or after receiving 514 the second CN-to-BS message, receiving 566 the second UP-to-CP message, or sending 516 the second CU-to-DU message. In some implementations, the CU-CP 172A sends 518 the second BS-to-CN message to the CN 110 before receiving 505 the fourth CN-to-BS message or sending 519 the fourth BS-to-CN message. In other implementations, the CU-CP 172A sends 518 the second BS-to-CN message to the CN 110 after receiving 505 the fourth CN-to-BS message or sending 519 the fourth BS-to-CN message.

[0171] In some implementations, CN 110 includes the first slice information in a fourth CN to BS message at event 505. In some such cases, CN 110 does not include the first slice information in the first CN to BS message. In some implementations, CN 110 includes the first MBS area information in a fourth CN to BS message at event 505. In some such cases, CN 110 does not include the first MBS area information in the first CN to BS message.

[0172] Figure 5E Shown are FIG. 5A to FIG. 5DExample scenario 500E is similar to the scenarios 500A-D shown in FIG. In scenario 500E, CN 110 includes the first MBS QoS flow configuration in a third CN-to-BS message at event 520, and then CN 110, CU-CP 172A, CU-CP 172A, and DU 174 perform 592E an MBS session resource configuration procedure, which is similar to procedure 592B, except that CU-CP 172A generates a second MBS QoS flow configuration based on the first MBS QoS flow configuration, such as for Figure 5A described.

[0173] In some implementations, CN 110 includes the first slice information in a third CN to BS message at event 520. In some such cases, CN 110 does not include the first slice information in the first CN to BS message. In some implementations, CN 110 includes the first MBS area information in a third CN to BS message at event 520. In some such cases, CN 110 does not include the first MBS area information in the first CN to BS message.

[0174] Fig. 5F Shown are FIG. 5A to FIG. 5E Example scenario 500F is similar to the scenarios 500A-E shown in the example. However, in example scenario 500E, UE 103 joins both the second MBS session (as in example scenario 500A) and the first MBS session (i.e., the same MBS session joined by UE 102 in process 502). RAN 105 or a node of UE 102 identifies the second MBS session by a second MBS session ID (i.e., session ID 2). More specifically, UE 103 may perform 501 an MBS session joining procedure for the second MBS session, and may perform 503 an MBS session joining procedure for the first MBS session. Then, base station 104 and CN 110 perform 591 an MBS session resource establishment procedure for the second MBS session, which is similar to process 592A, 592B, 592C, 592D, or 592E. UE 103, base station 104 and CN 110 perform 593 a UE-specific MBS session configuration procedure for the second MBS session, which is similar to procedure 594. In addition, UE 103, base station 104 and CN perform 595 a UE-specific MBS session configuration procedure for the first MBS session, which is similar to procedure 594.

[0175] UE 103 joins the same MBS session as UE 102 by specifying the same MBS session ID (e.g., the first MBS session ID) in the MBS session join request. In example scenario 500F, UE 103 joins the first MBS session after CN 110 and / or base station 104 have initiated sending 596 MBS data for the first MBS session to UE 102. During or after process 503, CU-CP 172A or CN 110 determines that the DL tunnel for the first MBS session already exists and that process 591 does not need to be performed. CU-CP 172A sends a first RRC reconfiguration message to UE 103 via DU 174 to configure UE 103 to receive MBS services for the second MBS session. In response, UE 103 sends a first RRC reconfiguration complete message to CU-CP 172A via DU 174. The first RRC reconfiguration message may include an LCID (value), an MRB configuration, and an RLC bearer configuration for the second MBS session that are different from the LCID (value), the MRB configuration, and the RLC bearer configuration for the first MBS session.

[0176] Similarly, CU-CP 172A sends a second RRC reconfiguration message to UE 103 to configure UE 103 to receive MBS services for the first MBS session. In response, UE 103 sends a second RRC reconfiguration complete message to CU-CP 172A via DU 174. When UE 102 and 103 operate in the same cell or in different cells, the second RRC reconfiguration message may include the same LCID (value), MRB configuration, and RLC bearer configuration as the LCID (value), MRB configuration, and RLC bearer configuration for UE 102. In some implementations, for example, when UE 102 and 103 operate in different cells, the second RRC reconfiguration message has different G-RNTI, LCID, and / or RLC bearer configuration. Alternatively, when UE 102 and 103 operate in different cells, the second RRC reconfiguration message has the same G-RNTI, LCID, and / or RLC bearer configuration. In a further implementation, when UEs 102 and 103 operate in different cells, the second RRC reconfiguration message includes the same MRB configuration as for UE 102 .

[0177] like Figure 3As shown, CU-UP 172B maps data packets arriving via a common CN to BS DL tunnel to one or more MRBs, each MRB corresponding to a common CU to DU DL tunnel and / or a corresponding logical channel. In addition, depending on the implementation, the RRC reconfiguration message includes the same LCID (value), MRB configuration and / or RLC bearer configuration for the first MBS session for UE 103 as the LCID (value), MRB configuration and / or RLC bearer configuration for the second MBS session for UE 103. Therefore, in such an implementation, UE 103 and UE 102 receive MBS data for the first MBS session via the same logical channel and / or MRB.

[0178] In any case, CN 110 then sends 538, 544 the MBS data for the first MBS session and the MBS data for the second MBS session to CU-UP 172B via different common CN to BS DL tunnels, respectively. CU-UP 172B then sends 540, 546 the MBS data for the first MBS session and the MBS data for the second MBS session to DU 174 via different common CU to DU DL tunnels, respectively. DU 174 sends (e.g., multicasts) 542 the MBS data for the second MBS session to UE 103 via one or more logical channels, and sends (e.g., multicasts) 548 the MBS data for the first MBS session to UE 103 and UE 102 via one or more logical channels. UE 103 receives 548 the MBS data for the first MBS session and receives 542 the MBS data for the second MBS session via multicast, so that UE 103 can receive two MBS data sets for different MBS sessions. The UE 102 may receive 548 the MBS data for the first MBS session via multicast.

[0179] In some implementations, CU-CP 172A includes the second multicast DRX configuration in the first RRC reconfiguration message to configure the second multicast DRX cycle. In other implementations, CU-CP 172A sends a third RRC reconfiguration message including the second multicast DRX configuration to UE 103 via DU 174. In response, UE 103 sends a third RRC reconfiguration complete message to CU-CP 172A via DU 174. DU 174 sends 542 MBS packets for the second MBS session according to the second multicast DRX cycle, and UE 103 sends 542 MBS packets for the second MBS session according to the second multicast DRX cycle.

[0180] In some implementations, CU-CP 172A includes the first multicast DRX configuration in the second RRC reconfiguration message to configure the first multicast DRX cycle. In other implementations, CU-CP 172A sends a fourth RRC reconfiguration message including the first multicast DRX configuration to UE 103 via DU 174. In response, UE 103 sends a fourth RRC reconfiguration complete message to CU-CP 172A via DU 174. DU 174 sends 548 MBS packets for the first MBS session according to the first multicast DRX cycle, and UE 103 receives 548 MBS packets for the first MBS session according to the first multicast DRX cycle.

[0181] Next, refer to Fig. 6A and Figure 6B Discussion can be conducted by Figure 1A and / or Figure 1B The illustrated apparatus implements several example timing diagrams illustrating the timing of message delivery.

[0182] Fig. 6A and Figure 6BExample scenarios 600A and 600B are shown, in which the DRX command shortens the on-duration period. It should be understood that the reference to "stopping the on-duration period" or "shortening the on-duration period" in the present disclosure refers to performing this operation by "stopping the timer associated with the on-duration period". Similar operations for stopping other such periods are performed similarly. Specifically, in scenario 600A, the UE 102 operates according to unicast DRX cycles 602-1, 602-2, and 602-3 (collectively referred to as "unicast DRX cycle 602") and multicast DRX cycles 612-1, 612-2, and 612-3 (collectively referred to as "multicast DRX cycle 612"). Each unicast DRX cycle 602 includes on-duration periods 604-1, 604-2, and 604-3 (collectively referred to as "unicast on-duration periods 604") and disconnection duration periods 606-1, 606-2, and 606-3 (collectively referred to as "unicast disconnection duration periods 606"). Similarly, each of the multicast DRX cycles 612 also includes an on-duration period 614-1, 614-2, and 614-3 (collectively, “multicast on-duration periods 614”) and an off-duration period 616-1, 616-2, and 616-3 (collectively, “multicast off-duration periods 616”). Similarly, in scenario 600B, the UE 102 operates according to a unicast DRX cycle 622-1, 622-2, and 622-3 (collectively, “unicast DRX cycle 622”) having an on-duration period 624-1, 624-2, and 624-3 (collectively, “unicast on-duration periods 624”) and an off-duration period 626-1, 626-2, and 626-3 (collectively, “unicast off-duration periods 626”). Scenario 600B depicts the same multicast DRX cycle 612 shown in scenario 600A. The unicast DRX cycle 622 of scenario 600B is time offset from the unicast DRX cycle of scenario 600A and time aligned with the multicast DRX cycle 612. During the unicast on-duration periods 604, 624 and / or the multicast on-duration period 614, the UE 102 is active to receive signals carrying messages and / or other data from the RAN 105. During the unicast off-duration periods 606, 626 and / or the multicast off-duration period 616, when messages and / or data are not expected, the UE 102 is instead inactive to save power.

[0183] In some implementations, the CU-CP 172A sends the desired DRX cycle length and / or other information about the configured DRX cycle (e.g., desired on-duration length, desired off-duration length, start time, etc.) when communicating with the DU 174, such as described above with respect to FIG. 5A to FIG. 5F600B or 600A. In some implementations, the multicast DRX cycle 612 is specific to an MBS session. In further implementations, multiple MBS sessions share the multicast DRX cycle 612. In further implementations, the unicast DRX cycles 602, 622 are UE-specific. Depending on the implementation, the DU 174 configures the DRX cycle such that the multicast DRX cycle 612 and the unicast DRX cycles 602, 622 of the UE 102 are synchronized according to scenario 600B or are not synchronized according to scenario 600A, as described below.

[0184] In some implementations, when the RAN 105 determines that no data is sent for the UE 102 and / or the base station 104 of the RAN 105 determines that no tunnel or uplink data is sent between the UE 102 and the base station 104, the base station 104 can receive and / or generate a DRX command to perform early termination of the DRX cycle. In some such implementations, the base station 104 sends a MAC PDU scheduled by a DCI with a CRC including the DRX command. As described above, if the UE 102 receives the DRX command using a UE-specific RNTI (such as, C-RNTI or CS-RNTI), the UE 102 determines that the DRX command is for a unicast cycle and terminates the OnDuration early at t3 (or t5) instead of at the regular time t4 (or t6). Similarly, if UE 102 receives the DRX command using an MBS-specific RNTI such as G-RNTI or G-CS-RNTI, UE 102 determines that the DRX command is for a multicast cycle and terminates the OnDuration early at t1 instead of the regular time t2.

[0185] In a further implementation, a node of the RAN 105, such as the base station 104, monitors data traffic of the UE 102 and configures the length of the OnDuration according to the data traffic of either or both of the unicast DRX cycle and / or the multicast DRX cycle.

[0186] In scenario 600A, the unicast DRX cycle 602 is not aligned with the corresponding multicast DRX cycle corresponding portion 612 starting at time t0. Therefore, even though the UE 102 should enter an inactive state during the off-duration period 616-1 according to the multicast DRX cycle 612-1, the UE 102 remains active or quickly becomes active due to the start of the on-duration period 604-1 of the unicast DRX cycle 602-1. Similarly, although the on-duration period 614-2 is stopped at t1 earlier than t2 in response to receiving a DRX command on a MAC PDU scheduled by a DCI having a CRC scrambled by a G-RNTI or G-CS-RNTI, the inactive period requested by the DRX command is shortened due to the start of the on-duration period 604-2 of the unicast DRX cycle. Similarly, in response to receiving a DRX command on a MAC PDU scheduled by a DCI having a CRC scrambled by a C-RNTI or CS-RNTI, the UE 102 stops the OnDuration period 604-2 at t3, which is earlier than t4, but the inactivity of the OffDuration period 606-2 is shortened by the start of the OnDuration period 614-3. Therefore, the unaligned DRX cycle reduces the overall power saving of the UE 102.

[0187] Thus, in some implementations, if a DRX command MAC control element (CE) is received in a transmission of a DCI scheduled on a PDCCH addressed by a G-RNTI or a G-CS-RNTI (i.e., the CRC of the DCI is scrambled by the G-RNTI or the G-CS-RNTI), the UE stops the on-duration timer of DRX (e.g., drx-onDurationTimerPTM) and / or stops the inactivity timer of DRX for the G-RNTI / G-CS-RNTI (e.g., drx-Inactivity TimerPTM).

[0188] In scenario 600B, UE 102 operates according to the same multicast DRX cycle 612, but also according to a set of aligned unicast DRX cycles 622. Since the aligned unicast DRX cycle 622 also starts at t0, the aligned unicast Off Duration period 626 is generally more aligned with the multicast Off Duration period 616, thereby achieving greater uninterrupted inactivity during the respective Off Duration periods. Similarly, even if the Off Duration periods have different starting points, such as, in response to receiving a DRX command, the Off Duration period 626-2 stops at t5, which is earlier than t6, while the Off Duration period 616-2 stops at t1, which is earlier than t2, the resulting inactivity period still has a longer uninterrupted length than the unaligned version described in scenario 600A.

[0189] Next, refer to Figures 7 to 15 Discussion can be conducted by Figure 1A and / or Figure 1B The illustrated apparatus implements several example methods.

[0190] First reference Figure 7 The method 700 may be implemented in a suitable DU and includes generating and sending multicast resources and multicast DRX configuration for an MBS session. For clarity, the method 700 is discussed with specific reference to DU 174, CU 172, CU-CP 172A, CU-UP 172B, CN 110, and UE 102.

[0191] At block 702, DU 174 performs a multicast context procedure with CU 172 for an MBS session (eg, FIG. 5A to FIG. 5F In some implementations, the DU 174 receives session-specific information for the MBS session in the multicast context process, such as the MBS session ID, the MRB ID, the DRX cycle length of the MBS session, and / or the MBS QoS flow configuration, as described above with respect to FIG. 5A to FIG. 5F At block 704, DU 174 generates a multicast resource configuration for the MBS session. At block 706, DU 174 generates a multicast DRX configuration for the MBS session. In implementations where DU 174 receives session-specific information for the MBS session during or before the multicast context procedure, DU 174 generates the multicast resource configuration and / or the multicast DRX configuration based on the session-specific information, such as the DRX cycle length or the QoS flow configuration.

[0192] At block 708, the DU 174 communicates with multiple UEs 102 in an MBS session (e.g., FIG. 5A to FIG. 5F Events 528, 594 of FIG. 10 ), and at block 710, at least one UE context process is performed for each UE 102 and CU 172 to send a multicast resource configuration and a multicast DRX configuration to UE 102 (e.g., FIG. 5A to FIG. 5F In some implementations, the DU 174 performs UE context procedures with the CU 172 for each UE 102 even when the same multicast DRX configuration is sent to each UE 102A, 102B.

[0193] Next reference Figure 8, the method 800 may be implemented in a suitable CU and includes performing a multicast context procedure with the DU to obtain a multicast DRX configuration. For clarity, the method 800 is discussed with specific reference to the DU 174, the CU 172, the CU-CP 172A, the CU-UP 172B, the CN 110, and the UE 102.

[0194] At block 802, CU 172 performs a multicast context procedure with a DU for a first MBS session, similar to Figure 7 At block 804, the CU 172 communicates with the DU 174 and the plurality of UEs 102 (e.g., FIG. 5A to FIG. 5F At block 806, CU 172 and DU 174 perform at least one UE context procedure to obtain multicast resource configuration and multicast DRX configuration, similar to Figure 7 At block 810, the CU 172 sends at least one message (e.g., FIG. 5A to FIG. 5F Event 594 of method 800). In some implementations, CU 172 sends the multicast resource configuration and the multicast DRX configuration for each UE 102 in a single message. In further implementations, CU 172 sends the multicast resource configuration for each UE 102 in a first message and sends the multicast DRX configuration for each UE 102 in a second message. In still further implementations, CU 172 sends a portion of the multicast resource configuration and / or a portion of the multicast DRX configuration for each UE 102 in separate messages. In some implementations, some blocks of method 800 (such as 802 and / or 806) reflect blocks of method 700. Thus, Figure 7 The examples and implementations described in also apply to Figure 8 .

[0195] Next reference Fig. 9 , method 900 can be implemented in a suitable DU and includes determining how to generate a unicast DRX configuration based on whether the UE is configured with an MBS (e.g., multicast) DRX cycle. For clarity, method 900 is discussed with specific reference to DU 174, CU 172, CU-CP 172A, CU-UP 172B, CN 110, and UE 102.

[0196] At block 902, the DU 174 determines to configure a unicast DRX cycle for the UE 102. Depending on the implementation, the DU 174 may determine to configure a unicast DRX cycle in response to an explicit request and / or message from the CU 172 or the UE 102 (e.g., FIG. 5A to FIG. 5F174 unicast DRX cycle configuration. In some implementations, the DU 174 configures the unicast DRX cycle using the unicast DRX cycle configuration. In some such implementations, the DU 174 receives the unicast DRX cycle configuration from the CU 172. In other implementations, the DU 174 is pre-configured with the unicast DRX cycle configuration. In still other implementations, the DU 174 generates a unicast DRX configuration that configures the unicast DRX cycle for the UE 102 based on the characteristics of the data service and / or QoS configuration parameters (such as QoS flow configuration). Depending on the implementation, the DU 174 determines to configure a unicast DRX cycle in response to receiving the data traffic and / or the QoS configuration parameters. In some implementations, the QoS configuration parameters are associated with a PDU session or DRX of the UE 102 .

[0197] At block 904, DU 174 determines whether UE 102 is already configured with an MBS DRX cycle (e.g., a multicast DRX cycle). If UE 102 is configured with an MBS DRX cycle, flow continues to block 906, where DU 174 generates a unicast DRX configuration that configures a unicast DRX cycle that overlaps with the MBS DRX cycle (e.g., Figure 6B 622 and 612). In some implementations, the first unicast DRX cycle and the first MBS DRX cycle partially overlap each other. In other implementations, the first unicast DRX cycle and the first MBS DRX cycle completely overlap each other. In some implementations, DU 174 generates the unicast DRX cycle and the MBS DRX cycle such that one DRX cycle includes the entire other DRX cycle. In some implementations, the first unicast DRX cycle is longer than the first MBS DRX cycle and includes the entire first MBS DRX cycle. In other implementations, the first MBS DRX cycle is longer than the first unicast DRX cycle and includes the entire first unicast DRX cycle. In further implementations, DU 174 generates the unicast DRX cycle and the MBS DRX cycle such that each cycle has a similar and / or identical start time for each on-duration, such as in the above Figure 6BIn still further implementations, the OnDuration period of the first unicast DRX cycle overlaps the OnDuration period of the first MBS DRX cycle. Thus, the UE 102 improves power conservation by reducing the amount of time the UE 102 is required to be in the OnDuration state, as described above.

[0198] If the UE 102 is not configured with an MBS DRX cycle, flow instead continues to block 908, where the DU 174 generates a unicast DRX configuration based on the unicast DRX cycle configuration, as described with respect to block 902. After generating the unicast DRX configuration, the DU 174 sends the unicast DRX configuration (e.g., FIG. 5A to FIG. 5F Depending on the implementation, DU 174 sends the DRX configuration to UE 102 directly or via CU 172.

[0199] Next reference Fig.10 , the method 1000 can be implemented in a suitable DU and includes generating a multicast DRX configuration and a unicast DRX configuration and sending the multicast DRX configuration and the unicast DRX configuration to a first UE and a second UE in a plurality of UEs. For clarity, the method 1000 is discussed with specific reference to the DU 174, the CU 172, the CU-CP 172A, the CU-UP 172B, the CN 110, the first UE 102, and the second UE 103.

[0200] At block 1002, DU 174 determines to configure an MBS DRX cycle (eg, a multicast DRX cycle) for a first MBS session. At block 1004, DU 174 generates a first MBS DRX configuration and a first unicast DRX configuration, similar to Figure 7 706 of the present invention. Similarly, in some implementations, DU 174 generates a first MBS DRX configuration and / or a first unicast DRX configuration based on session-specific information of the MBS session (such as, for example, a DRX cycle length and / or a QoS flow configuration). In a further implementation, DU 174 generates a first MBS DRX configuration and / or a first unicast DRX configuration in response to determining at box 1002 to configure the MBS DRX cycle. Depending on the implementation, DU 174 generates the first MBS DRX configuration and / or the first unicast DRX configuration to update an existing DRX cycle. When UE 102 does not have a DRX cycle, DU 174 generates the first MBS DRX configuration and / or the first unicast DRX configuration to implement a corresponding DRX cycle at UE 102. At box 1006, DU 174 sends the first MBS DRX configuration and the first unicast DRX configuration to the first UE 102, similar to Figure 7Thus, the DU 174 sends the DRX configuration to the first UE 102 directly or via the CU 172, depending on the implementation.

[0201] In some implementations, the first MBS DRX configuration at the first UE 102 configures a first MBS DRX cycle (e.g., a multicast DRX cycle), and the first unicast DRX configuration at the first UE 102 configures the first unicast DRX cycle. In some implementations, the DU 174 configures the DRX cycle such that the first unicast DRX cycle and the first MBS DRX cycle overlap each other (e.g., Figure 6B The cycles 622 and 612). Fig. 9 Other energy-saving DRX timing modes are described.

[0202] In some implementations, the flow ends after block 1006. In other implementations, the flow continues to blocks 1008, 1010, and 1012, each of which is similar to blocks 1002, 1004, and 1006, respectively. At block 1008, DU 174 determines to configure an MBS DRX cycle for the second MBS session. At block 1010, DU 174 generates a second MBS DRX configuration and a second unicast DRX configuration. At block 1012, DU 174 sends the second MBS DRX configuration and the second unicast DRX configuration to the second UE 103 directly or via CU 172.

[0203] In some implementations, the second MBS DRX configuration at the second UE 103 configures a second MBS DRX cycle, and the second unicast DRX configuration at the second UE 103 configures a second unicast DRX cycle. In some implementations, the DU 174 configures the DRX cycle such that the second unicast DRX cycle and the second MBS DRX cycle overlap each other, as shown in FIG. Fig. 9 The timing patterns are described with respect to the first unicast DRX cycle and the first MBS DRX cycle.

[0204] In an implementation where the first UE 102 and the second UE 103 are the same UE, DU 174 generates a second unicast DRX configuration to update the first unicast DRX configuration. In some implementations, DU 174 configures the DRX cycle so that the second unicast DRX cycle partially overlaps both the first MBS DRX cycle and the second MBS DRX cycle. In other implementations, DU 174 configures the DRX cycle so that the second unicast DRX cycle completely overlaps both the first MBS DRX cycle and the second MBS DRX cycle. In some implementations, the second unicast DRX cycle is longer than the first MBS DRX cycle and the second MBS DRX cycle and includes the first MBS DRX cycle and the second MBS DRX cycle.

[0205] In some implementations, DU 174 configures the DRX cycle so that the second MBS DRX cycle does not overlap with the first MBS DRX cycle. In other implementations, DU 174 configures the DRX cycle so that the second MBS DRX cycle overlaps with the first MBS DRX cycle. In some implementations, the first MBS DRX cycle is longer than the second MBS DRX cycle and includes the entire second MBS DRX cycle. In other implementations, the second MBS DRX cycle is longer than the first MBS DRX cycle and includes the entire first MBS DRX cycle.

[0206] Next reference Fig.11A , method 1100A may be implemented in a suitable DU and includes determining whether to generate and send a multicast DRX configuration based on whether the UE is configured with an MRB. For clarity, method 1100A is discussed with specific reference to DU 174, CU 172, CU-CP 172A, CU-UP 172B, CN 110, and UE 102.

[0207] At block 1102, DU 174 communicates with UE 102 and CU 172 (e.g., FIG. 5A to FIG. 5F Then, at block 1104, DU 174 determines whether UE 102 is configured with MRB. In some implementations, DU 174 determines whether UE 102 is configured with MRB based on parameters and / or information provided from CU 172. In further implementations, DU 174 determines whether UE 102 is configured with MRB based on information and / or data from UE 102 and / or without input from CU 172. If UE 102 is configured with MRB, flow continues to block 1106, where DU 174 sends a multicast DRX configuration to UE 102, similar to Fig. 9Otherwise, if UE 102 is not configured with MRB, the process skips block 1106 and proceeds to block 1108, where DU 174 sends a unicast DRX configuration to UE 102, also similar to Fig. 9 910. Depending on the implementation, the DU 174 sends the multicast DRX configuration and / or the unicast DRX configuration to the UE 102 directly or via the CU 172. In some implementations, the DU 174 sends the multicast DRX configuration and the unicast DRX configuration in the same message. In further implementations, the DU 174 sends the multicast DRX configuration and the unicast DRX configuration or portions of each DRX configuration in separate messages.

[0208] Next reference Fig. 11B , method 1100B is similar to method 1100A, but the determination is based on whether the UE is configured with MRB or DRB. Specifically, Fig. 11B Boxes 1102, 1106 and 1108 of Fig.11A 1103, 1106 and 1108 are similar. Therefore, Fig.11A The examples and implementations described in also apply to Fig. 11B .

[0209] At block 1102, DU 174 communicates with UE 102 and CU 172. At block 1103, DU 174 determines whether UE 102 is configured with MRB or DRB, similar to Fig.11A If the UE 102 is configured with an MRB, the process continues to block 1106, where the DU 174 sends the multicast DRX configuration to the UE 102 directly or via the CU 172. Otherwise, if the UE 102 is configured with a DRB, the process continues to block 1108, where the DU 174 sends the unicast DRX configuration to the UE 102 directly or via the CU 172.

[0210] Next reference Fig. 12A , the method 1200A can be implemented in a suitable DU and includes receiving a multicast DRX cycle configuration and a unicast DRX cycle configuration and generating a multicast DRX configuration and a unicast DRX configuration based on the multicast DRX cycle configuration and the unicast DRX cycle configuration. For clarity, the method 1200A is discussed with specific reference to the DU 174, the CU 172, the CU-CP 172A, the CU-UP 172B, the CN 110, and the UE 102.

[0211] At block 1202, the DU 174 receives a multicast DRX cycle configuration (eg, FIG. 5A to FIG. 5FEvent 506, 516, 522, 592A-F or 594). Similarly, at box 1204, DU 174 receives a unicast DRX cycle configuration from CU 172. Depending on the implementation, DU 174 receives the multicast DRX cycle configuration and the unicast DRX cycle configuration in the same message, in a separate message and / or as part of the multicast DRX cycle configuration and / or the unicast DRX cycle configuration in a separate message. In some implementations, the multicast DRX cycle configuration and / or the unicast DRX cycle configuration include a cycle length, an on duration length and / or a off duration length of the multicast DRX cycle and / or the unicast DRX cycle, respectively. At box 1206, DU 174 generates a multicast DRX configuration based on the multicast DRX cycle configuration. Similarly, at box 1208, DU 174 generates a unicast DRX configuration based on the unicast DRX cycle configuration. At block 1210, DU 174 sends a multicast DRX configuration (eg, FIG. 5A to FIG. 5F Similarly, at block 1212, DU 174 sends the unicast DRX configuration to CU 172. Depending on the implementation, DU 174 sends the multicast DRX configuration and the unicast DRX configuration in the same message, in separate messages, and / or as part of the multicast DRX configuration and / or the unicast DRX configuration in separate messages.

[0212] Similarly, refer to Fig. 12B , method 1200B is similar to method 1200A, but wherein the multicast DRX configuration and the unicast DRX configuration are based on the same DRX cycle configuration. Specifically, blocks 1203, 1207, 1209, 1210, and 1212 are similar to Fig. 12A 1202, 1206, 1208, 1210 and 1212. Therefore, Fig. 12A The examples and implementations described in also apply to Fig. 12B The differences between method 1200B and method 1200A are described in more detail below.

[0213] At block 1203, DU 174 receives a single DRX cycle configuration from CU 172, instead of separate multicast DRX cycle configurations and unicast DRX cycle configurations. At block 1207, DU 174 generates a multicast DRX configuration based on the DRX cycle configuration. Similarly, at block 1209, DU 174 generates a unicast DRX configuration based on the same DRX cycle configuration. Thus, DU 174 generates a multicast DRX configuration and a unicast DRX configuration based on the same general DRX cycle configuration, instead of based on a specific multicast DRX cycle configuration and / or unicast DRX cycle configuration. At blocks 1210 and 1212, DU 174 sends the multicast DRX configuration and the unicast DRX configuration, respectively, to CU 172, similar to Fig. 12A .

[0214] Next reference Fig.13A , method 1300A is similar to method 1200A, but is implemented in a CU and from a CU perspective instead. Specifically, blocks 1302, 1304, 1306, and 1308 are similar to Fig. 12A 1202, 1204, 1210 and 1212. Therefore, Fig. 12A The examples and implementations described in also apply to Fig.13A .

[0215] At block 1302, CU 172 sends a multicast DRX cycle configuration to DU 174 to cause DU 174 to generate a multicast DRX configuration, such as Fig. 12A Similarly, CU 172 sends a unicast DRX cycle configuration to DU 174 so that DU 174 generates a unicast DRX configuration, as described in relation to block 1206 of FIG. Fig. 12A Depending on the implementation, the CU 172 sends the multicast DRX cycle configuration and the unicast DRX cycle configuration in the same message, in separate messages, or as part of the multicast DRX cycle configuration and / or the unicast multicast DRX cycle configuration in separate messages.

[0216] At block 1306, CU 172 receives a first DU-CU message including a multicast DRX configuration from DU 174. Similarly, at block 1308, CU 172 receives a second DU-CU message including a multicast DRX configuration from DU 174. In some implementations, the first DU-CU message and the second DU-CU message are the same message, and CU 172 receives the multicast DRX configuration and the unicast DRX configuration together. In a further implementation, the first DU-CU message and the second DU-CU message are separate messages. In a still further implementation, the first DU-CU message and the second DU-CU message are the first DU-CU message in the first plurality of messages and the second DU-CU message in the second plurality of messages. Thus, each message in the first plurality of messages includes a portion of the multicast DRX configuration, and each message in the second plurality of messages includes a portion of the unicast DRX configuration.

[0217] At block 1310, CU 172 sends a first message, such as an RRC message (eg, FIG. 5A to FIG. 5F At block 1312, CU 172 sends a second message (e.g., FIG. 5A to FIG. 5F Similar to blocks 1306 and 1308, the first message and the second message are the same message, different messages, or a first message in the first plurality of messages and a second message in the second plurality of messages, depending on the implementation.

[0218] Similarly, refer to Fig. 13B , method 1300B is similar to method 1300A, but the CU sends a single DRX cycle configuration to the DU to generate a multicast DRX configuration and a unicast DRX configuration. Specifically, blocks 1303, 1306, 1308, 1310, and 1312 are similar to Fig.13A 1302, 1306, 1308, 1310 and 1312. Therefore, Fig.13A The examples and implementations described in also apply to Fig. 13B The differences between method 1300B and method 1300A are described in more detail below.

[0219] At block 1303, CU 172 sends a single DRX cycle configuration to DU 174 so that DU 174 generates both a multicast DRX configuration and a unicast DRX configuration. Thus, DU 174 generates both a multicast DRX configuration and a unicast DRX configuration based on the same DRX cycle configuration, rather than a multicast-specific or unicast-specific DRX configuration. At block 1306, CU 172 receives a first DU-to-CU message including the multicast DRX configuration from DU 174. At block 1308, CU 172 receives a second DU-to-CU message including the unicast DRX configuration from DU 174. At block 1310, CU 172 sends a first message including the DRX configuration to UE 102 via DU 174. At block 1312, CU 172 sends a second message including the unicast DRX configuration to UE 102 via DU 174.

[0220] Next reference Fig.14 , the method 1400 may be implemented in a suitable DU and includes managing DRX for an MBS session. For clarity, the method 1400 is discussed with specific reference to the DU 174, CU 172, CU-CP 172A, CU-UP 172B, CN 110, and UE 102.

[0221] At block 1402, the DU 174 receives DRX configuration data (eg, FIG. 5A to FIG. 5F , Figure 7 and Figures 9 to 12B At block 1404, the DU 174 generates a DRX configuration for the MBS session based at least on the DRX configuration data (e.g., FIG. 5A to FIG. 5F , Figure 7 and Figures 9 to 12B At block 1406, DU 174 sends a DRX configuration to UE 102 for the MBS session (e.g., FIG. 5A to FIG. 5F , Figure 7 and Figures 9 to 12B Event 528 or 594 and boxes 710, 910, 1006, 1012, 1106, 1108, 1210 or 1212).

[0222] Next reference Fig.15, the method 1500 may be implemented in a suitable CU and includes managing DRX for an MBS session. For clarity, the method 1500 is discussed with specific reference to the DU 174, CU 172, CU-CP 172A, CU-UP 172B, CN 110, and UE 102.

[0223] At block 1502, CU 172 receives an indication from CN 110 to activate an MBS session (eg, FIG. 5A to FIG. 5F At block 1504, CU 172 determines DRX configuration data for the MBS session (e.g., FIG. 5A to FIG. 5F , Figure 8 , Fig.13A and Fig. 13B At block 1506, CU 172 sends DRX configuration data to DU 174 to cause DU 174 to generate a multicast DRX configuration for UE 102 (e.g., FIG. 5A to FIG. 5F , Figure 8 , Fig.13A and Fig. 13B Event 506, 516, 522, 592A-F or 594 and box 802 / 804, 1302, 1303 or 1304).

[0224] The following list of examples reflects the various embodiments expressly contemplated by the present disclosure:

[0225] Example 1. A method for managing discontinuous reception (DRX) of a multicast and broadcast service (MBS) session, the method being implemented in a distributed unit (DU) of a distributed base station operating in a radio access network (RAN) and comprising: receiving, by processing hardware, information related to configuring DRX for the MBS session from a central unit (CU) of the distributed base station; generating, by the processing hardware, a DRX configuration for a user equipment (UE) participating in the MBS session based at least on the information related to configuring DRX; and sending, by the processing hardware, the DRX configuration to the UE.

[0226] Example 2. A method as described in Example 1, wherein receiving the information related to configuring DRX for the MBS session includes: receiving at least one of the following from the CU: (i) DRX cycle length, (ii) on-duration period length, (iii) expected multicast DRX cycle length, (iv) expected on-duration period length, or (v) start period.

[0227] Example 3. A method as described in Example 1 or 2, wherein receiving the information related to configuring DRX for the MBS session includes: receiving the information related to configuring DRX in at least one of the following: (i) a multicast context establishment message, (ii) a multicast distribution message, (iii) a UE context establishment message, or (iv) a multicast configuration message.

[0228] Example 4. A method as described in any of the preceding examples, wherein the UE is a first UE among a plurality of UEs, the method further comprising: sending the DRX configuration to each of the plurality of UEs.

[0229] Example 5. The method of Example 4, wherein sending the DRX configuration to each of the plurality of UEs is in response to determining that the DRX configuration is a multicast DRX configuration.

[0230] Example 6. A method as described in any of the preceding examples, wherein: generating the DRX configuration is based at least on whether the UE is configured with a multicast DRX cycle.

[0231] Example 7. A method as described in Example 1, wherein the DRX configuration is a unicast DRX configuration, and generating the DRX configuration includes: in response to determining that the UE is configured with a multicast DRX cycle, generating the unicast DRX configuration so that an on-duration period of the unicast DRX cycle configuration corresponding to the unicast DRX cycle overlaps with at least a portion of the on-duration period of the multicast DRX cycle.

[0232] Example 8. The method of Example 1, wherein the DRX configuration is a unicast DRX configuration, and generating the DRX configuration comprises: in response to determining that the UE is not configured with a multicast DRX cycle, generating the unicast DRX configuration according to a unicast DRX cycle configuration.

[0233] Example 9. The method of Example 7, wherein receiving the information related to configuring DRX comprises: receiving the unicast DRX cycle configuration from the CU.

[0234] Example 10. The method of Example 7, wherein the DU is pre-configured with the unicast DRX cycle configuration.

[0235] Example 11. The method as described in Example 7, wherein receiving the information related to configuring DRX includes: receiving QoS configuration parameters for the UE from a core network (CN); wherein generating the unicast DRX configuration includes: generating the unicast DRX cycle configuration using at least the QoS configuration parameters.

[0236] Example 12. The method of Example 11, wherein the QoS configuration parameter is associated with at least one of: (i) a PDU session or (ii) a DRX cycle of the UE.

[0237] Example 13. The method as described in any one of Examples 11 or 12 further includes: receiving data traffic from the UE; and generating the unicast DRX cycle configuration using at least the data traffic from the UE.

[0238] Example 14. The method of Example 13, wherein generating the unicast DRX cycle configuration comprises: generating an OnDuration length of an OnDuration period of the unicast DRX cycle based on at least one of: (i) the data traffic and (ii) the QoS configuration parameter.

[0239] Example 15. The method of Example 13 or 14, further comprising: generating an OnDuration length of an OnDuration period of the multicast DRX cycle based on at least one of: (i) the data traffic and (ii) the QoS configuration parameter.

[0240] Example 16. The method of Example 1, wherein the DRX configuration is a multicast DRX configuration, the method further comprising: generating a unicast DRX configuration based at least on the information related to configuring DRX; and sending the unicast DRX configuration to the first UE.

[0241] Example 17. The method as described in Example 16 further includes: generating a multicast DRX cycle for the UE; and generating a unicast DRX cycle for the UE, the unicast DRX cycle at least partially overlapping with the multicast DRX cycle; and providing at least one of the multicast DRX cycle and the unicast DRX cycle to the UE.

[0242] Example 18. A method as described in Example 16 or 17, wherein the MBS session is a first MBS session, the multicast DRX configuration is a first multicast DRX configuration, the unicast DRX configuration is a first unicast DRX configuration, and the information related to configuring DRX is first information related to configuring DRX for the first MBS session, the method further comprising: receiving second information related to configuring DRX for a second MBS session from the CU; generating a second multicast DRX configuration based at least on the second information related to configuring DRX; and generating a second unicast DRX configuration based at least on the second information related to configuring DRX.

[0243] Example 19. The method of Example 18, wherein the UE is a first UE among a plurality of UEs, the method further comprising: sending the second multicast DRX configuration and the second unicast DRX configuration to a second UE among the plurality of UEs.

[0244] Example 20. The method of Example 18 or 19, further comprising: configuring a second multicast DRX cycle for the second UE using the second multicast DRX configuration; and configuring a second unicast DRX cycle for the second UE using the second unicast DRX configuration.

[0245] Example 21. The method of Example 20, wherein the second multicast DRX cycle and the second unicast DRX cycle at least partially overlap.

[0246] Example 22. The method of Example 18, wherein the first UE and the second UE are a single UE, the method further comprising: sending the second unicast DRX configuration to the single UE to update the first unicast DRX configuration with the second unicast DRX configuration.

[0247] Example 23. The method of Example 22, wherein the second unicast DRX cycle at least partially overlaps with the first multicast DRX cycle and the second multicast DRX cycle.

[0248] Example 24. The method of Example 22, wherein the second unicast DRX cycle at least partially overlaps with the first multicast DRX cycle.

[0249] Example 25. The method of Example 22, wherein the second unicast DRX cycle does not overlap with the first multicast DRX cycle.

[0250] Example 26. The method of any one of Examples 22 to 25, wherein the first multicast DRX cycle includes the entire second multicast DRX cycle.

[0251] Example 27. The method of any one of Examples 22 to 25, wherein the second multicast DRX cycle includes the entire first multicast DRX cycle.

[0252] Example 28. The method of Example 1, wherein the DRX configuration is a unicast DRX configuration, the method further comprising: determining whether to generate a multicast DRX configuration based on whether the UE is configured with an MRB.

[0253] Example 29. The method of Example 28, wherein determining whether to generate a multicast DRX configuration comprises: determining to generate the multicast DRX configuration when the UE is configured with an MRB; and determining to avoid generating the multicast DRX configuration when the UE is not configured with an MRB.

[0254] Example 30. The method as described in Example 1 further includes: generating the DRX configuration based at least on whether the UE is configured with an MRB or a DRB.

[0255] Example 31. The method of Example 30, wherein generating the DRX configuration comprises: when the UE is configured with an MRB, determining to generate the DRX configuration as a multicast DRX configuration.

[0256] Example 32. The method of Example 30, wherein generating the DRX configuration comprises: when the UE is configured with a DRB, determining to generate the DRX configuration as a unicast DRX configuration.

[0257] Example 33. A method as described in Example 1, wherein: the information related to configuring DRX includes a multicast DRX cycle configuration and a unicast DRX cycle configuration, the DRX configuration includes a multicast DRX configuration and a unicast DRX configuration, and generating the DRX configuration includes: generating the multicast DRX configuration based on the multicast DRX cycle configuration, and generating the unicast DRX configuration based on the unicast DRX cycle configuration.

[0258] Example 34. The method of Example 33, wherein the multicast DRX cycle configuration comprises a multicast DRX cycle length, and the unicast DRX cycle configuration comprises a unicast DRX cycle length.

[0259] Example 35. A method as described in Example 1, wherein: the information includes a DRX cycle configuration, the DRX configuration includes a multicast DRX configuration and a unicast DRX configuration, and generating the DRX configuration includes: generating the multicast DRX configuration based on the DRX cycle configuration, generating the unicast DRX configuration based on the DRX cycle configuration.

[0260] Example 36. The method of Example 35, wherein the DRX cycle configuration includes a DRX cycle length.

[0261] Example 37. The method as described in any one of Examples 33 to 36 further includes: sending the multicast DRX configuration and the unicast DRX configuration to the CU.

[0262] Example 38. A distributed unit (DU) of a distributed base station, the DU configured to operate in a radio access network (RAN), the DU comprising processing hardware and configured to implement a method according to any one of Examples 1 to 37.

[0263] Example 39. A method for managing discontinuous reception (DRX) of a multicast and broadcast service (MBS) session, the method being implemented in a central unit (CU) of a distributed base station operating in a radio access network (RAN), the method comprising: receiving, by processing hardware, an indication to activate the MBS session from a core network (CN); determining, by the processing hardware, information related to configuring DRX for the MBS session; and sending, by the processing hardware, the information related to configuring the DRX to a distributed unit (DU) of the RAN.

[0264] Example 40. The method of Example 39, wherein receiving the indication to activate the MBS session from the CN comprises: receiving an MBS Quality of Service (QoS) configuration parameter from the CN; wherein determining the information related to configuring DRX is based at least on the MBS QoS configuration parameter.

[0265] Example 41. A method as described in Example 39, further comprising: sending a request for information related to the MBS session to the CN; and receiving MBS QoS configuration parameters from the CN in response to sending the request for information related to the MBS session; wherein determining the information related to configuring DRX is based at least on the MBS QoS configuration parameters.

[0266] Example 42. The method of Example 39, further comprising: after receiving the indication, receiving an update related to the MBS session from the CN from the CN, the update comprising an MBS QoS configuration parameter; wherein determining the information related to configuring DRX is based at least on the MBS QoS configuration parameter.

[0267] Example 43. The method of Example 39, further comprising: receiving an MBS QoS configuration parameter from the CN before receiving the indication; wherein determining the information related to configuring DRX is based at least on the MBS QoS configuration parameter.

[0268] Example 44. A method as described in any one of Examples 39 to 43, wherein the information related to configuring DRX includes at least one of the following: (i) MBS QoS flow configuration, (ii) MBS slice information, or (iii) MBS service area information.

[0269] Example 45. The method of Example 39, wherein determining the information related to configuring DRX is based at least on preconfigured MBS QoS configuration parameters.

[0270] Example 46. The method of Example 45, wherein the preconfigured MBS QoS configuration parameters are preconfigured at the DU.

[0271] Example 47. A method as described in any one of Examples 39 to 46, wherein the indication is a first indication, the MBS session is a first MBS session, the information related to configuring DRX is first information related to configuring DRX for the first MBS session, and the method further includes: receiving a second indication to activate a second MBS session from the CN; determining second information related to configuring DRX for the second MBS session; and sending the second information related to configuring DRX to the DU.

[0272] Example 48. A method as described in any one of Examples 39 to 47, further comprising: receiving a multicast DRX configuration from the DU; and sending the multicast DRX configuration to the UE in at least one message via the DU.

[0273] Example 49. The method of Example 48, wherein the UE is a first UE of a plurality of UEs, and sending the multicast DRX configuration comprises sending the multicast DRX configuration to each of the plurality of UEs in at least one message for each of the plurality of UEs.

[0274] Example 50. A method as described in any one of Examples 39 to 47, further comprising: receiving a first multicast DRX configuration from the DU; sending the first multicast DRX configuration to at least a first UE among a plurality of UEs; receiving a second multicast DRX configuration from the DU; and sending the second multicast DRX configuration to at least a second UE among the plurality of UEs.

[0275] Example 51. The method of Example 50, wherein the first multicast DRX configuration and the second multicast DRX configuration have at least one of: (i) different DRX cycle lengths or (ii) different DRX cycle on-duration periods.

[0276] Example 52. The method of Example 50, wherein the first multicast DRX configuration and the second multicast DRX configuration have at least one of: (i) the same DRX cycle length or (ii) the same DRX Cycle OnDuration period.

[0277] Example 53. A method as described in Example 39, wherein the information related to configuring DRX is multicast information related to configuring DRX, and the method further includes: determining, by the processing hardware, unicast information related to configuring DRX for the MBS session; and sending, by the processing hardware, the unicast information related to configuring DRX to the DU, so that the DU generates a unicast DRX configuration for the UE.

[0278] Example 54. The method of Example 39, wherein sending the information related to configuring DRX to the DU comprises: causing the DU to generate a unicast DRX configuration by sending the information related to configuring DRX to the DU.

[0279] Example 55. The method as described in Example 53 or 54 further includes: receiving a multicast DRX configuration and the unicast DRX configuration from the DU; sending a first message including the multicast DRX configuration to the DU; and sending a second message including the unicast DRX configuration to the DU.

[0280] Example 56. A method as described in any one of Examples 39 to 55, wherein the information related to configuring DRX includes a DRX cycle length of the DRX cycle.

[0281] Example 57. The method of any one of Examples 39 to 55, wherein the information related to configuring DRX includes (i) a multicast DRX cycle length of a multicast DRX cycle and (ii) a unicast DRX cycle length of a unicast DRX cycle.

[0282] Example 58. A central unit (CU) of a distributed base station, the CU being configured to operate in a radio access network (RAN), the CU comprising processing hardware and being configured to implement a method according to any one of Examples 39 to 57.

[0283] The following additional considerations apply to the foregoing discussion.

[0284] In general, the description of one of the above figures may apply to another of the above figures. The events or boxes described above may be optional or omitted. For example, the events or boxes with dashed lines in the figures may be optional or omitted. In some cases, if the events or boxes with solid lines in the figures are not required, the events or boxes may still be optional or omitted. In some implementations, "message" is used and "information element (IE)" can be used to replace "message". In some implementations, "IE" is used and "field" can be used to replace "IE". In some implementations, "configuration" or configuration parameters can be used to replace "configuration". In some implementations, "multicast" or "broadcast" can be used to replace "MBS". In some implementations, "multicast SPS" can be used to replace "SPS multicast". Similarly, "multicast dynamic" can be used to replace "dynamic scheduling multicast". In some implementations, "identification" can be used to replace "identifier". In some implementations, "CFR" is used and "MBS BWP" can be used to replace "CFR". In some implementations, the term "transport layer configuration" may be replaced with "tunnel information" or "transport layer information".

[0285] The user device (e.g., UE 102A, 102B, or UE 103) in which the technology of the present disclosure can be implemented can be any suitable device capable of wireless communication, such as a smart phone, a tablet computer, a laptop computer, a mobile game 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 smart watch), a wireless hotspot, a femtocell, or a broadband router. In addition, in some cases, the user device can be embedded in an electronic system, such as a head unit or an advanced driver assistance system (ADAS) of a vehicle. Further, the user device can be operated as an Internet of Things (IoT) device or a mobile Internet device (MID). Depending on the type, the user device may include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0286] Certain embodiments are described in the present disclosure as including logic or multiple 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 that is capable of performing certain operations and may be configured or arranged in a particular manner. A hardware module may include a dedicated circuit system or logic that is permanently configured (e.g., as a dedicated processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware module may also include programmable logic or circuit systems (e.g., contained within a general-purpose processor or other programmable processor) that are temporarily configured by software to perform certain operations. The decision to implement a hardware module with a dedicated and permanently configured circuit system or with a temporarily configured circuit system (e.g., configured by software) may be driven by cost and time considerations.

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

[0288] After reading this disclosure, those skilled in the art will understand the additional alternative structural and functional designs for performing the HARQ process to send MBS data through the principles disclosed herein. Therefore, although specific embodiments and applications have been shown and described, it should be understood that the disclosed embodiments are not limited to the precise construction and components disclosed herein. Various modifications, changes and variations that will be obvious to those of ordinary skill in the art may be made to the arrangement, operation and details of the methods and devices disclosed herein without departing from the spirit and scope defined in the appended claims.

Claims

1. A method for managing discontinuous reception (DRX) of a multicast and broadcast service (MBS) session, the method being implemented in a distributed unit (DU) of a distributed base station operating in a radio access network (RAN) and comprising: receiving, from a central unit CU of the distributed base station, information related to whether the UE is configured with a multicast DRX cycle for the MBS session; generating a DRX configuration for a user equipment UE participating in the MBS session based at least on the information related to configuring the DRX; as well as Sending the DRX configuration to the UE.

2. The method of claim 1, wherein the DRX configuration is a unicast DRX configuration, and generating the DRX configuration comprises: When the UE is configured with a multicast DRX cycle, the unicast DRX configuration is generated such that an OnDuration period of a unicast DRX cycle configuration corresponding to the unicast DRX cycle overlaps at least a portion of an OnDuration period of the multicast DRX cycle.

3. The method of claim 1, wherein the DRX configuration is a unicast DRX configuration, and generating the DRX configuration comprises: When the UE is not configured with a multicast DRX cycle, the unicast DRX configuration is generated according to a unicast DRX cycle configuration.

4. The method according to claim 2, wherein receiving the information related to configuring DRX comprises: receiving QoS configuration parameters for the UE from a core network CN; The generating of the unicast DRX configuration comprises: The unicast DRX cycle configuration is generated using at least the QoS configuration parameters.

5. The method of claim 1, wherein the DRX configuration is a multicast DRX configuration, the method further comprising: generating a unicast DRX configuration based at least on the information related to configuring DRX; as well as The unicast DRX configuration is sent to the UE.

6. The method of claim 5, further comprising: generating a multicast DRX cycle for the UE; as well as generating a unicast DRX cycle for the UE, the unicast DRX cycle at least partially overlapping with the multicast DRX cycle; as well as At least one of the multicast DRX cycle and the unicast DRX cycle is provided to the UE.

7. The method of claim 1, wherein: The information related to configuring DRX includes multicast DRX cycle configuration and unicast DRX cycle configuration, The DRX configuration includes a multicast DRX configuration and a unicast DRX configuration, and Generating the DRX configuration includes: generating the multicast DRX configuration based on the multicast DRX cycle configuration, and The unicast DRX configuration is generated based on the unicast DRX cycle configuration.

8. The method of claim 1, wherein: The information includes DRX cycle configuration, The DRX configuration includes a multicast DRX configuration and a unicast DRX configuration, and Generating the DRX configuration includes: generating the multicast DRX configuration based on the DRX cycle configuration, The unicast DRX configuration is generated based on the DRX cycle configuration.

9. A method for managing discontinuous reception (DRX) of a multicast and broadcast service (MBS) session, the method being implemented in a central unit (CU) of a distributed base station operating in a radio access network (RAN), the method comprising: receiving an indication to activate the MBS session from a core network CN; Determining information related to configuring DRX for the MBS session; as well as The information related to configuring DRX is sent to a distributed unit DU of the RAN.

10. The method of claim 9, wherein receiving the indication to activate the MBS session from the CN comprises: Receiving MBS quality of service (QoS) configuration parameters from the CN; The information related to configuring DRX is determined based on at least an MBS QoS configuration parameter.

11. The method of claim 9, further comprising: sending a request to the CN for information related to the MBS session; as well as receiving MBS QoS configuration parameters from the CN in response to sending the request for information related to the MBS session; The information related to configuring DRX is determined based at least on the MBS QoS configuration parameter.

12. The method of claim 9, further comprising: receiving, from the CN after receiving the indication, an update related to the MBS session from the CN, the update comprising MBS QoS configuration parameters; The information related to configuring DRX is determined based at least on the MBS QoS configuration parameter.

13. The method of claim 9, further comprising: receiving MBS QoS configuration parameters from the CN before receiving the indication; The information related to configuring DRX is determined based at least on the MBS QoS configuration parameter.

14. The method according to claim 9, wherein the information related to configuring DRX is multicast information related to configuring DRX, and the method further comprises: Determining, by the processing hardware, unicast information of the MBS session related to configuring DRX; The processing hardware sends the unicast information related to configuring DRX to the DU, so that the DU generates a unicast DRX configuration for the UE.

15. A network node comprising processing hardware and configured to implement the method according to any one of the preceding claims.

Images