Management of Multicast Session Establishment

Abstract

The central unit (CU) of the distributed base station transmits a distributed setup request message to the core network (CN), receives a distributed setup response message including a first MBS QoS flow configuration from the CN, and, in order to establish a multicast context for the MBS session, transmits a multicast context setup request message including a second MBS QoS flow configuration to the distributed unit (DU) of the distributed base station based on the first MBS QoS flow configuration.

Description

Technical Field

[0001] The present disclosure relates to wireless communication, and more particularly, to enabling one or more multicast and / or broadcast services (MBS).

Background Art

[0002] For the purpose of generally presenting the context of the present disclosure, the background art provided herein is described. The work of the inventors specified herein is not admitted as prior art to the present disclosure, either expressly or implicitly, to the extent described in this background art section and in aspects of the description that may not be eligible as prior art at the time of filing.

[0003] Base stations operating according to the new radio (NR) requirements of the fifth generation (5G) support significantly larger bandwidths than fourth generation (4G) base stations. Thus, the 3rd Generation Partnership Project (3GPP®) has proposed for Release 15 that user equipment units (UEs) support a 100 MHz bandwidth in frequency range 1 (FR1) and a 400 MHz bandwidth in frequency range 2 (FR2). The 5G NR system enables efficient distribution of multicast / broadcast services (MBS). In the case of a broadcast communication service, the same service and the same specific content data are provided simultaneously to all UEs within a geographical area (i.e., all UEs within the broadcast service area are given the right to receive the data). The base station distributes the broadcast communication service to the UEs using a broadcast session. The UEs can receive the broadcast communication service in the RRC_IDLE state, the RRC_INACTIVE state, and the RRC_CONNECTED state. In the case of a multicast communication service, the same service and the same specific content data are provided to a dedicated set of UEs simultaneously (i.e., not all UEs within the multicast service area are given the right to receive the data). The multicast communication service is delivered to UEs using a multicast session. 5G NR provides both point-to-point (PTP) and point-to-multipoint (PTM) delivery methods for transmitting MBS packet flows over the radio interface. In PTP communication, the RAN node transmits different copies of each MBS data packet to different UEs over the radio interface. On the other hand, in PTM communication, the RAN node transmits a single copy of each MBS data packet to multiple UEs over the radio interface according to a discontinuous reception (DRX) cycle.

[0004] 5G NR provides both point-to-point (PTP) and point-to-multipoint (PTM) delivery methods for transmitting MBS packet flows over the radio interface. In PTP communication, the RAN node transmits different copies of each MBS data packet to different UEs over the radio interface. On the other hand, in PTM communication, the RAN node transmits a single copy of each MBS data packet to multiple UEs over the radio interface. The multicast MBS session context establishment procedure is defined in 3GPP (registered trademark) specification 38.401 v17.0.0 and was recently updated according to document R3-224064. In these documents, it is required that the core network (CN) sends an NGAP message to the base station to trigger the establishment of the multicast session context, but it is unclear which NGAP message the CN should use in this case. Furthermore, none of the existing messages that the CN can send in this scenario convey sufficient information for the base station to properly configure the MBS session.

SUMMARY OF THE INVENTION

[0005] Before the CU of the base station according to the present disclosure has to configure the DU with the MBS service quality (QoS) flow configuration(s), it receives the MBS QoS flow configuration from the core network or retrieves it from memory according to a prior configuration. In this way, the CU ensures that the DU can properly configure the MBS QoS flow. In various embodiments, the CU receives this information from the CN in a multicast session activation request, a multicast session update request, or a distributed setup response received before the CU requests a multicast context setup from the DU.

[0006] An exemplary embodiment of these techniques is a method in a central unit (CU) of a distributed base station for multicast session establishment, the method including: obtaining, by one or more processors, a service quality (QoS) flow configuration of one or more multicast and broadcast services (MBS) at a first time during procedures for establishing a context for the multicast session; and transmitting, by one or more processors, one or more MBS QoS flow configurations to a distributed unit (DU) of the distributed base station at a second time following the first time during procedures for establishing a context for the multicast session.

[0007] Another exemplary embodiment of these techniques is a CU of a distributed base station, the CU including one or more processors and being configured to implement the method described above.

[0008] Still other exemplary embodiments of these techniques are methods in a core network (CN) for multicast session establishment, the method including: transmitting, by one or more processors, an activation or update request for a multicast session 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 from the base station to the activation or update request for the multicast session.

[0009] Other exemplary embodiments of these techniques include a core network including one or more computing devices and configured to implement the above method. BRIEF DESCRIPTION OF THE DRAWINGS

[0010]

Figure 1A

Figure 1B

Figure 2A

Figure 2B

Figure 3

Figure 4

Figure 5A

Figure 5B

Figure 5C

Figure 5D

Figure 5E

Figure 6

Figure 7

Figure 8A

Figure 8B

Figure 8C

Figure 8D

Figure 8E

Figure 9A

Figure 9B

[0011] FIG. 1A shows an exemplary wireless communication system 100 capable of implementing the techniques of the present disclosure 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 embodiments or scenarios, the wireless communication system 100 may include more or fewer UEs and / or more or fewer base stations than shown in FIG. 1A. The base stations 104, 106 can be any suitable one or more types of base stations, such as an evolved Node B (eNB), a next-generation eNB (ng-eNB), or a 5G Node B (gNB).

[0012] Base station 104 supports cell 124, and base station 106 supports cell 126. Since cell 124 partially overlaps with cell 126, UE 102A can be within the range of communicating with base station 104 and at the same time within the range of communicating with base station 106 (or within the range of detecting or measuring signals from base station 106). Due to the overlap, for example, before UE 102A experiences a radio link failure, UE 102A can enable handover between cells (e.g., from cell 124 to cell 126) or between base stations (e.g., from base station 104 to base station 106). Further, the overlap enables various dual connectivity (DC) scenarios. For example, UE 102A can communicate with base station 104 (operating as a master node (MN)) and base station 106 (operating as a secondary node (SN)) in DC.

[0013] In non-MBS (unicast) operation, UE102A can use radio bearers (e.g., DRB or SRB) terminated at the MN (e.g., base station 104) or SN (e.g., base station 106) at different times. For example, after handover to or SN change with base station 106, UE102A can use radio bearers (e.g., DRB or SRB) terminated at base station 106. UE102A can apply one or more security keys when communicating on the radio bearer in the uplink (from UE102A to the base station) direction and / or downlink (from the base station to UE102A) direction. In non-MBS operation, UE102A transmits data to the base station via a radio bearer on the uplink (UL) bandwidth part (BWP) of the cell (i.e., within), and / or receives data from the base station via a radio bearer on the downlink (DL) BWP of the cell. UE102A can receive paging, system information, public warning message(s), or random access response on the DL BWP.

[0014] In MBS operation, UE102A can use MBS radio bearers (MRBs) terminated at the MN (e.g., base station 104) or SN (e.g., base station 106) at different times. For example, after handover or SN change, UE102A can use an MRB terminated at base station 106 operating as the MN or SN. In some scenarios, the base station (e.g., MN or SN) can transmit MBS data to UE102A via unicast radio resources (i.e., radio resources dedicated to UE102A) via the MRB. In other scenarios, the base station (e.g., MN or SN) can transmit MBS data via the MRB via multicast radio resources (i.e., radio resources common to UE102A and one or more other UEs), or via the DL BWP of the cell from the base station to UE102A. The DL BWP can be the initial DL BWP, dedicated DL BWP, or MBS DL BWP (i.e., DL BWP specific to MBS, or not for unicast).

[0015] The base station 104 includes processing hardware 130 that may include one or more general-purpose processors (e.g., a central processing unit (CPU)), and a computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors (s), and / or a special-purpose processing unit. The processing hardware 130 in the exemplary embodiment of FIG. 1A includes an MBS controller 132 configured to manage or control the transmission of MBS information received from the CN110 or the edge server. For example, the MBS controller 132 may be configured to support other operations associated with those configurations and / or procedures, including radio resource control (RRC) configurations, procedures, and messaging, and / or HARQ processes associated with the MBS procedure, as described below. In some embodiments, the processing hardware 130 also includes a non-MBS controller 134 configured to manage or control one or more RRC configurations and / or RRC procedures when the base station 104 operates as an MN or SN during non-MBS operations.

[0016] The base station 106 includes processing hardware 140 that may include one or more general-purpose processors (e.g., a CPU) and a computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors (s), and / or a special-purpose processing unit. The processing hardware 140 in the exemplary embodiment of FIG. 1A includes an MBS controller 142 and a non-MBS controller 144 that may be similar to the controllers 132 and 134 of the base station 130, respectively. Although not shown in FIG. 1A, the RAN105 can include additional base stations having processing hardware similar to the processing hardware 130 of the base station 104 and / or the processing hardware 140 of the base station 106.

[0017] UE102A includes processing hardware 150, which in some embodiments includes one or more general-purpose processors (e.g., CPUs) and a computer-readable memory storing machine-readable instructions executable on the general-purpose processor(s), and / or a special-purpose processing unit. The processing hardware 150 in the exemplary embodiment of FIG. 1A includes an MBS controller 152 configured to manage or control the reception of MBS information. For example, the UE MBS controller 152 can be configured to support other operations associated with those configurations and / or procedures, including RRC configurations, procedures, and messaging associated with MBS procedures, and / or HARQ processes, as described below. The processing hardware 150 in further embodiments can also include a non-MBS controller 154 configured to manage or control one or more RRC configurations and / or RRC procedures according to any of the embodiments described below when the UE102A communicates with the MN and / or SN during non-MBS operations. Although not shown in FIG. 1A, in further embodiments, UE102B and 103 include processing hardware similar to the processing hardware 150 of UE102A.

[0018] In some embodiments, CN110 is an evolved packet core (EPC) 111 or a 5th generation core (5GC) 160, both of which are shown in FIG. 1A. Depending on the embodiment, the base station 104 is an eNB that supports an S1 interface for communicating with the EPC 111, an ng-eNB that supports an NG interface for communicating with the 5GC 160, or a gNB that supports an NR radio interface and an NG interface for communicating with the 5GC 160. In further embodiments, the base station 106 is an EUTRA-NR DC (EN-DC) gNB (en-gNB) having an S1 interface to the EPC 111, an en-gNB not connected to the EPC 111, a gNB that supports an NR radio interface and an NG interface to the 5GC 160, or an ng-eNB that supports an EUTRA radio interface and an NG interface to the 5GC 160. In some embodiments, the base stations 104 and 106 support an X2 interface or an Xn interface to directly exchange messages with each other during the scenarios described below.

[0019] Among other components, EPC 111 may include a Serving Gateway (SGW) 112, a Mobility Management Entity (MME) 114, and a Packet Data Network Gateway (PGW) 116. The SGW 112 is generally configured to transfer user plane packets related to, for example, voice calls, video calls, Internet traffic, etc. The MME 114 is generally 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, such as the Internet network and / or the Internet Protocol (IP) Multimedia Subsystem (IMS) network. 5GC 160 includes a User Plane Function (UPF) 162, an Access and Mobility Management (AMF) 164, and / or a Session Management Function (SMF) 166. The UPF 162 is generally configured to transfer user plane packets related to, for example, voice calls, video calls, Internet traffic, etc. The AMF 164 is generally configured to manage authentication, registration, paging, and other related functions. The SMF 166 is generally configured to manage PDU sessions.

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

[0021] Generally, in some embodiments, the wireless communication system 100 includes any suitable number of base stations that support NR cells and / or EUTRA cells. More specifically, in further embodiments, the EPC 111 or 5GC 160 connects to any suitable number of base stations that support NR cells and / or EUTRA cells. In the following examples, specific reference is made to particular CN types (EPC, 5GC) and RAT types (5G NR and EUTRA), but generally, the techniques of the present disclosure can also be applied to other suitable radio access technologies and / or core network technologies, such as, for example, 6th generation (6G) radio access and / or 6G core network or 5G NR-6G DC.

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

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

[0024] In some embodiments, the CU172 may include one or more logical nodes (CU-CP(s) 172A) that host the control plane portion of the packet data convergence protocol (PDCP) protocol of the CU172 and / or the radio resource control (RRC) protocol of the CU172. The CU172 may also include one or more logical nodes (CU-UP(s) 172B) that host the user plane portion of the PDCP protocol of the CU172 and / or the service data adaptation protocol (SDAP) protocol. As described herein, the CU-CP(s) 172A can transmit non-MBS control information and MBS control information, and the CU-UP(s) 172B can transmit non-MBS data packets and MBS data packets.

[0025] The CU-CP(s) 172A can be connected to a plurality of CU-UPs 172B via an E1 interface. The CU-CP(s) 172A selects a suitable CU-UP(s) 172B for the service requested by the UE 102A. In some embodiments, a single CU-UP 172B can be connected to a plurality of CU-CPs 172A via an E1 interface. The CU-CP 172A can be connected to one or more DUs 174 via an F1-C interface. The CU-UP 172B can be connected to one or more DUs 174 via an F1-U interface under the control of the same CU-CP 172A. In some embodiments, one DU 174 can be connected to a plurality of CU-UPs 172B under the control of the same CU-CP 172A. In such embodiments, the connection between the CU-UP 172B and the DU 174 is established by the CU-CP 172A using a bearer context management function.

