Managing multicast session setup

Abstract

A central unit (CU) of a distributed base station transmits a distribution setup request message to a core network (CN); receiving a distribution establishment response message including the first MBS QoS flow configuration from the CN; and transmitting a multicast context setup request message to a distributed unit (DU) of the distributed base station, the multicast context setup request message including a second MBS QoS flow configuration based on the first MBS QoS flow configuration to establish a multicast context for the MBS session.

Description

Technical Field

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

[0002] 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 described in this background section) and aspects of the specification that may not have been identified as prior art at the time of filing are neither explicitly nor implicitly admitted to be prior art to the present disclosure.

[0003] Base stations operating according to the fifth generation (5G) new radio (NR) requirements support significantly larger bandwidths than fourth generation (4G) base stations. Therefore, the third generation partnership project (3GPP) has proposed that for release 15, the user equipment unit (UE) supports 100 MHz bandwidth in frequency range 1 (FR1) and 400 MHz bandwidth in frequency range 2 (FR2). The 5G NR system 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.

[0004] 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 within the multicast service area are authorized to receive the data). Multicast communication services are delivered to UEs using multicast sessions. 5G NR provides point-to-point (PTP) and point-to-multipoint (PTM) delivery methods for the transmission of MBS packet streams over the radio interface. In PTP communication, the RAN node sends different copies of each MBS data packet to different UEs over the radio interface. On the other hand, in PTM communication, the RAN node sends a single copy of each MBS data packet to multiple UEs over the radio interface according to a discontinuous reception (DRX) cycle.

[0005] 5G NR provides point-to-point (PTP) and point-to-multipoint (PTM) delivery methods for the transmission of MBS packet streams over the radio interface. In PTP communication, the RAN node sends different copies of each MBS data packet to different UEs over the radio interface. On the other hand, in PTM communication, the RAN node sends a single copy of each MBS data packet to multiple UEs over the radio interface. The multicast MBS session context establishment process is defined in 3GPP specification 38.401 v17.0.0 and was recently updated according to document R3-224064. While these documents require the core network (CN) to send an NGAP message to the base station to trigger the establishment of a multicast session context, it is unclear which NGAP message the CN should utilize in this case. In addition, in this scenario, none of the existing messages that the CN can send can convey enough information for the base station to correctly configure the MBS session. Summary of the invention

[0006] The base station of the present disclosure receives an MBS Quality of Service (QoS) flow configuration from the core network before the time when the CU must configure the DU with the MBS QoS flow configuration, or retrieves the MBS QoS flow configuration from the memory according to the previous configuration. In this way, the CU ensures that the DU can correctly configure the MBS QoS flow. In various implementations, the CU receives this information from the CN in a multicast session activation request, a multicast session update request, or a distribution establishment response received before the CU requests a multicast context establishment from the DU.

[0007] An example embodiment of these techniques is a method for multicast session establishment in a central unit (CU) of a distributed base station, comprising: obtaining, by one or more processors, one or more multicast and broadcast service (MBS) quality of service (QoS) flow configurations at a first time during a process for establishing a context for the multicast session; and sending, by the one or more processors, the one or more MBS QoS flow configurations to a distributed unit (DU) of the distributed base station at a second time after the first time during the process for establishing a context for the multicast session.

[0008] Another example embodiment of these techniques is a CU of a distributed base station, the CU comprising one or more processors and configured to implement the above method.

[0009] Another example embodiment of these technologies is a method for multicast session establishment in a core network (CN), the method comprising: sending, by one or more processors, a multicast session activation or update request including one or more multicast and broadcast service (MBS) quality of service (QoS) flow configurations to a base station; and receiving, by one or more processors, a response to the multicast session activation or update request from the base station.

[0010] Another example embodiment of the techniques is a core network comprising one or more computing devices and configured to implement the above method. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1A is a block diagram of an example system in which techniques for managing MBS session activation of the present disclosure may be implemented;

[0012] Figure 1B is a block diagram of an example base station in which a centralized unit (CU) and a distributed unit (DU) may be Figure 1A Operate in a system

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

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

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

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

[0017] Figure 5A is a message passing diagram for the example scenario, where Figure 1A and / or Figure 1B The distributed base station receives one or more MBS QoS flow configurations from the CN in a multicast session activation request message and proceeds to establish a context for the multicast MBS session;

[0018] Figure 5B is with Figure 5A A message passing diagram of an example scenario similar to the scenario of FIG. 1 , but where the CU retrieves the QoS flow configuration from local storage;

[0019] Figure 5C is with Figure 5A A message passing diagram for an example scenario similar to the scenario of , but where the CU receives a distribution setup response with one or more MBS QoS flow configurations;

[0020] Figure 5D is with Figure 5A A message passing diagram of an example scenario similar to the scenario of , but in which the CU receives a multicast session update request message instead of a multicast session activation request message;

[0021] Figure 5E is with Figure 6 A to Figure 6 Message passing diagram for example scenarios similar to those of D, but including UE-specific CN to CU messaging;

[0022] Figure 6 is a flow chart of an example method for multicast session establishment that may be implemented in a CN of the present disclosure;

[0023] Figure 7 is with Figure 6 A flowchart of an example method for multicast session establishment similar to method A, but involving update requests instead of activation requests;

[0024] Fig. 8A is a flow chart of an example method for establishing a context for a multicast MBS session, wherein an MBS QoS flow configuration arrives in a multicast session activation request message, which method may be implemented in a base station of the present disclosure;

[0025] Figure 8B is with Fig. 8A A flowchart of an example method similar to that of , but wherein the CU retrieves the QoS flow configuration from a local memory;

[0026] Figure 8C is with Fig. 8A A flowchart of an example method similar to the method of , but wherein the CU receives a distribution setup response with an MBS QoS flow configuration before establishing a multicast context with the DU;

[0027] Fig.8D is with Fig. 8A A flowchart of an example method similar to the method of , but wherein the MBS QoS flow configuration arrives in a multicast session update request message;

[0028] Fig. 8E is with Fig. 8A A flowchart of an example method similar to the method of , but wherein the CU receives the QoS flow configuration in a message associated with a specific UE;

[0029] Fig. 9A is a flow chart of an example method for establishing a context for a multicast MBS session, wherein a CU determines whether to rely on a pre-stored MBS QoS flow configuration based on whether a CN has provided an MBS QoS flow configuration in a message to the CU; and

[0030] Fig. 9B is with Fig. 9AFlowchart of an example method similar to the method of , but wherein the CU determines whether to exclude mandatory information elements (IEs) from the CU to DU message based on whether the CN has provided the MBS QoS flow configuration in the message transmitted to the CU. DETAILED DESCRIPTION

[0031] Figure 1A An example wireless communication system 100 is depicted that can implement the disclosed techniques for managing the transmission and reception of multicast and / or broadcast service (MBS) information. The wireless communication system 100 includes user equipment (UE) 102A, 102B, and 103 and base stations 104, 106 of a radio access network (RAN) 105 connected to a core network (CN) 110. In other implementations or scenarios, the wireless communication system 100 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).

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

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

[0034] In MBS operation, UE 102A may use MBS radio bearers (MRBs) that terminate at MN (e.g., base station 104) or SN (e.g., base station 106) at different times. For example, after handover or SN change, UE 102A may use an MRB that terminates at base station 106, which operates as a MN or SN. In some scenarios, the base station (e.g., MN or SN) may send MBS data to UE 102A via the MRB over unicast radio resources (i.e., radio resources dedicated to UE 102A). In other scenarios, the base station (e.g., MN or SN) may send MBS data to UE 102A via the MRB over multicast radio resources (i.e., radio resources shared by 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).

[0035] The base station 104 includes processing hardware 130, which may include one or more general-purpose processors (e.g., central processing units (CPUs)) and computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and / or special-purpose processing units. Figure 1AIn an example implementation of the present invention, the processing hardware 130 includes an MBS controller 132 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.

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

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

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

[0039] Among other components, the EPC 111 may also include a serving gateway (SGW) 112, a mobility management entity (MME) 114, and a packet data network gateway (PGW) 116. The SGW 112 is generally configured to transmit user plane packets related to audio calls, video calls, Internet traffic, etc., and the MME 114 is configured to manage authentication, registration, paging, and other related functions. The PGW 116 provides a connection from a UE (e.g., UE 102A or 102B) to one or more external packet data networks (e.g., an Internet network and / or an Internet Protocol (IP) Multimedia Subsystem (IMS) network). The 5GC 160 includes a user plane function (UPF) 162 and an access and mobility management (AMF) 164, and / or a session management function (SMF) 166. UPF 162 is generally configured to transmit user plane packets associated with audio calls, video calls, Internet traffic, etc., AMF 164 is generally configured to manage authentication, registration, paging and other related functions, and SMF 166 is generally configured to manage PDU sessions.

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

[0041] Generally, in some implementations, the wireless communication system 100 includes any suitable number of base stations supporting NR cells and / or EUTRA cells. More specifically, in other 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 technology of the present disclosure can also be applied to other suitable radio access technologies and / or core network technologies, such as the sixth generation (6G) radio access and / or 6G core network or 5GNR-6G DC.

