Managing discontinuous reception of multicast and / or broadcast services

Abstract

A user equipment participating in a multicast and broadcast service (MBS) session may implement a method for managing discontinuous reception (DRX) for the MBS session. The method comprises: (i) receiving, by processing hardware, an MBS session transmission comprising a DRX command; (ii) determining, by the processing hardware, whether the DRX command belongs to a multicast DRX cycle or a unicast DRX cycle; and (iii) modifying, by the processing hardware, the DRX operation of the UE in accordance with the determination.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to and the benefit of provisional U.S. patent application No. 63 / 359,826, filed on July 9, 2022, entitled “MANAGING DISCONTINUOUS RECEPTION OF MULTICAST AND / OR BROADCAST SERVICES”, the entire contents of which are hereby expressly incorporated herein by reference. Technical Field

[0003] The present disclosure relates to wireless communications, and more particularly to enabling discontinuous reception of one or more multicast and / or broadcast services (MBS) via multicast transmissions. 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 in accordance with the fifth generation (5G) New Radio (NR) requirements support much 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 enables 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 the 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 to a dedicated group of UEs at the same time (i.e., not all UEs in the multicast service area are authorized to receive the data). The base station delivers the multicast communication service to the UE using a multicast session. 5G NR provides both a point-to-point (PTP) delivery method and a point-to-multipoint (PTM) delivery method for the transmission of MBS packet streams over the radio interface. In PTP communication, the RAN node transmits different copies of each MBS data packet to different UEs over the radio interface. On the other hand, in PTM communication, the RAN node transmits 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 used by IoT or MTC devices to reduce power consumption. Using the DRX mechanism, a user device can enter a sleep mode for a certain period (e.g., an off-duration period) and then be awakened after the off-duration period to monitor DL ​​signals from a base station (e.g., an on-duration period). The DRX cycle defines the time interval between two consecutive time periods when the UE wakes up. However, in some scenarios, it is unclear how the base station should configure DRX for one or more UEs to receive MBS data via multicast communication. Summary of the invention

[0008] The UE manages discontinuous reception (DRX) for a multicast and broadcast service (MBS) session. The UE joins the MBS session and subsequently receives a transmission over the MBS session from a node of a radio access network (RAN), the transmission including a DRX command from the MBS session transmission. The UE then determines whether the DRX command belongs to a multicast DRX cycle or a unicast DRX cycle. Depending on the implementation, the UE then modifies the DRX operation of the UE according to the DRX command based on the determination.

[0009] The RAN node similarly manages DRX for the MBS session. Specifically, the RAN node determines to transmit a DRX command to the UE, such as a command to stop the DRX on-duration. The RAN node generates the DRX command and then selects a transmission scheme for transmitting the DRX command based at least on the type of DRX operation, such as whether to use an MBS-specific RNTI or a UE-specific RNTI to scramble a cyclic redundancy check (CRC). The RAN then transmits the DRX command via the MBS session transmission according to the selected transmission scheme.

[0010] An example embodiment of these techniques is a method implemented in a UE for managing DRX for an MBS session. The method includes: receiving, by processing hardware, an MBS session transmission including a DRX command; determining, by processing hardware, whether the DRX command belongs to a multicast DRX cycle or a unicast DRX cycle; and modifying, by processing hardware, the DRX operation of the UE based on the determination.

[0011] Another example embodiment of these techniques is a method for managing DRX for an MBS session, the method being implemented in a RAN. The method includes: generating, by processing hardware, a DRX command to modify a DRX operation at a UE participating in the MBS session; selecting, by the processing hardware, a transmission scheme for providing the DRX command to the UE based on a type of the DRX operation; and transmitting, by the processing hardware, the DRX command to the UE according to the selected transmission scheme. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1A is a block diagram of an example system in which techniques for managing DRX for an MBS session of the present disclosure 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 yes Figure 1A The UE can use it to communicate with Figure 1A A block diagram of an example protocol stack for communicating with a base station;

[0015] Figure 2B yes Figure 1A A block diagram of an example protocol stack according to which a UE may communicate with a DU and a CU of a base station;

[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 for an example scenario of a distributed base station managing DRX cycle configuration data for an MBS session within the distributed base station and transmitting it to a UE;

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

[0020] Figure 5C is with Figure 5A A message passing diagram for an example scenario similar to that of but in which the CU transmits a request for data information corresponding to configured DRX and then receives the data information;

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

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

[0023] Fig. 5F is with Figure 5A Message passing diagram for an example scenario similar to but in which a distributed base station manages multiple MBS sessions for multiple UEs;

[0024] Fig. 6A is a timing diagram of an example scenario in which the OnDuration is shortened by a DRX command and the OnDuration of a unicast DRX cycle and the OnDuration of a multicast DRX cycle for UEs 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 UE for receiving a DCI and a CRC scrambled by an MBS-specific RNTI, subsequently receiving a DRX command, and stopping an On-Duration period in response;

[0027] Figure 8 is a flow chart of an example method implemented in a UE for determining whether to stop an OnDuration period of a multicast DRX cycle or an OnDuration period of a unicast DRX cycle based on whether a CRC is scrambled using an MBS-specific RNTI or a UE-specific RNTI;

[0028] Fig. 9is a flow chart of an example method implemented in a PHY layer of a UE for receiving a DCI and a CRC scrambled by an MBS-specific RNTI, then receiving a MAC PDU, and transmitting the MAC PDU to an upper layer;

[0029] Fig.10 is a flow chart of an example method implemented in a PHY layer of a UE for determining whether to transmit a multicast indication based on whether a downlink transmission from a RAN is a multicast transmission;

[0030] Fig.11 is a flow chart of an example method implemented in a PHY layer of a UE for determining whether to transmit a transmission type indication to an upper layer based on whether a transmission type indication function is enabled;

[0031] Fig.12 is a flow chart of an example method implemented in a MAC layer of a UE for determining whether to stop an OnDuration period of a multicast DRX cycle or an OnDuration period of a unicast DRX cycle based on whether a MAC PDU is received in a multicast transmission or in a unicast transmission;

[0032] Fig.13 is a flow chart of an example method implemented in a RAN node for generating DCI and scrambling a CRC using an MBS-specific RNTI, and transmitting the DCI and CRC to a UE in an MBS session;

[0033] Fig.14 is a flow chart of an example method implemented in a RAN node for determining whether to generate a DCI and scramble a CRC according to an MBS-specific RNTI or a UE-specific RNTI based at least on whether the DRX operation is multicast or unicast;

[0034] Fig.15 is a flow chart of an example method implemented in a RAN node for generating a MAC PDU and transmitting the MAC PDU using SPS multicast resources;

[0035] Fig.16 is a flow chart of an example method implemented in a UE for managing DRX for MBS; and

[0036] Fig.17 is a flow chart of an example method implemented in a RAN node for managing DRX for MBS. DETAILED DESCRIPTION

[0037] Figure 1AAn 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 includes more than 100 base stations. Figure 1A More or fewer UEs and / or more or fewer base stations are shown. For example, base stations 104, 106 can be any suitable base station of one or more types, such as an evolved Node B (eNB), a next generation eNB (ng-eNB), or a 5G Node B (gNB).

[0038] 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 can enable 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 can communicate with base station 104 (operating as a master node (MN)) and base station 106 (operating as a secondary node (SN)) in DC.

[0039] 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 an 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 (i.e., within) the uplink (UL) bandwidth part (BWP) of the cell, 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.

[0040] 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 transmit MBS data to the UE 102A via the MRB over unicast radio resources (i.e., radio resources dedicated to the UE 102A). In other scenarios, the base station (e.g., MN or SN) may transmit MBS data 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).

[0041] 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 1A The processing hardware 130 in an example implementation of includes an MBS controller 132 that is 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 that is 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.

[0042] Base station 106 includes processing hardware 140, which in some implementations includes one or more general purpose processors (eg, CPUs) and computer readable memory storing machine readable instructions executable on the general purpose processors, and / or special purpose processing units. Figure 1A The processing hardware 140 in the example implementation includes an MBS controller 142 and a non-MBS controller 144, which may be similar to the controllers 132 and 134 of the base station 130, respectively. Figure 1ANot 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.

[0043] UE 102A includes processing hardware 150, which in some implementations includes one or more general purpose processors (eg, CPUs) and computer readable memory storing machine readable instructions executable on the general purpose processors, and / or special purpose processing units. Figure 1A The processing hardware 150 in an example implementation 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. The processing hardware 150, in a further implementation, 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.

[0044] 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 . Depending on the implementation, base station 104 is an eNB supporting an S1 interface for communicating with EPC 111, an ng-eNB supporting an NG interface for communicating with 5GC 160, or a gNB supporting an NR radio interface and an NG interface for communicating with 5GC 160. In a further implementation, base station 106 is an EUTRA-NR DC (EN-DC) gNB (en-gNB) with an S1 interface to EPC 111, an en-gNB not connected to EPC 111, a gNB supporting an NR radio interface and an NG interface to 5GC 160, or an ng-eNB supporting an EUTRA radio interface and an NG interface to 5GC 160. In some implementations, in order to exchange messages directly with each other during the scenarios discussed below, base stations 104 and 106 support an X2 or Xn interface.