[0026] FIG. 2A shows a simplified exemplary protocol stack 200, where a UE (e.g., UE102A, 102B, or 103) can communicate with an eNB / ng-eNB or gNB (e.g., one or more of base stations 104, 106) according to protocol stack 200. In the exemplary protocol stack 200, the EUTRA PHY sublayer 202A provides a transport channel to the EUTRA MAC sublayer 204A, and the EUTRA MAC sublayer 204A in turn provides a logical channel to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A similarly provides an RLC channel to the EUTRA PDCP sublayer 208 and, optionally, to the NR PDCP sublayer 210. Similarly, the NR PHY 202B provides a transport channel to the NR MAC sublayer 204B, and the NR MAC sublayer 204B in turn provides a logical channel to the NR RLC sublayer 206B. The NR RLC sublayer 206B similarly provides an RLC channel to the NR PDCP sublayer 210. In some embodiments, UE102A supports both the EUTRA and NR stacks as shown in FIG. 2A to support handover between an EUTRA base station and an NR base station and / or to support DC via the EUTRA interface and the NR interface. Further, as shown in FIG. 2A, UE102A may support layering of NR PDCP 210 on EUTRA RLC 206A and of the SDAP sublayer 212 on the NR PDCP sublayer 210. A sublayer is also simply referred to herein as a "layer".

[0027] The EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 receive packets, which may be referred to as service data units (SDUs) (e.g., directly on the PDCP layer 208 or 210 or indirectly from an IP layer layered thereon), and output packets, which may be referred to as protocol data units (PDUs) (e.g., to the RLC layer 206A or 206B). Except where the difference between the SDU and the PDU is relevant, in the present disclosure, for simplicity, both the SDU and the PDU are referred to as "packets". The packets may be MBS packets or non-MBS packets. The MBS packets may include, for example, application content for MBS services (e.g., IPv4 / IPv6 multicast delivery, IPTV, software delivery via wireless, 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 MBS services.

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

[0029] In some embodiments, the base station (e.g., base stations 104, 106) broadcasts MBS data packets via one or more MBS radio bearers (MRBs (plural)), and similarly, UE102A, 102B, or 103 receives MBS data packets via the MRBs (plural). The base station can include the configuration(s) of the MRB(s) in the multicast configuration parameters (sometimes also referred to as MBS configuration parameters) described below. In some embodiments, the base station broadcasts MBS data packets via the RLC sublayer 206, MAC sublayer 204, and PHY sublayer 202, and correspondingly, UE102A receives MBS data packets using the PHY sublayer 202, MAC sublayer 204, and RLC sublayer 206. In some such embodiments, the base station and UE102A, 102B, or 103 do not use the PDCP sublayer 208 and SDAP sublayer 212 to communicate MBS data packets. In other embodiments, the base station transmits MBS data packets via the PDCP sublayer 208, RLC sublayer 206, MAC sublayer 204, and PHY sublayer 202, and correspondingly, UE102A, 102B, or 103 receives MBS data packets using the PHY sublayer 202, MAC sublayer 204, RLC sublayer 206, and PDCP sublayer 208. In some such embodiments, the base station and UE102A, 102B, or 103 do not use the SDAP sublayer 212 to communicate MBS data packets. In still other embodiments, the base station transmits MBS data packets via the SDAP sublayer 212, PDCP sublayer 208, RLC sublayer 206, MAC sublayer 204, and PHY sublayer 202, and correspondingly, UE102A, 102B, or 103 receives MBS data packets using the PHY sublayer 202, MAC sublayer 204, RLC sublayer 206, PDCP sublayer 208, and SDAP sublayer 212.

[0030] Figure 2B schematically shows an exemplary protocol stack 250 that UE102A, 102B, or 103 may use to communicate with a DU (e.g., DU174) and a CU (e.g., CU172). The radio protocol stack 200 of Figure 2A is functionally split as shown by the radio protocol stack 250 of Figure 2B. The CU in either base station 104 or 106 can hold all control and upper layer functions (e.g., RRC214, SDAP212, NR PDCP210), while the lower layer operations (e.g., NR RLC206B, NR MAC204B, and NR PHY202B) can be delegated to the DU. To support the connection to the 5GC, NR PDCP210 provides DRBs to SDAP212 and SRBs to RRC214.

[0031] Referring to Figure 3, the MBS session 302A may include a tunnel 312A with endpoints at the CN110 and the base station 104 / 106. The MBS session 302A can correspond to a specific session ID, such as, for example, a Temporary Mobile Group Identification Information (TMGI). The MBS data can include, for example, IP packets, TCP / IP packets, UDP / IP packets, Real-Time Transport Protocol (RTP) / UDP / IP packets, or RTP / TCP / IP packets.

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

[0033] Tunnel 312A can operate over a transport layer or sublayer, such as the User Datagram Protocol (UDP) protocol layered on top of the Internet Protocol (IP). As a more specific example, Tunnel 312A can be associated with the General Packet Radio Service (GPRS) Tunneling Protocol (GTP). Tunnel 312A can correspond to, for example, a specific IP address (e.g., the IP address of base stations 104 / 106) and a specific Tunnel Endpoint Identifier (TEID) (e.g., assigned by base stations 104 / 106). More generally, Tunnel 312A can have any suitable transport layer configuration. CN110 can specify the IP address and TEID address within the header(s) of the tunnel packet(s) containing the MBS data packet and send the tunnel packet(s) downstream to base stations 104 / 106 via Tunnel 312A (i.e., the header(s) can include the IP address and / or TEID). For example, the header(s) can include an IP header and a GTP header, each including an IP address and a TEID respectively. Thus, base stations 104 / 106 can identify the data packets moving through Tunnel 312A using the IP address and / or TEID.

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

[0035] MBS traffic can include one or more quality of service (QoS) flows for each of tunnels 312A, 312B, etc. For example, the MBS traffic on tunnel 312B can include a set of flows 316 that include QoS flows 316A, 316B, ... 316L. Further, the logical channels of the MRBs can support a single QoS flow or multiple QoS flows. In the exemplary configuration of FIG. 3, the base stations 104 / 106 map QoS flows 316A and 316B to the MTCH of MRB 314B-1 and map QoS flow 316L to the MTCH of MRB 314B-N.

[0036] In various scenarios, CN110 can allocate different types of MBS traffic to different QoS flows. For example, a flow with a relatively high QoS value can correspond to audio packets, and a flow with a relatively low QoS value can correspond to video packets. As another example, a flow with a relatively high QoS value can correspond to I-frames or full images used in video compression, and a flow with a relatively low QoS value can correspond to predicted pictures that only contain changes to P-frames or I-frames.

[0037] Continuing to refer to FIG. 3, the base stations 104 / 106 and CN110 can maintain one or more PDU sessions to support unicast traffic between CN110 and a particular UE. The PDU session 304A can include a UE-specific DL tunnel and / or a UE-specific UL tunnel 322A corresponding to one or more DRBs 324A, such as DRB324A-1, 324A-2,... 324A-N. Each DRB 324A can correspond to a respective logical channel, such as a dedicated traffic channel (DTCH).

[0038] Referring now to FIG. 4, when the base stations 104 / 106 are implemented in a distributed manner, the CU 172 and the DUs 174A / 174B can establish tunnels for downlink data and / or uplink data associated with the MRB or DRB. The MRB 314A-1 described above can be implemented as an MRB 402A that connects the CU 172 to a plurality of UEs such as the UEs 102A and 102B. The MRB 402A can include a DL tunnel 412A that connects the CU 172 and the DUs 174A / 174B, and a DL logical channel 422A corresponding to the DL tunnel 412A. In particular, the DUs 174A / 174B can map the downlink traffic received via the DL tunnel 412A to a DL logical channel 422A that can be, for example, an MTCH or a DTCH. The DL tunnel 412A can be a common DL tunnel, and the CU 172 can transmit MBS data packets to a plurality of UEs via the common DL tunnel. Alternatively, the DL tunnel 412A can be a UE-specific DL tunnel, and the CU 172 can transmit MBS data packets to a specific UE via the UE-specific DL tunnel.

[0039] The MRB 402A may also include a UL tunnel 413A that connects the CU 172 and the DUs 174A / 174B, and a UL logical channel 423A corresponding to the UL tunnel 413A. The UL logical channel 423A can be, for example, a DTCH. The DUs 174A / 174B can map the uplink traffic received via the UL logical channel 423A to the UL tunnel 413A.

[0040] Tunnels 412A and 413A can operate in the transport layer or sublayer of the F1-U interface. As a more specific example, CU172 and DU174A / 174B can utilize F1-U for user plane traffic, and tunnels 412A and 413A can be associated with the GTP-U protocol layered on UDP / IP, where IP is layered on the appropriate data link layer and physical (PHY) layer. Further, MRB(s) 402 and / or DRB(s) 404 can additionally support control plane traffic in at least some cases. More specifically, CU172 and DU174A / 174B can exchange F1-AP messages via an F1-C interface that depends on the Stream Control Transmission Protocol (SCTP) layered on IP, where IP is layered on the appropriate data link layer and PHY layer as in the case of F1-U.

[0041] Similarly, MRB 402B can include a DL tunnel 412B and may include a UL tunnel 413B. The DL tunnel 412B can correspond to the DL logical channel 422B, and the UL tunnel 413B can correspond to the UL logical channel 423B.

[0042] In some cases, CU172 uses DRB404A to send MBS data packets or unicast data packets associated with a PDU session to a specific UE (e.g., UE102A or UE102B). DRB404A can include a UE-specific DL tunnel 432A that connects CU172 and DU174A / 174B, and a DL logical channel 442A corresponding to DL tunnel 432A. In particular, DU174A / 174B can map the downlink traffic received via DL tunnel 432A to a DL logical channel 442A, which can be, for example, a DTCH. DRB404A further includes a UE-specific UL tunnel 433A that connects CU172 and DU174A / 174B, and a UL logical channel 443A corresponding to UL tunnel 433A. The UL logical channel 443A can be, for example, a PUSCH. DU174A / 174B can map the uplink traffic received via UL logical channel 443A to UL tunnel 433A.

[0043] Similarly, DRB404B can include a UE-specific DL tunnel 432B corresponding to DL logical channel 442B, and a UE-specific UL tunnel 433B corresponding to UL logical channel 443B.

[0044] Next, several scenarios in which the distributed base station facilitates the establishment of a multicast session and provides MBS QoS flow configuration(s) from the CU to the DU before setting up the multicast context in the DU will be described with reference to FIGS. 5A to 5E. The scenarios of FIGS. 5A to 5E include MBS QoS flow configuration(s), but the technology implemented by the network device can also be applied to network slices, as described below.

[0045] Referring initially to FIG. 5A, in an exemplary scenario 500A for establishing an MBS session, the base station 104 includes a DU 174, a CU-CP 172A, and a CU-UP 172B. Scenario 500A is also applicable to an integrated CU where the CP and UP functional nodes are not logically separated.

[0046] The UE 102 (e.g., UE 102A of FIG. 1A) first executes a procedure 502 for participating in an MBS session at the CN 110 via the base station 104 to participate in a first MBS session. In some embodiments, the procedure for participating in an MBS session may not involve the CU-CP 172B. In some scenarios, the UE 102 then executes one or more additional MBS participation procedures, and thus, event 502 is the first one of the plurality of MBS participation procedures. Since the base station 104 constructs a common DL tunnel for MBS traffic (rather than a UE-specific tunnel described later), procedures 502 and 592A can occur in either order. In other words, the base station 104 can construct a common DL tunnel even for a single UE before the UE participates in the first MBS session.

[0047] To execute the procedure for participating in an MBS session, in some embodiments, the UE 102 sends an MBS session participation request message to the CN 110 via the base station 104. In response, the CN 110 can send an MBS session participation response message to the UE 102 via the base station 104 to permit the UE 102 to access the first MBS session. In some embodiments, the UE 102 can include a first MBS session ID (e.g., MBS session ID1) of the first MBS session in the MBS session participation request message. The CN 110 may include the first MBS session ID in the MBS session participation response message in some cases. In some embodiments, the UE 102 can send an MBS session participation completion message to the CN 110 via the base station 104 in response to the MBS session participation response message.

[0048] In some embodiments, the MBS session participation request message, the MBS session participation response message, and the MBS session participation completion message can be Session Initiation Protocol (SIP) messages. In other embodiments, the MBS session participation request message, the MBS session participation response message, and the MBS session participation completion message can be NAS messages such as 5G Mobility Management (5GMM) messages or 5G Session Management messages (5GSM). In the case of 5GSM messages, UE102 can send a (first) UL container message including the MBS session participation request message to CN110 via base station 104, CN110 can send a DL container message including the MBS session participation response message to UE102 via base station 104, and UE102 can send a (second) UL container message including the MBS session participation completion message to CN110 via base station 104. These container messages can be 5GMM messages. In some embodiments, the MBS session participation request message, the MBS session participation response message, and the MBS session participation completion message can be a PDU Session Modification Request message, a PDU Session Modification Command message, and a PDU Session Modification Complete message, respectively. For the sake of simplicity in the following description, the terms MBS session participation request message, MBS session participation response message, and / or MBS session participation completion message can represent either the respective container messages or the respective messages without containers.

[0049] In some embodiments, UE 102 can establish a PDU session by performing a PDU session establishment procedure with CN 110 via base station 104 to execute the (first) MBS session participation procedure. During the PDU session establishment procedure, UE 102 can communicate the PDU session ID of the PDU session with CN 110 via base station 104.

[0050] Before, during, or after the first MBS session participation procedure (event 502), CN 110 can send 504 a first CN-to-BS message (e.g., Multicast Session Activation Request message) including the first MBS session ID to CU-CP 172A to request CU-CP 172A to configure or activate resources for the first MBS session (i.e., multicast (MBS) session).

[0051] In some embodiments, CN 110 includes in the first CN-to-BS message a first MBS service quality of service (QoS) flow configuration(s) for the first MBS session. In some embodiments, the first MBS QoS flow configuration(s) constitutes MBS QoS flow(s) 1,..., M associated with the first MBS session. M is an integer greater than zero. In some embodiments, the first MBS QoS flow configuration(s) includes the MBS QoS flow identifier(s) 1,..., M and / or the MBS QoS flow level QoS parameter(s) 1,..., M of the MBS QoS flow(s) 1,..., M associated with the first MBS session, respectively. In some embodiments, each of the MBS QoS flow configuration(s) 1,..., M includes an MBS QoS flow identifier and an MBS QoS flow level QoS parameter for a particular MBS QoS flow.

[0052] In some embodiments, CN110 can include first slice information indicating a network slice used for the first MBS session in a message from the first CN to the BS. For example, the first slice information may be a single network slice selection assistance information (S-NSSAI) that identifies a specific network slice. In addition to the first MBS QoS flow configuration(s), CU-CP172A configures and manages resources for the first MBS session based on the first slice information. In other embodiments, CN110 does not include slice information (e.g., S-NSSAI) in a message from the first CN to the BS. In such a case, a default network slice may be used for the first MBS session, and CU-CP172A configures and manages resources for the first MBS session within the default network slice.

[0053] In some embodiments, CN110 can include, in a message from the first CN to the BS, first MBS area information (e.g., MBS Service Area IE) that constitutes or indicates MBS area(s) for the first MBS session. When the first MBS session is a location-dependent multicast session, the first MBS area information includes one or more tuples of {MBS Area Session ID IE, MBS Service Area Information IE}. When the first MBS session is a location-independent multicast session, the first MBS is information that includes MBS Service Area Information IE. The MBS Service Area Information IE within the first MBS area information includes a list of one or more cell identities and / or a list of one or more tracking area identities (TAI(s)). In one embodiment, the one or more cell identities are one or more cell global identities (CGI(s)). In other embodiments, CN110 does not include MBS area information (e.g., MBS Service Area IE) in the message from the first CN to the BS.

[0054] After receiving the message from the first CN to the BS 504, the CU-CP 172A sends 560 a first CP-to-UP message (e.g., an MC Bearer Context Setup Request message) to the CU-UP 172B to request resources for the first MBS session. In some embodiments, the CU-CP 172A determines to configure one or more MRBs for the first MBS session or for one or more of the MBS QoS flows 1, ..., M. In response to the determination, the CU-CP 172A generates an MRB setup configuration to request resources for the one or more MRBs. The CU-CP 172A includes in the first CP-to-UP message a first MBS session ID for the first MBS session, the MRB setup configuration, and / or a second MBS QoS flow configuration (if any). In some embodiments, the second MBS QoS flow configuration (if any) includes QoS parameters for the MBS QoS flow(s) associated with the first MBS session. In some embodiments, the QoS parameters include, for example, 5G QoS identifier(s) (5QI(s)), priority level(s), packet delay budget(s), packet error rate(s), average window(s), and / or maximum data burst volume(s).

[0055] In some embodiments, the CU-CP 172A can include a second MBS QoS flow configuration(s) (e.g., MBS QoS flows Information to be Setup and / or MRB QoS IE(s), or QoS-Flow-QoS-Parameter-List and / or QoSFlowLevelQoSParameters IE(s)) in the MRB setup configuration (e.g., MCMRBSetupConfiguration IE). In some embodiments, the MRB setup configuration includes one or more MRB setup configuration item(s) (e.g., MCMRBSetupConfiguration-Item IE(s)). In some embodiments, each of the MRB setup configuration item(s) includes an MRB ID, an MRB configuration parameter (e.g., PDCP configuration and / or SDAP configuration), and / or a specific one(s) of the second MBS QoS flow configuration(s) for a specific MRB. In some embodiments, 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., an acknowledgment mode or an unacknowledged mode). In some embodiments, the SDAP configuration includes a default DRB configuration (e.g., DefaultDRB IE), an SDAP UL header configuration (e.g., SDAP-Header-UL), and / or an SDAP DL header configuration (e.g., SDAP-Header-DL).