[0042] Figure 1B An example distributed implementation of any one or more of base stations 104 and 106 is depicted. In this implementation, base station 104 or 106 includes a central unit (CU) 172 and one or more distributed units (DUs) 174. CU 172 includes processing hardware, such as one or more general-purpose processors (e.g., CPUs) and computer-readable memory storing machine-readable instructions that can be executed 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.

[0043] Each of the DUs 174 also includes processing hardware, which may include one or more general-purpose processors (e.g., CPUs) and computer-readable memory storing machine-readable instructions executable on 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. The processing hardware may also include a physical (PHY) layer controller configured to manage or control one or more PHY layer operations or procedures.

[0044] In some implementations, CU 172 may include 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. CU 172 may also include 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 may transmit non-MBS control information and MBS control information, and CU-UP 172B may transmit non-MBS data packets and MBS data packets, as described herein.

[0045] CU-CP 172A may be connected to multiple CU-UPs 172B via an E1 interface. CU-CP 172A selects an appropriate CU-UP 172B for the service requested by UE 102A. In some implementations, a single CU-UP 172B may be connected to multiple CU-CPs 172A via an E1 interface. CU-CP 172A may be connected to one or more DUs 174 via an F1-C interface. CU-UP 172B may be 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 may be 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.

[0046] Figure 2AAn example protocol stack 200 is shown in a simplified manner, according to which a UE (e.g., UE 102A, 102B, or 103) can communicate 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, the UE 102A may support layering of the NR PDCP 210 on the EUTRA RLC 206A, and layering of the SDAP sublayer 212 on the NR PDCP sublayer 210. The sublayers are also referred to herein simply as “layers”.

[0047] The EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 receive packets that may be referred to as service data units (SDUs) (e.g., from an IP layer layered directly or indirectly on the PDCP layer 208 or 210) and output packets that may be referred to as protocol data units (PDUs) (e.g., to the RLC layer 206A or 206B). Except for cases where the difference between SDUs and PDUs is important, for simplicity, the present disclosure refers to both SDUs and PDUs as "packets." The packets may be MBS packets or non-MBS packets. For example, the MBS packets may 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 may include application control information for the MBS services.

[0048] For example, on the control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 may 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 may provide DRBs to support data exchange. The data exchanged on the NR PDCP sublayer 210 may be, for example, SDAP PDUs, IP packets, or Ethernet packets.

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

[0050] Figure 2B An example protocol stack 250 is shown in a simplified manner that a UE 102A, 102B, or 103 may use 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 split, as shown by Figure 2B206B, NR MAC 204B, and NR PHY 202B) can be 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.

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

[0052] 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 may be referred to as a downlink (DL) tunnel. However, in other cases, CN 110 and base station 104 / 106 use tunnel 312A for downlink as well as uplink (UL) MBS traffic to support, for example, commands or service requests from UEs. In addition, since base station 104 / 106 may direct MBS traffic arriving via tunnel 312A to multiple UEs, tunnel 312A may be referred to as a common tunnel or a common DL tunnel.

[0053] Tunnel 312A may operate at a transport layer or sublayer, for example, on a user datagram protocol (UDP) protocol layered on an Internet protocol (IP). As a more specific example, tunnel 312A may be associated with a general packet radio system (GPRS) tunnel protocol (GTP). For example, tunnel 312A may correspond to a certain IP address (e.g., the IP address of base station 104 / 106) and a certain tunnel endpoint identifier (TEID) (e.g., assigned by base station 104 / 106). More generally, tunnel 312A may have any suitable transport layer configuration. CN 110 may specify an IP address and a TEID address in a header of a tunnel packet including an MBS data packet, and send the tunnel packet downstream to base station 104 / 106 via tunnel 312A (i.e., the header may include an IP address and / or a TEID). For example, the header may include an IP header and a GTP header including an IP address and a TEID, respectively. The base stations 104 / 106 may accordingly use the IP address and / or TEID to identify data packets propagating via the tunnel 312A.

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

[0055] For each of the tunnels 312A, 312B, etc., the MBS service may include one or more quality of service (QoS) flows. For example, the MBS service on the tunnel 312B may include a set of flows 316, including QoS flows 316A, 316B, ..., 316L. In addition, the logical channels of the MRB may 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.

[0056] In various scenarios, CN 110 may assign different types of MBS services to different QoS flows. For example, a flow with a relatively higher QoS value may correspond to an audio packet, while a flow with a relatively lower QoS value may correspond to a video packet. As another example, a flow with a relatively higher QoS value may correspond to an I frame or a complete image used in video compression, while a flow with a relatively lower QoS value may correspond to a P frame or a predicted picture including only a change to an I frame.

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

[0058] Reference now Figure 4 , when the base station 104 / 106 is implemented in a distributed manner, the CU 172 and the DU 174A / 174B may establish a tunnel for downlink data and / or uplink data associated with an MRB or a 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. The MRB 402A may include 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. Specifically, the DU 174A / 174B may map downlink traffic received via the DL tunnel 412A to the DL logical channel 422A, which may be, for example, an MTCH or a DTCH. The DL tunnel 412A may be a common DL tunnel, and the CU 172 sends MBS data packets to multiple UEs via the common DL tunnel. Alternatively, the DL tunnel 412A may be a UE-specific DL tunnel via which the CU 172 sends the MBS data packets to a specific UE.

[0059] Optionally, 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. For example, the UL logical channel 423A may be a DTCH. The DU 174A / 174B may map the uplink traffic received via the UL logical channel 423A to the UL tunnel 413A.

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

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

[0062] In some cases, CU 172 uses DRB 404A to send MBS data packets or unicast data packets associated with a PDU session to a specific UE (e.g., UE 102A or UE 102B). DRB 404A may include a UE-specific DL tunnel 432A connecting CU 172 and DU 174A / 174B, and a DL logical channel 442A corresponding to DL tunnel 432A. Specifically, for example, DU 174A / 174B can map downlink traffic received via DL tunnel 432A to DL logical channel 442A, which can be DTCH. DRB 404A also 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. For example, UL logical channel 443A can be PUSCH. The DU 174A / 174B may map uplink traffic received via the UL logical channel 443A to the UL tunnel 433A.

[0063] Similarly, the DRB 404B may include 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.

[0064] Next, refer to FIG. 5A to FIG. 5E Several scenarios are discussed where the distributed base station facilitates the establishment of a multicast session and provides the MBS QoS flow configuration from the CU to the DU before the multicast context is established at the DU. FIG. 5A to FIG. 5E The scenario involves MBS QoS flow configuration, but the techniques implemented by the network device can also be applied to network slicing, as explained below.

[0065] First reference Figure 5A In the example scenario 500A of establishing an MBS session, the base station 104 includes the DU 174, the CU-CP 172A, and the CU-UP 172B. The scenario 500A may also be applied to an integrated CU, where there is no logical separation of the CP and UP functional nodes.

[0066] 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 may not involve CU-CP 172B. In some scenarios, UE 102 subsequently performs one or more additional MBS join procedures, and event 502 is therefore the first of multiple MBS join procedures. Since base station 104 configures a common DL tunnel for MBS services (rather than a UE-specific tunnel as discussed below), processes 502 and 592A 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.

[0067] 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 may send an MBS session join response message to UE 102 via base station 104 to authorize UE 102 to access the first MBS session. In some implementations, UE 102 may include a first MBS session ID (e.g., MBS 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 may send an MBS session join complete message to CN 110 via base station 104 in response to the MBS session join response message.

[0068] In some implementations, the MBS session join request message, the MBS session join response message, and the MBS session join complete message may be session initiation protocol (SIP) messages. In other implementations, the MBS session join request message, the MBS session join response message, and the MBS session join complete message may be NAS messages, such as 5G mobility management (5GMM) messages or 5G session management messages (5GSM). In the case of 5GSM messages, the UE 102 may send a (first) UL container message including the MBS session join request message to the CN 110 via the base station 104, the CN 110 may send a DL container message including the MBS session join response message to the UE 102 via the base station 104, and the UE 102 may send a (second) UL container message including the MBS session join complete message to the CN 110 via the base station 104. These container messages may be 5GMM messages. In some implementations, the MBS session join request message, the MBS session join response message, and the MBS session join complete message may be a PDU session 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 represent corresponding container messages, or corresponding messages without containers.

[0069] In some implementations, UE 102 may perform 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.

[0070] Before, during, or after the first MBS session joining process (event 502), CN 110 may send 504 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).

[0071] In some implementations, the CN 110 includes a first MBS Quality of Service (QoS) flow configuration for the first MBS session in a first CN to BS message. In some implementations, the first MBS QoS flow configuration configures MBS QoS flows 1, ..., M associated with the first MBS session. M is an integer and is 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 some 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.

[0072] In some implementations, CN 110 may include first slice information in the first CN to BS message, the first slice information indicating the network slice used for the first MBS session. For example, the first slice information may be single network slice selection assistance information (S-NSSAI) that identifies a specific network slice. In addition to the first MBS QoS flow configuration, CU-CP 172A also configures and manages resources for the first MBS session based on the first slice information. In other implementations, CN 110 does not include slice information (e.g., S-NSSAI) in the first CN to BS message. In such cases, a default network slice may be used for the first MBS session, and CU-CP 172A configures and manages resources for the first MBS session within the default network slice.