[0045] Among other components, the EPC 111 may include a serving gateway (SGW) 112, a mobility management entity (MME) 114, and a packet data network gateway (PGW) 116. The SGW 112 is generally configured to deliver user plane packets associated with audio calls, video calls, Internet services, 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 deliver user plane packets associated with audio calls, video calls, Internet services, 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.

[0046] 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 flow, and / or manage or configure one or more MBS sessions or PDU sessions for MBS for UE (e.g., UE 102A or 102B). UPF 162 is configured to deliver MBS data packets of audio, video, Internet services, 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.

[0047] Typically, 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.

[0048] Figure 1BAn 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.

[0049] 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.

[0050] 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.

[0051] In some implementations, CU-CP 172A is connected to multiple CU-CPs 172B via an E1 interface. CU-CP 172A selects an appropriate CU-UP 172B for the requested service for 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 174 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 implementations, the connection between CU-UP 172B and DU 174 is established by CU-CP 172A using a bearer context management function.

[0052] Figure 2A An 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, to support switching between EUTRA and NR base stations and / or to support DC on EUTRA and NR interfaces. 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."

[0053] 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.

[0054] 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.

[0055] 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 yet 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.

[0056] Figure 2B An example protocol stack 250 is shown in a simplified manner that the UE 102A, 102B, or 103 uses to communicate with a DU (e.g., DU 174) and a CU (e.g., CU 172). Figure 2A The radio protocol stack 200 is functionally composed of Figure 2B 204B, 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.

[0057] refer to Figure 3 In some implementations, the MBS session 302A includes a tunnel 312A having 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 identity (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.

[0058] 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. Further, because 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 common DL tunnel.

[0059] In some implementations, tunnel 312A operates at a transport layer or sublayer, for example, operating on a user datagram protocol (UDP) protocol layered over 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 an IP address (e.g., an IP address of a base station 104 / 106) and a 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, CN110 specifies an IP address and a TEID address in a header of a tunnel packet including an MBS data packet, and transmits the tunnel packet downstream to base station 104 / 106 (i.e., the header may include an IP address and / or TEID) via tunnel 312A. For example, the header may include an IP header and a GTP header including an IP address and a TEID, respectively. In such examples, base stations 104 / 106 may then use the IP address and / or TEID to identify data packets traveling via tunnel 312A.

[0060] like Figure 3As 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 corresponds 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 NR RLC sublayer. For example, each of the MRBs 314A corresponds 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 tunnels 312B corresponding to 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.

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

[0062] 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.

[0063] Continue to refer Figure 3In 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).

[0064] 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, such as an MTCH or a DTCH. In some implementations, DL tunnel 412A is a common DL tunnel via which CU 172 transmits MBS data packets to multiple UEs. In other implementations, DL tunnel 412A is a UE-specific DL tunnel via which CU 172 transmits MBS data packets to a specific UE.

[0065] 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.

[0066] 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 a GTP-U protocol layered on UDP / IP, where IP is layered on appropriate data link and physical (PHY) layers. Further, 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.

[0067] 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.

[0068] In some cases, CU 172 uses DRB 404A to transmit MBS data packets or unicast data packets associated with a PDU session to a specific UE (e.g., UE 102A or UE 102B). 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.

[0069] 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.

[0070] Next, Figure 5AAn example scenario 500A is shown for establishing an MBS session. 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 CP and UP functional nodes.

[0071] 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. Because 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 can occur in either order. In other words, base station 104 can configure the common DL tunnel even before a single UE joins the first MBS session.

[0072] 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.

[0073] 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 transmits a (first) UL container message including an MBS session join request message to CN 110 via base station 104; CN 110 transmits a DL container message including an MBS session join response message to UE 102 via base station 104; and UE 102 transmits 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 a PDU session modification request message, a PDU session modification command message, and a PDU session modification complete message, respectively. To simplify the following description, the terms MBS session join request message, MBS session join response message, and / or MBS session join complete message may refer to corresponding container messages, or corresponding messages without containers.

[0074] In some implementations, UE 102 performs a PDU session establishment procedure with CN 110 via base station 104 to establish a PDU session in order to perform a (first) MBS session join 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.

[0075] 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).

[0076] In some implementations, CN 110 includes a first MBS Quality of Service (QoS) flow configuration for a 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 and 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.

[0077] 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.

[0078] 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-independent multicast session, the first MBS area information includes the MBS service area information IE. The MBS service area information IE in the first MBS area information includes a list of one / multiple cell identifiers and / or a list of one / multiple tracking area identifiers (TAIs). In some implementations, the one / multiple cell identifiers are one / multiple cell global identifiers (CGIs). 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.