[0056] In some embodiments, the second MBS QoS flow configuration(s) includes the QoS parameters required for each of the MBS QoS flow(s) associated with the MRB(s). In some embodiments, the second MBS QoS flow configuration(s) includes the MBS QoS flow identifier(s) 1, ..., M and / or the MBS QoS flow level QoS parameter(s) 1, ..., M of the MBS QoS flow(s) 1, ..., M associated with the first MBS session, respectively. The MBS QoS flow identifier(s) 1, ..., M identify the MBS QoS flow(s) 1, ..., M, respectively. For example, the MRB setup configuration includes the MRB setup configuration items 1, ..., N for the MRB(s) 1, ..., N, respectively. N is an integer greater than zero. In the MRB setup configuration, the CU-CP 172A can configure the mapping(s) or association(s) between the MBS QoS flow(s) 1, ..., M and the MRB(s) 1, ..., N, where N is an integer and M ≥ N > 0. In some embodiments, the CU-CP 172A associates or maps a specific QoS flow to only a specific MRB. In other words, the CU-CP 172A does not associate or map a specific QoS flow to two MRBs. In some embodiments, the MRB setup configuration item X includes the MRB ID X, the PDCP configuration X, the SDAP configuration X, and / or a specific MBS QoS flow configuration(s) of the second MBS QoS flow configuration(s) for the MRB X of the MRB(s) 1, ..., N, where 1 ≤ X ≤ N.

[0057] The MCMRBSetupConfiguration is a sequence of the size of the MCMRBSetupConfiguration-Item (1..maxnoofMRBs). Table 1 below shows the MRB setup configuration item.

Table 1

[0058] Table 2 below shows other MRB setup configurations, and CU-CP172A omits the SDAP configuration. [Table 2]

[0059] In some embodiments, CU-CP172A generates a second MBS QoS flow configuration(s) based on the first MBS QoS flow configuration(s). For example, the second MBS QoS flow configuration(s) is / are the same as the first MBS QoS flow configuration(s). In other examples, the second MBS QoS flow configuration(s) is / are similar to the first MBS QoS flow configuration(s).

[0060] In some cases where CU-CP172A receives the first slice information from CN110, for example, in a message from the first CN to the BS, CU-CP172A includes the first slice information in a message from the first CP to the UP in order to indicate that the first MBS session uses a specific network slice indicated by the first slice information. Therefore, CU-UP172B configures and manages resources based on the first slice information in addition to the second MBS QoS flow configuration(s). In some cases where CU-CP172A does not receive slice information from CN110 (for example, in a message from the first CN to the BS), CU-CP172A includes pre-configured slice information in a message from the first CP to the UP in order to indicate that a specific network slice is used for the first MBS session. Therefore, CU-UP172B configures and manages resources based on the pre-configured slice information in addition to the second MBS QoS flow configuration(s). Alternatively, in some such cases, CU-CP172A omits the slice information from a message from the first CP to the UP in order to indicate that the first MBS session uses the default network slice. Therefore, CU-UP172B configures and manages resources based on the second MBS QoS flow configuration(s) within or using the default network slice.

[0061] In some cases where CU-CP172A receives the first MBS area information from CN110 (e.g., in a message from the first CN to the BS), CU-CP172A includes the first MBS area information in the message from the first CP to the UP. In some cases where CU-CP172A does not receive the MBS area information from CN110 (e.g., in a message from the first CN to the BS), CU-CP172A includes the pre-configured MBS area information in the message from the first CP to the UP. Alternatively, in some such cases, CU-CP172A omits the MBS area information from the message from the first CP to the UP. In some cases where CU-CP172A receives the first MBS area information from CN110 (e.g., in a message from the first CN to the BS), CU-CP172A extracts the MBS Area Session ID from the first MBS area information and includes the MBS Area Session ID in the message from the first CP to the UP. In some further such cases, CU-CP172A refrains from including the MBS Service Area Information IE in the message from the first CP to the UP. In some cases where CU-CP172A does not receive the MBS area information from CN110 (e.g., in a message from the first CN to the BS), CU-CP172A includes the pre-configured MBS Area Session ID in the message from the first CP to the UP. Alternatively, in some such cases, CU-CP172A omits the MBS Area Session ID from the message from the first CP to the UP.

[0062] In response to the message from the first CP to the UP, the CU-UP 172B establishes or configures resources for the MRB(s), and transmits 562 a message from the first UP to the CP (first UP-to-CP message) (e.g., an MC Bearer Context Setup Response message). In some embodiments, the CU-UP 172B configures resources for each of the MRB(s) based on the corresponding MRB configuration parameter and / or specific ones (if any) of the second MBS QoS flow configuration(s). In some embodiments, the CU-UP 172B configures resources for the MRB(s), MBS QoS flow(s), and / or the first MBS session based on the first slice information. In some embodiments, the CU-UP 172B establishes and / or configures one or more PDCP entities 1, ..., N according to the PDCP configuration(s) 1, ..., N for the MRB(s) or MRB ID(s) 1, ..., N. In other embodiments, for each of the PDCP configuration(s) 1, ..., N, the CU-UP 172B ignores or discards a part of the PDCP configuration and establishes and / or configures the PDCP entity according to the remaining part of the PDCP configuration. In one embodiment, 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 other embodiments, 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.

[0063] In some embodiments, the CU-UP 172B establishes and / or configures one or more SDAP entities 1, ..., N according to the SDAP configuration(s) 1, ..., N for the MRB(s) or MRB ID(s) 1, ..., N. In other embodiments, for each of the SDAP configuration(s) 1, ..., N, the CU-UP 172B ignores or discards a part of the SDAP configuration and establishes and / or configures an SDAP entity according to the remaining part of the SDAP configuration. In one embodiment, the CU-UP 172B ignores or discards the default DRB configuration and the SDAP UL header configuration and establishes and / or configures an SDAP entity according to the SDAP DL header configuration. In other embodiments, the CU-UP 172B ignores or discards the default DRB configuration and establishes and / or configures an SDAP entity according to the SDAP UL header configuration and the SDAP DL header configuration. In yet other embodiments, the CU-UP 172B ignores or discards the entire SDAP configuration. This is because the CU-UP 172B determines not to use SDAP for transmitting the MBS data of the first MBS session.

[0064] In some embodiments, CU-UP172B includes a first CU transport layer configuration in a message from the first UP to the CP to configure a common CN-BS DL tunnel for the first MBS session. In some embodiments, the first CU transport layer configuration includes a CU transport layer address (e.g., an IP address and / or a TEID) to identify the first common CN-BS DL tunnel. In other embodiments, the first CU transport layer configuration is the MC Bearer Context NG-U TNL Info at NG-RAN. In some embodiments, CU-CP172A includes a first CU-CP MBS E1AP ID in a message from the first CP to the UP to identify the first MBS session on the E1 interface between CU-CP172A and CU-UP172B. In some embodiments, CU-UP172B includes a first CU-UP MBS E1AP ID in a message from the first UP to the CP to identify the first MBS session on the E1 interface between CU-CP172A and CU-UP172B. In further embodiments, CU-UP172B includes the first CU-CP MBS E1AP ID in a message from the first UP to the CP.

[0065] Events 560 and 562 are collectively referred to as the MC bearer context setup procedures in Figure 5A.