[0073] In some implementations, CN 110 may include first MBS area information (e.g., MBS service area IE) in the first CN to BS message, the first MBS area information configuring or indicating the MBS area for the first MBS session. In the case where the first MBS session is a location-dependent multicast session, the first MBS area information includes one or more tuples {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 cell identifiers and / or a list of tracking area identifiers (TAIs). In one implementation, the cell identifier is a cell global identifier (CGI). In other implementations, CN 110 does not include the MBS area information (e.g., MBS service area IE) in the first CN to BS message.

[0074] After receiving 504 the first CN to BS message, CU-CP 172A sends 560 a first CP to UP message (e.g., an MC bearer context establishment request message) to CU-UP 172B to request resources for the first MBS session. In some implementations, CU-CP 172A determines to configure one or more MRBs for the first MBS session or MBS QoS flows 1, ..., M. In response to the determination, CU-CP 172A generates an MRB establishment configuration to request resources for one or more MRBs. CU-CP 172A includes the first MBS session ID, the MRB establishment configuration, and / or the second MBS QoS flow configuration for the first MBS session in the first CP to UP message. In some implementations, the second MBS QoS flow configuration includes QoS parameters for the 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.

[0075] In some implementations, the CU-CP 172A may include the second MBS QoS flow configuration (e.g., MBS QoS flow information to be established IE and / or MRB QoS IE or QoS-Flow-QoS-Parameter-List IE 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).

[0076] 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 establishment configuration includes MRB establishment configuration items 1, ..., N for MRBs 1, ..., N, respectively. N is an integer and greater than zero. In the MRB establishment configuration, the CU-CP 172A may configure a mapping or association between MBS QoS flows 1, ..., M and MRBs 1, ..., N, where N is an integer and M>=N>0. In some implementations, the CU-CP 172A associates or maps a specific QoS flow to only a specific MRB. In other words, 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 establishment configuration item X includes an MRB ID X, a PDCP configuration X, an SDAP configuration X, and / or a specific MBS QoS flow configuration in the second MBS QoS flow configuration.

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

[0078]

[0079] (Table 1)

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

[0081]

[0082] (Table 2)

[0083] In some implementations, the 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.

[0084] In some cases where CU-CP 172A receives the first slice information from CN 110 (e.g., in the first CN to BS message), CU-CP 172A includes the first slice information in the first CP to UP message to indicate that the first MBS session uses the specific network slice indicated by the first slice information. Therefore, in addition to the second MBS QoS flow configuration, CU-UP 172B also configures and manages resources based on 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 the specific network slice is used for the first MBS session. Therefore, in addition to the second MBS QoS flow configuration, CU-UP 172B also configures and manages resources based on the preconfigured slice information. 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 the default network slice. Therefore, CU-UP 172B configures and manages resources within or using a default network slice based on the second MBS QoS flow configuration.

[0085] 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 other 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.

[0086] In response to the first CP to UP message, CU-UP 172B establishes or configures resources for the MRB and sends 562 a first UP to CP message (e.g., an MC bearer context setup response message). In some implementations, CU-UP 172B configures resources for each 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-UP 172B configures resources for the MRB, the MBS QoS flow, and / or the first MBS session based on the first slice information. In some implementations, CU-UP 172B establishes and / or configures PDCP entities 1, ..., N according to PDCP configurations 1, ..., N for MRBs or MRB IDs 1, ..., N, respectively. In other implementations, for each of PDCP configurations 1, ..., N, CU-UP 172B ignores or discards a portion of the PDCP configuration and establishes and / or configures the PDCP entity according to the remaining portion 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.

[0087] In some implementations, CU-UP 172B establishes and / or configures SDAP entities 1, ..., N according to SDAP configurations 1, ..., N for MRB or MRB ID 1, ..., N, respectively. In other implementations, for each of SDAP configurations 1, ..., N, CU-UP 172B ignores or discards a portion of the SDAP configuration and establishes and / or configures the SDAP entity according to the remainder of the SDAP configuration. In one implementation, CU-UP 172B ignores or discards the default DRB configuration and 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 send the MBS data for the first MBS session.

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

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

[0090] After receiving 504 the first CN-to-BS message (eg, in response to receiving the first CN-to-BS message), the CU-CP 172A sends 506 a first CU-to-DU message (eg, a multicast context setup request message) to the DU 174 to request the establishment of a multicast context and / or a common DL tunnel for the first MBS session. Figure 4and accompanying text. 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 to be established configuration to request resources for one or more MRBs. In some implementations, the first CU to DU message includes the first MBS session ID, the MRB to be established configuration and / or the third MBS QoS flow configuration for the first MBS session. In some implementations, CU-CP 172A includes the first slice information in the first CU to DU message to indicate that the specific network slice indicated by the first slice information is used for the first MBS session. In some implementations, the MRB to be established configuration includes an MRB ID that each identifies the MRB, and DU 174 configures resources (e.g., PHY, MAC and / or RLC resources) for the MRB. 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. For example, the MRB to be established configuration includes MRB IDs 1, ..., N for MRB1, ..., N, respectively. The third MBS QoS flow configuration includes QoS parameters required for the MBS QoS flow associated with the first MBS session. In some implementations, the third MBS QoS flow configuration includes MBS QoS flow identifiers 1, ..., M and / or MBS QoS flow level QoS parameters 1, ..., M for MBS QoS flows 1, ..., M associated with the first MBS session, respectively. MBS QoS flow identifiers 1, ..., M identify MBS QoS flows 1, ..., M, respectively. In the MRB to be established configuration, the CU-CP 172A may configure a mapping or association between the MBS QoS flows and the MRBs. For example, the MRB to be established configuration includes MRB to be established configuration items 1, ..., N for MRBs 1, ..., N, respectively. In some implementations, for MRB Y in MRB 1, ..., N, where 1 <= Y <= N, the MRB configuration item Y to be established includes MRB ID Y and a specific MBS QoS flow configuration in the third MBS QoS flow configuration. In some implementations, 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, CU-CP 172A includes the CU MBSF1AP ID in the first CU to DU message to identify the first MBS session on the F1 interface between CU-CP 172A and DU 174.

[0091] In the case where CU-CP 172A receives first slice information (e.g., S-NSSAI) associated with the first MBS session from CN 110 (e.g., in the first CN to BS message), CU-CP 172A includes the first slice information in the first CU to DU message to indicate that a specific network slice is used for the first MBS session. In the case where CU-CP 172A does not receive slice information (e.g., S-NSSAI) associated with the first MBS session from CN 110 (e.g., in the first CN to BS message), CU-CP 172A includes the preconfigured slice information in the first CU to DU message. Alternatively, in such a case, CU-CP 172A omits the slice information from the first CP to UP message.

[0092] In the case 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 may include the first MBS region information in the first CU to DU message. In the case 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 may include the preconfigured MBS region information in the first CU to DU message. Alternatively, in such a case, CU-CP 172A omits the MBS region information from the first CU to DU message. In the case 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 may retrieve the MBS region session ID from the first MBS region information and include the MBS region session ID in the first CU to DU message. In the event that 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 CU to DU message. Alternatively, in such a case, CU-CP 172A omits the MBS region session ID from the first CU to DU message.

[0093] In response to receiving 506 the first CU-to-DU message, the DU 174 establishes or configures resources (e.g., multicast context and / or PHY, MAC, RLC, and / or tunnel resources) for the MRB and sends 508 a first DU-to-CU message (e.g., a multicast context setup response message) to the CU-CP 172A. In some implementations, the DU 174 establishes and / or configures a MAC entity for the MRB. In some implementations, the DU 174. In some implementations, the CU-UP 172B establishes and / or configures RLC entities 1, ..., N for the MRB or MRB IDs 1, ..., N, respectively. In some implementations, the DU 174 includes a first DU transport layer configuration in the first DU-to-CU message to configure a common CU-to-DU DL tunnel for the first MBS session (e.g., the MRB identified by one of the MRB IDs). DU 174 may include additional DU transport layer configurations in the first DU to CU message to configure additional common CU to DU DL tunnels for additional MRBs identified by additional MRB IDs in the MRB IDs. In some implementations, DU 174 may include MRB IDs associated with the first DU transport layer configuration and / or additional DU transport layer configurations 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 additional DU transport layer configurations includes a DU transport layer address (e.g., an IP address and / or TEID). In some implementations, each of the first DU transport layer configuration and / or additional DU transport layer configurations may be an MRB F1-U TNL information IE at the DU.

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

[0095] In some implementations, DU 174 sends 510 a second DU-to-CU message (e.g., a multicast distribution setup request message) to CU-CP 172A after receiving 506 the first CU-to-DU message or sending 508 the first DU-to-CU message. In some implementations, DU 174 includes the first DU transport layer configuration and / or the additional DL transport layer configuration in the second DU-to-CU message instead of the first DU-to-CU message. In some implementations, DU 174 may include 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. Thus, the first DU-to-CU message does not include the DU transport layer configuration. In some implementations, CU-CP 172A sends 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. Events 510 and 516 occur at Figure 5A It is collectively referred to as the multicast distribution establishment process.

[0096] After receiving 504 the first CN to S message, receiving 562 the first UP to CP message, receiving 508 the first DU to CU message, or receiving 510 the second DU to CU message, CU-CP 172A sends 512 a first BS to CN message (e.g., a distribution setup request message) to CN 110. In some implementations, CU-CP 172A sends 512 the first BS to CN message to CN 110 before receiving 508 the first DU to CU message or receiving 510 the second DU to CU message. In some implementations, CU-CP 172A may include the first CU transport layer configuration in the first BS to CN message. Thus, CN 110 may send MBS data to CU-UP 172B via the first public CN to BS DL tunnel, as described for event 532. In some implementations, CU-CP 172A may include 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., an IP address) for identifying a first public CN to BS DL tunnel. In some implementations, at least one transport layer address includes an IP source address and / or an IP multicast address. In some implementations, the first CN transport layer configuration includes a TEID at CN 110 / TEID 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 one implementation, the fourth MBS QoS flow configuration is similar to the first MBS QoS flow configuration.