[0079] After receiving 504 the first CN to BS message, CU-CP 172A sends 560 a first CP to UP message (e.g., a MC bearer context setup request (Bearer Context Setup 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 setup configuration to request resources for one or more MRBs. CU-CP 172A includes the first MBS session ID, the MRB setup configuration, and / or the second MBS QoS flow configuration for 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 average window, and / or a maximum data burst size.

[0080] In some implementations, the CU-CP 172A includes the second MBS QoS flow configuration (e.g., MBS QoS flow information to be set 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 for 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).

[0081] In some implementations, the second MBS QoS flow configuration includes QoS parameters required for each of the MBS QoS flows 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. The MBS QoS flow identifiers 1, ..., M identify the MBS QoS flows 1, ..., M, respectively. For example, the MRB setting configuration includes MRB setting configuration items 1, ..., N for MRBs 1, ..., N, respectively. N is an integer and greater than zero. In the MRB setting 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, the CU-CP 172A avoids associating or mapping a specific QoS flow to two MRBs. In some implementations, for an MRB X in MRBs 1, ..., N, where 1 <= X <= N, the MRB setting configuration item X includes a specific MBS QoS flow configuration of an MRB ID X, a PDCP configuration X, an SDAP configuration X, and / or a second MBS QoS flow configuration.

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

[0083]

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

[0085]

[0086] In some cases where CU-CP 172A receives the first slice information from CN 110, e.g., in a 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 a 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 (e.g., 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 a 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.

[0087] 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 (e.g., 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 (e.g., 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.

[0088] 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., a MC Bearer Context Setup Response message). In some implementations, CU-UP 172B configures resources for each of the MRBs 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 one / multiple PDCP entities 1, ..., N, respectively, according to PDCP configurations 1, ..., N for MRBs or MRBIDs 1, ..., N. In other implementations, for each of the 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.

[0089] In some implementations, CU-UP 172B establishes and / or configures one / multiple SDAP entities 1, ..., N, respectively, according to SDAP configurations 1, ..., N for MRB or MRB ID 1, ..., N. 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, the CU-UP 172B ignores or discards the entire SDAP configuration because the CU-UP 172B determines not to use SDAP to transmit the MBS data for the first MBS session.

[0090] 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) to identify 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-UP MBSE1AP 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.

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

[0092] After receiving 504 the first CN-to-BS message (e.g., in response to receiving 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 setup of a multicast context and / or a common DL tunnel for the first MBS session. Figure 4 and attachments. 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 setup configuration to perform the setup configuration to request resources for one or more MRBs. In some implementations, the first CU to DU message includes information related to configuring DRX for UE 102 participating in the MBS session, such as a first MBS session ID, an MRB for performing the 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.

[0093] 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 setup 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 MRBs. 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 CUMBS F1AP 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 .

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

[0095] In some cases where CU-CP 172A receives the first MBS region information from CN 110 (e.g., 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. Thus, similar embodiments apply to the first CU to DU message.

[0096] In response to receiving 506 the first CU-to-DU message, 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 CU-CP 172A. In some implementations, DU 174 establishes and / or configures a MAC entity for the MRB. In some implementations, DU 174 establishes and / or configures one / multiple RLC entities 1, ..., N for the MRB or MRB IDs 1, ..., N, respectively. In some implementations, 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 a further implementation, DU 174 includes an additional DU transport layer configuration in the first DU to CU message to configure an additional common CU to DU DL tunnel for an additional MRB identified by an additional MRB ID in the MRB ID. 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 MRB F1-U TNL information at the DU IE.

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

[0098] In some implementations, DU 174 transmits 510 a second DU to CU message (e.g., a Multicast Distribution Setup Request message) to CU-CP 172A after receiving 506 or transmitting 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, CU-CP 172A transmits 516 a second CU to DU message (e.g., a Multicast Distribution Setup Response message) to DU 174 in response to the second DU to CU message. In some implementations, the second CU to DU message is similar to the first CU to DU message transmitted by CU 172 in event 506. Events 510 and 516 are Figure 5A It is collectively referred to as the Multicast Distribution Setup process.

[0099] 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 transmits 512 the first BS to CN message (e.g., a distribution setup request message) to CN 110. In some implementations, CU-CP 172A transmits 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 may include 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., IP address) and / or TEID to identify the 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.

[0100] After receiving 514 the second CN to BS message, CU-CP 172A sends 564 a second CP to UP message (e.g., a MC bearer context modification request (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., a MC bearer context modification response (Bearer ContextModification 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) to identify the first common DU to CU UL tunnel. The second CU transport layer configuration may further include a TEID of / at the CU-UP 172B. 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, the 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 the DU 174 in response to the second DU to CU message of event 510. After receiving 566 to the second UP to CP message or transmitting 516 the second CU to DU message, the CU-CP 172A transmits 518 the second BS to CN message (e.g., a Multicast Session Activation Response message) to the CN 110 in response to the first CN to BS message. Alternatively, the CU-CP 172A transmits 518 the second BS to CN message to the CN 110 before receiving 566 to the second UP to CP message or transmitting 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 the second BS to CN message to the CN 110 .

[0101] 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 for the MRB based on the fourth MBS QoS flow configuration. In some implementations, CU-UP 172B determines whether to modify or reconfigure the resources for 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 for the first MRB. Otherwise, CU-UP 172B modifies or reconfigures the resources for the MRB based on the fourth MBS QoS flow configuration. In some implementations, CU-UP 172B determines whether to modify or reconfigure the resources for a specific MRB among the MRBs based on the fourth MBS QoS flow configuration.

[0102] 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 related messages, ie, messages associated with the first session rather than a specific UE (eg, UE 102A).

[0103] In some implementations, CU-CP 172A includes a multicast DRX cycle request in a 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 a desired 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 a second CU-to-DU message of event 516, as described above.

[0104] In other implementations, the CN 110 sends 520 a third CN-to-BS message to the CU-CP 172A, the third CN-to-BS message indicating that (only) the UE 102 (e.g., UE 102A) joins the first MBS session. In some implementations, the CN 110 includes in the third CN-to-BS message 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 response to the third CN-to-BS message, the CU-CP 172A may send 527 a third BS-to-CN message to the CN 110. After receiving the third CN-to-BS message (e.g., in response to receiving the third CN-to-BS message), the CU-CP 172A may send 522 a UE Context Request message for the UE 102 (e.g., UE 102A) to the DU 174. In some implementations, CU-CP 172A may include information related to configuring DRX for UE 102, such as DRX cycle length and / or 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 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.

[0105] In response to the UE context request message of event 522, DU 174 sends 524 to CU-CP 172A a UE context response (Context Response) message including configuration parameters for 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 an MRB and / or an 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) for 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 one or more logical channels.

[0106] In some implementations, the third CN to BS message and the third BS to CN message are a PDU Session Resource Modify Request message and a PDU Session Resource Modify Response message, respectively. In other implementations, the third CN to BS message and the third BS to CN message are a PDU Session Resource Setup Request message and a PDU Session Resource Setup Response message, respectively. In some implementations, the third CN to BS message and the third BS to CN message are UE-related messages, i.e., these messages are associated with a specific UE (e.g., UE 102A, 102B, or 103).

[0107] In some implementations, the UE context request message and the UE context response message are respectively a UE context setup request message and a UE context setup response message. In some alternative implementations, the UE context request message and the UE context response message are respectively a UE context setup request message (Context Setup Request) and a UE context modification required (Context Modification Required) message. In some such implementations, the DU 174 sends a UE context setup response message to the CU-CP 172A in response to the UE context setup request message, and the CU-CP 172A sends a UE context modification confirmation (Context Modification Confirm) message to the DU 174 in response to the UE context modification required 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 required message. In some such implementations, DU 174 sends a UE context modification response message to CU-CP 172A in response to the UE context setup request message, and CU-CP 172A sends a UE context modification confirmation message to DU 174 in response to the UE context modification required message.

[0108] In some implementations, CU-CP 172A may perform a (UE-specific) bearer context procedure on UE 102 (e.g., UE 102A) with CU-UP 172B after receiving the third CN-to-BS message (e.g., in response to receiving the third CN-to-BS message). During 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 response (Bearer Context Response) message to CU-CP 172A. In other implementations, CU-CP 172A avoids performing a (UE-specific) bearer context procedure on UE 102 with CU-UP 172B upon receiving the third CN-to-BS message. In some implementations, the bearer context procedure is the bearer context setup procedure defined in section 8.3.1 of 3GPP specification 37.483 or 38.463. In such cases, the bearer context request message and the bearer context setup message are a bearer context setup request message and a bearer context setup response message, respectively. In other implementations, the bearer context procedure is the bearer context modification procedure defined in section 8.3.2 of 3GPP specification 37.483 or 38.463. In such cases, the bearer context request message and the bearer context setup message are a bearer context modification request message and a bearer context modification response message, respectively.

[0109] 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 transmits 526 the RRC reconfiguration message to the DU 174. The DU 174 in turn transmits 528 the RRC reconfiguration message to the UE 102 (e.g., UE 102A). The UE 102 then transmits 530 an RRC reconfiguration complete message to the DU 174, which in turn transmits 531 an RRC reconfiguration complete message (e.g., an RRCReconfigurationComplete message) to the CU-CP 172A.

[0110] Events 520, 522, 524, 526, 527 (discussed below), 528, 530, and 531 are Figure 5A102A and 102B. The above processes are collectively referred to as UE-specific MBS session configuration process 594. CN 110 and / or CU-CP 172A perform process 594 for each of the UEs (e.g., UE 102A and UE 102B) that join the first MBS session. Depending on the implementation, process 594 occurs before, after, or overlaps with process 592A.

[0111] In some implementations, DU 174 transmits (not shown) a third DU to CU message including a portion of the configuration parameters for UE 102 to CU-CP 172A after transmitting 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, CU-CP 172A transmits a second RRC reconfiguration message including a portion of the configuration parameters to UE 102 via DU 174 after transmitting 526 the RRC reconfiguration message or receiving 531 the RRC reconfiguration complete message. In response, similar to events 530, 531, UE 102 transmits 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 required message or a UE context modification response message. In some implementations, similar to the UE context request message of event 522, the CU-CP 172A transmits a third CU-to-DU message to the DU 174 to trigger transmission of the third DU-to-CU message.

[0112] 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 transmits 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 transmits 530 the PDCP PDU to the DU 174 via the RLC layer 206B, the MAC layer 204B, and / or the PHY layer 202B. DU 174 receives 522 PDCP PDU from UE 102 via PHY layer 202B, MAC layer 204B and / or RLC layer 206B, and sends 531 DU to CU including the PDCP PDU to CU-CP 172A. CU-CP 172A retrieves the PDCP PDU from the DU to CU message and retrieves the RRC reconfiguration complete message from the PDCP PDU.

[0113] In some implementations, the CU-CP 172A transmits 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”.

[0114] 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 data packets, each of which includes a specific MBS data packet, to transmit 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-BS DL tunnel.

[0115] 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 of the MBS QoS flows identified by the MBS QoS flow identifiers, CU-UP 172B determines which common CU-to-DU DL tunnel(s) to use to send the MBS data to DU 174 based on one or some of the 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.

[0116] In some implementations, CU-UP 172B generates tunnel packets, each of which includes a specific MBS data packet, to transmit 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 case where CU-UP 172B transmits one of the tunnel packets via the additional common CU to DU tunnel, CU-UP 172B sets parameters similar to the above event 532 using DU and CU transport layers instead of CU and CN transport layers.

[0117] When the DU 174 receives 534 the MBS data from the CU-UP 172B, the DU 174 transmits 536 the MBS data to the UE 102 (eg, multicast or unicast) via one or more logical channels. Figure 4 and attachments. 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 transmit 534 the PDCP PDU to the DU 174. In turn, the DU 174 generates a MAC PDU including the LCID and the PDCP PDU, and transmits 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 transmits 536 MBS data or MAC PDUs 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.

[0118] 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 configure 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) to identify the UE-specific CU to DU DL tunnel. In a further implementation, the CU transport layer configuration includes a TEID at / of the CU-UP 172B. In response, DU 174 includes a DU transport layer configuration that configures the 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 transmits 534 MBS data to DU 174 via a UE-specific CU-to-DU DL tunnel.

[0119] 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.

[0120] 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 UL configuration parameters 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 DL configuration parameters in the MRB configuration (e.g., as described above). In such cases, CU-CP 172A configures UE 102 to not transmit UL PDCP data PDUs to DU 174 and / or CU-CP 172A via MRB by excluding UL configuration parameters for MRB in the PDCP configuration in the MRB configuration. In another example, DU 174 avoids including UL configuration parameters in the RLC bearer configuration. In such cases, DU 174 configures UE 102 to not transmit control PDUs to base station 104 via logical channels by excluding UL configuration parameters from the RLC bearer configuration.

[0121] In the case where DU 174 includes UL configuration parameters in the RLC bearer configuration, UE 102 transmits 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, when 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 transmits 534 PDCP PDUs including the compressed MBS data packets to DU 174 via a first or additional common CU to DU DL tunnel. In turn, DU 174 transmits 536 the PDCP PDU to UE 102 (e.g., multicast or unicast) 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 transmits 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. In turn, DU 174 sends the PDCP control PDU to CU-UP 172B via the UL tunnel.

[0122] 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 to identify 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.

[0123] 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 in which 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 RB ID 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 RB ID 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 transmits 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 transmits the MRB-ToAddMod IE for configuring the RB to the UE 102, it is determined that the RB is an MRB.

[0124] 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.

[0125] 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.

[0126] 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 including a specific MAC PDU for UE 102 by generating a DCI, scrambling a cyclic redundancy check (CRC) of the DCI with the G-RNTI, and transmitting 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 the 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) number of HARQ processes, (viii) downlink assignment index, and / or (ix) PUCCH resource indicator.

[0127] In some implementations, the configuration parameters include a HARQ codebook (ID) indicating a HARQ ACK codebook index for a corresponding HARQ acknowledgement (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.

[0128] In some implementations, the configuration parameters include a PUCCH resource configuration that indicates HARQ resources on the PUCCH in which the UE 102 transmits 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 DU 174 transmit the HARQ feedback using the PUCCH resource configuration for unicast transmissions.

[0129] In some implementations, the configuration parameters include a HARQ NACK-only indication that configures the UE 102 to transmit only a HARQ negative ACK (NACK) for a dynamically scheduled multicast transmission 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 refrains from transmitting 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 cases where the configuration parameters do not include the indication, the UE 102 transmits 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.

[0130] In some implementations, the configuration parameters include a HARQ ACK / NACK indication that configures the UE 102 to transmit 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 transmit 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 cases where the configuration parameters do not include the indication, the UE 102 refrains from transmitting 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 such cases, the UE 102 transmits a HARQ NACK to the DU 174 only for dynamically scheduled multicast transmissions in which the UE 102 fails to obtain a transport block.

[0131] In some implementations, the configuration parameters include a HARQ ACK indication that configures the UE 102 to transmit 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 cases where the configuration parameters do not include the indication, the UE 102 refrains from transmitting 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 transmits a HARQ NACK to the DU 174 only for dynamically scheduled multicast transmissions in which 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 a HARQ ACK indication.

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

[0133] 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 transmits (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 transmits another DU configuration to the UE 102 that includes the aggregation factor for unicast transmissions.

[0134] 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.

[0135] 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.

[0136] 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 transmitting the DCI and the scrambled CRC on the PDCCH. Similar to the above-mentioned G-RNTI but for the SPS radio resources, after activating the SPS multicast radio resources, the DU 174 periodically transmits multicast transmissions on the SPS multicast radio resources according to the DCI.

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

[0138] In some implementations, the configuration parameters include a number of HARQ processes indicating the number of HARQ processes used to transmit SPS multicast transmissions. DU 174 uses up to this number of HARQ processes to transmit SPS multicast transmissions, and UE 102 uses up to this number of HARQ processes to receive SPS multicast transmissions.

[0139] In some implementations, the configuration parameters include HARQ codebook IDs for SPS multicast radio resources and 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.

[0140] 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.

[0141] 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.

[0142] 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.

[0143] In further implementations, 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 on-duration begins. In some implementations, the DRX offset is the drx-SlotOffsetPTM field in the DRX-ConfigPTM-r17 IE.

[0144] In further implementations, the multicast DRX configuration includes a DRX inactivity timer (value), which is the duration of the timer after a PDCCH occasion in which the DCI indicates a new DL multicast transmission. In some implementations, the DRX inactivity timer value is included in the drx-Inactivity TimerPTM field in the DRX-ConfigPTM-r17 IE.

[0145] In 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 inactivity period (eg, an OffDuration).

[0146] In further implementations, the multicast DRX configuration includes a DRX cycle start offset that defines a subframe in 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.

[0147] In 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.

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

[0149] 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.

[0150] 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 an MBS session ID. In further implementations, 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.

[0151] 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 further implementations, 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 UE-related CU to DU message (e.g., a message of event 522 or a third CU to DU message). In such cases, 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 first multicast DRX parameter in the first multicast DRX parameters, 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.

[0152] 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 of 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 including the expected value of 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 of 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 of the multicast DRX parameter in the 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 the CU-to-DU message that excludes the expected value of 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 of 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 of the multicast DRX parameter.

[0153] 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 transmits 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.

[0154] 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 discontinuously monitor the PDCCH from the DU 174 according to the first multicast DRX operation and the active time (Active Time) as described below. The active time includes the time when the drx-onDurationTimerPTM, drx-Inactivity TimerPTM or drx-RetransmissionTimerDL-PTM for the G-RNTI or G-CS-RNTI is running. 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-RetransmissionTimerDL timer is configured and started, the UE 102 stops the drx-RetransmissionTimerDL. If the UE 102 receives a DRX command MAC control element in a transmission scheduled by DCI 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.

[0155] Thus, in some implementations, if the UE 102 receives a MAC PDU according to the configured downlink multicast assignment, if HARQ feedback is enabled, the UE 102 starts a HARQ RTT timer (e.g., drx-HARQ-RTT-Timer DL-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 the drx-RetransmissionTimerDL timer has been configured and started, the UE 102 stops the drx-RetransmissionTimerDL timer of 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-RetransmissionTimer DL-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.

[0156] 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 the 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-RetransmissionTimer DL-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, drx-InactivityTimerPTM timer) in the first symbol after the end of PDCCH reception.

[0157] DU 174 may perform early termination of the on-duration in a specific instance of the first multicast DRX cycle by transmitting a DRX command to UE 102. To transmit the DRX command to UE 102, DU 174 generates a MAC PDU, which includes the DRX command and a subheader for the DRX command. To schedule multicast transmission of the MAC PDU, DU 174 generates a DCI, generates a CRC for the DCI, and scrambles the CRC using a G-RNTI or a G-CS-RNTI. DU 174 transmits the DCI and the scrambled CRC on the PDCCH, and transmits the multicast transmission according to the DCI. Upon 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 according to the DCI. Then, UE 102 decodes the multicast transmission according to the DCI to obtain the MAC PDU, and retrieves the DRX command from the MAC PDU. Otherwise, if the UE 102 determines 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 determining the scrambled CRC. If the UE 102 determines 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 determines that the scrambled CRC is invalid, the UE 102 avoids decoding or attempting to decode the multicast transmission according to the DCI.

[0158] In some implementations, the CU-CP 172A includes the MBS session join response message in the RRC reconfiguration message. The UE 102 may include the MBS session join completion message in the RRC reconfiguration completion message. Alternatively, the UE 102 sends a UL RRC message including the MBS session join completion message to the CU-CP 172A via the 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, the CU-CP 172A includes the MBS session join completion message in a second BS to CN message. Alternatively, the CU-CP 172A sends a BS to CN message (e.g., an uplink NAS send (UPLINKNAS TRANSPORT) message) including the MBS session join completion message to the CN 110.

[0159] In other implementations, the CU-CP 172A transmits 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.

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

[0161] 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.

[0162] 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.

[0163] In some implementations, the CU-CP 172A is pre-configured with the 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.

[0164] Events 503, 560, 562, 506, 508, 510, 512, 514, 564, 566, 516, and 518 are Figure 5B The above steps are collectively referred to as MBS session resource setup process 592B.

[0165] Figure 5C Shown in 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 setup procedure and the multicast context setup procedure) until the first MBS QoS flow configuration or the second CN to BS message is received.

[0166] Events 503, 512, 514, 560, 562, 506, 508, 510, 564, 566, 516, and 518 are Figure 5C The above steps are collectively referred to as MBS session resource setup process 592C.

[0167] 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.

[0168] Figure 5D Shown in FIG. 5A to FIG. 5CExample scenario 500D is similar to the scenarios 500A-C shown in FIG. 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 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 setup procedure and the multicast context setup procedure) until the first MBS QoS flow configuration or the fourth CN to BS message is received. In some implementations, the CU-CP 172A sends 519 a fourth BS-to-CN message (eg, a Multicast Session Update Response message) to the CN 110 in response to the fourth CN-to-BS message.

[0169] In some implementations, the CU-CP 172A sends 519 a fourth BS-to-CN message to the CN 110 upon receiving 503 the first CN-to-BS message. In other implementations, the CU-CP 172A transmits 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 transmitting 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.

[0170] 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.

[0171] Figure 5E Shown in FIG. 5A to FIG. 5D Example 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, as for example, for DU 174. Figure 5A described.

[0172] 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.

[0173] Fig. 5F Shown in 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 join procedure for the second MBS session, and may perform 503 an MBS session join procedure for the first MBS session. Then, similar to process 592A, 592B, 592C, 592D, or 592E, base station 104 and CN 110 perform 591 an MBS session resource setup procedure for the second MBS session. Similar to process 594, UE 103, base station 104 and CN 110 perform 593 a UE-specific MBS session configuration procedure for the second MBS session. Also, similar to event 594, UE 103, base station 104 and CN perform 595 a UE-specific MBS session configuration procedure for the first MBS session.

[0174] 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 begun transmitting 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 transmits 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 transmits a first RRC reconfiguration complete message to CU-CP 172A via DU 174. The first RRC reconfiguration message may include an LCID (value), MRB configuration, and RLC bearer configuration for the second MBS session that are different from the LCID (value), MRB configuration, and RLC bearer configuration for the first MBS session.

[0175] Similarly, CU-CP 172A transmits 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 transmits 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 used for UE 102. In some implementations, when UE 102 and 103 operate in different cells, the second RRC reconfiguration message has, for example, 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 .

[0176] 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 implementations, UE 103 and UE 102 receive MBS data for the first MBS session via the same logical channel and / or MRB.

[0177] In any case, CN 110 then sends 538, 544 MBS data for the first MBS session and 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 MBS data for the first MBS session and MBS data for the second MBS session to DU 174 via different common CU to DU DL tunnels, respectively. DU 174 transmits 542 MBS data for the second MBS session to UE 103 (e.g., multicast) via one or more logical channels, and transmits 548 MBS data for the first MBS session to UE 103 and UE 102 (e.g., multicast) via one or more logical channels. UE 103 receives 548 MBS data for the first MBS session and receives 542 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 MBS data for the first MBS session via multicast.

[0178] 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 transmits a third RRC reconfiguration message including the second multicast DRX configuration to UE 103 via DU 174. In response, UE 103 transmits 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 receives 542 MBS packets for the second MBS session according to the second multicast DRX cycle.

[0179] 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 transmits a fourth RRC reconfiguration message including the first multicast DRX configuration to UE 103 via DU 174. In response, UE 103 transmits a fourth RRC reconfiguration complete message to CU-CP 172A via DU 174. DU 174 sends 548 MBS packets for the first MBS 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.

[0180] Next, refer to Fig. 6A and Figure 6B The discussion shows that Figure 1A and / or Figure 1B Several example timing diagrams of message passing timing implemented by the shown apparatus.

[0181] 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 "stopping the on-duration period" or "shortening the on-duration period" mentioned in the present disclosure refers to performing such an 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 cycles 602") and multicast DRX cycles 612-1, 612-2, and 612-3 (collectively referred to as "multicast DRX cycles 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 off-duration periods 606-1, 606-2, and 606-3 (collectively referred to as "unicast off-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 referred to as the "multicast on-duration period 614") and an off-duration period 616-1, 616-2, and 616-3 (collectively referred to as the "multicast off-duration period 616"). Similarly, in scenario 600B, the UE 102 operates according to a unicast DRX cycle 622-1, 622-2, and 622-3 (collectively referred to as the "unicast on-duration period 624") having an on-duration period 624-1, 624-2, and 624-3 (collectively referred to as the "unicast on-duration period 624") and an off-duration period 626-1, 626-2, and 626-3 (collectively referred to as the "unicast off-duration period 626"). Scenario 600B depicts the same multicast DRX cycle 612 shown in scenario 600A. The unicast DRX cycles 622 of scenario 600B are time offset from those of scenario 600A and are 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 no messages and / or data are expected, the UE 102 is instead inactive to save power.

[0182] In some implementations, such as described above with respect to FIG. 5A to FIG. 5FIn the described events 506, 516 or 522, CU-CP 172A transmits the desired DRX cycle length and / or other information about configuring the DRX cycle (e.g., desired on duration length, desired off duration length, start time, etc.) in communication with DU 174. In such implementations, DU 174 configures the DRX cycle for UE 102 and transmits the DRX configuration to UE 102. 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, DU 174 configures the DRX cycle so that the multicast DRX cycle 612 and the unicast DRX cycles 602, 622 of UE 102 are synchronized according to scenario 600B, or are not synchronized according to scenario 600A, as described below.

[0183] In some implementations, when the RAN 105 determines that no data is transmitted for the UE 102 and / or the base station 104 of the RAN 105 determines that no tunnel or uplink data is transmitted between the UE 102 and the base station 104, the base station 104 can receive and / or generate a DRX command to perform an early termination of the DRX cycle. In some such implementations, the base station 104 transmits 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 a C-RNTI or a CS-RNTI, the UE 102 determines that the DRX command is for a unicast cycle and terminates the on-duration early at t3 (or t5) instead of at the regular time t4 (or t6). Similarly, if UE 102 receives a 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.

[0184] In a further implementation, a node such as the base station 104 of the RAN 105 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.

[0185] In scenario 600A, the unicast DRX cycle 602 and the corresponding multicast DRX cycle corresponding portion 612 (starting at time ) are not aligned. Thus, 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 UE 102 is inactive in response to receiving a DRX command on a DCI scheduled MAC PDU with a CRC scrambled by the G-RNTI or G-CS-RNTI, Earlier 614-2, but the inactivity period requested by the DRX command is shortened due to the start of the OnDuration period 604-2 of the unicast DRX cycle. Similarly, the UE 102 stops the OnDuration period 614-2 at the start of the OnDuration period 604-2 of the unicast DRX cycle. Earlier The on-duration period 604-2 is stopped at 614-2, but the inactivity of the off-duration period 606-2 is shortened by the start of the on-duration period 614-3. Thus, the misaligned DRX cycles may reduce the overall power saving of the UE 102.

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

[0187] In scenario 600B, UE 102 operates according to the same multicast DRX cycle 612, but also according to an aligned set of unicast DRX cycles 622. Because the aligned unicast DRX cycles 622 are also from 6, so the aligned unicast Off Duration period 626 is generally more aligned with the multicast Off Duration period 616, thereby allowing for more uninterrupted inactivity during the respective Off Durations. Similarly, even if the Off Duration periods have different starting points, such as having a start time in response to receiving a DRX command, the Off Duration period 626 may be aligned with the multicast Off Duration period 616. Earlier The off duration period 626-2 stopped at Earlier 616 - 2 , the resulting inactive state period still has a longer uninterrupted length than the unaligned version described in scenario 600A.

[0188] Next, refer to Figures 7 to 17 Discussion can be conducted by Figure 1A and / or Figure 1B Several example methods implemented by the illustrated apparatus.

[0189] First reference Figure 7 , the method 700 may be implemented in a suitable UE and includes receiving a DCI and a CRC scrambled by an MBS-specific RNTI, subsequently receiving a DRX command, and stopping the on-duration period in response. For clarity, the method 700 is discussed with specific reference to the RAN 105, the BS 104, the CN 110, the UE 102, the PHY sublayer 202, and the MAC sublayer 204.

[0190] At block 702, UE 102 performs multicast DRX operations with a node of RAN 105, such as BS 104 (e.g., FIG. 5A to FIG. 5F At block 704, UE 102 receives the DCI and CRC from RAN 105 (e.g., FIG. 5A to FIG. 5F Event 536 or 596 of the embodiment of the present invention. Depending on the implementation, the UE 102 determines the type of DRX operation based on the CRC. In some implementations, an MBS-specific RNTI such as a G-RNTI or a G-CS-RNTI scrambles the CRC to indicate a multicast type DRX operation to the UE 102. In further implementations, a UE-specific RNTI such as a C-RNTI or a CS-RNTI scrambles the CRC to indicate a unicast type DRX operation to the UE 102. In further implementations, the UE 102 receives the DCI and / or the CRC on the PDCCH in a time slot during the on-duration of the multicast DRX cycle.

[0191] At block 706, UE 102 receives and processes the downlink multicast transmission according to the DCI (e.g., event 536 or 596). At block 708, UE 102 obtains a DRX command from the downlink multicast transmission. In some implementations, the DRX command is an explicit command to stop the OnDuration period. In further implementations, the DRX command is not an explicit command to stop the OnDuration period, but ultimately the UE 102 stops the OnDuration period. At block 710, UE 102 stops the OnDuration period in response to receiving the DRX command at block 708 (e.g., event 536 or 596). Fig. 6A and Figure 6Bperiod 604-2, 614-2 or 624-2).

[0192] Next reference Figure 8 , the method 800 may be implemented in a suitable UE and includes determining whether to stop the on-duration period of the multicast DRX cycle or the on-duration period of the unicast DRX cycle based on the MBS-specific RNTI or the UE-specific RNTI by scrambling the CRC. For clarity, the method 800 is discussed with specific reference to the RAN 105, the BS 104, the CN 110, the UE 102, the PHY sublayer 202, and the MAC sublayer 204.

[0193] At block 802, UE 102 performs multicast DRX operation and unicast DRX operation with a node such as BS 104 of RAN 105 (e.g., FIG. 5A to FIG. 5F 528, 530, 594, 536, or 596). Similar to Figure 7 At block 804, UE 102 receives DCI and CRC from RAN 105. Similar to block 706, at block 806, UE 102 receives and processes the multicast transmission according to the DCI. Similarly, at block 808, UE 102 obtains a DRX command from the multicast transmission, as explained with respect to block 708. Thus, at Figure 7 The examples and implementations described in the box also apply to Figure 8 corresponding box.

[0194] At block 810, the UE 102 determines whether the CRC is scrambled by an MBS-specific RNTI, such as a G-RNTI or a G-CS-RNTI. If the CRC is scrambled by an MBS-specific RNTI, the flow proceeds to block 812, where the UE 102 stops the on-duration period of the multicast DRX cycle (e.g., Fig. 6A and Figure 6B If the MBS-specific RNTI does not scramble the CRC, flow instead proceeds to block 814 where the UE 102 stops the OnDuration period of the unicast DRX cycle in response to the DRX command (e.g., Fig. 6A and Figure 6B In some implementations, when the CRC is scrambled by a UE-specific RNTI, such as a C-RNTI or a CS-RNTI, the flow proceeds to block 814.

[0195] Next reference Fig. 9, method 900 can be implemented in a suitable PHY sublayer of the UE and includes receiving DCI and CRC scrambled by an MBS-specific RNTI, then receiving a MAC PDU, and transmitting the MAC PDU to an upper layer. For clarity, method 900 is discussed with specific reference to RAN 105, BS 104, CN 110, UE 102, PHY sublayer 202, and MAC sublayer 204.

[0196] Similar to Figure 7 At block 902, the UE 102 communicates with the RAN 105 at the PHY sublayer 202. Figure 7 At block 904, the UE 102 receives the DCI and CRC from the RAN 105 at the PHY sublayer 202. Figure 7 At block 906, the PHY sublayer 202 of the UE 102 receives and processes the multicast transmission according to the DCI. Figure 7 The examples and implementations described in the box also apply to Fig. 9 corresponding box.

[0197] At block 908, the PHY sublayer 202 of the UE 102 obtains the data packet from the multicast transmission. In some implementations, the data packet is a MAC PDU applicable to an upper layer of the UE 102, such as the MAC sublayer 204. Thus, at block 910, the PHY sublayer 202 of the UE 102 transmits the data packet to an upper layer, such as the MAC sublayer 204. In some implementations, the PHY sublayer 202 also transmits a multicast indication to the upper layer to indicate that the PHY sublayer 202 received the data packet via the multicast transmission. In further implementations, if the MAC PDU includes a DRX command, the MAC sublayer 204 stops the OnDuration period of the multicast DRX cycle in response to the multicast indication.

[0198] Next reference Fig.10 , method 1000 may be implemented in a suitable PHY sublayer of the UE and includes determining whether to transmit a multicast indication based on whether a downlink transmission from the RAN is a multicast transmission. For clarity, method 1000 is discussed with specific reference to RAN 105, BS 104, CN 110, UE 102, PHY sublayer 202, and MAC sublayer 204. Portions of method 1000 are similar to the techniques described in method 900. Specifically, blocks 1002, 1004, 1006, 1008, and 1010 are similar to Fig. 9 902, 904, 906, 908 and 910. Thus, Fig. 9 The examples and implementations described in the box also apply to Fig.10 corresponding box.

[0199] Compared to the example described in block 906, the UE 102 may receive and process a multicast or unicast transmission. Then, at block 1008, the PHY sublayer 202 obtains a data packet such as a MAC PDU from the multicast or unicast transmission and transmits the data packet to an upper layer of the UE 102 such as the MAC sublayer 204 at block 1010.

[0200] At block 1012, the UE 102 determines at the PHY sublayer 202 whether the transmission from the RAN 105 is a multicast transmission. If the RAN 105 transmission is a multicast transmission, the flow proceeds to block 1014 and the PHY sublayer 202 transmits a multicast indication of the data packet to upper layers of the UE 102, such as the MAC sublayer 204. In some implementations, if the MAC PDU includes a DRX command, the MAC sublayer 204 stops the on-duration period of the multicast DRX cycle in response to the multicast indication. If the RAN 105 transmission is not a multicast transmission, the flow proceeds to blocks 1016 or 1018, depending on the implementation. At block 1016, the PHY sublayer 202 refrains from transmitting a multicast indication of the data packet to upper layers of the UE 102. In some implementations, the lack of a transmission type indication indicates to upper layers of the UE 102 that the transmission is unicast and thus acts as an implicit indication. In further implementations, if the MAC PDU includes a DRX command, the MAC sublayer 204 stops the OnDuration period of the unicast DRX cycle in response to the implicit indication. In other implementations, the absence of the transmission type indication does not provide an implicit indication of the transmission type to upper layers of the UE 102. At block 1018, the PHY sublayer 202 transmits an explicit non-multicast indication, such as a unicast indication, to upper layers of the UE 102. In some implementations, if the MAC PDU includes a DRX command, the MAC sublayer 204 stops the OnDuration period of the unicast DRX cycle in response to the non-multicast indication.

[0201] Next reference Fig.11 , method 1100 may be implemented in a suitable PHY layer of the UE and includes determining whether to transmit a transmission type indication to an upper layer based on whether a transmission type indication function is enabled. For clarity, method 1100 is discussed with specific reference to RAN 105, BS 104, CN 110, UE 102, PHY sublayer 202, and MAC sublayer 204. Portions of method 1100 are similar to the techniques described in method 900. Specifically, blocks 1102, 1104, 1106, 1108, and 1110 are similar to Fig. 9 902, 904, 906, 908 and 910. Thus, Fig. 9 The examples and implementations described in the box also apply to Fig.11 corresponding box.

[0202] Compared to the example described in block 906, the UE 102 may receive and process a multicast or unicast transmission. Then, at block 1108, the PHY sublayer 202 obtains a data packet such as a MAC PDU from the multicast or unicast transmission and transmits the data packet to an upper layer of the UE 102 such as the MAC sublayer 204 at block 1110.

[0203] At block 1112, the UE 102 determines at the PHY sublayer 202 whether a transmission type indication function is enabled for the PHY sublayer 202. If the transmission type indication function is enabled, the flow proceeds to block 1114, where the PHY sublayer 202 transmits a transmission type indication for the data packet to upper layers of the UE 102. In some implementations, block 1112 occurs before block 1110, and the PHY sublayer 202 transmits the data packet and the transmission type indication in a single message and / or a group of messages. If the transmission type indication function is not enabled, the flow proceeds to block 1116 instead, where the PHY sublayer 202 refrains from transmitting a transmission type indication for the data packet to upper layers of the UE 102.

[0204] Fig.10 and Fig.11 At least three different methods are described for indicating the transmission type to upper layers of the UE 102: (a) unless the PHY sublayer 202 includes a multicast indication (e.g., an explicit multicast indication or an implicit unicast indication to make the determination), the upper layers will assume unicast transmission, (b) the lack of indication means a lack of support for type indication (e.g., an explicit multicast indication or an explicit unicast indication to make the determination), or (c) unless the PHY sublayer 202 includes a unicast indication (e.g., an explicit unicast indication or an implicit multicast indication to make the determination), the upper layers will assume multicast transmission.

[0205] Next reference Fig.12 , the method 1200 can be implemented in a suitable MAC sublayer of the UE and includes determining whether to stop the on-duration of the multicast DRX cycle or the on-duration of the unicast DRX cycle based on whether the UE 102 receives the MAC PDU in a multicast transmission or a unicast transmission. For clarity, the method 1200 is discussed with specific reference to the RAN 105, the BS 104, the CN 110, the UE 102, the PHY sublayer 202, and the MAC sublayer 204.

[0206] At block 1202, the MAC sublayer 204 of the UE 102 performs multicast DRX operations and unicast DRX operations with a node of the RAN, such as the BS 104 (e.g., FIG. 5A to FIG. 5FAt block 1204, the MAC sublayer 204 receives a data packet, such as a MAC PDU (e.g., FIG. 5A to FIG. 5F In some implementations, the UE 102 receives the data packet at the PHY sublayer 202, and the PHY sublayer 202 transmits the data packet to the MAC sublayer 204, as described above with respect to Fig. 9 , Fig.10 and Fig.11 At block 1206, the MAC sublayer 204 obtains a DRX command from the data packet. In some implementations, the DRX command is an explicit command to stop the on-duration period. In further implementations, the DRX command is not an explicit command to stop the on-duration period, but ultimately the UE 102 stops the on-duration period.

[0207] At block 1208, the MAC sublayer 204 determines whether the UE 102 received the data packet in a multicast transmission. In some implementations, the MAC sublayer 204 makes the determination based on whether there is an indication of a multicast or unicast transmission, as described above with respect to Fig.11 In an implementation where the UE 102 receives a data packet in a multicast transmission, flow proceeds to block 1210 where the MAC sublayer 204 stops the multicast DRX cycle (e.g., Fig. 6A and Figure 6B If the UE 102 does not receive data packets in the multicast transmission (i.e., the UE 102 receives data packets in the unicast transmission), the MAC sublayer 204 stops the unicast DRX cycle (e.g., Fig. 6A and Figure 6B The on-duration period of cycle 604-2 or 624-2).

[0208] Next reference Fig.13 , method 1300 may be implemented in a suitable RAN and includes generating DCI and scrambling CRC using an MBS-specific RNTI and transmitting the DCI and CRC to a UE in an MBS session. For clarity, method 1300 is discussed with specific reference to RAN 105, BS 104, CN 110, UE 102, PHY sublayer 202, and MAC sublayer 204.

[0209] At block 1302, the RAN 105 performs multicast DRX operations with the UE 102 (e.g., FIG. 5A to FIG. 5FEvent 536 or 596 of the present invention. In some implementations, UE 102 is a first UE and RAN 105 performs multicast DRX operation with multiple UEs participating in an MBS session. At block 1304, RAN 105 determines to transmit a DRX command to UE 102 (or multiple UEs). Depending on the implementation, RAN 105 selects a transmission scheme based on the type of DRX operation to be modified, such as MBS-specific RNTI, UE-specific RNTI, SPS, etc. For example, when modifying a multicast DRX cycle, RAN 105 selects an MBS-specific RNTI or SPS transmission scheme. When modifying a unicast DRX cycle, RAN 105 selects a UE-specific RNTI. In some implementations, the DRX command is an explicit command to stop the on-duration period. In further implementations, the DRX command is not an explicit command to stop the on-duration period, but ultimately UE 102 stops the on-duration period. At block 1308, RAN 105 then generates a DCI and a CRC and scrambles the CRC. In some implementations, the RAN 105 scrambles the CRC using an MBS-specific RNTI, such as a G-RNTI or a G-CS-RNTI.

[0210] At block 1310, the RAN 105 transmits the DCI and the scrambled CRC (e.g., FIG. 5A to FIG. 5F Event 536 or 596 of the DRX command. In some implementations, the RAN 105 transmits the DCI and the scrambled CRC to each UE 102 on the PDCCH. At block 1312, the RAN 105 generates a data packet, such as a MAC PDU, including the DRX command. In some implementations, the data packet also includes a subheader for the DRX command. In further such implementations, the subheader is or includes an indication of whether the DRX command is for a multicast DRX cycle or a unicast DRX cycle. At block 1314, the RAN 105 transmits a data packet (e.g., FIG. 5A to FIG. 5F event 536 or 596).

[0211] Next reference Fig.14, method 1400 may be implemented in a suitable RAN and includes determining whether to generate DCI according to an MBS-specific RNTI or a UE-specific RNTI and scramble the CRC based on at least whether the DRX operation is multicast or unicast. For clarity, method 1400 is discussed with specific reference to RAN 105, BS 104, CN 110, UE 102, PHY sublayer 202, and MAC sublayer 204. Portions of method 1400 are similar to the techniques described in method 1300. Specifically, blocks 1402, 1404, 1408, 1410, 1412, and 1414 are similar to Fig.13 1302, 1304, 1308, 1310, 1312 and 1314. Fig.13 The examples and implementations described in the box also apply to Fig.14 corresponding box.

[0212] At block 1402, the RAN 105 performs a DRX operation with the UE 102. A slight difference from block 1302 is that the DRX operation need not be a multicast DRX operation for multiple UEs. At block 1404, the RAN 105 determines to transmit a DRX command for the DRX operation. At block 1406, the RAN 105 determines whether the DRX operation is a multicast DRX operation or a unicast DRX operation. If the DRX operation is a multicast DRX operation, the flow proceeds to blocks 1408, 1410, 1412, and 1414.

[0213] If the DRX operation is a unicast DRX operation, the flow instead proceeds to block 1416, where the RAN 105 generates a second DCI and a CRC for the second DCI. However, instead of scrambling the CRC using an MBS-specific RNTI, the RAN 105 scrambles the CRC using a UE-specific RNTI for the UE 102, such as a C-RNTI or a CS-RNTI. At block 1418, the RAN 105 then transmits the second DCI and the scrambled CRC to the UE 102 (e.g., FIG. 5A to FIG. 5F Event 536 or 596). In some implementations, the RAN 105 transmits the second DCI and the scrambled CRC to the UE 102 on the PDCCH. Similar to block 1412, at block 1420, the RAN 105 then generates a data packet that includes a DRX command and a subheader for the DRX command. Subsequently, at block 1422, the RAN 105 transmits a data packet (e.g., FIG. 5A to FIG. 5F event 536 or 596).

[0214] Next reference Fig.15, method 1500 may be implemented in a suitable RAN and includes generating a MAC PDU and transmitting the MAC PDU using SPS multicast resources. For clarity, method 1500 is discussed with specific reference to RAN 105, BS 104, CN 110, UE 102, PHY sublayer 202, and MAC sublayer 204. Portions of method 1400 are similar to the techniques described in method 1300. Specifically, blocks 1504 and 1512 are similar to Fig.13 1304 and 1312. Thus, Fig.13 The examples and implementations described in the box also apply to Fig.15 corresponding box.

[0215] At block 1501, the RAN 105 configures and / or activates SPS multicast resources (e.g., FIG. 5A to FIG. 5F At block 1503, the RAN 105 performs multicast DRX operations with the plurality of UEs 102 (e.g., FIG. 5A to FIG. 5F At block 1504, the RAN determines to transmit a DRX command to the UE 102. At block 1512, the RAN 105 generates a data packet, such as a MAC PDU, including the DRX command and a subheader for the DRX command. At block 1515, the RAN 105 transmits the data packet to the UE 102 using the configured SPS multicast resources.

[0216] Next reference Fig.16 The method 1600 may be implemented in a suitable UE and includes managing DRX for an MBS session. For clarity, the method 1600 is discussed with specific reference to the RAN 105, BS 104, CN 110, UE 102, PHY sublayer 202, and MAC sublayer 204.

[0217] At block 1602, UE 102 receives an MBS session transmission (eg, FIG. 5A to FIG. 5F and Figures 7 to 12 At block 1604, the UE 102 determines whether the DRX command belongs to a multicast DRX cycle or a unicast DRX cycle (e.g., Figures 7 to 10 and Fig.12 At block 1606, the UE 102 modifies the DRX operation of the UE 102 based on the determination ( Figure 7 , Figure 8 and Fig.12710, 812, 814, 1210 and 1212).

[0218] Next reference Fig.17 The method 1700 may be implemented in a suitable RAN and includes managing DRX for an MBS session. For clarity, the method 1700 is discussed with specific reference to the RAN 105, BS 104, CN 110, UE 102, PHY sublayer 202, and MAC sublayer 204.

[0219] At block 1702, the RAN 105 generates a DRX command to modify DRX operation at a UE 102 participating in an MBS session (e.g., Figures 13 to 15 At block 1704, the RAN 105 selects a transmission scheme (e.g., Figures 13 to 15 At block 1706, the RAN 105 transmits a DRX command to the UE 102 according to the selected transmission scheme (e.g., FIG. 5A to FIG. 5F and Figures 13 to 15 Event 536 or 596 and boxes 1314, 1414, 1422 and 1515).

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

[0221] Example 1. A method for managing discontinuous reception (DRX) of a multicast and broadcast service (MBS) session, the method being implemented in a user equipment (UE) and comprising: receiving, by processing hardware, an MBS session transmission including a DRX command; determining, by the processing hardware, whether the DRX command belongs to a multicast DRX cycle or a unicast DRX cycle; and modifying, by the processing hardware, the DRX operation of the UE based on the determination.

[0222] Example 2. The method as described in Example 1 further includes: receiving a cyclic redundancy check (CRC) associated with the DCI and scrambled by a radio network temporary identifier (RNTI) from the RAN; wherein determining whether the DRX command belongs to a multicast DRX cycle or a unicast DRX cycle is based at least on whether the RNTI is an MBS-specific RNTI.

[0223] Example 3. The method of Example 2, wherein modifying the DRX operation of the UE comprises: when the RNTI is an MBS-specific RNTI, stopping an OnDuration period of a multicast DRX cycle.

[0224] Example 4. The method of Example 2, wherein modifying the DRX operation of the UE comprises: when the RNTI is not an MBS-specific RNTI, stopping an OnDuration period of a unicast DRX cycle.

[0225] Example 5. The method of Example 3 or 4 includes: determining that the RNTI is an MBS-specific RNTI when the RNTI is a G-RNTI or a G-CS-RNTI, and determining that the RNTI is not an MBS-specific RNTI when the RNTI is a C-RNTI or a CS-RNTI.

[0226] Example 6. The method of Example 1, wherein determining whether the DRX command belongs to a multicast DRX cycle or a unicast DRX cycle comprises determining whether an MBS session transmission including the DRX command is received via a multicast transmission or a unicast transmission.

[0227] Example 7. The method of Example 6, wherein receiving the MBS session transmission comprises: receiving a medium access control packet including a DRX command at an upper layer of the UE; and retrieving the DRX command from the medium access control packet.

[0228] Example 8. The method of any of the preceding examples, wherein receiving an MBS session transmission comprises transmitting a media access control packet including a multicast indication from a physical layer to an upper layer.

[0229] Example 9. The method of Example 8 further comprises: determining whether to transmit the transmission type indication to an upper layer based on whether a transmission type indication function is enabled at a physical layer of the UE.

[0230] Example 10. The method of Example 9, wherein the transmission type indication indicates multicast.

[0231] Example 11. The method of Example 10, further comprising: transmitting to an upper layer a transmission type indication indicating multicast when the MBS session transmission is a multicast transmission; and refraining from transmitting to an upper layer the transmission type indication when the MBS session transmission is not a multicast transmission.

[0232] Example 12. The method of Example 10, further comprising: transmitting to the upper layer a transmission type indicator indicating multicast when the MBS session transmission is multicast transmission; and transmitting to the upper layer a transmission type indicator indicating unicast when the MBS session transmission is not multicast transmission.

[0233] Example 13. The method of Example 9, wherein the transmission type indication indicates unicast.

[0234] Example 14. The method of Example 13, further comprising: transmitting to an upper layer a transmission type indicator indicating unicast when the MBS session transmission is unicast transmission; and avoiding transmitting to an upper layer the transmission type indication when the MBS session transmission is not unicast transmission.

[0235] Example 15. A method as described in any of Examples 2 or 6 to 14, wherein modifying the DRX operation of the UE includes stopping the on-duration operation.

[0236] Example 16. A user equipment (UE) comprising processing hardware and configured to implement a method according to any one of Examples 1 to 15.

[0237] Example 17. A method for managing discontinuous reception (DRX) for a multicast and broadcast service (MBS) session, the method being implemented in a radio access network (RAN) and comprising: generating, by processing hardware, a DRX command to modify a DRX operation at a UE participating in the MBS session; selecting, by the processing hardware, a transmission scheme for providing the DRX command to the UE based on a type of the DRX operation; and transmitting, by the processing hardware, the DRX command to the UE according to the selected transmission scheme.

[0238] Example 18. The method of Example 17, wherein selecting a transmission scheme comprises transmitting the DRX command using an MBS-specific RNTI when the type of DRX operation is multicast.

[0239] Example 19. The method of Example 17, wherein selecting a transmission scheme comprises transmitting the DRX command using a UE-specific RNTI when the type of DRX operation is unicast.

[0240] Example 20. A method as described in Example 17, wherein the type of DRX operation is multicast and the UE is the first UE among multiple UEs, the method further comprising: generating a DCI and a CRC for the DCI; scrambling the CRC using an MBS-specific RNTI; and transmitting the DCI and the scrambled CRC to multiple UEs; wherein transmitting the DRX command is based on the DCI.

[0241] Example 21. A method as described in Example 18, wherein the type of DRX operation is unicast, the method further comprising: generating a DCI and a CRC for the DCI; scrambling the CRC using a UE-specific RNTI; and transmitting the DCI and the scrambled CRC to the UE; wherein transmitting the DRX command is based on the DCI.

[0242] Example 22. A method as described in any one of Examples 18 to 21, including: determining that the RNTI is an MBS-specific RNTI when the RNTI is a G-RNTI or a G-CS-RNTI, and determining that the RNTI is not an MBS-specific RNTI when the RNTI is a C-RNTI or a CS-RNTI.

[0243] Example 23. The method of any one of Examples 17 to 22, wherein transmitting the DRX command comprises: transmitting a subheader for the DRX command, the subheader comprising an indication of a type of DRX operation.

[0244] Example 24. The method of Example 17, wherein the type of DRX operation is at least one of multicast or unicast.

[0245] Example 25. The method of Example 17, wherein selecting a transmission scheme comprises: configuring SPS multicast resources for the UE when the type of DRX operation is multicast; and transmitting a DRX command to the UE using the SPS multicast resources.

[0246] Example 26. A radio access network (RAN) node comprising processing hardware and configured to implement a method according to any one of Examples 17 to 25.

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

[0248] 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, an event or box with a dotted line in the figure may be optional or omitted. In some cases, if an event or box with a solid line in the figure is not required, the event or box 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".

[0249] The user device (e.g., UE 102A, 102B or UE 103) that can implement the technology of the present disclosure 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. Further, in some cases, the user device can be embedded in an electronic system, such as a head unit (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.

[0250] 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.

[0251] 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.

[0252] After reading this disclosure, those skilled in the art will understand additional alternative structural and functional designs for performing HARQ processes to transmit 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 constructions and components disclosed herein. Various modifications, changes and variations that will be apparent to those of ordinary skill in the art may be made to the arrangement, operation and details of the methods and apparatus disclosed herein without departing from the spirit and scope defined in the appended claims.

Claims

1. A method for managing discontinuous reception (DRX) for a multicast and broadcast service (MBS) session, the method being implemented in a user equipment (UE) and comprising: receiving an MBS session transmission including a DRX command associated with a radio network temporary identifier (RNTI); determining, based on the RNTI, whether the DRX command belongs to a multicast DRX cycle or a unicast DRX cycle; as well as Based on the determination, a timer associated with an OnDuration period of the multicast DRX cycle is stopped.

2. The method of claim 1, wherein determining whether the DRX command belongs to a multicast DRX cycle or a unicast DRX cycle based on the RNTI comprises: determining whether the DRX command belongs to a multicast DRX cycle based on whether the RNTI is an MBS-specific RNTI, When the RNTI is an MBS-specific RNTI, stopping the timer occurs.

3. The method of any one of claims 1 or 2, wherein modifying the DRX operation of the UE further comprises: When the RNTI is not an MBS-specific RNTI, the onDuration period of the unicast DRX cycle is stopped.

4. The method of claim 2, comprising: determining that the RNTI is an MBS-specific RNTI when the RNTI is a G-RNTI or a G-CS-RNTI, and When the RNTI is a C-RNTI or a CS-RNTI, it is determined that the RNTI is not an MBS-specific RNTI.

5. The method of any preceding claim, wherein receiving the MBS session transmission comprises: A medium access control packet including a multicast indication is sent from the physical layer to an upper layer.

6. The method of claim 5, further comprising: Whether to transmit a transmission type indication to the upper layer is determined based on whether a transmission type indication function is enabled at the physical layer of the UE.

7. The method of claim 6, wherein the transmission type indication indicates multicast, the method further comprising: When the MBS session transmission is a multicast transmission, transmitting to the upper layer the transmission type indication indicating multicast; as well as Avoid transmitting the transmission type indication to the upper layer when the MBS session transmission is not a multicast transmission.

8. The method of claim 6, wherein the transmission type indication indicates unicast, the method further comprising: When the MBS session transmission is unicast transmission, transmitting to the upper layer a transmission type indicator indicating unicast; as well as Avoid transmitting the transmission type indication to the upper layer when the MBS session transmission is not a unicast transmission.

9. The method of any of the preceding claims, wherein the timer is a drx-onDurationTimerPTM timer.

10. A user equipment (UE) comprising processing hardware and configured to implement the method according to any one of claims 1 to 9.

11. A method for managing discontinuous reception (DRX) for a multicast and broadcast service (MBS) session, the method being implemented in a radio access network (RAN) and comprising: generating a DRX command associated with a radio network temporary identifier (RNTI), the DRX command being used to stop a timer associated with an OnDuration period of a multicast DRX cycle based on the RNTI; selecting, based on the type of the DRX operation, a transmission scheme for providing the DRX command to the UE; as well as The DRX command is transmitted to the UE according to the selected transmission scheme.

12. The method of claim 11, wherein selecting the transmission scheme comprises: The DRX command is transmitted using an MBS-specific RNTI when the type of DRX operation is multicast.

13. The method of claim 11, wherein selecting the transmission scheme comprises: The DRX command is transmitted using a UE-specific RNTI when the type of DRX operation is unicast.

14. The method according to any one of claims 11 to 13, comprising: determining that the RNTI is an MBS-specific RNTI when the RNTI is a G-RNTI or a G-CS-RNTI, and When the RNTI is a C-RNTI or a CS-RNTI, it is determined that the RNTI is not an MBS-specific RNTI.

15. The method of any one of claims 11 to 14, wherein transmitting the DRX command comprises: A subheader for the DRX command is transmitted, the subheader including an indication of the type of DRX operation.

16. The method of claim 11, wherein selecting the transmission scheme comprises: When the type of DRX operation is multicast, configure SPS multicast resources for the UE; as well as The DRX command is transmitted to the UE using the SPS multicast resource.

17. A Radio Access Network (RAN) node comprising processing hardware and configured to implement the method according to any one of claims 11 to 16.

Images