[0066] After receiving 504 the first CN-to-BS message (e.g., in response to receiving 504), the CU-CP 172A transmits 506 a first CU-to-DU message (e.g., Multicast Context Setup Request message) to the DU 174 to request setup for the multicast context of the first MBS session and / or for a common DL tunnel. See Figure 4 and the accompanying text. The CU-CP 172A determines to configure one or more MRBs for the first MBS session or for MBS QoS flow(s) 1, ..., M. In response to the determination, the CU-CP 172A generates MRBs to be in a setup configuration for requesting resources for one or more MRBs. In some embodiments, the first CU-to-DU message includes a first MBS session ID for the first MBS session, an MRB in setup configuration, and / or a third MBS QoS flow configuration(s). In some embodiments, the CU-CP 172A includes first slice information in the first CU-to-DU message to indicate that a particular network slice indicated by the first slice information is used for the first MBS session. In some embodiments, the MRBs in setup configuration each include MRB ID(s) that identify the MRBs, and the DU 174 configures resources (e.g., PHY, MAC, and / or RLC resources) for the MRB(s). The MRB ID(s) included in the first CU-to-DU message are the same as the MRB ID(s) included in the first CP-to-UP message. For example, the MRBs in setup configuration include MRB ID(s) 1, ..., N for MRB(s) 1, ..., N, respectively. The third MBS QoS flow configuration(s) includes QoS parameters required for the MBS QoS flow(s) associated with the first MBS session.In some embodiments, the third MBS QoS flow configuration(s) includes the MBS QoS flow identifier(s) 1, ..., M and / or the MBS QoS flow level QoS parameter(s) 1, ..., M for the MBS QoS flow(s) 1, ..., M associated with the first MBS session. The MBS QoS flow identifier(s) 1, ..., M respectively identify the MBS QoS flow(s) 1, ..., M. In the MRB for the setup configuration, the CU-CP 172A can configure the mapping(s) or association(s) between the MBS QoS flow(s) and the MRB(s). For example, the MRB for the setup configuration includes the setup configuration item(s) 1, ..., N for the MRB(s) 1, ..., N respectively. In some embodiments, the MRB that is the setup configuration item Y includes the MRB ID Y for the MRB Y of the MRB(s) 1, ..., N and the specific MBS QoS flow configuration(s) of the third MBS QoS flow configuration(s), where 1 ≤ Y ≤ N. In some embodiments, the CU-CP 172A generates the third MBS QoS flow configuration(s) based on the first MBS QoS flow configuration(s). For example, the third MBS QoS flow configuration(s) is the same as the first MBS QoS flow configuration(s). In other examples, the third MBS QoS flow configuration(s) is similar to the first MBS QoS flow configuration(s). In some embodiments, the CU-CP 172A includes the CU MBS F1AP ID in the message from the first CU to the DU to identify the first MBS session on the F1 interface between the CU-CP 172A and the DU 174.

[0067] When CU-CP172A receives, for example, in a message from the first CN to the BS, the first slice information (e.g., S-NSSAI) associated with the first MBS session from CN110, CU-CP172A includes the first slice information in the message from the first CU to the DU in order to indicate that a specific network slice is used for the first MBS session. When CU-CP172A does not receive, for example, in a message from the first CN to the BS, the slice information (e.g., S-NSSAI) associated with the first MBS session from CN110, CU-CP172A includes the pre-configured slice information in the message from the first CU to the DU. Alternatively, in such a case, CU-CP172A omits the slice information in the message from the first CP to the UP.

[0068] When CU-CP172A receives the first MBS area information from CN110, for example, in a message from the first CN to the BS, CU-CP172A can include the first MBS area information in a message from the first CU to the DU. When CU-CP172A does not receive the MBS area information from CN110, for example, in a message from the first CN to the BS, CU-CP172A can include the pre-configured MBS area information in a message from the first CU to the DU. Alternatively, CU-CP172A can omit the MBS area information from a message from the first CU to the DU in such a case. When CU-CP172A receives the first MBS area information from CN110, for example, in a message from the first CN to the BS, CU-CP172A can extract the MBS Area Session ID from the first MBS area information and include the MBS Area Session ID in a message from the first CU to the DU. When CU-CP172A does not receive the MBS area information from CN110, for example, in a message from the first CN to the BS, CU-CP172A can include the pre-configured MBS Area Session ID in a message from the first CU to the DU. Alternatively, CU-CP172A can omit the MBS Area Session ID from a message from the first CU to the DU in such a case.

[0069] In response to receiving a message from the first CU to the DU 506, the DU 174 establishes or configures resources for the MRB(s) (e.g., multicast context and / or PHY, MAC, RLC and / or tunnel resources), and transmits 508 a message from the first DU to the CU (first DU-to-CU message) (e.g., Multicast Context Setup Response message) to the CU-CP 172A. In some embodiments, the DU 174 establishes and / or configures a MAC entity for the MRB(s). In some embodiments, there is a DU 174. In some embodiments, the CU-UP 172B establishes and / or configures one or more RLC entities 1, ..., N for each of the MRB(s) or MRB ID(s) 1, ..., N. In some embodiments, the DU 174 includes a first DU transport layer configuration in a message from the first DU to the CU to configure a common CU-DU DL tunnel for the first MBS session (e.g., for the MRB identified by one of the MRB ID(s)). The DU 174 can include additional DU transport layer configuration(s) in a message from the first DU to the CU to configure additional common CU-DU DL tunnel(s) for additional MRB(s) identified by additional MRB ID(s) of the MRB ID(s). In some embodiments, the DU 174 can include in a message from the first DU to the CU the MRB ID(s) associated with the first DU transport layer configuration and / or additional DU transport layer configuration(s). For example, each of the MRB ID(s) is associated with a particular DU transport layer configuration. In some embodiments, each of the first DU transport layer configuration and / or additional DU transport layer configuration(s) includes a DU transport layer address (e.g., IP address and / or TEID). In some embodiments, each of the first DU transport layer configuration and / or additional DU transport layer configuration(s) can be the MRB F1-U TNL Info at DU IE.

[0070] Events 506 and 508 are collectively referred to as multicast context setup procedures in FIG. 5A. In some embodiments, the multicast context setup procedures and the MC bearer context setup procedures can be performed in parallel. In other embodiments, the multicast context setup procedures may occur after the MC bearer context setup procedures, or vice versa.

[0071] In some embodiments, after receiving message 506 from the first CU to the DU or after transmitting message 508 from the first DU to the CU, DU 174 transmits message 510 to CU-CP 172A, a message (second DU-to-CU message) from the second DU to the CU (e.g., Multicast Distribution Setup Request message). In some embodiments, DU 174 includes the first DU transport layer configuration and / or additional DL transport layer configuration(s) in the message from the second DU to the CU instead of the message from the first DU to the CU. In some embodiments, DU 174 can include the MRB ID(s) associated with the first DU transport layer configuration and / or additional DU transport layer configuration(s) in the message from the second DU to the CU instead of the message from the first DU to the CU. Thus, the message from the first DU to the CU does not include the DU transport layer configuration. In some embodiments, in response to the message from the second DU to the CU, CU-CP 172A transmits message 516 to DU 174, a message (second CU-to-DU message) from the second CU to the DU (e.g., Multicast Distribution Setup Response message). Events 510 and 516 are collectively referred to as multicast distribution setup procedures in FIG. 5A.

[0072] After receiving the first CN-to-BS message at 5f04, after receiving the first UP-to-CP message at 562, after receiving the first DU-to-CU message at 508, or after receiving the second DU-to-CU message at 510, CU-CP 172A sends a first BS-to-CN message (e.g., Distribution Setup Request message) to CN 110 at 512. In some embodiments, CU-CP 172A sends a first BS-to-CN message to CN 110 at 512 before receiving the first DU-to-CU message at 508 or before receiving the second DU-to-CU message at 510. In some embodiments, CU-CP 172A can include a first CU transport layer configuration in the first BS-to-CN message. Thus, CN 110 can send MBS data to CU-UP 172B via the first common CN-BS DL tunnel as described for event 532. In some embodiments, CU-CP 172A can include a first MBS session ID in the first BS-to-CN message. In some embodiments, CN 110 sends a second CN-to-BS message (e.g., Distribution Setup Response message) to CU-CP 172A at 514 in response to the first BS-to-CN message. In some embodiments, CN 110 can 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., one or more IP addresses) to identify the first common CN-BS DL tunnel. In some embodiments, the at least one transport layer address includes an IP source address and / or an IP multicast address. In some embodiments, the first CN transport layer configuration includes the TEID at CN 110 / TEID of CN 110.In some embodiments, CN110 includes a fourth MBS QoS flow configuration(s) for the first MBS session in a message from a second CN to the BS. In one embodiment, the fourth MBS QoS flow configuration(s) is the same as the first MBS QoS flow configuration(s).

[0073] After receiving the message from the second CN to the BS 514, the CU-CP 172A transmits 564 a message from the second CP to the UP (second CP-to-UP message) (e.g., MC Bearer Context Modification Request message) to the CU-UP 172B. In some embodiments, the CU-CP 172A includes in the message from the second CP to the UP the MRB ID(s), the first DU transport layer configuration, additional DU transport layer configuration(s), and / or the first CN transport layer configuration. In response to the message from the second CP to the UP for event 564, the CU-UP 172B transmits 566 a message from the second UP to the CP (second UP-to-CP message) (e.g., MC Bearer Context Modification Response message). In some embodiments, the CU-UP 172B includes the MRB ID(s) and / or the second CU transport layer configuration in the message from the second UP to the CP. In some embodiments, the second CU transport layer configuration includes a CU transport layer address (e.g., an IP address) to identify the first common CU-DU DL tunnel. The second CU transport layer configuration can additionally include the TEID / CU-UP 172B's TEID at the CU-UP 172B. In some embodiments, the second CU transport layer configuration is the same as the first CU transport layer configuration. In other embodiments, the second CU transport layer configuration is different from the first CU transport layer configuration. In some embodiments, the CU-CP 172A includes the second CU transport layer configuration in the message from the second CU to the DU and transmits 516 the message from the second CU to the DU to the DU 174 in response to the message from the second DU to the CU for event 510.After receiving the second UP-to-CP message 566 or after transmitting the second CU-to-DU message 516, the CU-CP 172A transmits 518 a second BS-to-CN message (e.g., Multicast Session Activation Response message) to the CN 110 in response to the first CN-to-BS message. Alternatively, the CU-CP 172A transmits 518 a second BS-to-CN message to the CN 110 before receiving the second UP-to-CP message 566 or before transmitting the second CU-to-DU message 516. For example, the CU-CP 172A transmits 518 a second BS-to-CN message to the CN 110 after receiving the first CN-to-BS message 504, after receiving the first UP-to-CP message 562, after receiving the second DU-to-CU message 510, or after receiving the second CN-to-BS message 514.

[0074] In some embodiments, the CU-CP 172A can include a fourth MBS QoS flow configuration(s) in the MC Bearer Context Modification Request message. In such embodiments, the CU-UP 172B can modify or reconfigure resources for the MRB(s) based on the fourth MBS QoS flow configuration(s). In such embodiments, the CU-UP 172B can determine whether to modify or reconfigure resources for the MRB(s) based on the fourth MBS QoS flow configuration(s). For example, if the resources for the MRB(s) at event 562 can still satisfy the fourth MBS QoS flow configuration(s), the CU-UP 172B does not modify or reconfigure the resources for the first MRB. Otherwise, the CU-UP 172B modifies or reconfigures the resources for the MRB(s) based on the fourth MBS QoS flow configuration(s). In such embodiments, the CU-UP 172B can determine whether to modify or reconfigure resources for a specific MRB among the MRB(s) based on the fourth MBS QoS flow configuration(s). For example, if the resources for the first MRB among the MRB(s) at event 562 can still satisfy a specific one(s) of the fourth MBS QoS flow configuration(s) for a specific MBS QoS flow(s) mapped to the first MRB, the CU-UP 172B does not modify or reconfigure the resources for the first MRB. Otherwise, the CU-UP 172B modifies or reconfigures the resources for the first MRB based on the specific MBS QoS flow configuration(s).

[0075] Events 504, 560, 562, 506, 508, 510, 512, 514, 564, 566, 516, and 518 are collectively referred to in FIG. 5A as the MBS session resource setup procedure 592A.

[0076] In some embodiments, CN110 can send 520 to CU-CP172A a third CN-to-BS message indicating that UE102 (e.g., UE102A) participates (only) in a first MBS session. In some embodiments, CN110 can include in the third CN-to-BS message a first MBS session ID and / or one or more MBS QoS flow identifiers that identify the first MBS session and the one or more MBS QoS flows associated with the first MBS session, respectively. In response to the third CN-to-BS message, CU-CP172A can send 527 to CN110 a third BS-to-CN message. After receiving the third CN-to-BS message (e.g., in response to receiving it), CU-CP172A can send 522 to DU174 a UE context request message for UE102. In some embodiments, CU-CP172A can include one or more MRB IDs in the UE context request message. In some embodiments, CU-CP172A determines the one or more MRB IDs based on the first MBS session ID and / or the one or more MBS QoS flow identifiers received in the third CN-to-BS message. In some embodiments, CU-CP172A may not include the first MBS session ID in the UE context request message.

[0077] In response to the UE context request message of event 522, DU174 transmits 524 a UE context response message including configuration parameters for UE102A to CU-CP172A to receive MBS data of the first MBS session via one or more MRBs. Some or all of the configuration parameters may be associated with one or more MRBs / MRB IDs. In some embodiments, DU174 generates a DU configuration (i.e., a first DU configuration) to include the configuration parameters (i.e., a first plurality of configuration parameters) and includes the DU configuration in the UE context response message. In some embodiments, the DU configuration can be a CellGroupConfig IE. In other embodiments, the DU configuration can be an MBS-specific IE. In some embodiments, the configuration parameters configure one or more logical channels (LCs) for one or more MRBs. For example, the configuration parameters include one or more logical channel IDs (LCIDs) to configure one or more logical channels. Each LCID identifies a specific logical channel among one or more logical channels. In some embodiments, the message from the third CN to the BS and the message from the third BS to the CN can be a PDU Session Resource Modify Request message and a PDU Session Resource Modify Response message, respectively. In other embodiments, the message from the third CN to the BS and the message from the third BS to the CN can be a PDU Session Resource Setup Request message and a PDU Session Resource Setup Response message, respectively. In some embodiments, the message from the third CN to the BS and the message from the third BS to the CN can be UE-related messages, i.e., the messages are associated with a specific UE (e.g., UE102A, 102B, or 103).