[0097] After receiving 514 the second CN to BS message, CU-CP 172A sends 564 a second CP to UP message (e.g., an MC bearer context modification request message) to CU-UP 172B. In some implementations, CU-CP 172A includes the MRB ID, the first DU transport layer configuration, the additional DU transport layer configuration, and / or the first CN transport layer configuration in the second CP to UP message. In response to the second CP to UP message of event 564, CU-UP 172B sends 566 a second UP to CP message (e.g., an MC bearer context modification response message). In some implementations, CU-UP 172B includes the MRB ID and / or the second CU transport layer configuration in the second UP to CP message. In some implementations, the second CU transport layer configuration includes a CU transport layer address (e.g., an IP address) for identifying the first common CU to DUDL tunnel. In addition, the second CU transport layer configuration may include a TEID at CU-UP 172B / TEID of 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, CU-CP 172A includes the second CU transport layer configuration in the second CU to DU message and sends 516 the second CU to DU message to DU 174 in response to the second DU to CU message of event 510. After receiving 566 the second UP to CP message or sending 516 the second CU to DU message, CU-CP 172A sends 518 the second BS to CN message (e.g., a multicast session activation response message) to CN 110 in response to the first CN to BS message. Alternatively, CU-CP 172A sends 518 the second BS to CN message to CN 110 before receiving 566 the second UP to CP message or sending 516 the second CU to DU message. For example, the CU-CP 172A sends 518 a second BS to CN message to the CN 110 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.

[0098] In some implementations, CU-CP 172A may include the fourth MBS QoS flow configuration in the MC bearer context modification request message. In such implementations, CU-UP 172B may modify or reconfigure the resources for the MRB based on the fourth MBS QoS flow configuration. In some implementations, CU-UP 172B may determine whether to modify or reconfigure the resources for the MRB based on the fourth MBS QoS flow configuration. For example, if the resources for 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-UP172B may determine whether to modify or reconfigure the resources for a specific MRB among the MRBs based on the fourth MBS QoS flow configuration. For example, if the resources for the first MRB in the MRBs at event 562 can still satisfy the specific MBS QoS flow configuration in the fourth MBS QoS flow configuration for the specific MBS QoS flow mapped to the first MRB, 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 first MRB based on the specific MBS QoS flow configuration.

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

[0100] In some implementations, the CN 110 may send 520 a third CN-to-BS message to the CU-CP 172A, which (only) indicates that the UE 102 (e.g., UE 102A) joins the first MBS session. In some implementations, the CN 110 may include a first MBS session ID and / or an MBS QoS flow identifier that respectively identifies the first MBS session and the MBS QoS flow associated with the first MBS session in the third CN-to-BS message. In response to the third CN-to-BS message, 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 to the DU 174. In some implementations, the CU-CP 172A may include the MRB ID in the UE context request message. In some implementations, the CU-CP 172A determines the MRB ID based on the first MBS session ID and / or the MBS QoS flow identifier received in the third CN to BS message. In some implementations, the CU-CP 172A may not include the first MBS session ID in the UE context request message.

[0101] In response to the UE context request message of event 522, DU 174 sends 524 a UE context response message including configuration parameters to CU-CP 172A so that UE 102A receives MBS data for the first MBS session via the MRB. Some or all of the configuration parameters may be associated with the MRB / 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 the one or more logical channels. In some implementations, the third CN to BS message and the third BS to CN message may be a PDU session resource modification request message and a PDU session resource modification response message, respectively. In other implementations, the third CN to BS message and the third BS to CN message may be a PDU session resource establishment request message and a PDU session resource establishment response message, respectively. In some implementations, the third CN to BS message and the third BS to CN message may be UE-related messages, i.e., these messages are associated with a specific UE (e.g., UE 102A, 102B, or 103).

[0102] In some implementations, the UE context request message and the UE context response message are respectively a UE context establishment request message and a UE context establishment response message. In 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.

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

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

[0105] Events 520, 522, 524, 526, 527 (discussed below), 528, 530, and 531 are Figure 5A594. CN 110 and / or CU-CP 172A performs process 594 for each of the UEs (e.g., UE 102A and UE 102B) that join the first MBS session. In some scenarios or implementations, process 594 may occur before process 592A. In other scenarios or implementations, process 594 may occur after process 592A. In yet other scenarios or implementations, process 594 may overlap with process 592A.

[0106] In some implementations, the CU-CP 172A generates a PDCP PDU including an RRC reconfiguration message and sends 526 a CU-to-DU message to the DU 174. In such implementations, the DU 174 retrieves the PDCP PDU from the CU-to-DU message and sends 528 the PDCP PDU to the UE 102 via the RLC layer 206B, the MAC layer 204B, and 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 the RLC layer 206B. In some implementations, the UE 102 generates a PDCP PDU including an RRC reconfiguration complete message and sends 530 the PDCP PDU to the DU 174 via the RLC layer 206B, the MAC layer 204B, and the PHY layer 202B. DU 174 receives 522 PDCP PDU from UE 102 via PHY layer 202B, MAC layer 204B, and 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.

[0107] Before or after receiving 524 the UE context response message, CU-CP 172A may send 527 a third BS to CN message to CN 110 in response to the third CN to BS message 520. In some implementations, CU-CP 172A sends 527 the third BS to CN message to CN 110 before receiving 531 the RRC reconfiguration complete message. In other implementations, CN 110 sends 527 the third BS to CN message to CN 110 after receiving 531 the RRC reconfiguration complete message. 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, CN 110 assigns a first CN UE interface ID that identifies UE 102 (e.g., UE 102A), and CU-CP 172A assigns a first RAN UE interface ID that identifies UE 102 (e.g., UE 102A). In some implementations, the “CN UE interface ID” may be the “AMFUE NGAP ID” and the “RAN UE interface ID” may be the “RAN UE NGAP ID”.

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

[0109] 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 the additional common CU-to-DU DL tunnels (i.e., according to the first and / or additional DU transport layer configurations). In the event that the MBS data is associated with one or some of the MBS QoS flows identified by the MBS QoS flow identifiers, CU-UP 172B may determine which common CU-to-DU DL tunnel 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 of 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 the second one of the MBSQoS 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. In some implementations, CU-UP 172B generates tunnel packets each including a specific MBS data packet to send the MBS data packets via the first common CU-to-DU tunnel and / or the additional common CU-to-DU DL tunnel. In the case where CU-UP 172B sends one of the tunnel packets via the first common CU-to-DU tunnel, CU-UP 172B sets the source IP address, the destination IP address, and the TEID in the header of the tunnel packet to the IP address in the second CU transport layer configuration, the IP address in the first DU transport layer configuration, and the TEID in the first DU transport layer configuration, respectively. In such implementations, the IP address in the second CU transport layer configuration, the IP address in the first DU transport layer configuration, and the TEID in the first DU transport layer configuration identify the first common CU-to-DU DL tunnel. In the case where CU-UP 172B sends one of the tunnel packets via the additional common CU-to-DU tunnel, CU-UP 172B sets the source IP address, the destination IP address, and the TEID in the header of the tunnel packet to the IP address in the second CU transport layer configuration, the IP address in the additional DU transport layer configuration, and the TEID in the additional DU transport layer configuration, respectively. In such an implementation, the IP address in the second CU transport layer configuration, the IP address in the additional DU transport layer configuration, and the TEID in the additional DU transport layer configuration identify the first common CU-to-DU DL tunnel.

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

[0111] In some implementations, CU-CP 172A may request DU 174 to configure a UE-specific CU to DU DL tunnel for UE 102 in a UE context request message of event 522. In some implementations, CU-CP 172A may include a CU transport layer configuration in the UE context request message to request configuration of a UE-specific CU to DU DL tunnel for UE 102. The CU transport layer configuration includes a CU transport layer address (e.g., an IP address) for identifying a UE-specific CU to DU DL tunnel. In addition, the CU transport layer configuration may include a TEID at CU-UP 172B / TEID of CU-UP 172B. In response, DU 174 may include a DU transport layer configuration for configuring a UE-specific CU to DU DL tunnel in a UE context response message. The DU transport layer configuration includes a DU transport layer address (e.g., an IP address and / or TEID). After receiving 524 the UE context response message, CU-CP 172A may send 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. Thereafter, CU-UP 172B may send 534 MBS data to DU 174 via a UE-specific CU to DU DL tunnel.

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

[0113] In some implementations, the CU-CP 172A may configure the MRB as a DL-only RB in the MRB configuration. For example, the CU-CP 172A may avoid including the UL configuration parameters in the PDCP configuration within the MRB configuration to configure the MRB as a DL-only RB. The CU-CP 172A may include only the DL configuration parameters in the MRB configuration, for example, as described above. In such cases, the CU-CP 172A configures the UE 102 to not send UL PDCP data PDUs to the DU 174 and / or the CU-CP 172A via the MRB by excluding the UL configuration parameters for the MRB in the PDCP configuration in the MRB configuration. In another example, the DU 174 avoids including the UL configuration parameters in the RLC bearer configuration. In such cases, the DU 174 configures the UE 102 to not send control PDUs to the base station 104 via a logical channel by excluding the UL configuration parameters from the RLC bearer configuration.

[0114] In the case where DU 174 includes the UL configuration parameters in the RLC bearer configuration, UE 102 may send 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. If the control PDU is a PDCP control PDU, DU 174 may send the PDCP control PDU to CU-UP 172B. For example, CU-CP 172A may configure the UE to receive MBS data using a (de)compression protocol (e.g., a Robust Header Compression (ROHC) protocol). In this case, when CU-UP 172B receives 532 an MBS data packet from CN 110, CU-UP 172B compresses the MBS data packet using a compression protocol to obtain a compressed MBS data packet, and sends 534 a PDCP PDU including the compressed MBS data packet to DU 174 via a first or additional common CU to DU DL tunnel. In turn, DU 174 sends (e.g., multicast or unicast) 536 PDCP PDUs to UE 102 via the logical channel. When UE 102 receives the PDCP PDUs via the logical channel, UE 102 retrieves compressed MBS data packets from the PDCP PDUs. UE 102 decompresses the compressed MBS data packets using a (de)compression protocol to obtain the original MBS data packets. In such cases, UE 102 may send 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. 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 a UE 102 (e.g., UE 102A). In some implementations, the CU-CP 172A may include a CU transport layer configuration that configures a UE-specific UL tunnel in a UE context request message. The CU transport layer configuration includes a CU transport layer address (e.g., an Internet Protocol (IP) address) and a TEID for identifying a UE-specific UL tunnel. The DU 174 may include a DU transport layer configuration that configures 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, the IP address in the DU transport layer configuration and the IP address and TEID in the CU transport layer configuration identify a first common UL tunnel.

[0115] 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, when the CU-CP 172A has configured the DRB to the UE 102 for unicast data communication, the CU-CP 172A may set one or more of the MRB IDs to a value different from the DRB ID of the DRB. In 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 may set one or more of the MRB IDs to a value that may be the same as the DRB ID. In 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 UE 102 receives the DRB-ToAddMod IE for configuring the RB, UE 102 can determine that the RB is a DRB, and if UE 102 receives the MRB-ToAddMod IE for configuring the RB, it is determined that the RB is an MRB. Similarly, if CU-CP 172A sends the DRB-ToAddMod IE for configuring the RB to UE 102, CU-CP 172A can determine that the RB is a DRB, and if CU-CP 172A sends the MRB-ToAddMod IE for configuring the RB to UE 102, it is determined that the RB is an MRB.

[0116] 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 (LCs). In some implementations, the logical channel may be a dedicated traffic channel (DTCH). In other implementations, the logical channel may be a multicast traffic channel (MTCH).

[0117] In some implementations, the configuration parameters may include dynamically scheduled multicast configuration parameters to enable UE 102 to receive multicast transmissions, each of which includes MBS data or a specific portion of MBS data. In some implementations, the dynamically scheduled multicast configuration parameters may include at least one of the following configuration parameters:

[0118] ● Group Radio Network Temporary Identifier (G-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 sending the DCI and the scrambled CRC on the PDCCH. The MAC PDU may include 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 validates the scrambled CRC with the G-RNTI. For each multicast transmission, after UE 102 validates that the (scrambled) CRC is valid, UE 102 receives the multicast transmission according to the corresponding DCI and retrieves a specific MAC PDU from the multicast transmission. In this case, each multicast transmission is a dynamically scheduled multicast transmission used in the following description. In some implementations, each DCI includes configuration parameters that configure 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 value and / or different values ​​of the following configuration parameters.

[0119] ○ Frequency domain resource assignment

[0120] ○ Time domain resource assignment

[0121] ○ Virtual Resource Block (VRB) to Physical Resource Block (PRB) mapping

[0122] ○ Modulation and Coding Scheme (MCS)

[0123] ○ New Data Indicator

[0124] ○ Redundant version

[0125] ○ HARQ process number

[0126] ○ Downlink Assignment Index

[0127] ○ PUCCH resource indicator

[0128] ● HARQ codebook (ID) indicating a HARQ acknowledgement (ACK) codebook index of a corresponding HARQ ACK codebook for a dynamically scheduled multicast transmission received by UE 102. DU 174 uses the HARQ codebook (ID) to receive the HARQ ACK. In the event that the configuration parameters do not include the HARQ codebook (ID), UE 102 and DU 174 may use the HARQ codebook (ID) for unicast transmission. In some implementations, UE 102 may receive 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 may receive the HARQ codebook (ID) for unicast transmission in another DU configuration from DU 174.

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

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

[0131] ● A HARQ ACK / NACK indication, which configures the UE 102 to send a HARQ NACK for a dynamically scheduled multicast transmission in which the UE 102 failed to obtain a transport block, and configures the UE 102 to send a HARQ ACK for a dynamically scheduled multicast transmission that the UE 102 successfully received and from which the UE 102 obtained a transport block. In the event that the configuration parameters do not include this indication, the UE 102 refrains from sending a HARQ ACK to the DU 174 for a dynamically scheduled multicast transmission that the UE 102 successfully received and from which the UE 102 obtained a transport block. In such a case, the UE 102 is only allowed to send a HARQ NACK to the DU 174 for a dynamically scheduled multicast transmission in which the UE 102 failed to obtain a transport block.

[0132] ● A HARQ ACK indication, which configures the UE 102 to send a HARQ ACK for a dynamically scheduled multicast transmission that the UE 102 successfully received and from which the UE 102 obtained a transport block. In the event that the configuration parameters do not include this indication, the UE 102 refrains from sending a HARQ ACK to the DU 174 for a dynamically scheduled multicast transmission in which the UE 102 successfully obtained a transport block. In such a case, the UE 102 is only allowed to send a HARQ NACK to the DU 174 for a dynamically scheduled multicast transmission in which the UE 102 failed to obtain a transport block. In some implementations, the DU 174 may include any of a HARQ NACK indication, a HARQ ACK / NACK indication, and a HARQ ACK indication.

[0133] ● A modulation and coding scheme (MCS) configuration that indicates an MCS table used by the DU 174 to send dynamically scheduled multicast transmissions and by the UE 102 to receive dynamically scheduled multicast transmissions. For example, the MCS table can be an MCS table defined in 3GPP specification 38.214 (e.g., a low SE 64QAM table indicated in Table 5.1.3.1-3 of 3GPP TS 38.214, or a new table specific to multicast transmissions). In some implementations, if the DU 174 does not include the MCS configuration in the DU configuration, the UE 102 and the DU 174 can apply an MCS table predefined in the 3GPP specification 38.214. For example, the predefined MCS table can be, for example, a 256QAM table or a 64QAM table indicated in Table 5.1.3.1-2 of specification 38.214, respectively, or a non-low SE 64QAM table indicated in Table 5.1.3.1-1. In the case where DU 174 does not include the MCS configuration in the DU configuration, UE 102 and DU 174 may apply the MCS table for unicast transmission to receive dynamically scheduled multicast transmission from DU 174. In some implementations, DU 174 may include a PDSCH configuration (e.g., PDSCH-Config) that configures the MCS table for unicast transmission in the DU configuration. In other implementations, similar to events 516, 518, and 520, DU 174 may send another DU configuration including the PDSCH configuration to UE 102.

[0134] ● An aggregation factor, which is the number of repetitions for the dynamically scheduled multicast transmission. DU 174 may send (i.e., multicast) multiple repetitions of the dynamically scheduled multicast transmission according to the aggregation factor, and UE 102 may receive the repetitions based on the aggregation factor. In the event that DU 174 does not include the aggregation factor in the DU configuration, in some implementations, UE 102 may apply the aggregation factor for unicast transmissions. In some implementations, DU 174 may include the aggregation factor for unicast transmissions to UE 102 in the DU configuration. In other implementations, similar to events 516, 518, and 520, DU 174 may send another DU configuration to UE 102 that includes the aggregation factor for unicast transmissions.

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

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

[0137] ● Group configured scheduling radio network temporary identifier (G-CS-RNTI), which is used to activate or release SPS multicast radio resources. DU 174 can activate SPS multicast radio resources for UE 102 by generating an SPS multicast radio resource activation command (i.e., DCI), scrambling the CRC of the DCI with the G-CS-RNTI, and sending the DCI and the scrambled CRC on the PDCCH. After activating the SPS multicast radio resources, DU 174 periodically sends multicast transmissions on the SPS multicast radio resources according to the DCI. UE 102 receives the DCI and the scrambled CRC on the PDCCH and confirms the scrambled CRC with the G-CS-RNTI. After UE 102 confirms that (scrambled) CRC is valid, UE 102 activates SPS multicast radio resources in response to DCI (receives on SPS multicast radio resources), and periodically receives multicast transmission on SPS multicast radio resources according to SPS multicast radio resource activation command (i.e., DCI) before UE 102 deactivates SPS multicast radio resources. In this case, multicast transmission is SPS multicast transmission used in the following description. In some implementations, DU 174 can deactivate (or release) SPS multicast radio resources by generating SPS multicast radio resource deactivation command (i.e., DCI), scrambling CRC of DCI with G-CS-RNTI and sending DCI and scrambled CRC on PDCCH. UE 102 receives DCI and scrambled CRC on PDCCH and confirms scrambled CRC with G-CS-RNTI. After UE 102 verifies that the (scrambled) CRC is valid, UE 102 deactivates the SPS multicast radio resource, i.e., stops receiving on the SPS multicast radio resource. Each of the SPS multicast transmissions includes a specific MAC PDU, which may include an MBS data packet or a portion of an MBS data packet. In some implementations, the SPS multicast radio resource activation command (i.e., DCI) includes configuration parameters for configuring the SPS multicast radio resource. In some implementations, the configuration parameters may include at least one of the following parameters.

[0138] ○ Frequency domain resource assignment

[0139] ○ Time domain resource assignment

[0140] ○ Virtual Resource Block (VRB) to Physical Resource Block (PRB) mapping

[0141] ○ Modulation and Coding Scheme (MCS)

[0142] ○ New Data Indicator

[0143] ○ Redundant version

[0144] ○ HARQ process number

[0145] ○ Downlink Assignment Index

[0146] ○ PUCCH resource indicator

[0147] ● Periodicity, which indicates the periodicity of the SPS multicast radio resources.

[0148] • Number of HARQ processes, which indicates the number of HARQ processes used to transmit SPS multicast transmissions. The DU 174 uses at most this number of HARQ processes to send SPS multicast transmissions, and the UE 102 uses at most this number of HARQ processes to receive SPS multicast transmissions.

[0149] ● HARQ codebook ID, which indicates the HARQ ACK codebook index of the corresponding HARQ ACK codebook for the SPS multicast transmission or SPS multicast radio resource deactivation command received by the UE 102. In the case where the configuration parameters do not include the HARQ codebook (ID), the UE 102 may use the HARQ codebook (ID) for dynamically scheduled multicast transmission, as described above. Alternatively, the UE 102 may use the HARQ codebook (ID) for unicast transmission. In some implementations, the UE 102 may receive the HARQ codebook (ID) for unicast transmission in the DU configuration from the DU 174, as described above.

[0150] • HARQ Process ID Offset, which indicates the offset used in deriving the HARQ process ID for the DU 174 to send SPS multicast transmissions and for the UE 102 to receive SPS multicast transmissions.

[0151] ● PUCCH resource configuration for SPS multicast transmission, which indicates HARQ resources on the PUCCH where the UE 102 sends HARQ feedback (e.g., HARQ ACK and / or negative ACK (NACK)) for the SPS multicast transmission. In the event that the configuration parameters do not include PUCCH resource configuration for SPS multicast transmission, the UE 102 and DU 174 may transmit HARQ feedback using the PUCCH resource configuration for dynamically scheduled multicast transmission, as described above. Alternatively, the UE 102 may use the PUCCH resource configuration for unicast transmission. In some implementations, the UE 102 may use the PUCCH resource configuration for unicast transmission, as described above.

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

[0153] ● A HARQ ACK / NACK indication, which configures the UE 102 to send a HARQ NACK for an SPS multicast transmission in which the UE 102 failed to obtain a transport block, and configures the UE 102 to send a HARQ ACK for an SPS multicast transmission that the UE 102 successfully received and from which the UE 102 obtained a transport block. In the event that the configuration parameters do not include this indication, the UE 102 refrains from sending a HARQ ACK to the DU 174 for an SPS multicast transmission in which the UE 102 successfully received and obtained a transport block. In such a case, the UE 102 is only allowed to send a HARQ NACK to the DU 174 for an SPS multicast transmission in which the UE 102 failed to obtain a transport block.

[0154] ● A HARQ ACK indication, which configures the UE 102 to send a HARQ ACK for SPS multicast transmissions that the UE 102 successfully received and from which the UE 102 obtained a transport block. In the event that the configuration parameters do not include this indication, the UE 102 refrains from sending a HARQ ACK to the DU 174 for SPS multicast transmissions in which the UE 102 successfully obtained a transport block. In such a case, the UE 102 is only allowed to send a HARQ NACK to the DU 174 for SPS multicast transmissions in which the UE 102 failed to obtain a transport block. In some implementations, the DU 174 may include any of a HARQ NACK indication, a HARQ ACK / NACK indication, and a HARQ ACK indication.

[0155] ● An aggregation factor, which is the number of repetitions of the SPS multicast transmission. DU 174 may send (i.e., multicast) multiple repetitions of the SPS multicast transmission according to the aggregation factor, and UE 102 may receive the repetitions based on the aggregation factor. In the event that DU 174 does not include the aggregation factor in the DU configuration, in some implementations, UE 102 and DU 174 may apply an aggregation factor for dynamically scheduled multicast transmissions, as described above. Alternatively, UE 102 and DU 174 may apply an aggregation factor for unicast transmissions. In some implementations, UE 102 and DU 174 may apply an aggregation factor for unicast transmissions, as described above.

[0156] ● MCS configuration, which indicates the MCS table used by DU 174 to send SPS multicast transmissions and UE 102 to receive SPS 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 DU 174 does not include the MCS configuration in the DU configuration, UE 102 and DU 174 can apply the MCS table predefined in 3GPP specification 38.214. For example, the predefined MCS table can be, for example, a 256QAM table or a 64QAM table indicated in Table 5.1.3.1-2 of specification 38.214, respectively, or a non-low SE 64QAM table indicated in Table 5.1.3.1-1. In the case where DU 174 does not include the MCS configuration in the DU configuration, in other implementations, UE 102 and DU 174 may apply the MCS table for dynamically scheduled multicast transmission to receive SPS multicast transmission from DU 174, as described above. Alternatively, UE 102 and DU 174 may apply the MCS table for unicast transmission to receive SPS multicast transmission from DU 174. In some implementations, UE 102 and DU 174 may apply the MCS table for unicast transmission to receive SPS multicast transmission from DU 174, as described above. In some implementations, DU 174 may include a PDSCH configuration (e.g., PDSCH-Config) of the MCS table configured for unicast transmission in the DU configuration. In other implementations, similar to events 516, 518, and 520, DU 174 may send another DU configuration including the PDSCH configuration to UE 102.

[0157] In some implementations, the CU-CP 172A may include 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 may send 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. The CU-CP 172A may include the MBS session join completion message in a second BS to CN message. Alternatively, the CU-CP 172A may send a BS to CN message (e.g., an uplink NAS transport message) including the MBS session join completion message to the CN 110.

[0158] In other implementations, the CU-CP 172A sends a DL RRC message including an MBS session join response message to the UE 102. The DL RRC message may be a DL information transfer message, another RRC reconfiguration message, or any suitable RRC message that may include a DL NASPDU. The UE 102 may send 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.

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

[0160] In the event that CU-CP 172A does not receive slice information from CN 110, CU-CP 172A may include the preconfigured slice information in the first CP to UP message of event 560. In the event that CU-CP 172A does not receive slice information from CN 110, CU-CP 172A may include the preconfigured slice information in the first CU to DU message of event 506.

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

[0162] In some implementations, the CU-CP 172A may be pre-configured with a pre-configured MBS QoS flow configuration before receiving the first CN to BS message. In other implementations, the CU-CP 172A may receive 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.

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

[0164] Figure 5C Shown with FIG. 5A to FIG. 5B Example scenario 500C is similar to scenarios 500A to 500B shown respectively. In scenario 500C, CN 110 includes the first MBS QoS flow configuration in the second CN to BS message of event 514. In this case, CN 110 may 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 CU 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 establishment process and the multicast context establishment process) until the first MBS QoS flow configuration or the second CN to BS message is received.

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

[0166] In some implementations, CN 110 includes the first slice information in the second CN to BS message at event 514. In such a case, CN 110 may 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 such a case, CN 110 may not include the first MBS area information in the first CN to BS message.

[0167] Figure 5D Shown with FIG. 5A to FIG. 5CExample scenario 500D similar to scenarios 500A to 500C shown respectively. In scenario 500D, CN 110 sends 505 a fourth CN to BS message (e.g., a multicast session update request message) to CU-CP 172A after sending 503 the first CN to BS message, which includes the first MBS session ID and the first MBS QoS flow configuration. After receiving the fourth CN to BS message, CU-CP 172A sends 560 the first CU 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 establishment procedure and the multicast context establishment procedure) until the first MBS QoS flow configuration or the fourth CN to BS message is received. CU-CP 172A may send 519 a fourth BS to CN message (e.g., a multicast session update response message) to CN 110 in response to the fourth CN to BS message.

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