[0078] In some embodiments, the UE context request message and the UE context response message are a UE Context Setup Request message and a UE Context Setup Response message, respectively. In other embodiments, the UE context request message and the UE context response message are a UE Context Modification Request message and a UE Context Modification Response message, respectively.

[0079] In some embodiments, after receiving a message from the third CN to the BS (e.g., in response to receiving), the CU-CP 172A can execute (UE-specific) bearer context procedures at the CU-UP 172B. In the bearer context procedures, the CU-CP 172A sends a bearer context request message to the CU-UP 172B to request establishing or modifying the (unicast) bearer context for the UE 102. In response, the CU-UP 172B establishes or modifies the (unicast) bearer context for the UE 102 and sends a bearer context response message to the CU-CP 172A. In other embodiments, when the CU-CP 172A receives a message from the third CN to the BS, it prevents the CU-UP 172B from executing the (UE-specific) bearer context procedures for the UE 102. In some embodiments, the bearer context procedures are the bearer context setup procedures defined in section 8.3.1 of 3GPP (registered trademark) specification 37.483. In such a case, the bearer context request message and the bearer context setup message are the Bearer Context Setup Request message and the Bearer Context Setup Response message, respectively. In other embodiments, the bearer context procedures are the bearer context modification procedures defined in section 8.3.2 of 3GPP (registered trademark) specification 37.483. In such a case, the bearer context request message and the bearer context setup message are the Bearer Context Modification Request message and the Bearer Context Modification Response message, respectively.

[0080] After receiving the UE context response message 524, the CU-CP 172A generates an RRC reconfiguration message (e.g., RRCReconfiguration message) including configuration parameters and one or more MRB configurations (i.e., the first MRB configuration (multiple possible)), and transmits 526 the RRC reconfiguration message to the DU 174. Similarly, the DU 174 transmits 528 the RRC reconfiguration message to the UE 102. Thereafter, the UE 102 transmits 530 an RRC reconfiguration complete message to the DU 174, and the DU 174 similarly transmits 531 the RRC reconfiguration complete message (e.g., RRCReconfigurationComplete message) to the CU-CP 172A.

[0081] Events 520, 522, 524, 526, 527 (described later), 528, 530, and 531 are collectively referred to as UE-specific MBS session configuration procedures 594 in FIG. 5A. The CN 110 and / or the CU-CP 172A executes the procedure 594 for each of the UEs (e.g., UE102A and UE102B) participating in the first MBS session. In some scenarios or embodiments, the procedure 594 may occur before the procedure 592A. In other scenarios or embodiments, the procedure 594 may occur after the procedure 592A. In still other scenarios or embodiments, the procedure 594 may overlap with the procedure 592A.

[0082] In some embodiments, the CU-CP 172A generates a PDCP PDU including an RRC reconfiguration message and transmits 526 the message from the CU to the DU including the PDCP PDU to the DU 174. In such embodiments, the DU 174 extracts the PDCP PDU from the message from the CU to the DU and transmits 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 embodiments, the UE 102 generates a PDCP PDU including an RRC reconfiguration complete message and transmits 530 the PDCP PDU to the DU 174 via the RLC layer 206B, the MAC layer 204B, and the PHY layer 202B. The DU 174 receives 522 the PDCP PDU from the UE 102 via the PHY layer 202B, the MAC layer 204B, and the RLC layer 206B and transmits 531 a message from the DU to the CU (DU-to-CU message) including the PDCP PDU to the CU-CP 172A. The CU-CP 172A extracts the PDCP PDU from the message from the DU to the CU and extracts the RRC reconfiguration complete message from the PDCP PDU.

[0083] Before or after receiving 524 the UE context response message, the CU-CP 172A can transmit 527 a message from the third BS to the CN to the CN 110 in response to the message 520 from the third CN to the BS. In some embodiments, the CU-CP 172A transmits 527 a message from the third BS to the CN to the CN 110 before receiving 531 the RRC reconfiguration complete message. In other embodiments, the CN 110 transmits 527 a message from the third BS to the CN to the CN 110 after receiving 531 the RRC reconfiguration complete message. The CU-CP 172A can include the first CN UE interface ID and the first RAN UE interface ID in the message from the third BS to the CN. In some embodiments, the CN 110 assigns a first CN UE interface ID that identifies the UE 102 (e.g., UE 102A), and the CU-CP 172A assigns a first RAN UE interface ID that identifies the UE 102 (e.g., UE 102A). In some embodiments, the "CN UE interface ID" can be the "AMF UE NGAP ID", and the "RAN UE interface ID" can be the "RAN UE NGAP ID".

[0084] After receiving the message from the second BS to the CN 518, or after receiving the message from the third BS to the CN 527, the CN 110 (e.g., (MB-)UPF 162) transmits 532 the 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-BS DL tunnel (i.e., according to the first CU transport layer configuration and / or the first CN transport layer configuration). In some embodiments, the CN 110 generates tunnel packets each containing a specific MBS data packet and transmits the MBS data packets via the first common CN-BS DL tunnel. In each header of the tunnel packet, the CN 110 sets the source IP address, the target IP address, and the TEID to the IP address within the first CN transport layer configuration, the IP address within the first CU transport layer configuration, and the TEID within the first CU transport layer configuration, respectively. In such embodiments, the IP address within the first CN transport layer configuration, the IP address within the first CU transport layer configuration, and the TEID within the first CU transport layer configuration identify the first common CN-BS DL tunnel.

[0085] When CU-UP172B receives MBS data of the first MBS session from CN110 at 532, CU-UP172B similarly transmits the MBS data to DU174 via the first common CU-DU inter-tunnel and / or an additional common CU-DU inter DL tunnel (i.e., according to the first and / or additional DU transport layer configuration(s)) at 534. If the MBS data is associated with one or some of the MBS QoS flow(s) identified by the MBS QoS flow identifier(s), CU-UP172B can determine which common CU-DU inter DL tunnel(s) to use to transmit the MBS data to DU174 based on one or some of the MBS QoS flow identifier(s). For example, when CU-UP172B receives from CN110 the first MBS data packet associated with the first MBS QoS flow identifier among the MBS QoS flow identifier(s), CU-UP172B transmits the first MBS data packet to DU174 via the first common CU-DU inter DL tunnel. When CU-UP172B receives from CN110 the second MBS data packet associated with the second MBS QoS flow identifier among the MBS QoS flow identifier(s), CU-UP172B transmits the second MBS data packet to DU174 via one of the additional common CU-DU inter-tunnels. In some embodiments, CU-UP172B generates tunnel packets each containing a specific MBS data packet and transmits the MBS data packet via the first common CU-DU inter-tunnel and / or an additional common CU-DU inter DL tunnel. When CU-UP172B transmits one of the tunnel packets via the first common CU-DU inter-tunnel, CU-UP172B sets the source IP address, target IP address, and 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 an embodiment, 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-DU DL tunnel. When CU-UP 172B sends one of the tunnel packets via an additional common CU-DU tunnel, CU-UP 172B sets the source IP address, the target 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 embodiment, 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-DU DL tunnel.

[0086] When DU174 receives MBS data from CU-UP172B at 534, DU174 transmits (e.g., multicasts or unicasts) the MBS data to UE102 via one or more logical channels at 536. UE102 receives the MBS data via one or more logical channels at 536. For example, CU-UP172B may receive MBS data packets at 532, generate PDCP PDUs containing the MBS data packets, and transmit the PDCP PDUs to DU174 at 534. Similarly, DU174 generates MAC PDUs containing logical channel IDs and PDCP PDUs, and transmits the MAC PDUs to UE102 via multicast or unicast at 536. UE102 receives the MAC PDUs via multicast or unicast at 536, extracts the PDCP PDUs and logical channel IDs from the MAC PDUs, identifies the PDCP PDUs associated with the MRB according to the logical channel IDs, and extracts the MBS data packets from the PDCP PDUs according to the PDCP configuration within the MRB configuration. In some embodiments, DU174 can transmit the MBS data or MAC PDUs to UE102 via one or more multicast transmissions (e.g., dynamic or SPS multicast transmissions (multiple possible)) as described above at 536. In such cases, UE102 can receive the MBS data or MAC PDUs from DU174 via one or more multicast transmissions as described above at 536.

[0087] In some embodiments, CU-CP 172A can request DU 174 to configure a UE-specific CU-DU DL tunnel for UE 102 in an event 522 UE context request message. In some embodiments, CU-CP 172A can include a CU transport layer configuration in the UE context request message to request a UE-specific CU-DU DL tunnel for UE 102. The CU transport layer configuration includes a CU transport layer address (e.g., an IP address) to identify the UE-specific CU-DU DL tunnel. The CU transport layer configuration can additionally include the TEID / CU-UP 172B's TEID at CU-UP 172B. In response, DU 174 can include a DU transport layer configuration that configures the UE-specific CU-DU DL tunnel in the UE context response message. The DU transport layer configuration includes a DU transport layer address (e.g., an IP address and / or a TEID). After receiving 524 the UE context response message, CU-CP 172A can send a Bearer Context Modification Request message including the DU transport layer configuration to CU-UP 172B, and in response, CU-UP 172B can send a Bearer Context Modification Response message to CU-CP 172A. Thereafter, CU-UP 172B can send 534 MBS data to DU 174 via the UE-specific CU-DU DL tunnel.

[0088] In some embodiments, the configuration parameters can also include one or more RLC bearer configurations, each associated with a specific MRB. Each MRB configuration(s) can include an MRB ID, a PDCP configuration, a first MBS session ID, a PDCP re-establishment flag (e.g., reestablishPDCP), and / or a PDCP recovery flag (e.g., recoveryPDCP). In some embodiments, the PDCP configuration can be a PDCP-Config IE for a DRB. In some embodiments, the RLC bearer configuration can be an RLC-BearerConfig IE. In some embodiments, the RLC bearer configuration can include a logical channel (LC) ID that configures a logical channel. In some embodiments, the logical channel can be a (multicast) MBS traffic channel (MTCH). In other embodiments, the logical channel can be a dedicated traffic channel (DTCH). In some embodiments, the configuration parameters can include a logical channel configuration (e.g., LogicalChannelConfig IE) that configures a logical channel. In some embodiments, the RLC bearer configuration can include an MRB ID.

[0089] In some embodiments, the CU-CP 172A can configure the MRB as a DL dedicated RB in the MRB configuration. For example, the CU-CP 172A can prevent including UL configuration parameters in the PDCP configuration within the MRB configuration to configure the MRB as a DL dedicated RB. The CU-CP 172A can include only DL configuration parameters in the MRB configuration as described above, for example. In such a case, the CU-CP 172A configures the UE 102 not to transmit 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 within the MRB configuration. In another example, the DU 174 prevents including UL configuration parameters in the RLC bearer configuration. In such a case, the DU 174 configures the UE 102 not to transmit control PDU(s) to the base station 104 via the logical channel by excluding the UL configuration parameters from the RLC bearer configuration.

[0090] When DU174 includes UL configuration parameter(s) in the RLC bearer configuration, UE102 may use the UL configuration parameter(s) to transmit control PDU(s) (e.g., PDCP control PDU(s) and / or RLC control PDU(s)) to DU174 via a logical channel. When the control PDU is a PDCP control PDU, DU174 can transmit the PDCP control PDU to CU-UP172B. For example, CU-CP172A may configure the UE to receive MBS data using a compression (decompression) protocol (e.g., Robust Header Compression (ROHC) protocol). In this case, when CU-UP172B receives MBS data packets from CN110, CU-UP172B compresses the MBS data packets using the compression protocol to obtain compressed MBS data packet(s), and transmits a PDCP PDU including the compressed MBS data packet(s) to DU174 via the first or an additional common CU-DU DL tunnel. Similarly, DU174 transmits the PDCP PDU to UE102 via a logical channel (e.g., multicast or unicast). When UE102 receives the PDCP PDU via the logical channel, UE102 extracts the compressed MBS data packet from the PDCP PDU. UE102 decompresses the compressed MBS data packet(s) using the compression (decompression) protocol to obtain the original MBS data packet. In such a case, UE102 may transmit a PDCP control PDU including header compression protocol feedback (e.g., sporadic ROHC feedback) for the operation of the header compression (decompression) protocol to DU174 via the logical channel. Similarly, DU174 transmits the PDCP control PDU to CU-UP172B via the UL tunnel. In some embodiments, the UL tunnel is a first common DU-CU inter-tunnel composed of a first DU transport layer configuration and a second CU transport layer configuration. For example, the IP address in the first DU transport layer configuration, and the IP address and TEID in the second CU transport layer configuration identify the first common DU-CU inter-tunnel.In other embodiments, the UL tunnel is specific to UE 102 (e.g., UE 102A). In some embodiments, CU-CP 172A can include, in the UE context request message, a CU transport layer configuration that configures a UE-specific UL tunnel. The CU transport layer configuration includes a CU transport layer address (e.g., Internet Protocol (IP) address) and a TEID to identify the UE-specific UL tunnel. DU 174 can include, in the UE context response message, a DU transport layer configuration that configures a UE-specific UL tunnel. The DU transport layer configuration includes a DU transport layer address (e.g., IP address and / or TEID). For example, the IP address within the DU transport layer configuration, and the IP address and TEID within the CU transport layer configuration identify a first common UL tunnel.

[0091] In some embodiments, the MRB configuration can be an MRB-ToAddMod IE that includes an MRB ID (e.g., mrb-Identity or MRB-Identity). The MRB ID identifies a particular MRB among the MRB(s). When CU-CP 172A configures DRB(s) for UE 102 for unicast data communication, in some embodiments, CU-CP 172A can set one or more of the MRB ID(s) to a value different from the DRB ID(s) of the DRB(s). In such a case, UE 102 and CU-CP 172A can distinguish whether an RB is an MRB or a DRB according to the RB ID of the RB. In other embodiments, CU-CP 172A can set one or more of the MRB ID(s) to a value that can be the same as the DRB ID(s). In such a case, UE 102 and CU-CP 172A can distinguish whether an RB is an MRB or a DRB according to the RB ID of the RB and the RRC IE that configures the RB. For example, the DRB configuration that configures a DRB is a DRB-ToAddMod IE that includes a DRB identity (e.g., drb-Identity or DRB-Identity) and a PDCP configuration. Therefore, when UE 102 receives a DRB-ToAddMod IE that configures an RB for UE 102, UE 102 can determine that the RB is a DRB, and when UE 102 receives an MRB-ToAddMod IE that configures an RB, UE 102 can determine that the RB is an MRB. Similarly, when CU-CP 172A transmits a DRB-ToAddMod IE that configures an RB to UE 102, CU-CP 172A can determine that the RB is a DRB, and when CU-CP 172A transmits an MRB-ToAddMod IE that configures an RB to UE 102, CU-CP 172A can determine that the RB is an MRB.

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

[0093] In some embodiments, the configuration parameters can include dynamic scheduling multicast configuration parameter(s) for UE102 for receiving multicast transmissions each including MBS data or a particular portion of the MBS data. In some embodiments, the dynamic scheduling multicast configuration parameter(s) can include at least one of the following configuration parameters. ● Group Radio Network Temporary Identifier (G-RNTI). DU174 generates DCI, scrambles the cyclic redundancy check (CRC) of the DCI with the G-RNTI, and transmits the DCI and the scrambled CRC on the PDCCH to dynamically schedule multicast transmissions for UE102, respectively, including a specific MAC PDU. The MAC PDU can include an MBS data packet or a part of an MBS data packet. UE102 receives the DCI and the scrambled CRC on the PDCCH and verifies the CRC scrambled with the G-RNTI. For each multicast transmission, after UE102 verifies that the (scrambled) CRC is valid, UE102 receives the multicast transmission according to the corresponding DCI and extracts a specific MAC PDU from the multicast transmission. In this case, each multicast transmission is a dynamic scheduling multicast transmission used in the following description. In some embodiments, each DCI includes configuration parameters that configure dynamic scheduling multicast radio resources for the corresponding multicast transmission. In some embodiments, the configuration parameters can include at least one of the following parameters. The configuration parameters of each DCI can include the same value and / or different values as the following configuration parameters. ○ Frequency domain resource allocation ○ Time domain resource allocation ○ Mapping from virtual resource block (VRB) to physical resource block (PRB) ○ Modulation and coding scheme (MCS) ○ New data indicator ○ Redundancy version ○ HARQ process number ○ Downlink allocation index ○ PUCCH resource indicator ● The HARQ codebook (ID) indicates the HARQ acknowledgement (ACK) codebook index of the HARQ ACK codebook corresponding to the dynamically scheduled multicast transmission received by UE102. DU174 uses the HARQ codebook (ID) to receive the HARQ ACK. If the configuration parameter does not include the HARQ codebook (ID), UE102 and DU174 may use the HARQ codebook (ID) for unicast transmission. In some embodiments, UE102 can receive the HARQ codebook (ID) for unicast transmission in the DU configuration from DU174. In other embodiments, UE102 can receive the HARQ codebook (ID) for unicast transmission in other DU configurations from DU174, similar to events 516, 518, and 520. ● The PUCCH resource configuration indicates the HARQ resources on the PUCCH on which UE102 transmits HARQ feedback (e.g., HARQ ACK and / or negative ACK (NACK)) for dynamically scheduled multicast transmission. If the configuration parameter does not include the PUCCH resource configuration, UE102 and DU174 can communicate HARQ feedback using the PUCCH resource configuration for unicast transmission. ● The indication of only HARQ NACK configures the UE102 to send only HARQ negative ACK (NACK) for dynamic scheduling multicast transmissions that the UE102 receives from the DU174 and from which the UE102 cannot obtain a transport block. In some embodiments, the UE102 cannot obtain a transport block because the UE102 fails a cyclic redundancy check (CRC) of the transport block or because the UE102 does not receive a dynamic scheduling multicast transmission. In accordance with the indication, the UE102 is prevented from sending HARQ ACK to the DU174 for dynamic scheduling multicast transmissions that the UE102 successfully receives and from which the UE102 obtains a transport block. If the configuration parameter does not include the indication, the UE102 may send HARQ ACK to the DU174 for dynamic scheduling multicast transmissions that the UE102 successfully receives and from which the UE102 obtains a transport block. ● The HARQ ACK / NACK indication configures the UE102 to send HARQ NACK for dynamic scheduling multicast transmissions from which the UE102 cannot obtain a transport block and to send HARQ ACK for dynamic scheduling multicast transmissions that the UE102 successfully receives and from which the UE102 obtains a transport block. If the configuration parameter does not include the indication, the UE102 is prevented from sending HARQ ACK to the DU174 for dynamic scheduling multicast transmissions that the UE102 successfully receives and from which the UE102 obtains a transport block. In such a case, the UE102 is only permitted to send HARQ NACK to the DU174 for dynamic scheduling multicast transmissions from which the UE102 cannot obtain a transport block. ● The HARQ ACK indication configures the UE 102 to transmit HARQ ACK for dynamically scheduled multicast transmissions from which the UE 102 successfully receives and from which the UE 102 obtains a transport block. If the configuration parameter does not include the indication, the UE 102 does not transmit HARQ ACK for dynamically scheduled multicast transmissions from which the UE 102 successfully obtains a transport block to the DU 174. In such a case, the UE 102 is only permitted to transmit HARQ NACK for dynamically scheduled multicast transmissions from which the UE 102 cannot obtain a transport block to the DU 174. In some embodiments, the DU 174 may include any one of a HARQ NACK indication, a HARQ ACK / NACK indication, and a HARQ ACK indication. ● The configuration of the modulation and coding scheme (MCS) shows the MCS table used for the DU174 to transmit dynamic scheduling multicast transmissions and for the UE102 to receive dynamic scheduling multicast transmissions. For example, the MCS table can be the MCS table defined in the 3GPP (registered trademark) specification 38.214 (e.g., the low SE 64QAM table shown in Table 5.1.3.1-3 of 3GPP (registered trademark) TS 38.214, or a new table specific to multicast transmissions). In some embodiments, if the DU174 does not include an MCS configuration within the DU configuration, the UE102 and the DU174 can apply the MCS table predefined in the 3GPP (registered trademark) specification 38.214. For example, the predefined MCS table can be a 256QAM table or a 64QAM table, and is shown by the non-low SE 64QAM table shown in Table 5.1.3.1-2 or Table 5.1.3.1-1 of the specification 38.214, respectively. If the DU174 does not include an MCS configuration in the DU configuration, the UE102 and the DU174 can apply the MCS table for unicast transmissions to receive dynamic scheduling multicast transmissions from the DU174. In some embodiments, the DU174 can include in the DU configuration a PDSCH configuration (e.g., PDSCH-Config) that configures the MCS table for unicast transmissions. In other embodiments, the DU174 can transmit to the UE102 other DU configurations that include a PDSCH configuration, similar to events 516, 518, and 520. ● The aggregation coefficient is the number of repetitions of dynamic scheduling multicast transmission(s). DU174 can transmit the number of repetitions of dynamic scheduling multicast transmission according to the aggregation coefficient (i.e., multicast), and UE102 receives the repetitions based on the aggregation coefficient. If DU174 does not include the aggregation coefficient in the DU configuration, UE102 can, in some embodiments, apply the aggregation coefficient for unicast transmission(s). In some embodiments, DU174 can include in the DU configuration the aggregation coefficient for unicast transmission(s) to UE102. In other embodiments, DU174 can transmit other DU configurations that include the aggregation coefficient for unicast transmission to UE102, similar to events 516, 518, and 520.

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

[0095] In some embodiments, the configuration parameters can include at least one semi-persistent scheduling (SPS) multicast configuration for UE102 for receiving MBS data. Each of the at least one SPS multicast configurations can include at least one of the following parameters for SPS multicast transmission. ● Group-Configured Scheduling Radio Network Temporary Identifier (G-CS-RNTI), which is used to activate or release SPS multicast radio resources. DU174 can activate the SPS multicast radio resources for UE102 by generating an SPS multicast radio resource activation command (i.e., DCI), scrambling the CRC of the DCI with the G-CS-RNTI, and transmitting the DCI and the scrambled CRC on the PDCCH. After activating the SPS multicast radio resources, DU174 periodically transmits multicast transmissions on the SPS multicast radio resources according to the DCI. UE102 receives the DCI and the scrambled CRC on the PDCCH and verifies the CRC scrambled with the G-CS-RNTI. After UE102 verifies that the (scrambled) CRC is valid, UE102 activates (receives) the SPS multicast radio resources in response to the DCI and periodically receives multicast transmissions on the SPS multicast radio resources according to the SPS multicast radio resource activation command (i.e., DCI) before UE102 deactivates the SPS multicast radio resources. In this case, the multicast transmission is the SPS multicast transmission used in the following description. In some embodiments, DU174 can deactivate (or release) the SPS multicast radio resources by generating an SPS multicast radio resource deactivation command (i.e., DCI), scrambling the CRC of the DCI with the G-CS-RNTI, and transmitting the DCI and the scrambled CRC on the PDCCH. UE102 receives the DCI and the scrambled CRC on the PDCCH and verifies the CRC scrambled with the G-CS-RNTI. After UE102 verifies that the (scrambled) CRC is valid, UE102 deactivates the SPS multicast radio resources, i.e., stops receiving on the SPS multicast radio resources. Each SPS multicast transmission includes a specific MAC PDU that can include an MBS data packet or a part of an MBS data packet.In some embodiments, the SPS multicast radio resource activation command (i.e., DCI) includes configuration parameters that configure the SPS multicast radio resources. In some embodiments, the configuration parameters can include at least one of the following parameters. ○ Frequency domain resource allocation ○ Time domain resource allocation ○ Mapping from virtual resource block (VRB) to physical resource block (PRB) ○ Modulation and coding scheme (MCS) ○ New data indicator ○ Redundancy version ○ HARQ process number ○ Downlink allocation index ○ PUCCH resource indicator ● Periodicity indicates the periodicity of the SPS multicast radio resources. ● The number of HARQ processes indicates the number of HARQ processes for communicating SPS multicast transmissions. DU174 transmits SPS multicast transmissions using at most the number of HARQ processes, and UE102 receives SPS multicast transmissions using at most the number of HARQ processes. ● The HARQ codebook ID indicates the HARQ ACK codebook index of the HARQ ACK codebook corresponding to the SPS multicast transmission received by UE102 or the SPS multicast radio resource deactivation command. If the configuration parameters do not include the HARQ codebook (ID), UE102 can use the HARQ codebook (ID) for dynamically scheduled multicast transmissions as described above. Alternatively, UE102 can use the HARQ codebook (ID) for unicast transmissions. In some embodiments, as described above, UE102 can receive the HARQ codebook (ID) from DU174 for unicast transmissions in the DU configuration. ● The HARQ process ID offset indicates the offset used when DU174 derives the HARQ process ID for transmitting SPS multicast and when UE102 derives the HARQ process ID for receiving SPS multicast. ● The PUCCH resource configuration for SPS multicast indicates the HARQ resources on the PUCCH on which UE102 transmits HARQ feedback (e.g., HARQ ACK and / or negative ACK (NACK)) for SPS multicast. If the configuration parameters do not include the PUCCH resource configuration for SPS multicast, UE102 and DU174 can communicate HARQ feedback as described above using the PUCCH resource configuration for dynamically scheduled multicast. Alternatively, UE102 can use the PUCCH resource configuration for unicast transmission. In some embodiments, UE102 can use the PUCCH resource configuration for unicast transmission as described above. ● The HARQ NACK-only indication configures UE102 to transmit only HARQ negative ACK (NACK) for SPS multicast transmissions that UE102 receives from DU174 and from which UE102 cannot obtain a transport block. In some embodiments, UE102 cannot obtain a transport block because UE102 fails a cyclic redundancy check (CRC) of the transport block or because UE102 does not receive a dynamically scheduled multicast transmission. In accordance with the indication, UE102 does not send a HARQ ACK to DU174 for SPS multicast transmissions that UE102 receives successfully and from which UE102 obtains a transport block. If the configuration parameters do not include the indication, UE102 can send a HARQ ACK to DU174 for SPS multicast transmissions that UE102 receives successfully and from which UE102 obtains a transport block. ● The HARQ ACK / NACK indication configures the UE102 to send a HARQ NACK for SPS multicast transmissions where the UE102 fails to obtain the transport block, and configures the UE102 to send a HARQ ACK for SPS multicast transmissions where the UE102 receives successfully and obtains the transport block therefrom. If the configuration parameter does not include the indication, the UE102 is not to send a HARQ ACK to the DU174 for SPS multicast transmissions where the UE102 receives successfully and obtains the transport block. In such a case, the UE102 is only permitted to send a HARQ NACK to the DU174 for SPS multicast transmissions where the UE102 fails to obtain the transport block. ● The HARQ ACK indication configures the UE102 to send a HARQ ACK for SPS multicast transmissions where the UE102 receives successfully and obtains the transport block therefrom. If the configuration parameter does not include the indication, the UE102 is not to send a HARQ ACK to the DU174 for SPS multicast transmissions where the UE102 obtains the transport block successfully. In such a case, the UE102 is only permitted to send a HARQ NACK to the DU174 for SPS multicast transmissions where the UE102 fails to obtain the transport block. In some embodiments, the DU174 may include any one of a HARQ NACK indication, a HARQ ACK / NACK indication, and a HARQ ACK indication. ● The aggregation coefficient is the number of repetitions of SPS multicast transmission (multiple allowed). DU174 can transmit (i.e., multicast) the number of repetitions of SPS multicast transmission according to the aggregation coefficient, and UE102 receives the repetitions based on the aggregation coefficient. If DU174 does not include the aggregation coefficient in the DU configuration, UE102 and DU174 can, in some embodiments, apply the aggregation coefficient for dynamic scheduling multicast transmission as described above. Alternatively, UE102 and DU174 can apply the aggregation coefficient for unicast transmission (multiple allowed). In some embodiments, UE102 and DU174 can apply the aggregation coefficient for unicast transmission (multiple allowed) as described above. ● The MCS configuration shows the MCS table used by DU174 to send SPS multicast transmissions and used by UE102 to receive SPS multicast transmissions. For example, the MCS table can be the MCS table defined in 3GPP (registered trademark) specification 38.214 (e.g., the low SE 64QAM table shown in Table 5.1.3.1-3 of 3GPP (registered trademark) TS38.214, or a new table specific to multicast transmissions). In some embodiments, if DU174 does not include the MCS configuration in the DU configuration, UE102 and DU174 can apply the MCS table predefined in 3GPP (registered trademark) specification 38.214. For example, the predefined MCS table can be a 256QAM table or a 64QAM table, e.g., shown by the non-low SE 64QAM tables in Table 5.1.3.1-2 or Table 5.1.3.1-1 of specification 38.214 respectively. If DU174 does not include the MCS configuration in the DU configuration, in other embodiments, UE102 and DU174 can apply the MCS table as described above for dynamic scheduling multicast transmissions to receive SPS multicast transmissions from DU174. Alternatively, UE102 and DU174 can apply the MCS table for unicast transmissions to receive SPS multicast transmissions from DU174. In some embodiments, UE102 and DU174 can apply the MCS table for unicast transmissions as described above to receive SPS multicast transmissions from DU174. In some embodiments, DU174 can include in the DU configuration a PDSCH configuration (e.g., PDSCH-Config) that configures the MCS table for unicast transmissions. In other embodiments, DU174 can send to UE102 other DU configurations including the PDSCH configuration, similar to events 516, 518, and 520.