[0169] In some implementations, CN 110 includes the first slice information in a fourth CN to BS message at event 505. In such a case, CN 110 may 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 such a case, CN 110 may not include the first MBS area information in the first CN to BS message.

[0170] Figure 5E Shown with FIG. 5A to FIG. 5BExample scenario 500E is similar to scenarios 500A to 500B, respectively. In scenario 500E, CN 110 includes the first MBS QoS flow configuration in a third CN-to-BS message at event 520, and CN 110, CU-CP 172A, CU-CP 172B, and DU 174 then 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 Figure 5A described.

[0171] In some implementations, CN 110 includes the first slice information in the third CN to BS message at event 520. In such a case, CN 110 may 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 third CN to BS message at event 520. In such a case, CN 110 may not include the first MBS area information in the first CN to BS message.

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

[0173] first, Figure 6 6 is a flow chart of an example method 600 for multicast session establishment, which may be implemented in CN 110 or another suitable CN. At block 602, the CN determines that it should request a RAN node (such as base station 104) to configure or activate MBS resources for an MBS session. Next, at block 604, the CN sends a multicast activation request message to the base station (e.g., event 504). The message includes one or more MBS QoS flow configurations. The flow then proceeds to optional block 610, where the CN receives a distribution establishment request from the base station (e.g., event 512). At optional block 612, the CN sends a distribution establishment response to the base station (e.g., event 514). Next, at block 614, the CN receives a multicast session activation response (e.g., event 518) in response to the multicast session activation request sent to the base station at block 604.

[0174] Figure 77 is a flow chart of an example method 700 for multicast session establishment similar to method 600, but involving update requests rather than activation requests. At block 702, the CN initiates a request to configure or activate MBS resources for an MBS session at a RAN node (such as base station 104). At block 704, the CN sends a multicast session activation request to the base station in response to the initiation (e.g., event 504). The request may include an MBS session identifier. At block 706, the CN receives a multicast session activation response from the base station (e.g., event 518), and at block 708, the CN sends a multicast session update request message to the base station (e.g., event 505). The multicast session update request message includes one or more MBS QoS flow configurations. Similar to method 600 discussed above, the CN optionally performs blocks 710 and 712, which are similar to blocks 610 and 612, respectively. Finally, at block 714, the CN receives a multicast session update response (e.g., event 519) in response to the multicast session update request sent to the base station at block 708.

[0175] Fig. 8A 8 is a flow chart of an example method 800A for establishing a context for a multicast MBS session, wherein the MBS QoS flow configuration arrives in a multicast session activation request message, which can be implemented in CU 172 or another suitable RAN node. At block 802, the CU receives a multicast session activation request message including one or more MBS QoS flow configurations from a CN to request configuration or activation of MBS resources for an MBS session (e.g., event 504). At block 804, the CU generates a multicast context establishment request message including the MBS QoS flow configuration. The CU includes an MBS QoS flow configuration generated based on or identical to the MBS QoS flow configuration received from the CN. At block 806, the CU sends a multicast context establishment request message to a DU (such as DU 174) to establish a multicast context for the MBS session (e.g., event 506). Next, at block 808, the CU receives a multicast context establishment response message in response to the multicast context establishment request message sent at block 806 (e.g., event 508). Finally, at block 810, the CU sends a multicast session activation response message to the CN in response to the multicast session activation request message received at block 802 (eg, event 518).

[0176] Figure 8B800A, but in which the CU retrieves the QoS flow configuration from local memory. At box 801, the CU receives a multicast session activation request message to request configuration or activation of MBS resources for an MBS session (e.g., 503). Unlike the multicast session activation request message of method 800A, the message here does not include one or more MBS QoS flow configurations. Instead, at box 805, the CU retrieves one or more MBS QoS flow configurations from local memory, i.e., the CU uses pre-configured or pre-stored MBS QoS flow configurations. The CU then generates a multicast context establishment request message including one or more MBS QoS flow configurations. The CU then performs boxes 806, 808, and 810 discussed above.

[0177] Figure 8C 800A, but in which the CU receives a distribution setup response with an MBS QoS flow configuration before establishing a multicast context with the DU. At block 801, the CU receives a multicast session activation request message from the CN, requesting the CU to configure or activate MBS resources for an MBS session (e.g., event 503). At block 812, and after receiving the multicast session activation request message, the CU sends a distribution setup request message to the CN (e.g., event 512), and receives a distribution setup response message at block 814 (e.g., event 514). The CU then performs blocks 804, 806, 808, and 810 discussed above.

[0178] refer to Fig.8D , example method 800D is generally similar to method 800A, but here one or more MBS QoS flow configurations arrive from the CN in a multicast session update request message. At box 801, the CU receives a multicast session activation request message to request configuration or activation of MBS resources for an MBS session (e.g., event 503). At box 803, the CU receives a multicast session update request message for the MBS session from the CN (e.g., event 505). The message includes one or more MBS QoS flow configurations. The CU then performs boxes 804, 806, 808, and 810 discussed above. At box 811, the CU sends a multicast session update response message to the CN in response to the message received at box 803.

[0179] Fig. 8E800A, but in which the CU receives a QoS flow configuration in a message associated with a specific UE (e.g., event 520). At block 821, the CU receives a CN-to-CU message from the CN that is associated with a specific UE (rather than a group of UEs) and is related to the UE joining the MBS session. The message includes one or more MBS QoS flow configurations. The CU then performs blocks 801, 804, 806, 808, and 810 discussed above.