[0096] In some embodiments, CU-CP 172A may include an MBS session participation response message in the RRC reconfiguration message. UE 102 may include an MBS session participation completion message in the RRC reconfiguration complete message. Alternatively, UE 102 may send a UL RRC message including the MBS session participation completion message to CU-CP 172A via DU 174. The UL RRC message may be a UL Information Transfer message or any suitable RRC message that may include a UL NAS PDU. CU-CP 172A may include the MBS session participation completion message in a message from the second BS to the CN. Alternatively, CU-CP 172A may send a BS-to-CN message (e.g., an UPLINK NAS TRANSPORT message) including the MBS session participation completion message to CN 110.

[0097] In other embodiments, CU-CP 172A sends a DL RRC message including an MBS session participation response message to UE 102. The DL RRC message may be a DL Information Transfer message, another RRC reconfiguration message, or any suitable RRC message that may include a DL NAS PDU. UE 102 may send a UL RRC message including the MBS session participation completion message to CU-CP 172A via 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.

[0098] Events 532, 534, and 536 are collectively referred to as MBS session data transmission procedures 596 in FIG. 5A.

[0099] When CU-CP172A does not receive slice information from CN110, CU-CP172A can include the pre-configured slice information in the message from the first CP to UP for event 560. When CU-CP172A does not receive slice information from CN110, CU-CP172A can include the pre-configured slice information in the message from the first CU to DU for event 506.

[0100] FIG. 5B shows an exemplary scenario 500B similar to scenario 500A shown in FIG. 5A. In scenario 500B, CN110 sends 503 a message from the first CN to the BS (e.g., a Multicast Session Activation Request message) including the first MBS session ID to CU-CP172A to request CU-CP172A to configure or activate resources for the first MBS session (i.e., a multicast (MBS) session). In this scenario, CN110 does not include MBS QoS flow configuration(s) for the first MBS session in the message from the first CN to the BS. Therefore, CU-CP172A generates a second MBS QoS flow configuration(s) based on the pre-configured MBS QoS flow configuration(s). For example, the second MBS QoS flow configuration(s) is the same as the pre-configured MBS QoS flow configuration(s). In other embodiments, the second MBS QoS flow configuration(s) is similar to the pre-configured MBS QoS flow configuration(s).

[0101] In some embodiments, CU-CP 172A may be preconfigured with a preconfigured MBS QoS flow configuration(s) before receiving a message from the first CN to the BS. In other embodiments, CU-CP 172A may receive a preconfigured MBS QoS flow configuration(s) from an operation, administration, and maintenance (OAM) node before receiving a message from the first CN to the BS. The examples or embodiments described for the first MBS QoS flow configuration(s) can be applied to the preconfigured MBS QoS flow configuration(s).

[0102] Events 503, 560, 562, 506, 508, 510, 512, 514, 564, 566, 516, and 518 are collectively referred to as MBS session resource setup procedure 592B in FIG. 5B.

[0103] FIG. 5C shows an exemplary scenario 500C similar to scenarios 500A - 500B shown in FIGS. 5A - 5B respectively. In scenario 500C, CN 110 includes a first MBS QoS flow configuration(s) in the message from the second CN to the BS for event 514. In this case, CN 110 may not include the first MBS QoS flow configuration(s) in the message from the first CN to the BS. After receiving the message from the second CN to the BS, CU-CP 172A transmits 506 the message from the first CU to the UP to CU-UP 172B and transmits 560 the message from the first CU to the DU to DU 174. In other words, CU-CP 172A delays the transmission of the message from the first CP to the UP and the message from the first CU to the DU (e.g., delays the execution of the MC bearer context setup procedure and the multicast context setup procedure) until it receives the first MBS QoS flow configuration(s) or the message from the second CN to the BS.

[0104] Events 503, 512, 514, 560, 562, 506, 508, 510, 564, 566, 516, and 518 are collectively referred to as the MBS session resource set-up procedure 592C in FIG. 5C.

[0105] In some embodiments, CN110 includes first slice information in a message from the second CN to the BS for event 514. In such a case, CN110 may not include the first slice information in a message from the first CN to the BS. In some embodiments, CN110 includes first MBS area information in a message from the second CN to the BS for event 514. In such a case, CN110 may not include the first MBS area information in a message from the first CN to the BS.

[0106] FIG. 5D shows an exemplary scenario 500D similar to scenarios 500A - 500C respectively shown in FIGS. 5A - 5C. In scenario 500D, after CN110 transmits a message from the first CN to the BS at 503, it transmits a fourth CN - to - BS message (e.g., Multicast Session Update Request message) including the first MBS session ID and the first MBS QoS flow configuration(s) to CU - CP172A at 505. After receiving the fourth CN - to - BS message, CU - CP172A transmits a message from the first CU to the UP to CU - UP172B at 506 and a message from the first CU to the DU to DU174 at 560. In other words, CU - CP172A delays the transmission of the message from the first CP to the UP and the message from the first CU to the DU (e.g., delays the execution of the MC bearer context setup procedure and the multicast context setup procedure) until it receives the first MBS QoS flow configuration(s) or the fourth CN - to - BS message. CU - CP172A can transmit a message from the fourth BS to the CN (e.g., Multicast Session Update Response message) to CN110 at 519 in response to the fourth CN - to - BS message.

[0107] In some embodiments, when CU-CP172A receives 503 a message from the first CN to the BS, it transmits 519 a message from the fourth BS to the CN to CN110. In other embodiments, CU-CP172A transmits 518 a message from the second BS to the CN to CN110 before or after receiving 514 a message from the second CN to the BS, before or after receiving 566 a message from the second UP to the CP, or before or after transmitting 516 a message from the second CU to the DU. In some embodiments, CU-CP172A transmits 518 a message from the second BS to the CN to CN110 before receiving 505 a message from the fourth CN to the BS or before transmitting 519 a message from the fourth BS to the CN. In other embodiments, CU-CP172A transmits 518 a message from the second BS to the CN to CN110 after receiving 505 a message from the fourth CN to the BS or after transmitting 519 a message from the fourth BS to the CN.

[0108] In some embodiments, CN110 includes the first slice information in the message from the fourth CN to the BS for event 505. In such a case, CN110 may not include the first slice information in the message from the first CN to the BS. In some embodiments, CN110 includes the first MBS area information in the message from the fourth CN to the BS for event 505. In such a case, CN110 may not include the first MBS area information in the message from the first CN to the BS.

[0109] FIG. 5E shows an exemplary scenario 500E similar to scenarios 500A-500B respectively shown in FIGS. 5A-5B. In scenario 500E, as described with respect to FIG. 5A, except that CU-CP 172A generates a second MBS QoS flow configuration (s) based on the first MBS QoS flow configuration (s), similar to step 592B, CN 110 includes the first MBS QoS flow configuration (s) in the message from the third CN to the BS for event 520, and then CN 110, CU-CP 172A, CU-UP 172B, and DU 174 execute the MBS session resource configuration procedure 592E.

[0110] In some embodiments, CN 110 includes first slice information in the message from the third CN to the BS for event 520. In such a case, CN 110 may not include the first slice information in the message from the first CN to the BS. In some embodiments, CN 110 includes first MBS area information in the message from the third CN to the BS for event 520. In such a case, CN 110 may not include the first MBS area information in the message from the first CN to the BS.

[0111] Next, some exemplary methods that may be implemented by the devices shown in FIGS. 1A and / or 1B are described with reference to FIGS. 6-9B.

[0112] First, FIG. 6 is a flow diagram of an exemplary method 600 for multicast session establishment that may be implemented in CN110 or other suitable CNs. 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 transmits a multicast activation request message to the base station (e.g., event 504). This message includes one or more MBS QoS flow configurations (s). The flow then proceeds to optional block 610, where the CN receives a distributed setup request from the base station (e.g., event 512). At optional block 612, the CN transmits a distributed setup response to the base station (e.g., event 514). Next, at block 614, the CN receives a multicast session activation response in response to the multicast session activation request transmitted to the base station at block 604 (e.g., event 518).

[0113] FIG. 7 is a flow diagram of an exemplary method 700 for multicast session establishment that is similar to method 600, but includes an update request instead of an activation request. 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, in response to the initiation, the CN sends a multicast session activation request to the base station (e.g., event 504). The request can include an MBS session identity. 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 described above, the CN may perform blocks 710 and 712, similar to blocks 610 and 612 respectively. Finally, at block 714, the CN receives a multicast session update response in response to the multicast session update request sent to the base station at block 708 (e.g., event 519).

[0114] FIG. 8A is a flowchart of an exemplary method 800A for establishing a context for a multicast MBS session, where the MBS QoS flow configuration arrives in a multicast session activation request message, which may be implemented at the CU 172 or other suitable RAN node. At block 802, the CU receives from the CN a multicast session activation request message including one or more MBS QoS flow configurations (plural), and requests the configuration or activation of MBS resources for the MBS session (e.g., event 504). At block 804, the CU generates a multicast context setup request message including the MBS QoS flow configuration. The CU includes the MBS QoS flow configuration (plural) generated based on or identical to the MBS QoS flow configuration (plural) received from the CN. At block 806, the CU transmits the multicast context setup request message to a DU such as the 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 setup response message in response to the multicast context setup request message transmitted at block 806 (e.g., event 508). Finally, at block 810, the CU transmits a multicast session activation response message to the CN in response to the multicast session activation request message received at block 802 (e.g., event 518).

[0115] Figure 8B is a flow diagram of an exemplary method 800B that is similar to method 800A, except that the CU retrieves the QoS flow configuration(s) from local memory. At block 801, the CU receives a multicast session activation request message (e.g., 503) that requests the configuration or activation of MBS resources for an MBS session. Unlike the multicast session activation request message of method 800A, here this message does not include one or more MBS QoS flow configuration(s). Instead, at block 805, the CU retrieves one or more MBS QoS flow configuration(s) from local memory, i.e., the CU uses a pre-configured or pre-stored MBS QoS flow configuration. The CU then generates a multicast context setup request message that includes the one or more MBS QoS flow configuration(s). The CU then performs blocks 806, 808, and 810 as described above.

[0116] Figure 8C is a flow diagram of an exemplary method 800C that is similar to method 800A, except that the CU receives a distributed setup response using the MBS QoS flow configuration before the DU sets up the multicast context. At block 801, the CU receives from the CN a multicast session activation request message (e.g., event 503) that requests the CU to configure or activate MBS resources for an MBS session. After receiving the multicast session activation request message at block 812, the CU transmits a distributed setup request message to the CN (e.g., event 512), and at block 814, receives a distributed setup response message (e.g., event 514). The CU then performs blocks 804, 806, 808, and 810 as described above.

[0117] Referring to FIG. 8D, the exemplary method 800D is generally similar to the method 800A, except that one or more MBS QoS flow configurations (s) arrive from the CN in a multicast session update request message. At block 801, the CU receives a multicast session activation request message requesting the configuration or activation of MBS resources for the MBS session (e.g., event 503). At block 803, the CU receives a multicast session update request message from the CN for the MBS session (e.g., event 505). This message includes one or more MBS QoS flow configurations (s). The CU then performs blocks 804, 806, 808, and 810 described above. At block 811, the CU transmits a multicast session update response message to the CN in response to the message received at block 803.

[0118] FIG. 8E is a flow diagram of an exemplary method 800E that is similar to the method 800A, except that the CU receives QoS flow configuration (s) in a message related to a particular UE (e.g., event 520). At block 821, the CU receives a CN-to-CU message from the CN that is associated with a particular UE (not a group of UEs) and that is related to a UE participating in the MBS session. This message includes one or more MBS QoS flow configurations. The CU then performs blocks 801, 804, 806, 808, and 810 described above.

[0119] FIG. 9A is a flowchart of an exemplary method 900A for establishing a context for a multicast MBS session, where a CU (e.g., CU172 or CU-CP172A) determines whether to rely on a pre-stored MBS QoS flow configuration(s) based on whether the CN (e.g., CN110) provided an MBS QoS flow configuration(s) in a message to the CU. At block 902, the CU initiates a request to the 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(s) from the CN. If the CU has received an MBS QoS flow configuration(s) from the CN, the flow proceeds to block 906, where at block 906, the CU includes the received one or more MBS QoS flow configuration(s) in a message from the CU to the DU using an essential information element (IE) (e.g., event 506 in FIGS. 5A, 5C, 5D, and 5E). Otherwise, the flow proceeds from block 904 to block 908, where at block 908, the CU includes a pre-configured or pre-stored MBS QoS flow configuration(s) in a message from the CU to the DU (e.g., event 506 in FIG. 5B). Then, at block 910, the CU transmits a message from the CU to the DU to the DU.

[0120] Finally, FIG. 9B shows an exemplary method 900B, according to which the CU determines whether to exclude an essential information element (IE) from the message from the CU to the DU based on whether the CN provided MBS QoS flow configuration(s) in the message to the CU. After performing blocks 902 and 904 described above, the CU similarly proceeds to block 906 and includes the received one or more MBS QoS flow configuration(s) in the message from the CU to the DU. However, in block 904, if the CU determines that no MBS QoS flow configuration(s) has arrived from the CN, the flow proceeds to block 909, where the CU omits the IE for transmitting the MBS QoS flow configuration(s) from the message from the CU to the DU. In some embodiments, these IEs are defined as essential elements of the message from the CU to the DU. Then, the flow proceeds to block 910, where the CU transmits the message from the CU to the DU to the DU.

[0121] Generally referring to the methods described above, these techniques are similarly applicable to network slice information. For example, messages such as 503, 504, or 560 can include network slice information instead of, or in addition to, one or more QoS MBS flow configuration(s).

[0122] The following additional considerations apply to the above description.

[0123] Generally speaking, the description of one of the above figures is applicable to the other figures of the above figures. The events or blocks described above may be optional or omissible. For example, an event or block having a dashed line in the figure may be optional or omissible. In some cases, an event or block having a solid line in the figure may also be optional, or may be omitted if the event or block is not necessary. In some embodiments, "message" is used and can be replaced with "information element (IE)". In some embodiments, "IE" is used and can be replaced with "field". In some embodiments, "configuration" can be replaced with "a plurality of configurations" or configuration parameters. In some embodiments, "MBS" can be replaced with "multicast" or "broadcast". In some embodiments, "SPS multicast" can be replaced with "multicast SPS". Similarly, "dynamic scheduling multicast" can be replaced with "multicast dynamic". In some embodiments, "identifier" can be replaced with "identity". In some embodiments, "CFR" is used and can be replaced with "MBS BWP". In some embodiments, the term "transport layer configuration" can be replaced with "tunnel information" or "transport layer information".

[0124] A user device (e.g., UE102A, 102B, or UE103) capable of implementing the technology of the present disclosure can be any suitable device capable of wireless communication, such as a smartphone, a tablet computer, a laptop computer, a mobile game console, a point-of-sale (POS) terminal, a health management device, a drone, a camera, a media streaming dongle or other personal media device, a smartwatch, a wireless hotspot, a femtocell, or a wearable device such as a broadband router. Further, the user device may optionally be embedded in an electronic system such as a vehicle head unit or an advanced driver assistance system (ADAS). Still further, the user device can operate as an Internet of Things (IoT) device or a mobile Internet device (MID). Depending on the type, the user device can include one or more general-purpose processors, computer-readable memory, a user interface, one or more network interfaces, one or more sensors, and the like.

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

[0126] When implemented in software, the technology can be provided as part of an operating system, a library used by multiple applications, a particular software application, etc. The software is executable by one or more general-purpose processors or one or more special-purpose processors.

[0127] Upon reading this disclosure, those skilled in the art will understand additional alternative structural and functional designs for performing a HARQ process for transmitting MBS data through the principles disclosed in this disclosure. Thus, while specific embodiments and applications are shown and described, it should be understood that the disclosed embodiments are not limited to the exact configurations and components disclosed herein. Various obvious modifications, changes, and variations can be made to the arrangements, operations, and details of the methods and apparatuses disclosed herein without departing from the spirit and scope of the appended claims.

[0128] The following additional embodiments are explicitly contemplated in the present disclosure.

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

[0130] Example 2. The method according to Example 1, wherein obtaining the network slice information comprises receiving, from a core network (CN), a multicast session activation request including the network slice information.

[0131] Example 3. The method according to Example 1, wherein obtaining the network slice information comprises retrieving the network slice information from a memory of the CU.

[0132] Example 4. The method according to Example 3, wherein retrieving the network slice information from the memory comprises using a mapping between an MBS session identifier and the network slice information.

[0133] Example 5. The method according to Example 3, wherein retrieving the network slice information from the memory of the CU is in response to a determination by one or more processors that the CU has not received the network slice information from the CN.

[0134] Example 6. The method according to Example 1, wherein receiving the network slice information comprises receiving, from the CN, a distributed setup response including the network slice information.

[0135] Example 7. The method according to Example 6, wherein a distributed setup response including network slice information is received before the CU requests the DU to set up a multicast context.

[0136] Example 8. The method according to Example 6 or 7, further comprising receiving a multicast session activation request from the CN and, in response to receiving the multicast session activation request, sending a distributed setup request to the CN, wherein the distributed setup response is in response to the distributed setup request.

[0137] Example 9. The method according to Example 1, wherein obtaining network slice information includes receiving, from the core network (CN), a multicast session update request including network slice information.

[0138] Example 10. The method according to Example 1, wherein obtaining network slice information includes receiving, from the CN, a message associated with a UE configured to participate in a multicast session, the message including network slice information.

[0139] Example 11. The method according to any one of Examples 1 to 10, wherein obtaining network slice information includes obtaining network slice information in the CU control plane (CU-CP) and sending the network slice information from the CU-CP to the CU user plane (CU-UP).

[0140] Example 12. The method according to Example 11, wherein sending the network slice information from the CU-CP to the CU-UP includes sending a bearer context setup request including the network slice information.

[0141] Example 13. The method according to any one of Examples 1 to 12, wherein transmitting network slice information to the DU includes transmitting a multicast context setup request message including the network slice information.

[0142] Example 14. The method according to any one of Examples 1 to 13, wherein transmitting network slice information to the DU includes transmitting in an essential field of a message from the CU to the DU.

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

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

[0145] Example 17. The method according to Example 16, wherein transmitting includes transmitting a multicast session activation request.

[0146] Example 18. The method according to Example 16, wherein transmitting includes transmitting a multicast session update request.

[0147] Example 19. The method according to any one of Examples 16 to 18, further comprising receiving, from the base station, a distributed setup request message and transmitting, to the base station, a distributed setup response message.

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

[0149] Example 21. A method in a central unit (CU) of a distributed base station for multicast session establishment, the method including: obtaining, by one or more processors, a service quality (QoS) flow configuration of one or more multicast and broadcast services (MBS) at a first time during procedures for establishing a context for a multicast session; and transmitting, by 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 following the first time during procedures for establishing a context for the multicast session.

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

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

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

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

[0154] Example 26. The method according to Example 21, wherein receiving one or more MBS QoS flow configurations comprises receiving a distributed setup response from the CN that includes one or more MBS QoS flow configurations.

[0155] Example 27. The method according to Example 26, wherein a distributed setup response including one or more MBS QoS flow configurations is received before the CU requests the DU to set up a multicast context.

[0156] Example 28. The method according to Example 26 or 27, further comprising receiving a multicast session activation request from the CN and, in response to receiving the multicast session activation request, sending a distributed setup request to the CN, wherein the distributed setup response responds to the distributed setup request.

[0157] Example 29. The method according to Example 21, wherein obtaining one or more MBS QoS flow configurations comprises receiving a multicast session update request from the core network (CN) that includes one or more MBS QoS flow configurations.

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

[0159] Example 31. The method according to any one of Examples 21 to 30, wherein obtaining one or more MBS QoS flow configurations comprises obtaining one or more MBS QoS flow configurations in the CU control plane (CU-CP) and sending the one or more MBS QoS flow configurations from the CU-CP to the CU user plane (CU-UP).

[0160] Example 32. The method according to Example 31, wherein transmitting one or more MBS QoS flow configurations from the CU-CP to the CU-UP includes transmitting a bearer context setup request including the one or more MBS QoS flow configurations.

[0161] Example 33. The method according to any one of Examples 21 to 32, wherein transmitting one or more MBS QoS flow configurations to the DU includes transmitting a multicast context setup request message including the one or more MBS QoS flow configurations.

[0162] Example 34. The method according to any one of Examples 21 to 33, wherein transmitting one or more MBS QoS flow configurations to the DU includes transmitting in an essential field of a message from the CU to the DU.

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

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

[0165] Example 37. The method according to Example 36, wherein transmitting includes transmitting a multicast session activation request.

[0166] Example 38. The method according to Example 36, wherein transmitting comprises transmitting a multicast session update request.

[0167] Example 39. The method according to any one of Examples 36 to 38, further comprising receiving a distributed setup request message from a base station and transmitting a distributed setup response message to the base station.

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

Claims

1. A method for establishing a multicast session, implemented in a central unit (CU) of a distributed base station, sending a distributed setup request message to a core network (CN); receiving a distributed setup response message including a first MBS QoS flow configuration from the CN; sending, to a distributed unit (DU) of the distributed base station, a 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; A method comprising the above.

2. The method according to claim 1, further comprising receiving, from the DU, a multicast context setup response in response to the multicast context setup request message.

3. The method according to claim 1 or 2, wherein the first MBS QoS flow configuration includes flow-level QoS parameters.

4. The method according to claim 3, wherein the first MBS QoS flow configuration further includes an MBS QoS flow identifier.

5. Further comprising receiving, from the CN, a message related to configuring resources for the MBS session before sending the distributed setup request message, wherein the sending of the distributed setup request message is in response to the message from the CN. The method according to any one of claims 1 to 4.

6. The method according to any one of claims 1 to 5, wherein the MBS session corresponds to temporary mobile group identification information (TMGI).

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

8. The method according to any one of claims 1 to 7, further comprising sending, to a CU user plane (CU-UP), an MC bearer context modification request message following the reception of the distributed setup response message.

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

10. The method according to any one of claims 1 to 9, wherein the distributed setup response message includes an Internet Protocol (IP) source address.

11. The method according to any one of claims 1 to 10, wherein the distributed setup response message includes an IP multicast address.

12. The method according to any one of claims 1 to 11, wherein the distributed setup response message includes a tunnel endpoint identifier (TEID).

13. The method according to any one of claims 1 to 12, wherein the second MBS QoS flow configuration is the same as the first MBS QoS flow configuration.

14. The method according to any one of claims 1 to 13, 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, comprising one or more processors, and configured to implement the method according to any one of claims 1 to 14.

Images