[0180] Fig. 9A 900A is a flow chart of an example method 900A for establishing a context for a multicast MBS session, in which a CU (e.g., CU 172 or CU-CP 172A) determines whether to rely on pre-stored MBS QoS flow configurations based on whether a CN (e.g., CN 110) has provided the MBS QoS flow configurations in a message transmitted to the CU. At block 902, the CU initiates a request to a DU to establish a multicast context for the MBS session. At block 904, the CU determines whether the CU has received an MBS QoS flow configuration from the CN. If the CU has received an MBS QoS flow configuration from the CN, the process proceeds to block 906, in which the CU includes the received one or more MBS QoS flow configurations in a CU-to-DU message (e.g., IE) using mandatory information elements (IEs). Figure 5A , Figure 5C , Figure 5D and Figure 5E Otherwise, flow proceeds from block 904 to block 908, where the CU includes the pre-configured or pre-stored MBS QoS flow configuration in the CU-to-DU message (e.g., Figure 5B Then, at block 910, the CU sends a CU-to-DU message to the DU.

[0181] at last, Fig. 9B An example method 900B is shown, according to which the CU determines whether to exclude mandatory information elements (IEs) from the CU-to-DU message based on whether the CN has provided the MBS QoS flow configuration in the message transmitted to the CU. After performing blocks 902 and 904 discussed above, the CU similarly proceeds to block 906 to include the received one or more MBS QoS flow configurations in the CU-to-DU message. However, if the CU determines at block 904 that no MBS QoS flow configuration has arrived from the CN, the process proceeds to block 909, where the CU omits the IEs for conveying the MBS QoS flow configuration from the CU-to-DU message. In some implementations, these IEs are defined as mandatory elements of the CU-to-DU message. The process then proceeds to block 910, where the CU sends the CU-to-DU message to the DU.

[0182] Generally referring to the methods discussed above, these techniques are similarly applied to network slice information. For example, instead of or in addition to one or more QoS MBS flow configurations, a message such as 503, 504 or 560 may also include network slice information.

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

[0184] 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".

[0185] The user device (e.g., UE 102A, 102B, or UE 103) in which the technology of the present disclosure can be implemented can be any suitable device capable of wireless communication, such as a smart phone, a tablet computer, a laptop computer, a mobile game console, a point of sale (POS) terminal, a health monitoring device, a drone, a camera, a media streaming dongle or another personal media device, a wearable device (such as a smart watch), a wireless hotspot, a femtocell, or a broadband router. In addition, in some cases, the user device can be embedded in an electronic system, such as a head unit or an advanced driver assistance system (ADAS) of a vehicle. In addition, 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.

[0186] 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., a 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 certain 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.

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

[0188] After reading this disclosure, those skilled in the art will appreciate additional alternative structural and functional designs for performing HARQ processes to send MBS data through the principles disclosed herein. Therefore, although specific embodiments and applications have been shown and described, it should be understood that the disclosed embodiments are not limited to the precise 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.

[0189] The following additional examples are expressly contemplated by this disclosure.

[0190] Example 1. A method for multicast session establishment in a central unit (CU) of a distributed base station, the method comprising: obtaining, by one or more processors, network slice information at a first time during a process for establishing a context for the multicast session; and sending, by the one or more processors, the network slice information to a distributed unit (DU) of the distributed base station at a second time after the first time during the process for establishing a context for the multicast session.

[0191] Example 2. A method as described in Example 1, wherein obtaining the network slice information includes: receiving a multicast session activation request including the network slice information from a core network (CN).

[0192] Example 3. A method as described in Example 1, wherein obtaining the network slice information includes: retrieving the network slice information from the memory of the CU.

[0193] Example 4. A method as described in Example 3, wherein retrieving the network slice information from the memory includes: using a mapping between an MBS session identifier and the network slice information.

[0194] Example 5. A method as described in Example 3, wherein retrieving the network slice information from the memory of the CU is in response to the one or more processors determining that the CU has not received the network slice information from the CN.

[0195] Example 6. A method as described in Example 1, wherein receiving the network slice information includes: receiving a distribution establishment response including the network slice information from the CN.

[0196] Example 7. A method as described in Example 6, wherein: the distribution establishment response including the network slice information is received before the CU requests the DU to establish a multicast context.

[0197] Example 8. The method as described in Example 6 or 7 further includes: receiving a multicast session activation request from the CN; and in response to receiving the multicast session activation request, sending a distribution establishment request to the CN; wherein the distribution establishment response is in response to the distribution establishment request.

[0198] Example 9. A method as described in Example 1, wherein obtaining the network slice information includes: receiving a multicast session update request including the network slice information from a core network (CN).

[0199] Example 10. A method as described in Example 1, wherein obtaining the network slice information includes: receiving a message associated with a UE configured to participate in the multicast session from the CN, the message including the network slice information.

[0200] Example 11. A method as described in any of the preceding examples, wherein obtaining the network slice information comprises: obtaining the network slice information at a CU control plane (CU-CP); and sending the network slice information from the CU-CP to a CU user plane (CU-UP).

[0201] Example 12. A method as described in Example 11, wherein sending the network slice information from the CU-CP to the CU-UP includes sending a bearer context establishment request including the network slice information.

[0202] Example 13. A method as described in any of the preceding examples, wherein sending the network slice information to the DU comprises: sending a multicast context establishment request message including the network slice information.

[0203] Example 14. A method as described in any of the preceding examples, wherein sending the network slice information to the DU comprises: sending the network slice information in a mandatory field of a CU to DU message.

[0204] Example 15. A central unit (CU) of a distributed base station, the CU comprising one or more processors and configured to implement the method according to any one of the preceding examples.

[0205] Example 16. A method for establishing a multicast session in a core network (CN), the method comprising: sending, by one or more processors, a multicast session activation or update request including network slice information to a base station; and receiving, by the one or more processors, a response to the multicast session activation or update request from the base station.

[0206] Example 17. The method of Example 16, wherein the sending comprises: sending the multicast session activation request.

[0207] Example 18. The method of Example 16, wherein the sending comprises: sending the multicast session update request.

[0208] Example 19. The method as described in any one of Examples 16 to 18 also includes: receiving a distribution establishment request message from the base station; and sending a distribution establishment response message to the base station.

[0209] Example 20. A core network comprising one or more computing devices and configured to implement the method according to any one of Examples 16 to 19.

[0210] Example 21. A method for multicast session establishment in a central unit (CU) of a distributed base station, the method comprising: obtaining, by one or more processors, one or more multicast and broadcast service (MBS) quality of service (QoS) flow configurations at a first time during a process for establishing a context for a multicast session; and sending, by the one or more processors, the one or more MBS QoS flow configurations to a distributed unit (DU) of the distributed base station at a second time after the first time during the process for establishing a context for the multicast session.

[0211] Example 22. The method of Example 21, wherein obtaining the one or more MBS QoS flow configurations comprises: receiving a multicast session activation request including the one or more MBS QoS flow configurations from a core network (CN).

[0212] Example 23. The method of Example 21, wherein obtaining the one or more MBS QoS flow configurations comprises retrieving the one or more MBS QoS flow configurations from a memory of the CU.

[0213] Example 24. The method of Example 23, wherein retrieving the one or more MBS QoS flow configurations from the memory comprises using a mapping between an MBS session identifier and the one or more MBS QoS flow configurations.

[0214] Example 25. The method of Example 23, wherein retrieving the one or more MBS QoS flow configurations from the memory of the CU is in response to determining, by the one or more processors, that the CU has not received the one or more MBS QoS flow configurations from the CN.

[0215] Example 26. The method of Example 21, wherein receiving the one or more MBS QoS flow configurations comprises: receiving a distribution setup response including the one or more MBS QoS flow configurations from the CN.

[0216] Example 27. The method of Example 26, wherein: the distribution setup response including the one or more MBS QoS flow configurations is received before the CU requests the DU to establish a multicast context.

[0217] Example 28. The method as described in Example 26 or 27 further includes: receiving a multicast session activation request from the CN; and in response to receiving the multicast session activation request, sending a distribution establishment request to the CN; wherein the distribution establishment response is in response to the distribution establishment request.

[0218] Example 29. The method of Example 21, wherein obtaining the one or more MBS QoS flow configurations comprises: receiving a multicast session update request including the one or more MBS QoS flow configurations from a core network (CN).

[0219] Example 30. The method of Example 21, wherein obtaining the one or more MBS QoS flow configurations comprises: receiving a message associated with a UE configured to participate in the multicast session from the CN, the message including the one or more MBS QoS flow configurations.

[0220] Example 31. A method as described in any of the preceding examples, wherein obtaining the one or more MBS QoS flow configurations comprises: obtaining the one or more MBS QoS flow configurations at a CU control plane (CU-CP); and sending the one or more MBS QoS flow configurations from the CU-CP to a CU user plane (CU-UP).

[0221] Example 32. The method of Example 31, wherein sending the one or more MBS QoS flow configurations from the CU-CP to the CU-UP comprises sending a bearer context establishment request including the one or more MBS QoS flow configurations.

[0222] Example 33. A method as described in any of the preceding examples, wherein sending the one or more MBS QoS flow configurations to the DU includes: sending a multicast context establishment request message including the one or more MBS QoS flow configurations.

[0223] Example 34. A method as described in any of the preceding examples, wherein sending the one or more MBS QoS flow configurations to the DU includes: sending the one or more MBS QoS flow configurations in a mandatory field of a CU to DU message.

[0224] Example 35. A central unit (CU) of a distributed base station, the CU comprising one or more processors and configured to implement a method according to any one of the preceding examples.

[0225] Example 36. A method for multicast session establishment in a core network (CN), the method comprising: sending, by one or more processors, a multicast session activation or update request including one or more multicast and broadcast service (MBS) quality of service (QoS) flow configurations to a base station; and receiving, by the one or more processors, a response to the multicast session activation or update request from the base station.

[0226] Example 37. The method of Example 36, wherein the sending comprises: sending the multicast session activation request.

[0227] Example 38. The method of Example 36, wherein the sending comprises: sending the multicast session update request.

[0228] Example 39. The method as described in any one of Examples 36 to 38 also includes: receiving a distribution establishment request message from the base station; and sending a distribution establishment response message to the base station.

[0229] Example 40. A core network comprising one or more computing devices and configured to implement a method according to any one of Examples 36 to 39.

Claims

1. A method for multicast session establishment, the method being implemented in a central unit (CU) of a distributed base station and comprising: Sending a distribution setup request message to a core network (CN); receiving a distribution setup response message including a first MBS QoS flow configuration from the CN; as well as A multicast context establishment request message is sent to a distributed unit (DU) of the distributed base station, wherein the multicast context establishment request message includes a second MBS QoS flow configuration based on the first MBS QoS flow configuration to establish a multicast context for an MBS session.

2. The method of claim 1, further comprising: In response to the multicast context setup request message, a multicast context setup response is received from the DU.

3. The method of claim 1 or 2, wherein the first MBS QoS flow configuration comprises flow level QoS parameters. The method of claim 3 , wherein the first MBS QoS flow configuration further comprises an MBS QoS flow identifier.

5. The method according to any one of the preceding claims, further comprising: receiving, prior to said sending of said distribution setup request message, a message from said CN related to configuring resources for said MBS session, wherein said sending of said distribution setup request message is in response to said message from said CN.

6. A method as claimed in any preceding claim, wherein the MBS session corresponds to a Temporary Mobile Group Identity (TMGI).

7. The method according to any one of the preceding claims, implemented in a CU control plane (CU-CP).

8. The method of any one of the preceding claims, further comprising: After said receiving of said distribution setup response message, sending a MC bearer context modification request message to a CU user plane (CU-UP).

9. The method of claim 8, wherein the MC bearer context modification request message comprises an MBS QoS flow configuration based on the first MBS QoS flow configuration.

10. A method as claimed in any preceding claim, wherein the distribution setup response message comprises an Internet Protocol (IP) source address.

11. A method as claimed in any preceding claim, wherein the distributed setup response message comprises an IP multicast address.

12. The method of any preceding claim, wherein the distribution setup response message comprises a tunnel endpoint identifier (TEID).

13. The method of any preceding claim, wherein the second MBS QoS flow configuration is the same as the first MBS QoS flow configuration.

14. The method of any preceding claim, wherein the second MBS QoS flow configuration is generated based on the first MBS QoS flow configuration.

15. A Central Unit (CU) of a distributed base station, the CU comprising one or more processors and configured to implement the method according to any one of the preceding claims.

Images