5G Multicast-Broadcast Service (MBS): Multiplexing, Reliability, and Power Saving

Abstract

This disclosure relates to 5G Multicast-Broadcast Services (MBS): multiplexing, reliability, and power saving. This document describes methods and apparatus for multicast / broadcast MBS services. The embodiments described herein relate to managing multiplexed MBS services, prioritizing MBS-related UL services, unicast UL services, and SL services, handling HARQ retransmissions on C-RNTI, supporting PDCP status reporting for MBS services, and procedures for enabling a Radio Transmit / Receive Unit (WTRU) to join an initiated / active multicast session. In one example, a WTRU may receive multiplexed MBS services via one or more MBS Radio Bearers (MRBs) and / or one or more unicast Data Radio Bearers (DRBs). The WTRU may be configured with a single Service Data Adaptation Protocol (SDAP) entity for these MBS services, and service demultiplexing may be performed at the SDAP layer. The WTRU may be configured to demultiplex multiple logical channels across different MBS services, wherein these logical channels are received on the same transport block.

Description

[0001] This application is a divisional application of the PCT application filed on March 31, 2022, with national application number 202280033749.9 and entitled "5G Multicast-Broadcast Service (MBS): Multiplexing, Reliability and Power Saving", which has entered the Chinese national phase.

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 168,710, filed March 31, 2021, and U.S. Provisional Patent Application No. 63 / 185,726, filed May 7, 2021, the entire contents of which are incorporated herein by reference. Background Technology

[0003] Multicast / broadcast service (MBS) can be provided via New Radio (NR) and is designed to meet a variety of QoS requirements. The delivery of this service to interested UEs is intended to be highly flexible and adaptable. The network can dynamically change how the service is delivered to the UE. However, this flexibility and the anticipated support for changing QoS requirements lead to several issues regarding the effective delivery of this MBS service. The issues experienced with MBS involve how to configure the MBS radio bearers used for service, how to effectively multiplex MBS services, how to improve the reliability of MBS transmissions, and how to handle the initiation of receiving MBS services that have already been received by other UEs. Therefore, improved MBS technology is needed. Summary of the Invention

[0004] The purpose of providing this summary is to introduce selected concepts in a simplified form, which are further described in the following detailed description. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to addressing any or all of the shortcomings pointed out in any part of this disclosure.

[0005] This document describes methods and apparatus for Multicast / Broadcast Services (MBS). The embodiments described herein relate to managing multiplexed MBS services, prioritizing MBS-related UL services, unicast UL services, and SL services, handling HARQ retransmissions on Cell Radio Network Temporary Identifiers (C-RNTIs), supporting PDCP status reporting for MBS services, and procedures for enabling a Radio Transmit / Receive Unit (WTRU) to join an initiated / active multicast session. In one example, a WTRU can receive multiplexed MBS services via one or more MBS Radio Bearers (MRBs) and / or one or more unicast Data Radio Bearers (DRBs). The WTRU can be configured with a single Service Data Adaptation Protocol (SDAP) entity for these MBS services, and service demultiplexing can be performed at the SDAP layer. The SDAP entity can demultiplex multiple MBS Quality of Service (QoS) streams across different MBS services. The WTRU can demultiplex services at the MAC layer. The WTRU can be configured to demultiplex multiple logical channels across different MBS services, wherein these logical channels are received on the same transport block. Attached Figure Description

[0006] The foregoing description of the invention and the following detailed description will be better understood when read in conjunction with the accompanying drawings. Various aspects of this disclosure are shown to illustrate the present disclosure. However, this disclosure is not limited to the specific aspects discussed. In the drawings:

[0007] Figure 1A An embodiment of an exemplary communication system in which the methods and apparatus described and claimed herein may be specifically implemented is shown;

[0008] Figure 1B This is a block diagram of an exemplary apparatus or device (such as, for example, a wireless transmit / receive unit (WTRU)) configured for wireless communication according to the embodiments shown herein;

[0009] Figure 1C It is a system diagram of the RAN and core network according to an implementation plan;

[0010] Figure 1D It is a system diagram of the RAN and core network according to an implementation plan;

[0011] Figure 1E It is a system diagram of the RAN and core network according to an implementation plan;

[0012] Figure 1F It is one of the concrete implementations. Figure 1A , Figure 1C , Figure 1D and Figure 1EA block diagram of an exemplary computing system of one or more devices of the communication network shown;

[0013] Figure 1G An embodiment of an exemplary communication system in which the methods and apparatus described and claimed herein may be specifically implemented is shown;

[0014] Figure 2 An example of MBSFN transmission is shown;

[0015] Figure 3A and Figure 3B An example of MBS service reuse is shown;

[0016] Figure 4 An example of the multiplexing of MBS and unicast services is shown;

[0017] Figure 5 An example of the new MAC header is shown;

[0018] Figure 6 Examples of initial transmissions on Group Radio Network Temporary Identifier (G-RNTI) and HARQ retransmissions on C-RNTI are shown;

[0019] Figure 7 An example of an alternative to the MBS HARQ process is shown;

[0020] Figure 8 An example RLC UM window is shown;

[0021] Figure 9 An example RLC AM window is shown;

[0022] Figure 10 An example of HARQ feedback is shown;

[0023] Figure 11 An example of preempting MBS transmission is shown; and

[0024] Figure 12 An example of HARQ RTT and retransmission timer is shown. Detailed Implementation

[0025] This document describes methods and apparatus for multicast / broadcast services (MBS). For illustrative purposes, the techniques described herein may be described as being performed in a UE or gNB; however, the techniques described herein may be performed by any type of apparatus or device configured to operate and / or communicate in a wireless environment, including but not limited to WTRUs or base stations.

[0026] The following abbreviations and definitions may be used in this article:

[0027] 5QI 5G QoS identifier

[0028] AM Confirmation Mode

[0029] ARQ Automatic Retransmission Request

[0030] BM-SC Broadcast Multicast Service Center

[0031] CRC Cyclic Redundancy Check

[0032] DCI Downlink Control Information

[0033] DL downlink

[0034] DL SCH DL shared channel

[0035] DRB Data Radio Bearer (Unicast)

[0036] DRX Discontinuous Reception

[0037] eMBB Enhanced Mobile Broadband

[0038] eMTC Enhanced Machine Type Communication

[0039] eNB E-UTRAN Node B

[0040] gNB NR node B

[0041] G-RNTI Group RNTI

[0042] GBR Guaranteed Bit Rate

[0043] GW gateway

[0044] HARQ Hybrid ARQ

[0045] IoT (Internet of Things)

[0046] ITS Intelligent Transportation System

[0047] L2 Floor 2

[0048] LTE Long Term Evolution

[0049] MAC Media Access Control

[0050] MBMS Multicast / Broadcast Multimedia Services

[0051] MBS Multicast / Broadcast Service

[0052] MBSFN Multicast Broadcast Single Frequency Network

[0053] MCE Multi-Cell / Multicast Coordination Entity

[0054] MCH Multicast Transport Channel

[0055] mMTC (Mass Machine Type Communication)

[0056] MooD On-Demand MBMS Operations

[0057] MRB MBS Radio Bearer

[0058] MTCH Multicast Service Channel

[0059] NB-IoT Narrowband IoT

[0060] NR New Radio

[0061] PDCP (Packet Data Convergence Protocol)

[0062] PDCCH (Physical Downlink Control Channel)

[0063] PDSCH (Physical Downlink Shared Channel)

[0064] PMCH Physical Multicast Channel

[0065] PTP (Point-to-Point)

[0066] PTM Point-to-Multipoint

[0067] QoS or QOS service quality

[0068] RAN Radio Access Node

[0069] RLC Radio Link Control

[0070] RoHC robust standard head compressor

[0071] ROM Receive-only mode

[0072] RSRP reference signal received power

[0073] SC single cell

[0074] SDAP Service Data Adaptation Protocol

[0075] SL side link

[0076] TB transfer block

[0077] UCI uplink control information

[0078] UE User Equipment

[0079] UM Unconfirmed Mode

[0080] URLLC Ultra-Reliable Low-Latency Communication

[0081] V2X Connectivity of Everything

[0082] The following terms are used in this article:

[0083] Multicast service: A one-way point-to-multipoint service in which data is efficiently transmitted from a single source to a multicast group within the associated multicast service area. Multicast services can only be received by users who have subscribed to a specific multicast service and joined a multicast group associated with that service.

[0084] Broadcast service: A one-way point-to-multipoint service in which data is efficiently transmitted from a single source to multiple UEs in an associated broadcast service area. Broadcast services can be received by all users who have locally enabled a specific broadcast service on their UE and are within the broadcast area defined for that service.

[0085] PTP: A term used in radio access networks to indicate that over-the-air transmission is from a single RAN node to a single UE.

[0086] PTM: A term used in radio access networks to refer to an over-the-air transport from a single RAN node to multiple UEs. PTM transports from multiple cells can be combined to create a multi-cell PTM transport.

[0087] MBS Session: Core network delivery mechanism for MBS services

[0088] Multicast Session: Core network delivery mechanism used for multicast sessions

[0089] Broadcast Session: Core network delivery mechanism used for broadcast sessions

[0090] MBS Radio Bearer: A radio bearer used for MBS services. MBS radio bearers can be segmented bearers with PTP tributaries / paths and PTM tributaries / paths. Alternatively, MBS radio bearers can be non-segmented bearers of the PTM type.

[0091] Split bearer: A type of radio bearer with two branches / paths. In the case of MBS, one of these branches is a PTP branch, and the other is a PTM branch. Split bearers can be anchored at different layers: SDAP, PDCP, RLC, MAC.

[0092] Group RNTI: An RNTI destined for a group of UEs. It can also be called a group common RNTI.

[0093] PTP path or PTP tributary: A tributary of a split bearer in which transport blocks are transmitted to a single UE using C-RNTI.

[0094] PTM path of PTM tributary: a tributary of split bearer in which transport blocks are transmitted to multiple UEs, and all UEs share the same G-RNTI.

[0095] PTP transmission: The gNB delivers a separate copy of the MBS data packets to each UE independently. That is, the gNB uses a UE-specific PDCCH with a CRC scrambled by the UE-specific RNTI (e.g., C-RNTI) to schedule a UE-specific PDSCH scrambled with the same UE-specific RNTI.

[0096] PTM transmission: The gNB delivers a single copy of the MBS data packets to a group of UEs. That is, the gNB uses the group common PDCCH with a CRC scrambled by the group common RNTI to schedule the group common PDSCH scrambled with the same group common RNTI.

[0097] MBS Transport: Transport of MBS services.

[0098] Unicast transmission: The transmission of unicast services.

[0099] MBS group: A group of UEs that receive MBS transmissions and share G-RNTI.

[0100] LTE MBMS Overview and Limitations

[0101] Multicast / Broadcast Multimedia Services (MBMS) are characterized by distributing content of common interest from a source entity to multiple receiving entities interested in the service. Mobile networks are primarily designed for unicast services and are therefore not optimized for multicast / broadcast services. Therefore, providing multicast / broadcast services requires optimizing how communication traffic from these services is transmitted through the core network and the radio access network.

[0102] The 3rd Generation Partnership Project (3GPP) has developed technical standards for cellular telecommunications network technologies, including radio access, core transport networks, and service capabilities, including studies on codecs, security, and quality of service. Recent Radio Access Technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), and LTE Advanced. 3GPP has begun working on the standardization of next-generation cellular technologies known as New Radio (NR) (also called “5G”). The development of the 3GPP NR standard is expected to include the definition of next-generation radio access technologies (new RATs), which are anticipated to include new flexible radio access below 6 GHz and new ultra-mobile broadband radio access above 6 GHz. This flexible radio access is expected to include new non-backward-compatible radio access in the new spectrum below 6 GHz and is expected to include different operating modes that can be multiplexed together in the same spectrum to address a wide range of 3GPP NR use cases with different requirements. Ultra-mobile broadband is expected to include centimeter-wave and millimeter-wave spectrum, which will provide opportunities for ultra-mobile broadband access for applications such as indoor spaces and hotspots. Specifically, ultra-mobile broadband is expected to share a common design framework with flexible radio access below 6 GHz, featuring centimeter-wave and millimeter-wave-specific design optimizations.

[0103] 3GPP has identified a variety of use cases that NR is expected to support, resulting in diverse user experience requirements regarding data rates, latency, and mobility. Use cases include the following general categories: enhanced mobile broadband (e.g., broadband access in dense areas, ultra-high-bandwidth access indoors, broadband access in congested areas, 50+ Mbps everywhere, ultra-low-cost broadband access, mobile broadband in vehicles); critical communications; massive machine-type communications; network operations (e.g., network slicing, routing, migration and interworking, energy saving); and enhanced vehicle-to-everything (eV2X) communications, which may include any of vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-network (V2N), vehicle-to-pedestrian (V2P), and vehicle-to-other entity communications. Specific services and applications within these categories include, for example: surveillance and sensor networks, remote device control, two-way remote control, personal cloud computing, video streaming, cloud-based wireless offices, first responder connectivity, automotive electronic calling, disaster alerts, real-time gaming, multi-person video calling, autonomous driving, augmented reality, haptic internet, and virtual reality, among others. This document considers all of these and other use cases.

[0104] Figure 1AAn embodiment of an exemplary communication system 100 in which the methods and apparatus described and claimed herein may be specifically implemented is shown. As shown, the exemplary communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f and / or 102g (which may generally or commonly be referred to as WTRU 102), radio access networks (RANs) 103 / 104 / 105 / 103b / 104b / 105b, core networks 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and a V2X server (or ProSe function and server) 113. However, it should be understood that any number of WTRUs, base stations, networks and / or network elements are contemplated in the embodiments disclosed herein. Each of WTRUs 102a, 102b, 102c, 102d, 102e, 102f, and 102g can be any type of device or apparatus configured to operate and / or communicate in a wireless environment. Each WTRU of 102a, 102b, 102c, 102d, 102e, 102f, and 102g can be configured to perform any of the methods described herein. Although each WTRU 102a, 102b, 102c, 102d, 102e, 102f, and 102g... Figures 1A to 1E While described as a handheld wireless communication device, it should be understood that each WTRU may include, or be embodied in, any type of apparatus or device configured to transmit and / or receive wireless signals, utilizing a wide variety of use cases envisioned for 5G wireless communication. By way of example only, such apparatus or devices include user equipment (UE), mobile stations, fixed or mobile subscriber units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, tablets, netbooks, notebook computers, personal computers, wireless sensors, consumer electronics devices, wearable devices (such as smartwatches or smart clothing), medical or e-health devices, robots, industrial equipment, drones, vehicles (such as cars, trucks, trains, or airplanes), etc.

[0105] The communication system 100 may also include base stations 114a and 114b. Base station 114a may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, and 102c to facilitate access to one or more communication networks (such as core networks 106 / 107 / 109, the Internet 110, and / or other networks 112). Base station 114b may be any type of device configured to wired and / or wirelessly interface with at least one of RRHs (Remote Radio Headers) 118a and 118b, TRPs (Transmit and Receive Points) 119a and 119b, and / or RSUs (Roadside Units) 120a and 120b to facilitate access to one or more communication networks (such as core networks 106 / 107 / 109, the Internet 110, other networks 112, and / or V2X servers (or ProSe functions and servers) 113). RRH 118a and 118b can be any type of device configured to wirelessly interface with at least one of WTRU 102c to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, Internet 110, and / or other networks 112. TRP 119a and 119b can be any type of device configured to wirelessly interface with at least one of WTRU 102d to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, Internet 110, and / or other networks 112. RSU 120a and 120b can be any type of device configured to wirelessly interface with at least one of WTRU 102e or 102f to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, Internet 110, other networks 112, and / or V2X server (or ProSe function and server) 113. By way of example, base stations 114a and 114b can be transceiver base stations (BTS), Node B, evolved Node B, home Node B, home evolved Node B, site controller, access point (AP), wireless router, etc. Although base stations 114a and 114b are each depicted as a single element, it should be understood that base stations 114a and 114b can include any number of interconnected base stations and / or network elements.

[0106] Base station 114a may be part of RAN 103 / 104 / 105, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114b may be part of RAN 103b / 104b / 105b, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a may be configured to transmit and / or receive radio signals within a specific geographical area, which may be referred to as a cell (not shown). Base station 114b may be configured to transmit and / or receive wired and / or radio signals within a specific geographical area, which may be referred to as a cell (not shown). The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, for example, one transceiver per sector of the cell. In one implementation, base station 114a may employ multiple-input multiple-output (MIMO) technology, thus enabling the use of multiple transceivers for each sector of the cell.

[0107] Base station 114a can communicate with one or more of WTRUs 102a, 102b, and 102c via air interfaces 115 / 116 / 117, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Any suitable radio access technology (RAT) can be used to establish air interfaces 115 / 116 / 117.

[0108] Base station 114b can communicate with one or more of RRH 118a, 118b, TRP 119a, 119b and / or RSU 120a and 120b via wired or air interfaces 115b / 116b / 117b. These wired or air interfaces can be any suitable wired communication link (e.g., cable, fiber optic, etc.) or wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Any suitable radio access technology (RAT) can be used to establish air interfaces 115b / 116b / 117b.

[0109] RRH 118a, 118b, TRP 119a, 119b and / or RSU 120a, 120b can communicate with one or more of WTRU 102c, 102d, 102e, 102f via air interface 115c / 116c / 117c, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 115c / 116c / 117c.

[0110] WTRUs 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g can communicate with each other via air interface 115d / 116d / 117d (not shown in the attached figures), which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 115d / 116d / 117d.

[0111] More specifically, as noted above, the communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base station 114a in RAN 103 / 104 / 105 and WTRU 102a, 102b, 102c or RRH 118a, 118b, TRP 119a, 119b and RSU 120a, 120b and WTRU 102c, 102d, 102e, 102f in RAN 103b / 104b / 105b can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can use Wideband CDMA (WCDMA) to establish air interfaces 115 / 116 / 117 or 115c / 116c / 117c respectively. WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink Packet Access (HSDPA) and / or High-Speed ​​Uplink Packet Access (HSUPA).

[0112] In one implementation, base station 114a and WTRUs 102a, 102b, 102c or RRH 118a, 118b in RAN 103b / 104b / 105b, TRP 119a, 119b and / or RSU 120a, 120b, and WTRUs 102c, 102d can implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can use Long Term Evolution (LTE) and / or LTE Advanced (LTE-A) to establish air interfaces 115 / 116 / 117 or 115c / 116c / 117c respectively. In the future, air interfaces 115 / 116 / 117 can implement 3GPP NR technology. LTE and LTE-A technologies include LTE D2D and V2X technologies and interfaces (such as sidelink communication). 3GPP NR technology includes NR V2X technologies and interfaces (such as sidelink communication).

[0113] In one implementation, base station 114a in RAN 103 / 104 / 105 and WTRU 102a, 102b, 102c or RRH 118a, 118b, TRP 119a, 119b and / or RSU 120a, 120b, and WTRU 102c, 102d, 102e, 102f in RAN 103b / 104b / 105b can implement radio technologies such as IEEE 802.16 (e.g., Global Microwave Access Interoperability (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), GSMEDGE (GERAN), etc.

[0114] Figure 1ABase station 114c can be, for example, a wireless router, a home node B, a home evolution node B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial locations, homes, vehicles, campuses, etc. In one embodiment, base station 114c and WTRU 102e can implement radio technologies (such as IEEE 802.11) to establish a wireless local area network (WLAN). In one embodiment, base station 114c and WTRU 102d can implement radio technologies (such as IEEE 802.15) to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114c and WTRU 102e can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b may have a direct connection to the Internet 110. Therefore, base station 114c may not need to access the Internet 110 via core networks 106 / 107 / 109.

[0115] RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b can communicate with core network 106 / 107 / 109, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU 102a, 102b, 102c, and 102d. For example, core network 106 / 107 / 109 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication.

[0116] although Figure 1A As not shown, but it should be understood that RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b and / or core network 106 / 107 / 109 can communicate directly or indirectly with other RANs that use the same RAT as or a different RAT than RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b. For example, in addition to being connected to RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b, which may be utilizing E-UTRA radio technology, core network 106 / 107 / 109 can also communicate with another RAN (not shown) using GSM radio technology.

[0117] Core networks 106 / 107 / 109 may also act as gateways for WTRUs 102a, 102b, 102c, 102d, 102e to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another core network connected to one or more RANs, which may use the same RAT as RAN103 / 104 / 105 and / or RAN 103b / 104b / 105b or a different RAT.

[0118] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multi-mode capabilities. For example, WTRUs 102a, 102b, 102c, 102d, and 102e may include multiple transceivers for communicating with different wireless networks via different wireless links. Figure 1A The WTRU 102e shown can be configured to communicate with a base station 114a that can employ cellular-based radio technology and with a base station 114c that can employ IEEE 802 radio technology.

[0119] Figure 1B This is a block diagram of an exemplary device or apparatus (such as, for example, WTRU 102) configured for wireless communication according to the embodiments shown herein. Figure 1B As shown, the exemplary WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and other peripheral devices 138. It should be understood that, while remaining consistent with the implementation, the WTRU 102 may include any sub-combination of the foregoing elements. Additionally, the implementation envisions that base stations 114a and 114b and / or the nodes that base stations 114a and 114b may represent (such as, but not limited to, transceiver stations (BTS), node B, site controllers, access points (APs), home node B, evolved home node B (Evolved Node B), Home Evolved Node B (HeNB), Home Evolved Node B gateway, and proxy nodes, etc.) may be included in... Figure 1B Some or all of the elements depicted in and described herein.

[0120] Processor 118 can be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 can be coupled to transceiver 120, which can be coupled to transmitting / receiving element 122. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it should be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0121] Transmitting / receiving element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via air interface 115 / 116 / 117. For example, in one embodiment, transmitting / receiving element 122 can be an antenna configured to transmit and / or receive RF signals. In one embodiment, transmitting / receiving element 122 can be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, transmitting / receiving element 122 can be configured to transmit and receive both RF signals and optical signals. It should be understood that transmitting / receiving element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0122] Furthermore, although the transmitting / receiving element 122 is in Figure 1B While depicted as a single element, WTRU 102 may include any number of transmitting / receiving elements 122. More specifically, WTRU 102 may employ MIMO technology. Therefore, in one embodiment, WTRU 102 may include two or more transmitting / receiving elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interfaces 115 / 116 / 117.

[0123] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As noted above, WTRU 102 may have multi-mode capability. For example, transceiver 120 may therefore include multiple transceivers to enable WTRU 102 to communicate via various RATs such as UTRA and IEEE 802.11.

[0124] The processor 118 of WTRU 102 can be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad / indicator 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit), and can receive user input data from the aforementioned components. The processor 118 can also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicator 128. Furthermore, the processor 118 can access information from any type of suitable memory (such as non-removable memory 130 and / or removable memory 132), and store data in any type of suitable memory. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a Subscriber Identity Module (SIM) card, a Memory Stick, a Secure Digital (SD) memory card, etc. In one implementation, processor 118 can access memory information that is never physically located on WTRU 102 (such as on a server or home computer (not shown)) and store the data in that memory.

[0125] The processor 118 may receive power from the power supply 134 and may be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 may be any suitable device for powering the WTRU 102. For example, the power supply 134 may include one or more dry cell batteries, solar cells, fuel cells, etc.

[0126] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to, or instead of, information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interfaces 115 / 116 / 117 and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that, while remaining consistent with the implementation, the WTRU 102 may acquire location information using any suitable location determination method.

[0127] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral device 138 may include various sensors such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, digital cameras (for photos or videos), Universal Serial Bus (USB) ports or other interconnect interfaces, vibration devices, television transceivers, hands-free headsets, etc. Modules, FM radio units, digital music players, media players, video game player modules, internet browsers, and so on.

[0128] WTRU 102 can be implemented in other devices or equipment, such as sensors, consumer electronics, wearable devices (such as smartwatches or smart clothing), medical or e-health devices, robots, industrial equipment, drones, or vehicles (such as cars, trucks, trains, or airplanes). WTRU 102 can be connected to other components, modules, or systems of such devices or equipment via one or more interconnect interfaces (such as interconnect interfaces that may include one of the peripheral devices 138).

[0129] Figure 1C This is a system diagram of RAN 103 and core network 106 according to one implementation scheme. As described above, RAN 103 can communicate with WTRUs 102a, 102b, and 102c via air interface 115 using UTRA radio technology. RAN 103 can also communicate with core network 106. Figure 1C As shown, RAN 103 may include nodes B 140a, 140b, and 140c, each of which may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 115. Nodes B 140a, 140b, and 140c may each be associated with a specific cell (not shown) within RAN 103. RAN 103 may also include RNCs 142a and 142b. It should be understood that RAN 103 may include any number of nodes B and RNCs while remaining consistent with the implementation scheme.

[0130] like Figure 1CAs shown, nodes B 140a and 140b can communicate with RNC 142a. Additionally, node B 140c can communicate with RNC 142b. Nodes B 140a, 140b, and 140c can communicate with their respective RNCs 142a and 142b via the Iub interface. RNCs 142a and 142b can communicate with each other via the Iur interface. Each of RNCs 142a and 142b can be configured to control its connected corresponding node B 140a, 140b, or 140c. Furthermore, each of RNCs 142a and 142b can be configured to perform or support other functionalities such as outer-loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, etc.

[0131] Figure 1C The core network 106 shown may include a Media Gateway (MGW) 144, a Mobile Switching Center (MSC) 146, a Serving GPRS Support Node (SGSN) 148, and / or a Gateway GPRS Support Node (GGSN) 150. While each of the foregoing elements is depicted as part of the core network 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0132] RNC 142a in RAN 103 can be connected to MSC 146 in core network 106 via IuCS interface. MSC 146 can be connected to MGW 144. MSC 146 and MGW 144 can provide WTRU 102a, 102b, and 102c with access to circuit-switched networks (such as PSTN 108) to facilitate communication between WTRU 102a, 102b, and 102c and traditional landline communication equipment.

[0133] RNC 142a in RAN 103 can also be connected to SGSN 148 in core network 106 via IuPS interface. SGSN 148 can be connected to GGSN 150. SGSN 148 and GGSN 150 can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices.

[0134] As described above, core network 106 can also be connected to network 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0135] Figure 1DThis is a system diagram of RAN 104 and core network 107 according to one implementation scheme. As noted above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with core network 107.

[0136] RAN 104 may include evolved Nodes B 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of evolved Nodes B while remaining consistent with the implementation scheme. Each evolved Node B 160a, 160b, and 160c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one implementation, evolved Nodes B 160a, 160b, and 160c may implement MIMO technology. Therefore, evolved Node B 160a may, for example, use multiple antennas to transmit radio signals to and receive radio signals from WTRU 102a.

[0137] Each of the evolved Nodes B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in the uplink and / or downlink, etc. Figure 1D As shown, evolution nodes B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0138] Figure 1D The core network 107 shown may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. Although each of the foregoing elements is depicted as part of the core network 107, it should be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0139] The MME 162 can connect to each of the evolved nodes B 160a, 160b, and 160c in RAN 104 via the S1 interface and can be used as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can also provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM or WCDMA.

[0140] Serving Gateway 164 can connect to each of the evolved Nodes B 160a, 160b, and 160c in RAN 104 via the S1 interface. Serving Gateway 164 can typically route and forward user data packets to / from WTRUs 102a, 102b, and 102c. Serving Gateway 164 can also perform other functions, such as anchoring the user plane during handover between evolved Nodes B, triggering paging when downlink data is available to WTRUs 102a, 102b, and 102c, managing and storing the context of WTRUs 102a, 102b, and 102c, etc.

[0141] Service gateway 164 can also be connected to PDN gateway 166, which can provide WTRU 102a, 102b, 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0142] Core network 107 can facilitate communication with other networks. For example, core network 107 can provide WTRUs 102a, 102b, and 102c with access to circuit-switched networks (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and traditional landline communication equipment. For example, core network 107 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between core network 107 and PSTN 108, or can communicate with such an IP gateway. Furthermore, core network 107 can provide WTRUs 102a, 102b, and 102c with access to network 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0143] Figure 1E This is a system diagram of RAN 105 and core network 109 according to the implementation plan. RAN 105 may be an Access Service Network (ASN) that communicates with WTRUs 102a, 102b, and 102c via air interface 117 using IEEE 802.16 radio technology. As will be discussed further below, the different functional entities of WTRUs 102a, 102b, and 102c, and the communication links between RAN 105 and core network 109 can be defined as reference points.

[0144] like Figure 1EAs shown, RAN 105 may include base stations 180a, 180b, 180c and ASN gateway 182; however, it should be understood that RAN 105 may include any number of base stations and ASN gateways while remaining consistent with the implementation scheme. Base stations 180a, 180b, and 180c may each be associated with a specific cell in RAN 105 and may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 117. In one implementation, base stations 180a, 180b, and 180c may implement MIMO technology. Therefore, base station 180a may, for example, use multiple antennas to transmit radio signals to and receive radio signals from WTRU 102a. Base stations 180a, 180b, and 180c may also provide mobility management functions such as handover triggering, tunnel establishment, radio resource management, traffic classification, Quality of Service (QoS) policy enforcement, etc. ASN Gateway 182 can be used as a service aggregation point and can be responsible for paging, caching subscriber profiles, routing to the core network 109, etc.

[0145] The air interface 117 between WTRUs 102a, 102b, and 102c and RAN 105 can be defined as an R1 reference point implementing the IEEE 802.16 specification. Furthermore, each of WTRUs 102a, 102b, and 102c can establish a logical interface (not shown) with the core network 109. The logical interface between WTRUs 102a, 102b, and 102c and the core network 109 can be defined as an R2 reference point, which can be used for authentication, authorization, IP host configuration management, and / or mobility management.

[0146] The communication link between each of base stations 180a, 180b, and 180c can be defined as an R8 reference point, which includes protocols for facilitating WTRU handover and data transmission between the base stations. The communication link between base stations 180a, 180b, and 180c and ASN gateway 182 can be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of WTRUs 102a, 102b, and 102c.

[0147] like Figure 1EAs shown, RAN 105 can be connected to core network 109. The communication link between RAN 105 and core network 109 can be defined as an R3 reference point, which includes, for example, protocols for facilitating data transfer and mobility management capabilities. Core network 109 may include a Mobile IP Home Agent (MIP-HA) 184, an Authentication, Authorization, and Accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements is depicted as part of core network 109, it should be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0148] MIP-HA manages IP addresses and enables WTRUs 102a, 102b, and 102c to roam between different ASNs and / or different core networks. MIP-HA 184 provides WTRUs 102a, 102b, and 102c with access to packet-switched networks (such as the Internet 110), facilitating communication between WTRUs 102a, 102b, and 102c and IP-enabled devices. AAA server 186 handles user authentication and user support services. Gateway 188 facilitates interoperability with other networks. For example, gateway 188 provides WTRUs 102a, 102b, and 102c with access to circuit-switched networks (such as PSTN 108), facilitating communication between WTRUs 102a, 102b, and 102c and traditional landline communication equipment. In addition, gateway 188 can provide WTRU 102a, 102b, 102c with access to network 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0149] Despite Figure 1E Although not shown, it should be understood that RAN 105 can connect to other ASNs, and core network 109 can connect to other core networks. The communication link between RAN 105 and other ASNs can be defined as an R4 reference point, which may include protocols for coordinating the mobility of WTRUs 102a, 102b, and 102c between RAN 105 and other ASNs. The communication link between core network 109 and other core networks can be defined as an R5 reference point, which may include protocols for facilitating interoperability between the home core network and the visited core network.

[0150] Described in this article and Figure 1A , Figure 1C , Figure 1D and Figure 1EThe core network entities shown are identified by the names given to those entities in certain existing 3GPP specifications; however, it should be understood that those entities and functions may be identified by other names in the future, and certain entities or functions may be combined in future specifications published by 3GPP (including future 3GPP NR specifications). Therefore, Figure 1A , Figure 1B , Figure 1C , Figure 1D and Figure 1E The specific network entities and functions described and illustrated herein are provided by way of example only, and it should be understood that the subject matter disclosed and claimed herein may be specifically implemented or practiced in any similar communication system, whether currently defined or to be defined in the future.

[0151] Figure 1F It can be implemented in practice. Figure 1A , Figure 1C , Figure 1D and Figure 1E The diagram illustrates an exemplary computing system 90 of one or more devices in a communication network (such as certain nodes or functional entities in RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, or other networks 112). The computing system 90 may include a computer or server and may be controlled primarily by computer-readable instructions, which may be in the form of software, regardless of where or by what means such software is stored or accessed. These computer-readable instructions may be executed within a processor 91 to enable the computing system 90 to function. The processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 91 may perform signal encoding, data processing, power control, input / output processing, and / or any other functionality that enables the computing system 90 to function within the communication network. Coprocessor 81 is an optional processor, distinct from main processor 91, that can perform additional functions or assist processor 91. Processor 91 and / or coprocessor 81 can receive, generate, and process data relating to the methods and apparatus disclosed herein.

[0152] In operation, processor 91 fetches instructions, decodes and executes them, and transfers information to and from other resources via the main data transfer path (system bus 80) of the computing system. This system bus connects components within the computing system 90 and defines the medium for data exchange. System bus 80 typically includes data lines for transmitting data, address lines for transmitting addresses, and control lines for transmitting interrupts and operating the system bus. An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus.

[0153] The memory coupled to the system bus 80 includes random access memory (RAM) 82 and read-only memory (ROM) 93. This type of memory includes circuitry that allows information to be stored and retrieved. ROM 93 typically contains stored data that cannot be easily modified. Data stored in RAM 82 can be read or changed by the processor 91 or other hardware devices. Access to RAM 82 and / or ROM 93 can be controlled by the memory controller 92. The memory controller 92 provides address translation functionality, converting virtual addresses to physical addresses as instructions are executed. The memory controller 92 also provides memory protection functionality that isolates processes within the system and separates system processes from user processes. Therefore, a program running in first mode can only access memory mapped through its own process virtual address space; it cannot access memory in another process's virtual address space unless inter-process memory sharing is configured.

[0154] In addition, the computing system 90 may include a peripheral device controller 83 responsible for passing instructions from the processor 91 to peripheral devices such as printer 94, keyboard 84, mouse 95 and disk drive 85.

[0155] A display 86, controlled by a display controller 96, is used to display visual output generated by a computing system 90. This visual output may include text, graphics, animated graphics, and video. The visual output can be provided in the form of a graphical user interface (GUI). The display 86 can be implemented using a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touchpad. The display controller 96 includes the electronic components required to generate the video signals sent to the display 86.

[0156] Additionally, the computing system 90 may include communication circuitry, such as a network adapter 97, which can be used to connect the computing system 90 to an external communication network, such as... Figure 1A , Figure 1B , Figure 1C , Figure 1D and Figure 1EThe RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, or other network 112 are configured to enable the computing system 90 to communicate with other nodes or functional entities in those networks. Communication circuitry, either separately or in conjunction with the processor 91, can be used to perform the transmit and receive steps of certain means, nodes, or functional entities described herein.

[0157] Figure 1G An embodiment of an exemplary communication system 111 in which the methods and apparatus described and claimed herein may be specifically implemented is shown. As shown, the exemplary communication system 111 may include wireless transmit / receive units (WTRUs) A, B, C, D, E, F, a base station, a V2X server, and RSUs A and B; however, it should be understood that the embodiments disclosed herein contemplate any number of WTRUs, base stations, networks, and / or network elements. One or more or all WTRUs A, B, C, D, E may be outside the network's range (e.g., outside the cell coverage boundary as shown by the dashed line in the figure). WTRUs A, B, C form a V2X group, with WTRU A as the group leader and WTRUs B and C as group members. WTRUs A, B, C, D, E, F may communicate via a Uu interface or a sidelink (PC5) interface.

[0158] It should be understood that any or all of the apparatuses, systems, methods, and processes described herein can be embodied in the form of computer-executable instructions (e.g., program code) stored on a computer-readable storage medium, which, when executed by a processor (such as processor 118 or 91), cause the processor to perform and / or implement the systems, methods, and processes described herein. Specifically, any of the steps, operations, or functions described herein can be implemented in the form of such computer-executable instructions that execute on a processor of an apparatus or computing system configured for wireless and / or wired network communication. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented using any non-transitory (e.g., tangible or physical) method or technology for storing information, but such computer-readable storage media do not include signals. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical disc storage devices, magnetic tape cassettes, magnetic tape, disk storage devices or other magnetic storage devices, or any other tangible or physical medium that can be used to store desired information and is accessible by a computing system.

[0159] Support for MBMS on LTE networks has evolved considerably across various LTE versions. Table 1 provides an overview of the major changes / enhancements across versions. Further details are provided below.

[0160]

[0161] Table 1: Evolution of MBMS in LTE

[0162] Since version 9, LTE networks have supported MBMS through a mechanism called MBSFN (Multicast Broadcast Single Frequency Network). MBMS is provided on a carrier shared with unicast services. MBSFN requires a new logical entity in the core network and relies on the simultaneous transmission of the same MBMS service from one or more eNBs.

[0163] Figure 2 An example of an LTE architecture 200 for MBSFN transmission is shown. Logical entities may include BM-SC 201, MBMS GW 202, MCE 203, and MME 204. Furthermore, each of the eNBs 205 shown in the figure participates in MBSFN transmission. This transmission may originate from, for example, a content provider 206. Transmissions from these eNBs 205 define an MBSFN area, encompassing the region from which the UE can receive MBSFN transmissions from multiple eNBs 205. These transmissions are conducted via a multicast transport channel (MCH) that can be mapped to a physical channel (e.g., a physical multicast channel (PMCH)). Transmission of the PMCH in reserved subframes is permitted. For example, the eNB may have reserved subframes for MBSFN transmission purposes. These subframes can be used to carry MBMS control plane information (e.g., multicast control channel (MCCH)) and MBS user plane traffic (e.g., multicast communication traffic channel (MTCH)). Based on system information, the UE can determine: the subframes reserved for MBMS and which of these subframes carry the MCCH, as well as the configuration for the PMCH. The latter allows the UE to decode services received on the PMCH in the reserved subframes. The UE can read the MCCH to obtain scheduling information for MBMS user plane services. For example, the UE can determine which subframes in the reserved subframes contain streams from specific multicast / broadcast streams. The UE can use this scheduling information to determine the multicast / broadcast streams of interest and receive / decode MBMS services. The UE can monitor the MCCH to determine if there are any changes in MBMS service provision.

[0164] MBSFN operation can be used for both RRC_CONNECTED and RRC_IDLE UEs. During MBSFN operation, a single transport block can be transmitted in each reserved subframe, and the single transport can be used for the MCH (neither blind HARQ repeat nor RLC fast repeat). Additionally, during MBSFN operation, the MTCH and MCCH can use RLC-UM mode (the configuration of RLC-UM mode is fixed and known to the UE).

[0165] Version 10 introduces RAN-based counting for UEs in connected mode interested in MBMS services. This version also allows the RAN to use any unused MBSFN subframes for unicast transmission. Finally, this version enhances admission control for MBMS sessions by introducing allocation and reservation priority session parameters.

[0166] Version 11 introduces service acquisition and service continuity in multi-frequency deployments that provide MBMS services via more than one frequency. The initial version of eMBMS assumed that MBMS characteristics did not affect mobility procedures in E-UTRA. Therefore, some UEs receiving or interested in MBMS services could not receive them due to cell reselection in RRC_IDLE or handover in RRC_CONNECTED. To address this, the network can provide auxiliary information to inform UEs about the mapping between carrier frequencies and MBMS services, as well as the transmission timing of MBMS services. By using auxiliary information, when a UE is interested in a specific MBMS service, a UE in RRC_IDLE can autonomously set the carrier frequency carrying the MBMS service to the highest cell reselection priority during the scheduling time. Therefore, it is likely that the UE will reselect to a cell on the carrier frequency carrying the MBMS service. Also in Version 11, for UEs in RRC_CONNECTED, the UE can notify the serving cell of the carrier frequency to which the interested MBMS service is scheduled to be transmitted. For this purpose, the RRC layer introduces a new uplink message called the MBMSInterestIndication message. The intention is that the eNB will use this information to select the target cell for handover.

[0167] Version 12 introduces one of the major enhancements, MooD (On-Demand MBMS Operation), which enables automatic and seamless activation and deactivation of MBMS services based on the UE's service consumption report.

[0168] The main enhancement is the introduction of single-cell point-to-multipoint in version 13. SC-PTM uses the same new logical entities (BM-SC, MBMS-GW) in the core network, but does not rely on simultaneous transmissions from multiple eNBs (as in the case of MBSFN). Instead, each eNB schedules its own MBMS transmissions independently. These transmissions are carried over the Downlink Shared Channel (DL-SCH) and on the Physical Downlink Shared Channel (PDSCH). Therefore, unicast traffic and MBMS traffic are multiplexed on the DL-SCH, enabling more flexible and dynamic radio resource allocation for MBMS transmissions. Furthermore, since scheduling is not left to the MCE for synchronization between eNBs, reduced end-to-end latency is expected. For SC-PTM, MBMS are transmitted within the coverage area of ​​a single cell. SC-PTM transmissions carry both the Control Channel (SC-MCCH) and the Communication Traffic Channel (SC-MTCH). The SC-MCCH and SC-MTCH transmit logical channel-specific RNTI indications, each on its own Physical Downlink Control Channel (PDCCH). Specifically, there is the SC-RNTI for SC-MCCH and the G-RNTI for SC-MTCH. Note that there is a one-to-one mapping between each MBMS session supported in the cell and the G-RNTI used to receive the DL-SCH to which the SC-MTCH is mapped. Even when SC-PTM is scheduled like unicast communication traffic, it does not rely on any UL feedback, and therefore SC-PTM does not support link adaptation or HARQ operation. During the 3GPP work project phase, there was some discussion about utilizing unicast UL feedback to allow advanced link adaptation schemes, such as adaptive modulation and coding for groups with a small number of UEs. However, this feature was not ultimately standardized in Release 13. Additionally, MBMS transmissions can be configured using an MBMS-specific DRX mode so that the UE does not need to continuously monitor the SC-PTM RNTI. This mode follows a simple on / off period, where the DRX activity time is extended when the UE receives SC-PTM communication traffic. This MBMS-specific DRX mode is independent of the UE-specific DRX mode.

[0169] SC-PTM services can be received by both RRC_CONNECTED and RRC_IDLE UEs. During SC-PTM operation, a single transmission can be used for DL-SCH (neither blind HARQ repeat nor RLC fast repeat). SC-MTCH and SC-MCCH can use RLC-UM mode (the configuration of which is fixed and known to the UE).

[0170] Version 14 introduces MBSFN and SC-PTM for V2X (Vehicle-to-the-World) communication, SC-PTM for the Internet of Things (IoT), eMTC (Enhanced Machine-Type Communication), and NB-IoT (Narrowband IoT). Version 14 also introduces numerous features to enhance the delivery of TV services utilizing eMBMS, extend the reach of MBMS to traditional TV receivers, and enable the deployment of dedicated broadcast eMBMS networks that support public broadcast requirements. The service provided can be distributed in such a way that it can be received by all users, including those who are not mobile subscribers. This is also known as Receive-Only Mode (ROM) or free-to-watch.

[0171] Version 16 focuses on enhancements to terrestrial broadcasting (particularly the new frame structure and new cyclic prefix) to find solutions that allow EN-TV to meet the 5G broadcasting requirements of "terrestrial broadcasting".

[0172] This document describes the NR MBS requirements, use cases, and work project objectives. 3GPP RAN has considered various use cases that will benefit from 5G MBS support. Use cases can be categorized into four main types:

[0173] Media and entertainment: For example, multiple users may be interested in receiving shared virtual reality or augmented reality content.

[0174] Public Warnings: Warnings can be sent to users using multimedia messages. These messages include a description of the warning type and multimedia data providing instructions, suggestions, and additional information (e.g., pictures of missing children, maps of their last known locations, instructions on what to do, etc.). This service is inherently "ad-hoc" because users may not necessarily subscribe to it.

[0175] Automotive: Various V2X applications require information to be delivered to vehicles from Intelligent Transportation System (ITS) infrastructure, such as ITS roadside units and sensors. Examples include: road safety, signage, maps, and autonomous driving.

[0176] IoT: In many cases, firmware updates or new configurations can be sent to a large number of devices. The devices themselves may have the capability to reduce [the impact of these limitations].

[0177] These use cases have quite different requirements in terms of bit rate, latency, user density, and reliability, but will each benefit from PTM transport formats in the RAN. Based on these use cases, 3GPP has identified several requirements related to 5G MBS. Within the scope of Release 17, 3GPP RAN focuses on a range of high-level requirements anticipated from 5G MBS. These may include:

[0178] Bit rate: can be very high;

[0179] Latency: Can be very low;

[0180] Reliability: Must support use cases with extremely high reliability;

[0181] Density: It should be able to handle extremely dense deployments;

[0182] Mobility: It should be able to handle highly mobile UEs;

[0183] Flexibility: Operators should be able to dynamically change the size of the capacity and service area reserved for MBS;

[0184] Efficiency: Operators should be able to dynamically change how services are provided to UEs (multicast, broadcast, unicast, PTP, PTM) and allow UEs to receive multiple concurrent services (one or more unicast services plus one or more MBS services).

[0185] Therefore, the 3GPP RAN group has started a new work project[3] that addresses some of the limitations of MBMS operation on LTE and attempts to meet the requirements listed above.

[0186] This work project has two main objectives:

[0187] Specify the basic RAN functions for broadcast / multicast for UEs in the RRC_CONNECTED state, including:

[0188] Specify group scheduling mechanisms to allow UEs to receive broadcast / multicast services (and also specify the necessary enhancements required to achieve simultaneous operation with unicast reception);

[0189] Specify dynamic changes for a given UE to support broadcast / multicast service delivery between multicast (PTM) and unicast (PTP) with service continuity;

[0190] Specify support for basic mobility with service continuity;

[0191] Required changes to improve the reliability of broadcast / multicast services can be specified through methods such as UL feedback. The reliability level should be based on the requirements of the application / service being provided.

[0192] The study investigates support for dynamic control of broadcast / multicast transmission zones within a gNB-DU and specifies what is required to enable it (if any).

[0193] Specify the basic RAN functions [RAN2,RAN1] for broadcast / multicast for UEs in the RRC_IDLE / RRC_INACTIVE state:

[0194] To maintain the greatest commonality in PTM reception configuration between the RRC_CONNECTED state and the RRC_IDLE / RRC_INACTIVE state, specify the necessary changes to enable the UE in the RRC_IDLE / RRC_INACTIVE state to receive point-to-multipoint transmissions.

[0195] Note that the work item does not include any objectives related to FR2 operation, SFN operation, dynamic resource allocation to MBS up to 100%, or receive-only mode operation. Nevertheless, it is generally required that any design decisions made should not prevent the introduction of such features or operations in future releases.

[0196] This article describes NR MBS operation. As part of the development of NR MBS, the 3GPP working group has made several agreements regarding this operation. Several of these agreements are listed below:

[0197] The initial RAN focus can be deployed independently on the NR;

[0198] For multicast services, the network supports PTP and PTM transport of shared services delivered by 5GC, at least for connection mode (this is not intended to exclude other cases);

[0199] For the UE, the gNB dynamically determines whether to deliver multicast data via PTM or PTP;

[0200] RAN can support two delivery modes:

[0201] Delivery mode 1 is used for high QoS (reliability, latency) requirements and is available under RRC_CONNECTED (the UE may switch to other states if no data reception TBD exists). It is primarily used for multicast sessions.

[0202] Delivery mode 2 is used for "low" QoS requirements, where the UE can also receive data under RRC_CONNECTED, RRC_IDLE, and RRC_INACTIVE modes. It is primarily used for broadcast sessions, but may also be used for multicast sessions.

[0203] The RAN should be provided with information on the MBS services / groups subscribed to by the UE (e.g., TMGI) and the QoS requirements for the MBS services;

[0204] Supported SDAP functionality: Mapping from QoS flows to MBS RBs;

[0205] Supported PDCP functionalities: RoHC (at least U mode); reordering and in-order delivery in PDCP; data transfer; maintenance of PDCP SN; duplicate discarding; status reporting (for lossless handover).

[0206] Supported RLC functionalities: RLC-AM for PTP transmission; RLC UM for PTP transmission; RLC UM for PTM transmission in NR MBS.

[0207] For cases where both the source and target cells support MBS, lossless handover is supported.

[0208] To support lossless handover of 5G MBS services, the network side should ensure at least DL PDCP SN synchronization and continuity between the source cell and the target cell.

[0209] From the network side, the source gNB can forward data to the destination gNB, and the destination gNB can deliver the forwarded data.

[0210] MRB can include both PTP tributaries and PTM tributaries;

[0211] In the case of split bearer, both PTP and PTM tributaries are RLC-UM, supporting configurations for PTM-PTP handover without L2ARQ and with PDCP anchoring (e.g., for services that would typically be configured with RLC UM for unicast).

[0212] For RRC_IDLE UEs / RRC_INACTIVE UEs using NR MBS delivery mode 2, the MBS configuration (for broadcast / delivery mode 2) is provided via the two-step approach (i.e., BCCH and MCCH) employed by LTE SC-PTM. It is assumed that this can also be used for RRC_CONNECTED UEs.

[0213] Suppose that the MCCH change notification mechanism is used to notify of changes in the MCCH configuration due to the start of a session in delivery mode 2 of NR MBS (or FFS in other cases).

[0214] Assume that MBS interest indication is supported for UEs in connected mode used for broadcast services.

[0215] RAN defines three transmission schemes:

[0216] PTP transmission: For RRC_CONNECTED UEs, UE-specific PDSCH scrambled with the same UE-specific RNTI is scheduled using UE-specific PDCCH with a CRC scrambled by UE-specific RNTI (e.g., C-RNTI).

[0217] PTM Transmission Scheme 1: For RRC_CONNECTED UEs in the same MBS group, a group common PDCCH with a CRC scrambled by the group common RNTI is used to schedule a group common PDSCH scrambled with the same group common RNTI. This scheme can also be called a group scheduling scheme based on the group common PDCCH.

[0218] PTM Transmission Scheme 2: For RRC_CONNECTED UEs in the same MBS group, a group common PDSCH scrambled with a group common RNTI is scheduled using a UE-specific PDCCH with a CRC scrambled by a UE-specific RNTI (e.g., C-RNTI). This scheme can also be referred to as a group scheduling scheme based on a UE-specific PDCCH.

[0219] For the delivery of MBS TB, PTM transmission scheme 1 is supported for the initial transmission; other schemes are still under discussion.

[0220] For retransmissions, when PTM transmission scheme 1 is used in the initial transmission, both PTM transmission scheme 1 and PTP transmission are supported (when HARQ based on ACK / NACK is supported); PTM transmission scheme 2 is still under discussion.

[0221] For RRC_CONNECTED UEs, HARQ-ACK feedback is supported for multicast.

[0222] For RRC_CONNECTED UEs that receive multicast, the following items are supported:

[0223] For HARQ-ACK feedback based on ACK / NACK for multicast:

[0224] The network configures orthogonal PUCCH resources among UEs in the same group.

[0225] If the initial transmission used for multicast is based on PTM transmission scheme 1, retransmission using PTP transmission is supported. The HARQ process ID and NDI indicated in the DCI are used to associate PTM scheme 1 with PTP transmissions of the same TB.

[0226] FFS: HARQ-ACK feedback based solely on NACK for multicast:

[0227] PUCCH resources are configured by the network and can be shared among UEs within the same group.

[0228] Supports enabling / disabling HARQ-ACK feedback for MBS.

[0229] The priority of HARQ-ACK feedback used for receiving multicast RRC_CONNECTED UEs can be lower, higher, or equal to that used for unicast HARQ-ACK feedback.

[0230] Based on the progress of NR MBS development, many unresolved issues have been identified. The first unresolved issue involves the mapping of UEs to G-RNTIs. G-RNTI represents the RNTI used for UE groups. MBS transport blocks are transmitted using G-RNTIs. However, it remains unclear which UEs are in this group. Various options have been discussed, including:

[0231] A 1:1 mapping between MBS service and G-RNTI. All UEs interested in the service listen to G-RNTI;

[0232] The N:1 mapping between MBS services and G-RNTIs involves multiplexing a group of N services on a single transport block transmitted on a single G-RNTI.

[0233] G-RNTI is geographic region-specific. All services provided within a geographic region are multiplexed on a single G-RNTI.

[0234] The second unresolved issue concerns how to achieve reliability. Some MBS services require high reliability, but how to achieve this reliability remains unresolved. Various options have been discussed: maintaining all services requiring high reliability on the PTP tributary or unicast DRB, layer 2 retransmission at the PDCP layer, layer 2 retransmission at the RLC layer, and layer 1 HARQ retransmission with ACK / NACK feedback.

[0235] The third unresolved issue involves the multiple ways in which a network can provide the same multicast service. Multicast services can be provided on DRBs or MRBs, which can be segmented or non-segmented bearers, and services can be replicated on more than one MRB.

[0236] Based on the decisions made regarding these unresolved issues, many problems need to be addressed. The list of problems is divided into two broad areas: reuse issues and reliability issues.

[0237] This article describes the reuse problem.

[0238] Question 1: The process for reusing MBS services:

[0239] The gNB can be permitted to multiplex MBS services from multiple MBS services on a single transport block. Therefore, the UE can receive transport blocks with MBS services from logical channels that are not of interest to the UE. A procedure needs to be defined to allow the UE to process the reception of multiplexed transport blocks. This requires consideration of multiplexing at both the SDAP and MAC layers, as well as optimization of HARQ feedback signaling.

[0240] Furthermore, the gNB can be permitted to multiplex unicast and multicast services on a single transport block. Unicast services can be destined for one of the UEs receiving a transport block transmitted on the G-RNTI. This document defines the procedures that allow a UE to process the reception of this multiplexed transport block.

[0241] Question 2: The process of logical channel prioritization at the UE:

[0242] A UE receiving MBS services may need to send MBS-related uplink transmissions (e.g., status reports, HARQ feedback, measurement results) to support the MBS service. Furthermore, this UE can communicate simultaneously via both the Uu and SL interfaces. The UE's action when MBS-related uplink transmissions overlap with Uu or SL transmissions is not defined. When the UE cannot send these transmissions simultaneously, a priority rule is required to select one transmission over the other.

[0243] This article describes the reliability issue.

[0244] Question 3: The HARQ retransmission process used on C-RNTI:

[0245] A UE can receive the initial transmission of a transport block on the G-RNTI and receive retransmissions on the C-RNTI. In such cases, the UE needs a mechanism to associate the transport block received on the C-RNTI with the same HARQ process that handled the reception on the G-RNTI (this is to allow the UE to perform soft combination). Secondly, the UE needs to determine the rules for monitoring the C-RNTI for HARQ retransmissions. Finally, a process for resolving potential HARQ process conflicts needs to be defined. These conflicts occur when the UE is receiving a transport block retransmitted on the C-RNTI but the network begins to transmit a new transport block on the G-RNTI using the same HARQ process. Consider the case where the gNB decides to send some MBS service retransmissions on the C-RNTI. Assume the gNB will use the same HARQ process ID for the C-RNTI transmission as the one used for the initial G-RNTI transmission (allowing the UE to soft combine the two transmissions). However, the gNB continues to process MBS data and may eventually transmit a new TB on the G-RNTI using the original HARQ process. In this situation, the UE can receive the retransmission of TB1 on C-RNTI to HARQ process K and the new transmission of TB2 on G-RNTI to HARQ process K.

[0246] Question 4: The process for sending PDCP status reports:

[0247] PDCP status reports are used to ensure lossless handover for services with high reliability requirements. The same mechanism can also be used for MBS services requiring high reliability to ensure lossless PTM-PTP handover and lossless MRB reconfiguration. However, a new trigger for sending PDCP status reports needs to be defined to achieve lossless PTM-PTP handover and lossless MRB reconfiguration. Secondly, the transmission of PDCP status reports requires an uplink path from the UE to the gNB. This uplink path is not always available for MBS services. In such cases, a solution capable of transmitting PDCP status reports is needed.

[0248] Question 5: The procedure for enabling a UE to join an already started / active multicast session:

[0249] When a UE begins receiving services from an MBS service, that service may already be active and sending MBS services to other UEs. An active service consists of one or more MRBs, each with its own PDCP, RLC, and HARQ states and context. The UE is unaware of this context, leading to synchronization issues. For example, the RLC UM reassembly window of a UE MRB may not be synchronized with the RLC UM transmission of this MRB. This could cause the UE to drop certain MBS services. Therefore, a UE procedure needs to be defined for when a UE joins an already active MBS session.

[0250] Question 6: The process used by the UE during the transition from multicast active to multicast inactive:

[0251] Multicast sessions can be in ACTIVE or INACTIVE state. In INACTIVE state, no MBS data services are sent to the UE, and the UE can transition to RRC IDLE or RRC INACTIVE mode. This document defines the UE actions when transitioning a multicast service to INACTIVE, assuming multiple MBS services are multiplexed on a single G-RNTI.

[0252] Question 7: The procedure for reliable transmission when MBS is preempted:

[0253] To support URLLC, the gNB can preempt eMBB and MBS transmissions. When this preemption occurs, a portion of the received transport block may be corrupted. If this preemption occurs for a multicast transport block that requires HARQ feedback, many multicast UEs will send NACKs to the gNB. This is inefficient for the uplink.

[0254] This article describes the power saving problem.

[0255] Question 8: DRX granularity for NR MBS:

[0256] In LTE, to save power, the UE can be configured with a DRX for receiving SC-PTM. The UE only monitors the G-RNTI and SC-RNTI for SC-PTM during the active period of the configured DRX. The DRX is configured based on the SC-MTCH. Since LTE SC-PTM does not support multiplexing MBMS services on the G-RNTI, the DRX configuration is actually based on the G-RNTI. For NRMBS, it is likely that multiple MBS services will be multiplexed on a single G-RNTI, and therefore, the granularity of the DRX for NR MBS needs to be defined.

[0257] Question 9: DRX configuration for NR MBS

[0258] Because LTE SC-PTM does not support HARQ feedback for MBMS, DRX configuration is based on: DRX loop, DRX start offset, on-duration timer, and inactivity timer. However, since NR MBS allows HARQ feedback and HARQ retransmissions, DRX configuration will need to take these retransmissions into account.

[0259] Question 10: UE DRX process

[0260] The UE DRX procedure for Uu links used in NR unicast transmission assumes: 1) HARQ feedback is sent from the UE to the gNB; 2) transport blocks only include logical channels configured for the receiving UE. In NR MBS, these two assumptions do not hold. First, HARQ feedback can be enabled / disabled, and furthermore, the HARQ retransmission mode can vary. RAN1 has defined three modes: PTM scheme 1, PTM scheme 2, and PTP scheme. Second, transport blocks received by the UE may contain logical channels that are not of interest to the UE. These factors need to be considered in the MBSDRX procedure.

[0261] The MBS service provided on NR is designed to meet a variety of QoS requirements. The way this service is delivered to interested UEs is designed to be highly flexible and adaptable. The network can dynamically change how services are delivered to UEs.

[0262] However, this flexibility and the anticipated support for changing QoS requirements raise several questions regarding the effective transmission of this MBS service. These questions involve how to configure the MBS radio bearers used for the service, how to effectively multiplex MBS services, how to improve the reliability of MBS transmissions, and how to handle the initiation of receiving MBS services that have already been received by other UEs.

[0263] This disclosure attempts to address these problems by proposing the following:

[0264] The process used to manage reused MBS services;

[0265] The process used for prioritizing MBS-related UL services, unicast UL services, and SL services;

[0266] Used to handle HARQ retransmissions on C-RNTI;

[0267] The process used to support PDCP status reporting for MBS services;

[0268] The procedure used to enable a UE to join an already started / activated multicast session;

[0269] Used to handle the process of multicast transitioning from active to inactive;

[0270] The process used to handle MBS service preemption;

[0271] The process of DRX operation for a UE used to receive MBS services.

[0272] This article describes the process for reusing MBS services.

[0273] This document describes the following implementation scheme:

[0274] Implementation Scheme 1: A first device configured to receive multiplexed MBS services via one or more MBS radio bearers (MRBs) and / or one or more unicast data radio bearers (DRBs).

[0275] Implementation Scheme 2: The first device according to Implementation Scheme 1, wherein the UE is configured with a single SDAP entity for these MBS services, and service multiplexing is performed at the SDAP layer. Multiple MBS QoS flows across different MBS services are multiplexed on the same MRB.

[0276] Implementation Scheme 3: The first device according to Implementation Scheme 1, wherein service multiplexing is performed at the MAC layer. Multiple logical channels across different MBS services are multiplexed on the same transport block.

[0277] Implementation Scheme 4: The first device according to Implementation Scheme 3, wherein the Logical Channel ID (LCID) of all multiplexed logical channels is unique, and the UE is configured with a list of LCIDs associated with the MBS service of interest. During disassembly of transport blocks, the disassembly and demultiplexing entity discards logical channels not on this list.

[0278] Implementation Scheme 5: The first device according to Implementation Scheme 3, wherein the logical channel ID (LCID) of all multiplexed logical channels is not guaranteed to be unique, and wherein the MAC PDU includes an identifier for each multiplexed MAC SDU to allow the UE to determine whether the SDU is for a logical channel corresponding to the MBS service of interest. When disassembling transport blocks, the disassembler and demultiplexer entity uses this header to determine whether the MAC SDU is for the MBS service of interest. MAC SDUs that do not correspond to the MBS service of interest are discarded.

[0279] Implementation Scheme 6: The first device according to Implementation Scheme 5, wherein the identifier is an MBS service ID (such as TMGI or session ID or an alternative ID identifying the MBS service), and wherein a list of MBS service IDs of the MBS services of interest to the UE is provided.

[0280] Implementation Scheme 7: The first device according to Implementation Scheme 3, wherein the logical channel ID (LCID) of all multiplexed logical channels is not guaranteed to be unique, and wherein the DCI of the scheduled transport block contains a bit field for indicating which MBS services are multiplexed in the transport block.

[0281] Implementation Scheme 8: The first device according to Implementation Scheme 7, wherein the PHY layer is provided with MBS services of interest. If the DCI indicates that the transport block does not contain any MBS services of interest, the UE does not decode the transport block.

[0282] Implementation Scheme 9: The first device according to Implementation Scheme 7, wherein the PHY layer provides a transport block and bit fields to the HARQ entity. If the bit fields indicate that the transport block does not contain any MBS services of interest, the HARQ entity decides to discard the transport block.

[0283] Implementation Scheme 10: The first device according to Implementation Scheme 9, wherein if the UE discards the transport block, the UE may send as HARQ feedback: ACK, DTX, or Don't Care (optional).

[0284] This article describes the process of logical channel prioritization at the UE.

[0285] Implementation Scheme 11: According to the first device of Implementation Scheme 1, when MBS-related UL transmissions overlap with unicast UL transmissions or sidelink transmissions and the UE cannot transmit simultaneously, the device determines which service to prioritize.

[0286] Implementation Scheme 12: The first device according to Implementation Scheme 11, wherein the transmission priority is always fixed.

[0287] Implementation Scheme 13: The first device according to Implementation Scheme 12, wherein MBS-related uplink transmissions are always de-prioritized relative to sidelink transmissions or unicast uplink transmissions.

[0288] Implementation Scheme 14: The first device according to Implementation Scheme 12, wherein uplink transmissions associated with MBS are always prioritized relative to sidelink transmissions or unicast uplink transmissions.

[0289] Implementation Scheme 15: The first device according to Implementation Scheme 11, wherein uplink services related to MBS are assigned a certain priority value.

[0290] Implementation Scheme 16: The first device according to Implementation Scheme 15, wherein the priority value of the uplink service associated with MBS is equal to the priority value of the multiplexed MBS transport block.

[0291] Implementation Scheme 17: The first device according to Implementation Scheme 16, wherein the priority value of the multiplexed MBS transport block is set to the priority value of the highest priority logical channel multiplexed in the transport block.

[0292] Implementation Scheme 18: The first device according to Implementation Scheme 16, wherein the priority value of the multiplexed MBS transport block is set as a weighted average of the priority values ​​of the logical channels multiplexed in the transport block.

[0293] Implementation Scheme 19: The first device according to Implementation Scheme 11, wherein the transmission priority is based on the relative priority of MBS-related uplink transmissions and sidelink transmissions or unicast uplink transmissions. The UE transmits the service with the highest priority (e.g., the service with the lowest priority value).

[0294] Implementation Scheme 20: The first device according to Implementation Scheme 11, wherein the transmission priority is based on the priority of MBS-related uplink transmissions compared to a threshold (MBSPriorityThreshold). If the priority value of an MBS-related uplink transmission is lower than the threshold, the MBS-related uplink transmission is prioritized. If the priority value of an MBS-related uplink transmission is higher than the threshold, the MBS-related uplink transmission is de-prioritized.

[0295] Implementation Scheme 21: According to the first device described in Implementation Scheme 11, the transmission priority is based on the relative priority of different services and thresholds (MBSPriorityThreshold, ULPriorityThreshold, SLPriorityThreshold) associated with each service. If the priority value of an uplink transmission is lower than ULPriorityThreshold, then the uplink transmission is prioritized. If the priority value of an uplink transmission is higher than ULPriorityThreshold, then the UE prioritizes services with lower priority values.

[0296] Implementation Scheme 22: According to the first device described in Implementation Scheme 11, the uplink transmissions related to MBS include: RRC message, MAC CE, PDCP status report, PDCP control PDU, RLC status report, RLC control PDU, and HARQ feedback.

[0297] Implementation Scheme 23: The first device according to Implementation Scheme 18, wherein the UE has a fixed priority among different MBS-related uplink transmissions.

[0298] This article describes the process of HARQ retransmission on C-RNTI.

[0299] Implementation Scheme 24: A first device, the first device:

[0300] Receive configurations for one or more sets of HARQ processes: a DL HARQ process set for unicast transmission, an MBS HARQ process set for MBS transmission, a broadcast HARQ process set for BCCH transmission, and an SL HARQ process set for SL transmission.

[0301] Receive the DCI of the PDSCH scheduled for MBS transmission;

[0302] C-RNTI for MBS retransmission monitoring;

[0303] The transport block is decoded to determine the HARQ process that will handle it, and the transport block is forwarded to the determined HARQ process.

[0304] Implementation Scheme 25: The first device according to Implementation Scheme 24, wherein the UE is configured to receive an initial MBS transmission on the G-RNTI and an MBS retransmission on the C-RNTI, and wherein the initial transmission and the retransmission are both used for the same MBS HARQ process.

[0305] Implementation Scheme 26: The first device according to Implementation Scheme 24, wherein the DCI includes one or more of the following: HARQ process ID, G-RNTI / C-RNTI indicator, NDI, MBS HARQ process indicator, MBS indicator.

[0306] Implementation Scheme 27: The first device according to Implementation Scheme 24, wherein the first device monitors C-RNTI for MBS retransmission only during the period of expected MBS activity.

[0307] Implementation Scheme 28: The first device according to Implementation Scheme 24, wherein if the first device has already sent a NACK for the transport block, the first device only monitors C-RNTI for MBS retransmission.

[0308] Implementation Scheme 29: The first device according to Implementation Scheme 24, wherein the first device monitors C-RNTI for MBS retransmission only during the period when MBS activity is expected and the first device has sent a NACK for the transport block.

[0309] Implementation Scheme 30: The first device according to Implementation Scheme 24, wherein if the first device is in RRC_Idle or RRC_Inactive, the UE monitors MBS retransmission C-RNTI during the period when MBS activity is expected and the first device has sent a NACK for the transport block.

[0310] Implementation scheme 31: The first device according to implementation schemes 27, 28, 29 and 30, wherein MBS activity is expected during the DRX activity period of MBS service.

[0311] Implementation Scheme 32: The first device according to Implementation Scheme 24, wherein the determination of the HARQ process for processing the transport block is based on one or more of the following: the presence or absence of the MBS HARQ process indicator, the MBS indicator, and the G-RNTI / C-RNTI indicator.

[0312] Implementation Scheme 33: According to the first device described in Implementation Scheme 24, the first device detects a HARQ process conflict—the UE can receive transport block A (retransmission) on C-RNTI and transport block B (new transmission) on G-RNTI. These two transport blocks are designated to be handled by the same MBS HARQ process.

[0313] Implementation Scheme 34: The first device according to Implementation Scheme 33, the first device only considers the transport blocks received on C-RNTI and discards the transport blocks received on G-RNTI.

[0314] Implementation Scheme 35: According to the first device described in Implementation Scheme 33, the first device only considers the transport blocks received on G-RNTI, refreshes the HARQ process, and treats G-RNTI as a new transport.

[0315] This article describes the procedure for enabling a UE to join an already started / active multicast session.

[0316] Implementation Scheme 36: A first device that joins an already active multicast session, and the first device:

[0317] Receives an MRB configuration that includes a PTM tributary with RLC-UM;

[0318] Determine the initial values ​​of RX_Next_Reassembly and RX_Next_Highest;

[0319] Receive UMD PDU.

[0320] Implementation Scheme 37: The first device according to Implementation Scheme 36, wherein the determination of RX_Next_Reassembly and RX_Next_Highest is based on information included in the received configuration.

[0321] Implementation Scheme 38: The first device according to Implementation Scheme 36, wherein the determination of RX_Next_Reassembly and RX_Next_Highest is based on the value of the SN of the first received UMD PDU.

[0322] Implementation Scheme 39: The first device according to Implementation Scheme 36, wherein the determination of RX_Next_Reassembly and RX_Next_Highest is based on values ​​provided by the gNB using the control PDU.

[0323] Implementation Scheme 40: The first device according to Implementation Scheme 36, wherein the determination of RX_Next_Reassembly and RX_Next_Highest is based on information carried in the header of the received UMD PDU.

[0324] Implementation Scheme 41: A first device that joins an already active multicast session, and the first device:

[0325] Receives a configuration of MRB including a PTM tributary with RLC-AM;

[0326] Determine the initial value of RX_Next;

[0327] Receives AMD PDU.

[0328] Implementation Scheme 42: The first device according to Implementation Scheme 41, wherein the determination of RX_Next is based on information included in the received configuration.

[0329] Implementation Scheme 43: The first device according to Implementation Scheme 41, wherein the determination of RX_Next is based on the value of the SN of the first received AMD PDU.

[0330] Implementation Scheme 44: The first device according to Implementation Scheme 41, wherein the determination of RX_Next is based on a value provided by the gNB using the control PDU.

[0331] Implementation Scheme 45: The first device according to Implementation Scheme 41, wherein the determination of RX_Next is based on information carried in the header of the received AMD PDU.

[0332] Implementation Scheme 46: A first device that joins an already active multicast session, and the first device:

[0333] Receive configurations that require MRBs to be delivered in sequence;

[0334] Determine the initial values ​​of RX_NEXT and RX_DELIV;

[0335] Receive PDCP PDU.

[0336] Implementation Scheme 47: The first device according to Implementation Scheme 46, wherein the determination of RX_NEXT and RX_DELIV is based on information included in the received configuration.

[0337] Implementation Scheme 48: The first device according to Implementation Scheme 46, wherein the determination of RX_NEXT and RX_DELIV is based on the COUNT value of the first received PDCP PDU.

[0338] Implementation Scheme 49: The first device according to Implementation Scheme 46, wherein the determination of RX_NEXT and RX_DELIV is based on values ​​provided by the gNB using the control PDU.

[0339] Implementation Scheme 50: The first device according to Implementation Scheme 46, wherein the determination of RX_NEXT and RX_DELIV is based on information carried in the header of the received PDCP PDU.

[0340] Implementation Scheme 51: A first device that joins an already active multicast session, and the first device:

[0341] Receive MRB with HARQ feedback enabled;

[0342] Receive transmission block;

[0343] Determine whether to issue HARQ feedback.

[0344] Implementation Scheme 52: The first device according to Implementation Scheme 51, wherein the determination is based on whether the initial transmission received for the HARQ process is a new transmission or a retransmission.

[0345] Implementation scheme 53: The first device according to implementation scheme 51, wherein the determination is based on whether the transport block has been ACKed, up to a maximum number of times.

[0346] Implementation Scheme 54: According to the first device of Implementation Scheme 1, the first device is triggered to send a PDCP status report based on one or more of the following triggers: the device detects a lost MBS PDU, MBS radio bearer reconfiguration, PTM-PTP handover, and PTP-PTM handover.

[0347] Implementation Scheme 55: The first device according to Implementation Scheme 54, wherein the PDCP status report is sent by one or more of the following methods: RRC signaling, NAS signaling, RACH, via link radio bearer, on the PTP tributary of the MRB.

[0348] The process used to handle multicast transitions from active / inactive to inactive / active:

[0349] Implementation Scheme 56: A first device that has joined a multicast session, and the first device:

[0350] Receive an indication that the first multicast session is transitioning from active to inactive or vice versa.

[0351] Determine whether the G-RNTI carrying the first multicast session carries the second active multicast session, and

[0352] Based on this, and based on this instruction, control the behavior of PDCP, RLC, and MAC DRX.

[0353] Implementation Scheme 57: The first device according to Implementation Scheme 56, wherein the indication is received in one of an RRC message, a MAC CE, or a PHY DCI.

[0354] Implementation Scheme 58: The first device according to Implementation Scheme 57, wherein the indication in the PHY DCI is a bitmap, wherein a "1" in bit "k" indicates that the MBS session with index "k" is changing from active / inactive to inactive / active.

[0355] Implementation Scheme 59: According to the first device of Implementation Scheme 56, if the indication indicates a transition from multicast activity to inactivity, and the determination indicates that the UE is receiving a second active multicast session, then the UE may further:

[0356] Stop using DRX for MBS sessions.

[0357] RLC entity reconstruction is performed on the radio bearers of inactive MBS sessions, and

[0358] Suspend the PDCP physical radio bearer for inactive MBS sessions.

[0359] Implementation Scheme 60: According to the first device of Implementation Scheme 56, if the indication indicates a transition from multicast activity to inactivity, and the determination indicates that the UE is not receiving a second active multicast session, then the UE may further:

[0360] Stop monitoring G-RNTI and stop processing transport blocks received on G-RNTI.

[0361] Discontinue the use of DRX for G-RNTI.

[0362] Perform RLC entity reconstruction for radio bearers of inactive MBS sessions.

[0363] Suspend the PDCP physical radio bearer for inactive MBS sessions, and

[0364] Clear the HARQ processes associated with G-RNTI (e.g., those HARQ processes that are recovering transport blocks destined for G-RNTI).

[0365] Implementation Scheme 61: According to the first device of Implementation Scheme 56, wherein if the indication indicates a transition from multicast inactivity to activity, and the determination indicates that the UE is receiving a second active multicast session, then the UE may further:

[0366] Start using DRX for MBS sessions, and

[0367] Restore the PDCP physical radio bearer for inactive MBS sessions.

[0368] Implementation Scheme 62: According to the first device of Implementation Scheme 56, if the indication indicates a transition from multicast inactivity to activity, and the determination indicates that the UE is not receiving a second active multicast session, then the UE may further:

[0369] Start monitoring G-RNTI. Follow the DRX configuration used for this G-RNTI, if DRX configuration is configured, and

[0370] Restore the PDCP physical radio bearer for inactive MBS sessions.

[0371] The process used to handle MBS service preemption:

[0372] Implementation Scheme 63: A first device that has joined a multicast session, and the first device:

[0373] Receive MBS transport blocks,

[0374] Receive preemption instruction RNTI, and

[0375] Determine whether to send HARQ feedback for the preempted MBS transport block.

[0376] Implementation Scheme 64: The first device according to Implementation Scheme 63, wherein the determination is based on whether the MBS transmission is a new transmission or a retransmission.

[0377] Implementation scheme 64a: The first device according to implementation scheme 63, wherein the determination is based on an indication in the DCI that schedules MBS transmissions.

[0378] The process of DRX operation for a UE used to receive MBS services:

[0379] Implementation Scheme 65: A first device that has joined an MBS session, and the first device:

[0380] Receive one or more DRX configurations for MBS transmission, including: one (G-RNTI) for each MBS group and one (SC-RNTI) for each MCCH.

[0381] The event time is determined based on the DRX configuration, and

[0382] Monitor RNTIs from the following sources during the activity period: G-RNTI, SC-RNTI, C-RNTI, INT-RNTI

[0383] Implementation Scheme 66: The first device according to Implementation Scheme 65, wherein the DRX configuration includes one or more of the following parameters: drxMBS-onDurationTimer, drxMBS-SlotOffset, drxMBS-InactivityTimer, drxMBS-RetransmissionTimerDL, drxMBS-LongCycleStartOffset, drxMBS-ShortCycle, drxMBS-ShortCycleTimer, drxMBS-HARQ-RTT-TimerDL.

[0384] Implementation Scheme 67: The first device according to Implementation Scheme 65, wherein the DRX activity time includes the time during which the following timers are running: drxMBS-onDurationTimer, drxMBS-InactivityTimer, and drxMBSRetransmissionTimerDL.

[0385] Implementation Scheme 68: According to the first device of Implementation Scheme 66, if the transport block does not contain any MTCH channel for the MBS session of interest to the UE, the UE may stop the inactive timer for PTM scheme 1MBS transmission to G-RNTI.

[0386] Implementation Scheme 69: The first device according to Implementation Scheme 66, wherein the UE determines the RNTI to be monitored while the retransmission timer is running.

[0387] Implementation Scheme 70: The first device according to Implementation Scheme 69, wherein the UE always monitors both C-RNTI and G-RNTI.

[0388] Implementation Scheme 71: The first device according to Implementation Scheme 69, wherein the UE is determined based on a configuration from the network.

[0389] Implementation Scheme 72: The first device according to Implementation Scheme 69, wherein the UE determines the retransmission based on an indication carried in the initial transmission indicating how the gNB will send the retransmission.

[0390] Implementation Scheme 73: The first device according to Implementation Scheme 66, wherein the UE determines whether to start a retransmission timer when the UE fails to decode the transmission block.

[0391] Implementation Scheme 74: The first device according to Implementation Scheme 73, wherein the determination is based on an indication from the gNB that this is the last retransmission of the transport block and the UE should not start the retransmission timer.

[0392] The terms "tribute" and "path" are used interchangeably in this document. The terms "PTP tributary" and "PTP path" are used interchangeably in this document. The terms "PTM tributary" and "PTM path" are used interchangeably in this document. The terms "multicast service" and "multicast session" are used interchangeably in this document. The terms "MBS service" and "MBS session" are used interchangeably in this document. The terms "multicast session" and "MBS session" are used interchangeably in this document.

[0393] MBS service retransmissions can be sent via, for example, one of three mechanisms:

[0394] PTP retransmission scheme: The retransmitted transport block can use a UE-specific PDCCH with a CRC scrambled by a UE-specific RNTI (e.g., C-RNTI), which is scheduled to use a UE-specific PDSCH scrambled with the same UE-specific RNTI. In the following text, this may also be referred to as the PTP ReTx scheme or the PTP scheme.

[0395] PTM Retransmission Scheme 1: The retransmitted transport block is scheduled using a group common PDCCH with a CRC scrambled by the group common RNTI and a group common PDSCH scrambled with the same group common RNTI. In the following text, this may also be referred to as PTM ReTx Scheme 1 or PTM Scheme 1.

[0396] PTM Transmission Scheme 2: Retransmitted transport blocks are scheduled using a UE-specific PDCCH with a CRC scrambled by a UE-specific RNTI (e.g., C-RNTI) to a group common PDSCH scrambled by a group common RNTI. In the following text, this may also be referred to as PTM ReTx Scheme 2 or PTM Scheme 2.

[0397] The process for multiplexing MBS services provides a solution to problem 1 above. The network can be allowed to multiplex MBS services from different MBS services. This multiplexing can be performed at the SDAP and MAC layers. Note that the gNB can have a single SDAP entity for all MBS sessions, or it can have multiple SDAP entities, one for each MBS session. Alternatively, the gNB SDAP entity can serve multiple MBS sessions. Similarly, the UE can have a single SDAP entity for all MBS sessions of interest, or it can have multiple SDAP entities, one for each MBS session of interest to the UE. Alternatively, the UE SDAP entity can serve multiple MBS sessions. After correctly decoding the transport block, the decoded MAC PDU is sent to the disassembly and demultiplexing entity. This transport block can contain logical channel information from multiple MBS services, some of which are not of interest to the UE.

[0398] Figure 3A and Figure 3B Example 300 shows the reuse of MBS services from different MBS services at the SDAP or MAC layer. Figure 3A An example of multiplexing MBS traffic from MTCH1 303, MTCH3 304 and MTCH5 305 at MAC layer 320 is shown. Figure 3B An example of services from MBS Service 1 301 and MBS Service 2 302 being multiplexed at SDAP layer 312 is shown. Therefore, in Figure 3A and Figure 3BIn this network, there is multiplexed traffic from MBS service 1 301 and MBS service 2 302. The UE may only be interested in MBS service 1 301, and therefore, not in logical channel MTCH5 303. At the disassembly and demultiplexing entity, the UE needs to recover the MAC SDU for each logical channel and discard any MAC SDU associated with logical channel MTCH5 303. To achieve this functionality, the following alternative can be used:

[0399] In the first alternative, the network can guarantee that all logical channels multiplexed in a transport block have a unique Logical Channel ID (LCID). The UE can then be configured with the LCID associated with the MBS service of interest (e.g., the logical channel configuration may include a list of LCIDs corresponding to the MBS services of interest). Then, during the disassembly of the MAC PDU, the disassembly and demultiplexing entity discards logical channels not on this list.

[0400] In the second alternative, the network may not guarantee that all logical channels multiplexed in a transport block have unique logical channel IDs; for example, logical channels from different MBS services may have the same LCID. In this case, the MAC PDU may need to include an additional identifier for each MAC SDU to allow the UE to determine whether the SDU is for a logical channel corresponding to an MBS service of interest. For example, the MAC PDU header may include an MBS service ID (such as a TMGI or session ID, or an alternative ID identifying the MBS service). The UE can obtain a list of MBS service IDs of interest during UE configuration. When receiving and decoding the MAC PDU, the UE forwards the MAC PDU to the disassembler and demultiplexer entity. Then, when disassembling the MAC PDU, MAC SDUs with MBS service IDs not on the configuration list are discarded.

[0401] In the third alternative, a list of MBS service IDs indexed from 0 to maxMBSServices-1 can be configured for the UE. The DCI scheduling G-RNTI can include the index of the MBS service ID in a bit field. For example, an 8-bit field can carry an indication of whether the MBS service with index k is carried in the transport block (a "1" in bit k of the field indicates that the MBS service with index k is carried). Various options for using this bit field in the DCI are possible.

[0402] The UE PHY layer can be informed of the MBS service of interest. If the PHY layer determines through DCI that the TB does not carry the MBS service of interest, the UE does not need to attempt to decode the transport block.

[0403] The UE PHY can indicate the existence of a downlink assignment and deliver the associated HARQ information, along with its corresponding bit fields, to the HARQ entity. The HARQ entity can then evaluate whether the HARQ information contains data from the MBS service of interest.

[0404] If the UE is configured to send HARQ feedback to the gNB and the UE receives a transport block that does not have the MBS service of interest, the UE can be configured to: always respond with ACK regardless of whether the transport block is correctly decoded; always respond with DTX regardless of whether the transport block is correctly decoded; or respond with Don't Care (DC) regardless of whether the transport block is correctly decoded.

[0405] A UE receiving MBS service can be configured with one or more G-RNTIs. For services that do not require HARQ retransmission, the UE can have zero or one or more G-RNTIs. This is typical for broadcast services and multicast services with less stringent QoS requirements. For services that require HARQ retransmission, the UE can have zero or one or more G-RNTIs. Additionally, if in an RRC connection, the UE can also have unicast C-RNTIs.

[0406] In such cases, the network may be allowed to multiplex MBS services from different MBS services, as well as unicast services. During the multiplexing and assembly phases, additional resources may be available when allocating resources to logical channels. For example, after all MBS services including those that can be multiplexed on a transport block, the transport block may not be fully filled. In such cases, the gNB can multiplex unicast services into this transport block. The unicast service is destined for the UE receiving the transport block. Multiplexing can be performed at the MAC layer.

[0407] Figure 4 Example 400 is shown where a transport block includes both MBS and unicast services. In this example, the transport block includes MBS services from MBS service 1 401 via MTCH1 410 and MTCH3 411. This example also shows that the transport block may include unicast services from unicast PDU session 402 to UE1 (logical channel DTCH1 412) and to UE2 (logical channel DTCH2 413). Not all UEs can support multiplexing of multicast and unicast logical channels. UEs can share their support for multiplexed unicast and MBS services on a single transport block with the network. This information can be provided to the network through subscription, UE capability delivery, or a new dedicated RRC MBS capability delivery.

[0408] After correctly decoding the transport block, the decoded MAC PDU can be sent to the disassembler and demultiplexer entity. This transport block may contain logical channel information from multiple MBS services and zero or more unicast logical channels. At the disassembler and demultiplexer entity, the UE can recover the MAC SDU for each logical channel carried in the transport block and can discard any MAC SDU associated with MBS logical channels from services of no interest. The UE can use the alternatives described above. Furthermore, the UE can discard any MAC SDU from unicast logical channels destined for services other than this UE. To achieve this latter functionality, the UE can use one or more of the following alternatives.

[0409] In the first alternative, the network may include a field in the DCI indicating whether the transport block contains MBS logical channels, unicast logical channels, or both multicast and unicast logical channels. If the UE has not configured unicast logical channels, the UE may immediately discard all unicast logical channels it receives in the transport block.

[0410] In a second alternative, the network may include a field in the DCI indicating an identifier for the multiplexed logical channel. This identifier may be an LCID or some other identifier known to both the network and the UE. Upon receiving the DCI, the UE can determine whether the transport block contains an MBS logical channel from the service of interest and a unicast logical channel for a service whose destination is this UE.

[0411] In a third alternative, the network may include a field in the DCI indicating the UE ID of the receiver of the multiplexed logical channel. This UE ID may be a G-RNTI, C-RNTI, or some other identifier known to both the network and the UE. Upon receiving the DCI, the UE can determine whether the transport block contains an MBS logical channel from the service of interest and a unicast logical channel for the service destined for this UE. As an alternative to the UE ID, an index of the UE ID list can be used. For services requiring HARQ retransmission, the gNB can identify the UE that is the target of the transport block transmitted on the G-RNTI. The gNB can also determine which of these UEs may be able to receive transport blocks with multiplexed unicast and MBS services. The gNB can also determine which of these UEs are in RRC connected state and have a C-RNTI. Transmissions to the G-RNTI can be received by all UEs identified by these C-RNTIs. The network may maintain an index list of these C-RNTIs. The UE may be configured with an index in this list corresponding to its C-RNTI. Subsequently, when a multiplexed transport block is transmitted on the G-RNTI, the DCI scheduling the transport block may include a bitmap with an index of the UEs multiplexed in this transport. For example, if bit "k" in the bitmap is 1, this indicates that the UE identified by index "k" has a unicast logical channel multiplexed in the transport block.

[0412] In the fourth alternative, the network can include new fields in the MAC header to help identify multiplexed logical channels. For example, the MAC header can include a UE ID field and a Logical Channel ID (LCID) field for each multiplexed logical channel.

[0413] Figure 5 An example MAC header 500 is shown. Figure 5The example illustrates LCID field 501, UE ID field 502, and UEID field 503. UE ID fields 502 and 503 can identify the receiver of the logical channel. This receiver can be a G-RNTI or C-RNTI, or some other identifier known to both the network and the UE. The logical channel identifier can be LCID or some other identifier known to both the network and the UE. Upon receiving a transport block, the disassembler and demultiplexer entity can determine whether the logical channel corresponds to an MBS service or a unicast service. For MBS services, the disassembler and demultiplexer entity can determine whether the MBS service is a service of interest. For unicast services, the disassembler and demultiplexer entity can use the UE ID field to determine whether the UE is the receiver of this logical channel. If so, the UE can continue processing the logical channel. If not, the logical channel can be discarded. Alternatively, the MAC header can include a multicast / unicast field for each multiplexed logical channel. The multicast / unicast field can be a 1-bit indication (e.g., "0" = multicast and "1" for unicast). For the multicast / unicast field used to indicate a logical channel that is a unicast service, only the UE ID may be included. Alternatively, an index of the UE ID list can be used. For services requiring HARQ retransmission, the gNB can identify the UEs targeted by the transport block transmitted on the G-RNTI. The gNB can also determine which of these UEs are capable of receiving transport blocks with multiplexed unicast and MBS services. The gNB can also determine which of these UEs are in RRC connected state and have a C-RNTI. Transmissions to the G-RNTI can be received by all UEs identified by these C-RNTIs. The network can maintain an index list of these C-RNTIs. UEs can be configured with the index in this list corresponding to their C-RNTIs. Subsequently, when a multiplexed transport block is transmitted on the G-RNTI, the MAC header may include a field indicating whether any unicast logical channels are multiplexed in the transport block. The MAC header may be a bitmap. For example, if bit "k" in the bitmap is 1, this indicates that the UE identified by index "k" has a unicast logical channel multiplexed in the transport block.

[0414] This document describes the process for logical channel prioritization at the UE, providing a solution to Problem 2. UEs can simultaneously receive MBS services and involve both unicast reception and transmission, as well as sidelink reception and transmission. These UEs can perform both unicast uplink and sidelink transmissions for both user plane data and control plane data. The UE can be (pre-)configured with a priority list that allows the UE to determine which transmission to prioritize when two or more different unicast uplink and / or sidelink transmissions overlap. This priority list can be based on logical channel priority, the priority of different MAC CEs, the priority of MAC CEs relative to certain logical channels, and whether the transmission is uplink or sidelink. Furthermore, the UE may be required to transmit uplink control information (UCI) to the gNB. This information can be transmitted on the PUCCH physical channel, or it can be multiplexed on the PUSCH physical channel.

[0415] When a UE is involved in MBS services, it can have multiple MBS-related uplink transmissions (i.e., uplink transmissions bound to MBS services). These MBS-related uplink transmissions can include:

[0416] Uplink MCCH: MBS services can have an uplink MCCH for MBS-related UL RRC messages, and the processing of these RRC messages can be different on the UL.

[0417] Uplink MAC CE: MBS-specific uplink MAC CEs may exist to support certain features (e.g., requests for path switching).

[0418] PDCP Status Report: Due to handover or MRB (re)configuration, the UE can send a PDCP status report to help ensure service continuity.

[0419] PDCP control PDU: The UE can send PDCP control PDU to support certain features.

[0420] RLC Status Report: The UE can send an RLC status report for any MBS service transmitted on RLC-AM.

[0421] RLC Control PDU: The UE can send an RLC control PDU to support certain features.

[0422] HARQ Feedback: If HARQ feedback is enabled for MBS services, the UE can send HARQ feedback for such services, and the UE can be requested to send feedback.

[0423] Below, a priority value can be assigned to an MBS service. In the following, it may be assumed that a lower priority value represents a higher priority service. However, alternative interpretations are also possible (i.e., a higher priority value represents a higher priority service). Furthermore, note that MBS services from multiple services can be multiplexed in each MBS transmission (multiplexed within a single transport block). Each MBS logical channel in the multiplexed MBS logical channels can have a different priority. The priority value of the multiplexed service can correspond to the priority value of the highest priority logical channel that can be multiplexed in the transport block. Alternatively, the priority value of the multiplexed service can correspond to a weighted average of the priority values ​​of the MBS logical channels multiplexed in the transport block. The priority of an MBS-related uplink transmission can correspond to the priority of the MBS service for which it is transmitting the uplink transmission. For example, if the MBS-related uplink transmission is a PDCP status report for an MRB with a priority value "k", then the MBS-related uplink transmission can also have the same priority value "k". Alternatively, the priority of an MBS-related uplink transmission can be (pre)configured or fixed / normalized.

[0424] When MBS-related UL transmissions overlap with unicast UL transmissions or sidelink transmissions, and the UE may not be able to transmit simultaneously, one of these transmissions must take precedence over the other. The overlap can be complete or partial. Another scenario is when two transmissions occur in the same time slot without time-domain (e.g., symbol-level) overlap, and the UE may not be able to transmit simultaneously in that time slot; in this case, one of these transmissions must take precedence over the other. The following implementations can be used to prioritize one transmission over another. Note that, hereinafter, the term "overlap" can be used to indicate that transmissions can have complete or partial overlap (i.e., transmissions occur on one or more of the same symbols), and that transmissions occur in the same time slot (or micro-time slot) but not on the same symbol.

[0425] In the first embodiment, some transmission types are always prioritized over others. For example, MBS-related uplink transmissions may always be de-prioritized compared to sidelink transmissions or unicast uplink transmissions. Alternatively, MBS-related uplink transmissions may always be prioritized compared to sidelink transmissions or unicast uplink transmissions.

[0426] In the second implementation, the prioritized transmission can be based on the relative priority of MBS-related uplink transmissions and sidelink transmissions or unicast uplink transmissions. In the case of overlap, the UE can compare the priorities of the overlapping services and transmit the service with the higher priority. When overlapping services have the same priority, the UE can randomly decide which service to prioritize, or can use any of the other implementations described herein to decide which service to prioritize, or can rely on the specific implementation of the UE.

[0427] In the third implementation, the prioritized transmission can be based on the relative priority of MBS-related uplink transmissions and a threshold (MBSPriorityThreshold). In cases of overlap, the UE can compare the priority value of the MBS-related uplink transmission with the MBSPriorityThreshold. If the priority value is less than the MBSPriorityThreshold, the MBS-related uplink transmission can be prioritized and transmitted. If the priority value is higher than the MBSPriorityThreshold, the MBS-related uplink transmission can be de-prioritized, and sidelink transmissions or unicast uplink transmissions can be prioritized. If the priority value is equal to the MBSPriorityThreshold, the UE can randomly decide which service to prioritize, or can use any of the other implementations described herein to decide which service to prioritize, or can rely on the specific implementation of the UE. Note that the value of MBSPriorityThreshold can be (pre)configured or fixed / normalized.

[0428] In the fourth implementation, prioritized transmissions can be based on the relative priority of the transmission relative to a threshold. Each service type in the UL / SL service types has a priority value and a priority threshold (MBSPriorityThreshold, ULPriorityThreshold, SLPriorityThreshold). When there is overlap between MBS-related uplink transmissions and unicast uplink transmissions, the UE first checks the relative priority of the unicast uplink transmission by comparing its priority value with ULPriorityThreshold. If the unicast uplink transmission has a high priority (priority value <= ULPriorityThreshold), it can be prioritized. If the unicast uplink transmission has a low priority (priority value > ULPriorityThreshold), the UE relies on the relative priority comparison between MBS-related uplink transmissions and unicast uplink transmissions. The UE transmits the higher-priority service. When there is overlap between MBS-related uplink transmissions and sidelink transmissions, the UE first checks the relative priority of the sidelink transmission by comparing its priority value with SLPriorityThreshold. If a sidelink transmission has a high priority (priority value <= SLPriorityThreshold), it can be prioritized. If a sidelink transmission has a low priority (priority value > SLPriorityThreshold), the UE relies on a relative priority comparison between MBS-related uplink transmissions and sidelink transmissions. The UE transmits the higher-priority service.

[0429] Some types of MBS-related uplink transmissions may not have associated priority values. For example, UL MCCH and UL MAC CE services may not be associated with priority values. For these types of MBS-related uplink transmissions, the priority of the service can be fixed / normalized. Typical examples may include the highest priority listed first in the example list below. For example, UL MCCH has the highest priority among MBS-related uplink transmissions (higher than any MBS MAC CE, any PDCP status / control PDU, and any RLC status / control PDU). The example list below also shows the relative priority of MBS services with other unicast uplink and sidelink services.

[0430] C-RNTI MAC CE or data from UL-CCCH;

[0431] Data from UL-MCCH;

[0432] The configured authorization confirmation MAC CE or BFR MAC CE or multiple entries configured authorization confirmation MAC CE;

[0433] The authorization confirmation MAC (Access Control Point) configured on the side link;

[0434] MBS MAC CE;

[0435] LBT failure MAC CE;

[0436] MAC CE for SL-BSR prioritized according to Clause 5.22.1.6 of TS 38.321;

[0437] MAC CE for BSR, except for BSR used for filling;

[0438] Single entry PHR MAC CE or multiple entries PHR MAC CE;

[0439] MAC CE for the number of symbols to be protected;

[0440] MAC CE used to preempt BSR;

[0441] MAC CE for SL-BSR, excluding SL-BSRs prioritized under Clause 5.22.1.6 of TS 38.321 and SL-BSRs included for filling;

[0442] Data from any logical channel, except for data from UL-CCCH;

[0443] MAC CE for recommending bit rate queries;

[0444] MAC CE for inclusion in the BSR used for filling;

[0445] MAC CE for inclusion in the SL-BSR used for filling.

[0446] Note that the list above is provided as an example. In an alternative scenario described above, the relative priority of UL-MCCH and MBS MAC CE can be based on the type of MBS service the UE is receiving. Depending on the MBS service the UE is receiving, the UL-MCCH priority can be higher or lower. The MBS MAC CE priority can be based on the specific MAC CE commands sent by the UE, some of which have higher or lower priorities.

[0447] Although shown as separate implementations, it should be understood that these implementations can be used in any combination and can target certain MBS-related UL transmissions. For example, UL MCCH information can take precedence over other UE transmissions, and MBMS-related PDCP status reports can be prioritized based on the priority of the MBR that is sending the status report for it.

[0448] This article describes the process for HARQ retransmission on C-RNTI, which provides a solution to problem 3 described above.

[0449] Figure 6 An exemplary transport 600 of the MBS service with HARQ feedback enabled is shown. Figure 6 In the example, multiple UEs may have already joined the MBS service (UE1 601, UE2 602, UE3 603, UE4 604...UEk 605) and have been configured with MRB settings for receiving the MBS service. HARQ feedback can also be enabled for this MBS service. TB 610 can initially transmit from gNB 606 to the UEs (UE1 601, UE2 602, UE3 603, UE4 604...UEk 605) on G-RNTI 611. UEs interested in the service can correctly receive the transport block, except for UEk 605. UEk 605 can send back NACK 612 to gNB 606. Other UEs (UE1 601, UE2 602, UE3 603, UE4 604) can send back ACK to gNB 606. Figure 6 (Not shown in the image). Since only UEk605 has not yet received TB 610, gNB 606 can send retransmission TB 613 to UEk605 using only UEk 605's C-RNTI 614.

[0450] At the UE, multiple HARQ entities may exist. Each of these entities may have multiple sets of HARQ processes: one DL HARQ process set for unicast transmissions, one MBS HARQ process set for MBS transmissions, and a broadcast HARQ process set for BCCH transmissions. Another set of sidelink HARQ processes may also exist for SL transmissions, and these processes may reside within separate HARQ entities. In one example, the same MBS HARQ process may handle all transmissions for a single transport block, regardless of whether that transport block is received on G-RNTI or C-RNTI.

[0451] Figure 7 Example 700 shows MBS transfers of TB handled by the same MBS HARQ process. (See example 700.) Figure 7As shown, HARQ entity 701 may include MBS HARQ process 1 710, MBS HARQ process 2 711, MBS HARQ process 3 712, ..., MBS HARQ process k 713. MBS HARQ process 3 712 can handle TB transmission 720, including PDSCH reception 730 on G-RNTI and PDSCH reception 740 on C-RNTI.

[0452] The DCI that schedules PDSCH can include one or more of the following:

[0453] HARQ Process ID: The identifier of the HARQ process that should handle the received transport block;

[0454] G-RNTI / C-RNTI indication: Indication of whether PDSCH is being received on G-RNTI or C-RNTI;

[0455] NDI: A new data indicator used to indicate whether a transport block is the first transport of new data.

[0456] MBS HARQ process indicator: The HARQ process ID indicates whether it is an MBS HARQ process or a DL HARQ process;

[0457] MBS indicator: The transport block carries an indication of MBS service.

[0458] To receive retransmissions, the UE can monitor the C-RNTI. However, it may be unclear when the UE must monitor the C-RNTI: whether to always monitor it, or only when the UE anticipates a retransmission from the gNB on the C-RNTI. The UE has many options for monitoring the C-RNTI.

[0459] If the UE is in RRC connection mode, the UE can always monitor C-RNTI for potential MBS retransmissions from the gNB.

[0460] If the UE is in RRC connection mode and during a period when MBS activity can be expected (e.g., during MBSDRX activity periods), the UE can monitor C-RNTI for potential MBS retransmissions from the gNB.

[0461] If the UE is in RRC connected mode and during periods of anticipated MBS activity (e.g., during MBSDRX activity periods), the UE can monitor C-RNTI for potential MBS retransmissions from the gNB. Furthermore, if no other DL activity is anticipated during these MBSDRX activity periods (e.g., the UE may be in DRX for unicast transmissions), the UE can monitor C-RNTI for potential MBS retransmissions from the gNB only after sending a NACK as HARQ feedback for a transport block transmission or retransmission.

[0462] Regardless of the state (RRC idle, RRC inactive, RRC connected), the UE can always monitor C-RNTI for potential MBS retransmissions from the gNB.

[0463] The UE can monitor C-RNTI for potential MBS retransmissions from the gNB in ​​all states and during periods of expected MBS activity. For example, during MBSDRX activity periods.

[0464] The UE can monitor C-RNTI for potential MBS retransmissions from the gNB in ​​all states and during periods of expected MBS activity. For example, during MBSDRX activity periods. Furthermore, if no other activity is expected during these MBSDRX activity periods (e.g., the UE may be in DRX for unicast transmission), the UE can monitor C-RNTI for potential MBS retransmissions from the gNB only after sending a NACK as HARQ feedback for a transport block transmission or retransmission.

[0465] During periods of anticipated MBS activity, when the RRC is idle or inactive, the UE can monitor C-RNTI for potential MBS retransmissions from the gNB. For example, during MBSDRX activity periods.

[0466] Only after sending NACK as HARQ feedback for transport block transmission or retransmission, when the RRC is idle and inactive, the UE can monitor C-RNTI for potential MBS retransmissions from the gNB.

[0467] Upon receiving the DCI, the UE may be able to determine whether the transport block was received on the G-RNTI or the C-RNTI.

[0468] If it is G-RNTI, the UE will forward the transport block to the identified MBS HARQ process.

[0469] If it is a C-RNTI, the UE may first need to determine whether the transport block corresponds to an MBS service and needs to be sent to the MBS HARQ process, or whether the transport block corresponds to a DL unicast transmission and needs to be sent to the DL HARQ process. The UE can use the MBS indicator to determine whether the transport block corresponds to an MBS service or a DL unicast service. Alternatively, the UE can implicitly determine this based on the presence or absence of the G-RNTI / C-RNTI indicator. For example, if the G-RNTI / C-RNTI indicator is present, the UE can assume that the transport block corresponds to an MBS service. If the G-RNTI / C-RNTI indicator is absent, the UE can assume that the transport block corresponds to a DL unicast service. As another example, the UE can use the MBS HARQ process indicator to determine whether the HARQ process is an MBS HARQ process or a DL HARQ process. If the indicator indicates an MBS HARQ process, the UE can forward the transport block to the identified MBS HARQ process. For example, if the indicator indicates a DL HARQ process, the UE can forward the transport block to the identified DL HARQ process. Alternatively, based on the MBS HARQ process indicator, the network and UE can be configured such that the HARQ process ID for each HARQ process in the HARQ process is different. For example, the DL HARQ process ID can be in the range 0..15, and the MBS HARQ process ID can be in the range 16..32. The actual range can be part of the MRB configuration. In this case, the HARQ process ID implicitly informs the UE whether the transport block will be handled by the DL HARQ process or the MBS HARQ process.

[0470] When a transport block is transmitted on both G-RNTI and C-RNTI and these transport blocks are handled by the same HARQ process, there may be instances where the network starts transmitting a new transport block on G-RNTI using the same HARQ process. This effectively causes a HARQ process conflict. In such cases, the UE can receive transport block A (retransmission) on C-RNTI and transport block B (new transmission) on G-RNTI. Both transport blocks are designated to be handled by the same MBS HARQ process. To resolve the HARQ process conflict problem, the UE can use one of the following HARQ process conflict methods or any combination thereof:

[0471] In the first HARQ process conflict method, the UE may only consider the transport blocks received on C-RNTI and discard the transport blocks received on G-RNTI.

[0472] In the second HARQ process conflict method, the UE can consider only the transport block received on G-RNTI. The UE can refresh the HARQ process and treat G-RNTI as a new transport.

[0473] In the third HARQ process conflict method, the UE can process transport blocks received on C-RNTI and temporarily store transport blocks received on G-RNTI. The UE can move the temporarily stored transport blocks to the HA process in the following situations: once the transport block is successfully decoded; once the timer expires; once the configured maximum number of retransmissions has been received; once the UE receives an indication in the DCI that schedules the TB on C-RNTI.

[0474] In the fourth HARQ process collision method, after sending a NACK for a transport block received on G-RNTI, the UE can begin monitoring C-RNTI only. In this case, if the UE is receiving retransmissions on C-RNTI, the UE can discontinue monitoring G-RNTI. The UE can resume monitoring G-RNTI when: the transport block is successfully decoded; the timer expires; the maximum configured number of retransmissions has been received; or the UE receives an indication in the DCI that schedules the TB on C-RNTI.

[0475] For example, different MBS HARQ processes can be used for the same transport block—one MBS HARQ process when the transport block is received on G-RNTI, and a second MBS HARQ process when the transport block is received on C-RNTI.

[0476] This document describes the technology used for sending PDCP status reports, providing a solution to problem 4 described above. After handover, the UE may lose some PDCP SDUs. For services requiring reliability and service continuity, the receiving entity can send PDCP status reports to the transmitting entity, allowing the transmitting entity to know which PDCP SDUs need to be retransmitted. According to TS38.323, for AM DRBs configured by the upper layer to send PDCP status reports, the receiving PDCP entity can trigger PDCP status reports under the following conditions:

[0477] The upper layer requests the reconstruction of the PDCP entity;

[0478] The upper layer requests PDCP data recovery;

[0479] The upper layer requests an uplink data switch;

[0480] The upper layer reconfigures the PDCP entity according to the version of DAPS, and can configure daps-SourceRelease as described in TS 38.331.

[0481] For UM DRBs configured by the upper layer to send PDCP status reports in the uplink, the receiving PDCP entity can trigger a PDCP status report when the upper layer requests an uplink data switch.

[0482] The PDCP status reporting mechanism can be extended to provide lossless handover for MBS services, as well as lossless dynamic PTM-PTP handover and lossless MRB reconfiguration. To send PDCP status reports, the following new triggers are proposed:

[0483] After the timer expires;

[0484] When the UE detects a lost PDCP PDU;

[0485] After MBS radio bearer reconfiguration;

[0486] After the MBS radio bearer is reconfigured, and the UE detects a lost PDCP PDU;

[0487] After the PTM-PTP switch;

[0488] After the PTM-PTP handover, and the UE detects the lost PDCP PDU;

[0489] After the PTP-PTM switch;

[0490] After the PTP-PTM handover, and the UE detects the lost PDCP PDU;

[0491] When the PDCP reordering timer expires;

[0492] MBS radio bearer configuration may include changes to the MRB type. Examples of changes to the MRB bearer type include, but are not limited to, PTM-PTP handover, PTP-PTM handover, or changes to the MRB type.

[0493] When a UE is triggered to send a PDCP status report, the MRB may not have a UL path (on RLC AM or RLC UM) for sending this report. Below, a new mechanism for sending PDCP status reports is proposed.

[0494] The PDCP layer can notify higher layers (RRC or NAS) of the need to send status reports. Higher layers can request the establishment of an uplink path for the MRB. For example, the gNB can reconfigure the MRB to have an RLC AM PTP tributary. Alternatively, the UE can include the PDCP status report in the RRC or NAS layer messages sent to the network.

[0495] If the gNB can determine that the UE may need to send a PDCP status report, then the gNB can always configure a UL path for the UE.

[0496] The UE can include PDCP status reports on linked radio bearers with uplink paths. The identifier of the linked radio bearer can be provided to the UE when configuring the MRB. If the UE needs to send a PDCP status report for this MRB, it can send the PDCP status report via the linked radio bearer.

[0497] The UE can send PDCP status reports on RACH.

[0498] The UE can include PDCP status reports on the PTP tributary of another MRB split bearer. The split bearer identifier can be provided to the UE when configuring the MRB.

[0499] Solution to Problem 5: This document describes the process for a UE to join an already initiated / activated multicast session, providing a solution to Problem 5 described above. Note that this problem can be described as a UE joining an already activated / initiated multicast session. The presented implementation focuses on the scenario where the UE receives MBS configuration while MBS service may already be initiated / activated. However, it should be understood that the implementation is more generally applicable to any situation where a UE begins receiving MBS services that may already be in operation. For example, the same implementation can be applied to a UE performing a path handover from a PTP tributary to a PTM tributary. For example, the same implementation can be applied to situations where a PTM tributary or PTM radio bearer with a segmented bearer can be reconfigured.

[0500] This document describes an MRB with a PTM tributary configured with RLC-UM. Any PTM tributary (e.g., an MRB with a single PTM tributary or a split bearer with both PTP and PTM tributaries) can be configured with RLC-UM. For RLC-UM transmissions, the transmitter can add sequence numbers. For example, for NR, RLC-UM adds sequence numbers to all segments of the RLC SDU. The same sequence number can be added to each segment of an RLC SDU. On the receiver side, RLC-UM can maintain a reassembly window to allow the reassembly of segmented PDUs. The window can be maintained through two state variables, RX_Next_Highest and RX_Next_Reassembly, and a window size, UM_Window_Size. Initially, both RX_Next_Highest and RX_Next_Reassembly are set to 0. The reassembly window can be defined as: (RX_Next_Highest – UM_Window_Size) <= SN <RX_Next_Highest

[0501] Figure 8 An example is shown in which a reassembly window is typically shown on the round number space 800 due to modulo operation on SN. Figure 8 An example is shown in which the window can be maintained by two state variables RX_Next_Highest 811 and RX_Next_Reassembly 810, and RX_Next_Highest - UM_Window_Size 812. In Figure 8 the example, when the receiving entity receives a UMD PDU with a SN outside the reassembly window, the window moves. For example, if the receiving entity obtains a SN = x that can be outside the reassembly window (region 1 801), the receiving entity sets RX_Next_Highest = x + 1 (thus effectively moving the window). The receiving entity also maintains RX_Next_Reassembly 810 to represent the SN of the next RLC SDU that may be waiting for reassembly. If the receiving entity obtains a SN = x that can be inside the reassembly window and it may be in one of two regions (region 2 802 or region 3 803), then any UMD PDU received by the receiving entity with a SN between (RX_Next_Highest – UM_Window_Size 812) <= SN < RX_Next_Reassembly 810 can be in region 2 802. This UMD PDU belongs to an RLC SDU that has already been reassembled by the receiving entity and forwarded to the upper layer, and thus, this UMD PDU can be discarded.

[0502] Any UMD PDU received by the receiving entity with a SN between RX_Next_Reassembly 810 <= SN < RX_Next_Highest 811 can be in region 3 803. This UMD PDU can be stored in the receive buffer, and the UE can attempt to reassemble the RLC PDU. If all segments have been received, the RLC PDU can be forwarded to the upper layer.

[0503] A specific issue arises when the UE is initially configured with an RLC UM and starts with initial values ​​for RX_Next_Reassembly and RX_Next_Highest (i.e., set to 0). With this initial setup, areas 2 (802) and 3 (803) completely overlap. Since the MRB may already be operational, the UE may not know which SN the gNB is currently transmitting. When a UMD PDU arrives at the RLC-UM entity, it can have any SN. If this SN falls into area 2 (802), the UMD PDU may be discarded, which is clearly not the intended behavior. Although the UE RLC UM may eventually synchronize with the gNB RLC UM, many fragmented UMD PDUs may be discarded before this occurs. To address this issue, the following implementation scheme is proposed.

[0504] In the first implementation, as part of the UE RLC UM's MRB configuration, the initial values ​​of RX_Next_Reassembly 810 and RX_Next_Highest 811 can be provided to the UE. For example, the gNB can set these values ​​based on the SN of the last RLC SDU to be segmented. Alternatively, the gNB can set these values ​​based on the SN of the next RLC SDU that can be segmented. Upon receiving the configuration, the UE can establish a reassembly window based on the configuration values ​​of RX_Next_Reassembly 810 and RX_Next_Highest 811.

[0505] In the second implementation, the UE RLC UM can set the values ​​of RX_Next_Reassembly 810 and RX_Next_Highest 811 based on the SN value of the first received UMD PDU. For example, after MRB configuration, the UE may not set a reassembly window (and therefore may not set the values ​​of RX_Next_Reassembly 810 and RX_Next_Highest 811). Upon receiving the first UMD PDU for MRB, the RLC UM can extract SN=x and set RX_Next_Reassembly=x and RX_Next_Highest=x. Therefore, a reassembly window can be set upon receiving the first UMD PDU.

[0506] In the third implementation, the gNB may periodically transmit a control PDU containing the value of the SN of the last RLC SDU segmented by the gNB. Alternatively, the gNB may periodically transmit a control PDU containing the SN of the next RLC SDU that can be segmented. The UE RLC UM will receive this control PDU and recover the SN information to initialize or reinitialize RX_Next_Reassembly 810 and RX_Next_Highest 811 according to the SN value contained in the control PDU.

[0507] In the fourth embodiment, each unsegmented UMD PDU transmitted by the gNB may include the value of the SN of the last RLC SDU segmented by the gNB in ​​its header. Alternatively, each unsegmented UMD PDU transmitted by the gNB may include the SN of the next RLC SDU that can be segmented in its header. The UMD PDU may contain an indication that the UMD PDU includes the SN and that the UMD PDU contains the complete RLC SDU (unsegmented). This indication allows the UE to know that the UMD PDU includes the SN in its header, which corresponds to the value that the UE will use to (re)initialize RX_Next_Reassembly 810 and RX_Next_Highest 811.

[0508] In the fifth implementation, the UE does not perform any special processing on UMD PDUs received in area 2 802. That is, if a UMD PDU can be received and its SN can be in area 2 802, the UE does not discard the UMD PDU, but stores it in the receive buffer. The UMD PDU is only discarded when the reassembly window moves and the UMD PDU falls outside the reassembly window.

[0509] In an alternative to any of these five implementation schemes, the UE may discard any received RLC SDU segments that are not initial segments until the UE receives the first initial segment. When the UE first begins receiving MBS services for an ongoing MBS session, the gNB may have already completed its transmission of the first segment of the RLC SDU. Therefore, these segments may not be received by the UE, and thus, the UE may never be able to reassemble the RLC SDU. In such cases, any UMD PDUs received for this RLC SDU may be discarded immediately. The UE may use the Segment Information (SI) field and / or Segment Offset (SO) field in the UMD PDU header to determine whether the UMD PDU is an initial segment. The UE may continue to do so until it receives the initial segment of any RLC SDU.

[0510] This document describes an MRB with a PTM tributary configured with RLC-AM. Any PTM tributary (e.g., an MRB with a single PTM tributary or a split bearer with both PTP and PTM tributaries) can be configured with RLC-AM. For RLC-AM transmission, the transmitter can add a sequence number to each RLC SDU. If any RLC SDU is segmented, the transmitter can also add an indication of which bytes of the original RLC SDU are included in the segment. This information is all contained in the AMD PDU header. Furthermore, the receiver can send an RLC status report to the transmitter entity to notify it to retransmit certain AMD PDUs.

[0511] Figure 9 Another example 900 is shown where the receive window is maintained on the receive side in RLC-AM to allow reconstruction of the segmented PDU and to allow the transmission of status report information to the transmit side. The window can be maintained via a state variable: RX_Next 910 and a window size: AM_Window_Size. Initially, RX_Next can be set to 0. The receive window can be defined as:

[0512] RX_Next<=SN <RX_Next+AM_Window_Size 911

[0513] Whenever the UE receives an AMD PDU with a SN within the receive window (area 4 901), the UE can check if it has all segments of this RLC SDU. If so, the UE can forward the RLC SDU to the upper layer. If not, the UE can store the AMD PDU in the receive buffer, check to see if all segments of the RLC SDU have been received, and check if the receive window can be moved. The lower edge of the window can represent the SN of the next RLC SDU to be received and sent to the upper layer. The window moves when the receiving entity receives all segments of an RLC SDU with SN = RX_Next 910. In this case, the lower edge can be set to the expected next SN.

[0514] Whenever the UE receives an AMD PDU with a SN outside the receive window (area 5 902), the AMD PDU can be discarded.

[0515] A specific issue arises when the UE can be initially configured with RLC AM and starts with an initial value of RX_Next set to 0. For this initial setup, the receive window can be determined according to the following formula:

[0516] 0<=SN <AM_Window_Size

[0517] Since the MRB is already operational, the UE may not know which SN the gNB is currently transmitting. When an AMD PDU arrives at the RLC-AM entity, it can have any SN. If this SN falls into area 5 902, this AMD PDU may be discarded, which is clearly not the intended behavior. Although the UE RLC AM can eventually synchronize with the gNB RLC AM, many AMD PDUs may be discarded before this happens. To address this issue, the following implementation scheme is proposed.

[0518] In the first implementation, as part of the UE's RLC AM MRB configuration, the initial value of RX_Next910 can be provided to the UE. For example, the gNB can set this value based on the SN of the last transmitted RLC SDU. Alternatively, the gNB can set these values ​​based on the SN of the next RLC SDU that can be transmitted. Upon receiving the configuration, the UE can establish a receive window based on the configuration value of RX_Next910.

[0519] In the second implementation, the UE RLC AM can set the value of RX_Next 910 based on the SN value of the first received AMD PDU. For example, after MRB configuration, the UE may not establish a receive window (e.g., not set the value of RX_Next 910). Upon receiving the first AMD PDU for MRB, the RLC AM can extract SN=x and set RX_Next=x. Therefore, a receive window can be established upon receiving the first AMD PDU.

[0520] In the third embodiment, the gNB may periodically transmit a control PDU containing the value of the SN at the lower edge of the gNB transmission window. Alternatively, the gNB may periodically transmit a control PDU containing the SN at the lower edge of the gNB transmission window. The UE RLCAM may receive this control PDU and recover the SN information to initialize or reinitialize RX_Next 910 according to the SN value contained in the control PDU.

[0521] In the fourth embodiment, each AMD PDU transmitted by the gNB may include the value of the SN at the lower edge of the gNB transmission window in its header. Alternatively, each AMD PDU transmitted by the gNB may include the SN at the lower edge of the gNB transmission window in its header. The AMD PDU may contain an indication that the AMD PDU includes two SNs. This indication allows the UE to know that the AMD PDU contains a first SN that identifies the SN of the RLC SDU being transmitted and a second SN that identifies the lower edge of the gNB transmission window. The UE will use this second SN to (re)initialize RX_Next 910.

[0522] In an alternative to any of these four implementation schemes, the UE may discard any received RLC SDU segments that are not initial segments until the UE receives the first initial segment. When the UE first begins receiving MBS services for an ongoing MBS session, the gNB may have already completed its transmission of the first segment of the RLC SDU. Therefore, these segments may not be received by the UE, and thus, the UE may never be able to reassemble the RLC SDU. In such a case, any AMD PDU received for this RLC SDU may be discarded immediately. The UE may use the Segment Information (SI) field and / or Segment Offset (SO) field in the UMD PDU header to determine whether the AMD PDU is an initial segment. The UE may continue to do so until the initial segment of any RLC SDU becomes available.

[0523] This document describes an MRB with PDCP reordering. PDCP can guarantee that services can be delivered to higher layers in sequence if required by the service. To enable this functionality, the PDCP layer can maintain two variables, RX_NEXT and RX_DELIV, and can use a receive buffer to store these PDCP PDUs while waiting for their sequential delivery. The UE can calculate the RCVD_COUNT for each received PDCP PDU. RCVD_COUNT can be based on the superframe number (HFN) and the SN of the received PDCP PDU. The variable RX_NEXT can include the COUNT value of the next PDCP PDU expected to be received. The initial value can be 0. For example, when receiving a PDCP PDU with COUNT = x, RX_NEXT can be set to x+1. The variable RX_DELIV can represent the COUNT value of the last PDCP PDU delivered by PDCP to a higher layer. This can be the COUNT value of the last PDCP PDU delivered in sequence.

[0524] A PDCP entity can wait for a PDCP PDU with a COUNT value greater than RX_DELIV. Any received PDCP PDU with a COUNT value less than RX_DELIV is considered to have been received and delivered. Therefore, the PDCP layer can discard these PDCP PDUs.

[0525] A specific issue arises when the PDCP at the UE is initially configured and the UE starts with initial values ​​of RX_NEXT and RX_DELIV set to 0. Since the MRB may already be operational, the UE may not know the TX_NEXT value associated with the PDCP being transmitted by the gNB. This TX_NEXT value corresponds to HFN1 and SN1. When a PDCP PDU arrives at the PDCP entity, it can have any SN1 value. If the UE assumes HFN starts at 0, this value can be less than RX_DELIV when the UE determines the COUNT value. In this case, the PDCP PDU may be discarded, which is clearly not intended behavior. Although the UE PDCP may eventually synchronize with the gNB PDCP, many PDCP PDUs may be discarded before this happens. To address this issue, the following implementation scheme is proposed.

[0526] In a first implementation, as part of the UE's PDCP MRB configuration, initial values ​​for RX_NEXT and / or RX_DELIV can be provided to the UE. For example, the gNB can set these values ​​based on the TX_NEXT value of the last transmitted PDCP PDU. Alternatively, the gNB can set these values ​​based on the TX_NEXT value of the next PDCP PDU that can be transmitted. Upon receiving the configuration, the UE can establish variables based on the received configuration. Alternatively, the MRB configuration can include the value of TX_NEXT. Furthermore, the MRB configuration can include separate configurations for HFN and SN. The gNB can set these values ​​based on:

[0527] HFN: Set to the HFN portion of TX_NEXT (i.e., the number of most significant bits is equal to the length of HFN);

[0528] SN: Set to the SN portion of TX_NEXT (i.e., the number of least significant bits is equal to the PDCP SN length).

[0529] The UE can then determine the initial values ​​of RX_NEXT and / or RX_DELIV based on the configured HFN and SN. For example:

[0530] RX_NEXT = [HFN, SN]

[0531] RX_DELIV = [HFN, SN]

[0532] In the second implementation, the UE PDCP can set the values ​​of RX_NEXT and / or RX_DELIV based on the COUNT value of the first received PDCP PDU. For example, after MRB configuration, the UE may not initialize RX_NEXT and / or RX_DELIV. Upon receiving the first PDCP PDU for MRB, the PDCP can determine RCVD_COUNT = x and set RX_NEXT = x and / or RX_DELIV = x. Therefore, a receive window can be established upon receiving the first PDCP PDU.

[0533] In the third embodiment, the gNB can periodically transmit a control PDU containing the values ​​of RX_NEXT and / or RX_DELIV to be used. The UE PDCP will receive this control PDU and initialize or reinitialize RX_NEXT and / or RX_DELIV according to the values ​​contained in the control PDU. Alternatively, the gNB can periodically transmit a control PDU containing the value of TX_NEXT. This could be the value of the next PDCP PDU that can be transmitted or the value of the last PDCP PDU transmitted. Upon receiving a configuration, the UE can set variables based on the received configuration. Alternatively, the gNB can periodically transmit a control PDU containing the values ​​of HFN and SN. The UE can then determine the initial values ​​of RX_NEXT and / or RX_DELIV based on the received HFN and SN.

[0534] In the fourth embodiment, each PDCP PDU transmitted by the gNB may include the value of TX_NEXT in its header. The PDCP PDU may contain an indication that the PDCP PDU includes the value of TX_NEXT. This indication allows the UE to know that the PDCP PDU header contains a first field identifying the SN of the PDCP SDU being transmitted and a second field containing the value of TX_NEXT. The UE will use the second field to (re)initialize RX_NEXT and / or RX_DELIV. Alternatively, the gNB may include the values ​​of the HFN and SN associated with TX_NEXT in its header. The UE can then determine the initial values ​​of RX_NEXT and / or RX_DELIV based on the received HFN and SN.

[0535] In some cases, the above implementation schemes can be used in combination. The HFN portion of the state variable can be determined using one implementation scheme (e.g., configured by the gNB), and the SN portion of the state variable can be determined using another implementation scheme (e.g., based on the COUNT value of the first received PDCP PDU).

[0536] This article describes an MRB with HARQ feedback enabled.

[0537] Some MRBs can enable HARQ feedback. For these MRBs, the UE can send ACK and / or NACK feedback to the gNB, depending on whether the transport block (TB) can be successfully decoded by the UE. Typically, if MBS transports use PTM tributaries, these transports are destined for multiple UEs. For each transport, zero, one, or more of these UEs may fail to decode the TB. The UE can send HARQ feedback to the gNB, allowing the gNB to decide whether to send a retransmission, and if so, how to send it. A transport block is transmitted for the HARQ process, and the UE can be informed—via a New Data Indicator (NDI) carried in the PDCCH control signaling—when to start a new transport for this HARQ process.

[0538] A specific problem arises when HARQ feedback is enabled and the UE begins receiving transport blocks from one or more HARQ processes via the gNB. Since the MRB may already be operational, the UE may not know how many times a transport block has been transmitted. For example, the gNB may have transmitted the transport block K times, but when the UE begins receiving MBS service, it only receives one of those K transmissions where decoding failed. In such cases, the UE can continue to attempt to decode subsequent transport blocks received by the HARQ process, but it can decide not to send any HARQ feedback for those transport blocks. For example, consider a situation where the gNB might be performing the third transmission of a transport block when the UE begins monitoring MBS service. The UE may have just started listening, so it receives the third transmission but may have missed the first two. In such cases, it might be better for the UE not to send a NACK for this TB, as it might not be expected that the gNB would have to repeat the TB since the UE has just started listening and has already missed the first two transmissions. The UE can continue to decide not to send HARQ feedback for a given HARQ process until it receives an indication that the HARQ process has started a new transmission. At this point, the UE can send HARQ feedback for the HARQ process.

[0539] Figure 10 Example 1000 of UE receiving MRB is shown. Figure 10 In the example, the UE can start receiving MRB 1010 at time t0. The UE can receive retransmissions for HARQ process 1 1001, but can choose not to send any feedback 1011 to the gNB. At time t2, the UE can receive new transmissions and start sending HARQ feedback 1012.

[0540] In another example of HARQ operation, when the MBS service is destined for a group of interested UEs, transport blocks can be transmitted multiple times to ensure that all interested UEs successfully receive the transport blocks. In such cases, a UE may receive a transport block that it may have already successfully decoded. How the UE responds to these additional MBS HARQ retransmissions may not be defined in the NR, and therefore, once a UE has successfully decoded a transport block, it may send positive HARQ feedback for each subsequent retransmission of the transport block. This can lead to unnecessary uplink transmissions and may also cause problems with PUCCH resources carrying MBS HARQ feedback. To address this issue, the following implementation scheme is proposed.

[0541] In the first implementation, if the UE has successfully acknowledged receiving the transport block, the UE may decide not to send any HARQ feedback for this transport block.

[0542] In the second implementation, the UE may decide to send HARQ feedback, but only a maximum of a maximum number of times. The maximum number of times can be (pre)configured. For example, the UE can be (pre)configured to send a maximum of K successful HARQ feedback indications.

[0543] This document describes the HARQ feedback problem and the HARQ process. When a transmission occurs for the HARQ process, one or two (in the case of downlink spatial multiplexing) TBs and associated HARQ information are received from the HARQ entity. The HARQ process, as described in Clause 5.3.2.2 of the TS 38.321 specification, is as follows:

[0544] For each received TB and associated HARQ message, the HARQ process should be as follows:

[0545] 1> If the HARQ process can be equal to the MBS HARQ process

[0546] 2> If the NDI has been switched when it is provided compared to the value of the previously received transmission corresponding to this TB:

[0547] 3> Treat this transmission as a new MBS transmission.

[0548] 2> If this is the first received transmission for this TB (i.e., there is no previous NDI for this TB):

[0549] 3> Consider this transmission as the initial MBS transmission.

[0550] 2> Otherwise:

[0551] 3> Treat this transmission as an MBS retransmission

[0552] 1> Otherwise:

[0553] 2> If the NDI has been switched compared to the value of a previously received transmission corresponding to this TB when it is provided; or

[0554] 2> If the HARQ process is equal to the broadcast process, and this is the first received transmission for the TB scheduled according to the system information indicated by the RRC; or

[0555] 2> If this is the first received transmission for this TB (i.e., there is no previous NDI for this TB):

[0556] 3> Treat this transmission as a new transmission.

[0557] 2> Otherwise:

[0558] 3> Treat this transmission as a retransmission.

[0559] Then the MAC entity will:

[0560] 1> If this is a new transfer, a new MBS transfer, or an initial MBS transfer:

[0561] 2> Attempt to decode the received data.

[0562] 1> Otherwise, if this is a retransmission, a new MBS transfer, or an initial MBS transfer:

[0563] 2> If this TB of data has not yet been successfully decoded:

[0564] 3> Instruct the physical layer to combine the received data with the data currently in the soft buffer of this TB, and attempt to decode the combined data.

[0565] 1> If the data that the MAC entity attempted to decode for this TB was successfully decoded; or

[0566] 1> If this TB of data was successfully decoded previously:

[0567] 2> If the HARQ process equals the broadcast process:

[0568] 3> Deliver the decoded MAC PDU to the upper layer.

[0569] 2> Otherwise, if this is the first successful decoding of this TB of data:

[0570] 3> Deliver the decoded MAC PDU to the disassembler and demultiplexer entity.

[0571] 1> Otherwise:

[0572] 2> Instruct the physical layer to replace the data in this TB in the soft buffer with the data that the MAC entity attempts to decode.

[0573] 1> If the HARQ process is associated with a transfer indicated by a temporary C-RNTI, and race resolution has not yet been successful (see Clause 5.1.5); or

[0574] 1> If the HARQ process is associated with a transport indicated by MSGB-RNTI, and the random access procedure has not yet been successfully completed (see Clause 5.1.4a); or

[0575] 1> If the HARQ process equals the broadcast process; or

[0576] 1> If the timeAlignmentTimer associated with the TAG of the serving cell on which HARQ feedback is to be transmitted stops or expires, or;

[0577] 1> If the HARQ process equals the MBS HARQ process and this is not the first successful decoding of this TB of data, or;

[0578] 1> If the HARQ process is associated with the initial MBS transfer:

[0579] 2> Do not instruct the physical layer to generate confirmation of the data in this TB.

[0580] 1> Otherwise:

[0581] 2> Instruct the physical layer to generate confirmation of the data in this TB.

[0582] When determining whether the NDI on the PDCCH for the temporary C-RNTI used by the MAC entity has been switched compared to the value in the previous transmission, the MAC entity will ignore the NDI received in all downlink assignments on the PDCCH used for this C-RNTI.

[0583] Note: If the MAC entity receives a retransmission of a TB size that differs from the last TB size signaled for that TB, the UE behavior can be made dependent on the specific UE implementation.

[0584] This document describes the process of a UE transitioning from multicast ACTIVE to multicast INACTIVE, providing a solution to problem 6 described above. A UE may be interested in one or more multicast sessions. These multicast sessions can be multiplexed on one or more G-RNTIs. Furthermore, these multicast sessions can alternate between two states: active and inactive.

[0585] An active multicast session can be an established multicast session that is currently active. Multicast data can be transmitted to UEs that have joined the multicast session. 5G core network resources are reserved for the multicast session. Corresponding radio resources are reserved based on the location of the participating UEs. UEs joining the multicast session are in the CM CONNECTED state. UEs can be allowed to join the multicast session (after authorization checks). For receiving active multicast sessions, the UE can be in an RRC connected or RRC inactive state.

[0586] An inactive multicast session can be an established multicast session that is inactive. No multicast data is transmitted. A UE joining a multicast session can be in CM CONNECTED or CM IDLE state. A UE can be allowed to join a multicast session (after authorization checks). For an inactive multicast session, the UE can be in RRC connected state, RRC inactive state, or RRC idle state.

[0587] When the UE is in RRC connected or RRC inactive state, the multicast session can transition from active to inactive, and vice versa. The UE can receive an indication that the service has transitioned to an active or inactive mode. It can be assumed below that the MTCH logical channel associated with the multicast session is received on the G-RNTI, while the control channel associated with the multicast session is received on the same G-RNTI or on an SC-RNTI configured to carry control information for the MBS session. This indication can be received using one or more of the following implementations.

[0588] In the first implementation, the UE can receive an RRC message that includes an MBS session that has transitioned to active or inactive mode. This RRC message can be carried in system information on the BCCH. Alternatively, this RRC message can be carried in MBS control signaling on the MCCH. Or, this RRC message can be carried in dedicated signaling on the DCCH to all UEs receiving the MBS session.

[0589] In a second embodiment, the UE may receive a MAC CE including an index of MBS sessions that have transitioned to active or inactive modes. The UE may be configured with an index value for each MBS session. The MAC CE may be included in a MAC PDU sent to a G-RNTI configured to carry MBS sessions. Alternatively, the MAC CE may be included in a MAC PDU sent to an SC-RNTI configured to carry control information for MBS sessions. Alternatively, the MAC CE may be included in a MAC PDU sent to a shared RNTI (SH-RNTI) configured to carry MBS control information for a set of MBS sessions (including MBS sessions that may be transitioning to active or inactive modes) or all MBS sessions.

[0590] In a third implementation, the UE may receive a DCI including a bitmap indicating that an MBS session has transitioned to an active or inactive mode. The UE may be configured with an index value for each MBS session. For example, a "1" in bit position "k" may indicate that the MBS session with index 'k' has transitioned to an active or inactive mode. The DCI may target a G-RNTI configured to carry MBS session information. Alternatively, the DCI may target an SC-RNTI configured to carry control information for the MBS session. Alternatively, the DCI may target a shared RNTI (SH-RNTI) configured to carry MBS control information for a group of MBS sessions (including MBS sessions that may be transitioning to an active or inactive mode) or all MBS sessions. Alternatively, the DCI may target a C-RNTI for each UE interested in receiving an MBS session that may be transitioning to an active or inactive mode.

[0591] It can be assumed that for inactive multicast sessions, both RRC-connected UEs and RRC-inactive UEs maintain the MBS radio bearer configuration for inactive radio bearers. That is, MBS radio bearers that are part of a multicast session are not released. These MBS radio bearers can be considered suspended. When a multicast session transitions from active to inactive, the UE checks whether it is receiving any other MBS sessions on the G-RNTI. If so, the UE can:

[0592] Stop DRX used for MBS sessions if DRX is configured based on MBS sessions;

[0593] Perform RLC entity reconstruction for radio bearers of inactive MBS sessions;

[0594] Suspend the PDCP physical radio bearer for inactive MBS sessions.

[0595] When a multicast session transitions from active to inactive, the UE can check whether it is receiving any other MBS sessions on G-RNTI. If not, the UE can:

[0596] Stop monitoring G-RNTI and process the transport blocks received on G-RNTI;

[0597] Discontinue DRX for G-RNTI;

[0598] Perform RLC entity reconstruction for radio bearers of inactive MBS sessions;

[0599] Suspend the PDCP physical radio bearer for inactive MBS sessions;

[0600] Clear the HARQ processes associated with G-RNTI (e.g., those HARQ processes that are being restored to transport blocks whose destination can be G-RNTI).

[0601] When a multicast session transitions from inactive to active, the UE can check if it is receiving any other MBS sessions on G-RNTI. If so, the UE can:

[0602] Start using DRX for MBS sessions, if DRX is configured based on MBS sessions;

[0603] Restore the PDCP physical radio bearer for inactive MBS sessions.

[0604] When a multicast session transitions from active to inactive, the UE checks whether it is receiving any other MBS sessions on the G-RNTI. If not, the UE can:

[0605] Start monitoring the G-RNTI. Follow the DRX configuration used for this G-RNTI, if a DRX configuration is configured.

[0606] Restore the PDCP physical radio bearer for inactive MBS sessions.

[0607] Although the above has described multicast sessions and transitions from active / inactive to inactive / active, these procedures can also be applied to broadcast sessions and transitions from start / stop to stop / start.

[0608] A UE that is receiving an active multicast session and transitioning to an RRC inactive state may perform one or more of the following actions.

[0609] First, the UE can obtain an indication of whether a cell is broadcasting or multicasting an MBS session. Based on this indication, the UE can support cell reselection for those cells that are transmitting MBS sessions. This can be based on the priority of the MBS sessions.

[0610] Second, the UE can be configured to send an indication to the network whether it has detected problems with broadcast or multicast reception when it is in RRC inactivity. For example, the UE can be configured with a HARQ threshold, and the UE can monitor the number of failed transport blocks. If the UE observes that the percentage of failed transport blocks exceeds this threshold, the UE can send an indication to the network. As a second example, the UE can be configured with a minimum required reception level (e.g., minimum RSRP) or a minimum required quality level (e.g., RSRQ) in the cell. If the observed cell reception level or quality is below this threshold, the UE can send an indication to the network. The UE can send this indication when it is in RRC inactivity, or the UE can switch to an RRC connection to send this indication. Upon receiving this indication, the gNB can decide to take an action to help the UE receive MBS services. For example, modifying the MCS, increasing the transmit power, increasing the number of blind HARQ retransmissions, etc.

[0611] This document describes the procedure for reliable transmission when MBS is preempted, providing a solution to problem 7 described above. When a URLLC service request is present, whether within a scheduling cycle or in the middle of an eMBB, mMTC, or MBS transmission, the gNB can immediately transmit URLLC packets. In other words, to support URLLC packet transmission, ongoing eMBB, mMTC, or MBS transmissions can be stopped without notification.

[0612] Figure 11 An exemplary transport block 1100 is shown. Figure 11 In the example, when a TB comprising three code blocks 1111, 1112, and 1113 (e.g., a TB including MBS data 1101) is transmitted for MBS service, each code block 1111, 1112, and 1113 can be sequentially mapped to the scheduled time-frequency resource. Therefore, when a URLLC service is initiated in the middle of MBS transport block 1101, a portion of the symbols in the second code block is replaced by the symbols of URLLC packet 1114.

[0613] For example, a transport block of an MBS transmission can be preempted by a higher-priority transport from the gNB. The UE in the MBS group receiving the preempted transport block needs to be notified of this preemption. The gNB can notify the UE that the transport has been preempted by using INT-RNTI (Preemption Indication RNTI).

[0614] UEs in the MBS group can also monitor INT-RNTI. If a new transmission is preempted, all UEs in the MBS group will obviously fail to decode the transport block. If all UEs in the MBS group send HARQ feedback, this could lead to uplink issues. Since the gNB can determine that the initial transmission will be NACKed, it may not be beneficial to have all UEs in the MBS group send HARQ feedback.

[0615] If retransmission is preempted, some UEs in the MBS group may be able to decode the transport block. (Using data from...) Figure 11 For example, some UEs may be waiting to decode code block 1 1111, and may have already decoded code block 2 1112. Therefore, preemption of code block 2 1112 will not affect these UEs.

[0616] The UE can determine whether to send HARQ feedback for a preempted transport block based on whether it is a new transport or a retransmission. If it is a new transport, the UE may not send HARQ feedback for the preempted transport block. Alternatively, the UE can be configured to never send HARQ feedback for any preempted MBS transport (regardless of whether the MBS transport is a new transport or a retransmission). Alternatively, the UE can determine whether to send HARQ feedback for a preempted transport block based on an indication from the gNB. It is proposed that the gNB may also include an indication in the DCI scrambled with INT-RNTI whether the UE should send feedback. For example, this could be a 1-bit field where "1" indicates that the UE can send feedback, and "0" indicates that the UE should not send feedback.

[0617] This document describes the DRX granularity for NR MBS, providing a solution to problem 8 described above. Below, the term DRX MBS configuration is used to refer to the DRX configuration for MBS services, to distinguish it from the DRX configuration for unicast services. Similarly, the term MBS DRX operation is used to refer to DRX-related actions at the UE related to MBS service reception. Likewise, to differentiate between DRX timers for unicast and MBS service reception, qualifiers are sometimes added to timer names. For example, MBS retransmission timer can refer to the retransmission timer used for MBSDRX operation.

[0618] The granularity of DRX used for unicast transmission can be per UE per DRX group, where a DRX group can be a set of serving cells. That is, a UE can have a single DRX configuration for each DRX group. For LTE eMBMS transmission, the granularity of DRX can be based on SC-MTCH (logical channel). However, LTE eMBMS only allows one service per SC-MTCH and only maps one service per G-RNTI. Effectively, this results in the UE having an MBSDRX granularity per G-RNTI. For NR MBS, many MBS services can be mapped to G-RNTI and multiplexed in the same transport block. The MBSDRX granularity can be one of the following or a combination thereof.

[0619] By MTCH logical channel: Each logical channel can have its own DRX configuration;

[0620] By MBS session: Each MBS session can have its own DRX configuration. When an MBS session can transmit on multiple logical channels, the MBSDRX configuration will be applied to each of these logical channels.

[0621] Grouped RNTI (G-RNTI): Each G-RNTI can have its own DRX configuration. Since a G-RNTI can reuse multiple MTCHs, the DRX configuration will be the same for each logical channel.

[0622] By group RNTI used for MCCH (SC-RNTI): Each SC-RNTI can have its own DRX configuration.

[0623] When the MBSDRX granularity can be defined by MTCH logical channel or by MBS session, the gNB can determine a single MBSDRX configuration for G-RNTI. This single MBSDRX configuration is based on the combined DRX requirements of the MTCH logical channel and MBS session multiplexed on G-RNTI.

[0624] The UE can be configured with MBSDRX configuration for each G-RNTI it is monitoring, MBSDRX configuration for each SC-RNTI it may be monitoring, and unicast DRX configuration for each DRX group.

[0625] This article describes the DRX configuration for NR MBS, which provides a solution to problem 9.

[0626] The following DRX configuration parameters can be applied to MBSDRX:

[0627] drxMBS-onDurationTimer: The duration at the start of the MBSDRX loop;

[0628] drxMBS-SlotOffset: The delay before starting drx-onDurationTimer;

[0629] drxMBS-InactivityTimer: The duration following the PDCCH timing of a new DL or MBS transmission by a MAC entity, where the PDCCH indicates the time elapsed after the transmission.

[0630] drxMBS-RetransmissionTimerDL (by DL HARQ process): The maximum duration until an SL retransmission becomes available;

[0631] drxMBS-LongCycleStartOffset: The drxMBS-StartOffset for long MBSDRX cycles and for defining the subframes that start with long MBSDRX cycles and short MBSDRX cycles;

[0632] drxMBS-ShortCycle (optional): MBSDRX loop;

[0633] drxMBS-ShortCycleTimer (optional): The UE should follow the duration of the short MBSDRX cycle;

[0634] drxMBS-HARQ-RTT-TimerDL (by DL HARQ process): The MAC entity can anticipate the minimum duration prior to the DL assignment for HARQ MBS retransmission.

[0635] Individual MBSDRX configurations can be applied to each G-RNTI configured in the UE. Individual MBSDRX configurations can be applied to each SC-RNTI configured in the UE.

[0636] The MAC entity can be configured with MBSDRX functionality via RRC. This MBSDRX functionality controls the UE's PDCCH monitoring activities for the MAC entity's G-RNTI and SC-RNTI. When MBS transmission uses the PTP scheme or PTM scheme 2, the MBSDRX functionality also controls the UE's PDCCH monitoring activities for the MAC entity's C-RNTI. Furthermore, the MBSDRX functionality can also control the UE's PDCCH monitoring activities for the MAC entity's INT-RNTI. When in RRC_CONNECTED mode, if MBSDRX is configured, the MAC entity can use MBSDRX operation to monitor the PDCCH discontinuously for all active serving cells.

[0637] When MBSDRX loop is configured, the active time includes the time in the following cases:

[0638] The drxMBS-onDurationTimer or drxMBS-InactivityTimer configured for G-RNTI, SC-RNTI, or C-RNTI can be running; or

[0639] drxMBSRetransmissionTimerDL is running.

[0640] This document describes the UE DRX procedure, which provides a solution to problem 10. In the following example, the description can be based on MBS transmission over G-RNTI. It should be understood that this simplifies the description, and the procedure can be applied to any group RNTI used for MBS transmission. Therefore, the procedure can also be applied to MBS transmission over SC-RNTI.

[0641] MBS transmissions to the G-RNTI are to a group of UEs (hereinafter referred to as the MBS group). If the MBSDRX configuration is based on the G-RNTI, each UE in this MBS group has the same MBSDRX configuration. For MBS services, the gNB has various options for MBS HARQ transmissions and retransmissions, such as:

[0642] PTP scheme: For RRC_CONNECTED UEs, use a UE-specific PDCCH with a CRC scrambled by a UE-specific RNTI (e.g., C-RNTI) to schedule a UE-specific PDSCH that can be scrambled with the same UE-specific RNTI.

[0643] PTM Scheme 1: For RRC_CONNECTED UEs in the same MBS group, a group common PDCCH with a CRC scrambled by the group common RNTI is used to schedule a group common PDSCH that is also scrambled by the same group common RNTI. This scheme can also be referred to as a group scheduling scheme based on the group common PDCCH.

[0644] PTM Scheme 2: For RRC_CONNECTED UEs in the same MBS group, a group common PDSCH that can be scrambled with a group common RNTI is scheduled using a UE-specific PDCCH with a CRC scrambled by a UE-specific RNTI (e.g., C-RNTI). This scheme can also be referred to as a group scheduling scheme based on UE-specific PDCCH.

[0645] In addition, the UE may have the following options for HARQ feedback for multicast (the options used can be configured by the gNB):

[0646] No HARQ feedback;

[0647] HARQ-ACK feedback based on ACK / NACK;

[0648] HARQ-ACK feedback based on NACK only.

[0649] In order to utilize the DRX configuration, all UEs in the gNB and MBS group can be synchronized in terms of when to start and stop various timers (including inactive timers, HARQ RTT timers, and retransmission timers).

[0650] An inactivity timer can be started for each new MBS transmission received by the UE. An inactivity timer can be started at the UE:

[0651] When the UE receives a DCI indicating that the PTP scheme MBS is transmitted with the UE's C-RNTI as the destination;

[0652] When the UE receives a DCI indicating a PTM scheme 1MBS transmission to the UE's G-RNTI, the DCI can be scrambled with a group common RNTI.

[0653] When a UE receives a DCI indicating a PTM scheme 2MBS transmission to the UE's G-RNTI, the DCI can be scrambled by a UE-specific RNTI (e.g., C-RNTI).

[0654] For PTM scheme 1MBS transmissions to G-RNTI, it is possible that: due to MTCH channel multiplexing, the transport block does not contain any MTCH channels (hereinafter also referred to as interested MTCH channels) for the MBS session of interest to the UE. In such cases, the UE can stop the inactive timer after decoding the transport block and determining that the transport block does not contain any interested MTCH channels. Alternatively, for PTM scheme 1MBS transmissions to G-RNTI, if the transport block does not contain any interested MTCH channels, the UE can be informed how to manage the inactive timer. For example, if the transport block does not contain any interested MTCH channels, the DCI scheduling the transport block may include a 1-bit indication informing the UE to stop the inactive timer. As another example, if the transport block does not contain any interested MTCH channels, the MAC header may include an indication informing the UE to stop the inactive timer.

[0655] Figure 12 Various exemplary options 1200 for the UE are shown. It can be assumed that UE1 and UE2 are in the same MBS group and have the same DRX configuration for G-RNTI.

[0656] Step 1201: UE1 and UE2 can be in the same MBS group and share the DRX configuration.

[0657] Step 1202: During the MBSDRX activity period configured in DRX, UE1 and UE2 receive DCIs that schedule MBS transmissions. Depending on the transmission scheme (PTP scheme, PTM scheme 1, PTM scheme 2), UE monitoring is configured for one or more of C-RNTI, G-RNTI, or SC-RNTI for UE1 and UE2.

[0658] Step 1203a: UE1 can configure an inactivity timer for this DRX.

[0659] Step 1204a: UE1 can successfully decode the transport block.

[0660] Step 1205a: According to the HARQ feedback configuration, UE1 can send an ACK to gNB.

[0661] Step 1206a: If UE1 determines that the transport block does not contain the MTCH of interest, then for PTM scheme 1, UE1 can stop the inactive timer.

[0662] Note that, as an alternative to step 1205a, UE1 may send an ACK to the gNB only after decoding the transport block. If the transport block contains an MTCH of interest, UE1 may send an ACK to the gNB. If the transport block does not contain an MTCH of interest, UE1 may send an ACK or some other indication to the gNB to tell the gNB that the transport block was correctly received but is not of interest to UE1.

[0663] Step 1203b: UE2 can configure an inactivity timer for this DRX.

[0664] Step 1204b: UE2 may be unable to decode transport blocks.

[0665] Step 1205b: Based on the HARQ feedback configuration, UE2 can send a NACK to the gNB and start the HARQ RTT timer for the HARQ process.

[0666] Step 1206b: When the HARQ RTT timer expires, UE2 can start the retransmission timer.

[0667] The first problem to be solved is which RNTI the UE monitors while the retransmission timer is running. The UE is unaware of the scheme used for retransmissions. In a first alternative, UE2 can monitor both C-RNTI and G-RNTI while the retransmission timer is running. In a second alternative, UE2 can monitor either C-RNTI or G-RNTI while the retransmission timer is running. UE2 can make this determination based on its configuration. For example, UE2 can be configured to know which retransmissions are using the PTP scheme. Alternatively, UE2 can make this determination based on an indication in the initial transmission that tells the gNB how to send retransmissions (if any retransmissions are needed). For example, the initial transmission DCI can contain a 1-bit field indicating that retransmissions will use PTM scheme 1. Note that this indication can also be included in the DCI that schedules each retransmission to tell the UE how to send any subsequent or future retransmissions. In a third alternative, UE2 monitors C-RNTI during unicast DRX activity time. The gNB can ensure that it will send all DCIs that schedule MBS retransmissions during unicast DRX activity time.

[0668] The second problem to be addressed relates to retransmission timers. Note that, as described above, a single MBS transmission can lead to potentially different actions at the UE depending on whether the transport block can be successfully decoded. UEs that have not yet successfully decoded the transport block expect a retransmission. These UEs may start a HARQ RTT timer. These UEs may also start a retransmission timer to receive retransmissions. However, for UEs that have successfully decoded the transport block, a retransmission is not expected. These UEs will not start either the HARQ RTT timer or the retransmission timer. Since not all UEs in the MBS group will start a retransmission timer, it has been proposed that the gNB suppress the transmission of new transmissions while the retransmission timer is running, otherwise UEs that have not started a retransmission timer may not receive these new transmissions. However, for those UEs that do start a retransmission timer, there may be a problem. The gNB cannot use the time during which the retransmission timer can run to schedule new transmissions. The gNB can only schedule retransmissions. The gNB will likely only schedule a certain number of retransmissions. After that, the gNB will likely attempt to schedule a new transmission. In this case, if the UE sends a NACK for this last retransmission, the UE can trigger a retransmission timer, but there will be no transmission coming from the gNB. This could waste power-saving opportunities. The retransmission timer triggered by this event may expire; however, the UE behavior upon expiration of the retransmission timer may not be specified. To avoid both of these issues, it is proposed that the gNB can indicate whether the transmission is the last transmission or the last retransmission of a transport block. If so, and the UE fails to decode the transport block, the UE can decide not to start the HARQ RTT timer. The UE can also decide not to start the retransmission timer. Alternatively, the UE behavior upon expiration of the retransmission timer can be specified. For example, upon expiration of the retransmission timer, the UE can:

[0669] 2> If a short MBSDRX loop is configurable:

[0670] 3> Start or restart drxMBS-ShortCycleTimer for this G-RNTI in the first symbol after drxMBS-RetransmissionTimer expires;

[0671] 3> Use a short MBSDRX loop for this G-RNTI.

[0672] 2> Otherwise:

[0673] 3> Use a long MBSDRX loop for this G-RNTI.

Claims

1. A wireless transmit / receive unit (WTRU) comprising a processor and a memory, the processor and memory being configured to: receiving multicast / broadcast service (MBS) configuration information, the MBS configuration information comprising first MBS discontinuous reception (DRX) configuration information associated with a first group radio network temporary identifier (G-RNTI), second MBS DRX configuration information associated with a second G-RNTI, configuration information associated with at least a first MBS radio bearer (MRB), and an indication of one or more logical channel IDs (LCIDs) associated with the first MRB, wherein, The configuration information associated with the first MRB includes initial values ​​for variables used to determine which Packet Data Convergence Protocol (PDCP) packets to discard; the first MBS DRX configuration information indicates the values ​​of the first MBS DRX enable duration timer, the first MBS DRX slot offset, the first MBS DRX inactivity timer, the first MBS DRX cycle length, the first MBS DRX cycle start offset, the first MBS DRX downlink (DL) retransmission timer, and the first MBS DRX hybrid automatic repeat request (HARQ) round-trip time (RTT) timer; and the second MBS DRX configuration information indicates the values ​​of the second MBS DRX enable duration timer, the second MBS DRX slot offset, the second MBS DRX inactivity timer, the second MBS DRX cycle length, the second MBS DRX cycle start offset, the second MBS DRX DL retransmission timer, and the second MBS DRX HARQ RTT timer. During the first DRX active time associated with the first MBS DRX configuration information, the first G-RNTI is used to monitor the transmission of the physical downlink control channel (PDCCH), wherein the first active time includes the time during which the first MBS DRX enable duration timer, the first MBS DRX inactivity timer, or the first MBS DRX DL retransmission timer is running; During the second DRX active time associated with the second MBS DRX configuration information, PDCCH transmission is monitored using the second G-RNTI, wherein the second active time includes the time during which the second MBS DRX enable duration timer, the second MBS DRX inactivity timer, or the second MBS DRX DL retransmission timer is running; Use at least one of the first G-RNTI or the second G-RNTI to receive at least one PDCCH transmission; Based on the at least one PDCCH transmission, the transport block is decoded; At least one Media Access Control (MAC) Protocol Data Unit (PDU) is determined from the transport block. Discard the first data from the at least one MAC PDU associated with an LCID that is not one of the indicated LCIDs; and Based on the variables used to determine which PDCP packets to discard, it is determined whether to discard the second data corresponding to the PDCP PDU that comes from the at least one MAC PDU and is associated with an LCID that is one of the indicated LCIDs.

2. The WTRU according to claim 1, wherein the MBS configuration information includes PDCP layer configuration.

3. The WTRU according to claim 1, wherein the MBS configuration information includes Media Access Control (MAC) layer configuration.

4. The WTRU of claim 1, wherein the variable used to determine the PDCP packets to be discarded is RX_DELIV.

5. The WTRU of claim 4, wherein determining whether to discard the second data includes a comparison between the RX_DELIV and the COUNT value.

6. The WTRU according to claim 1, wherein the transport block includes MBS service.

7. The WTRU according to claim 6, wherein the MBS service includes broadcast service, multicast service or unicast service.

8. The WTRU of claim 1, wherein decoding the transport block includes demultiplexing the transport block at the MAC layer.

9. The WTRU of claim 1, wherein decoding the transport block includes disassembling the transport block at the MAC layer.

10. The WTRU of claim 1, wherein the processor and memory are further configured to start a first MBS DRX DL retransmission timer or a second MBS DRX DL retransmission timer after a failure to decode the transport block.

11. A method comprising: The system receives Multicast / Broadcast Service (MBS) configuration information, which includes first MBS Discontinuous Receive (DRX) configuration information associated with a first set of Radio Network Temporary Identifiers (G-RNTIs), second MBS DRX configuration information associated with a second G-RNTI, configuration information associated with at least a first MBS Radio Bearer (MRB), and indications of one or more Logical Channel IDs (LCIDs) associated with the first MRB. The configuration information associated with the first MRB includes initial values ​​for variables used to determine which Packet Data Convergence Protocol (PDCP) packets to discard. The first MBS DRX configuration information indicates the values ​​of a first MBS DRX on-duration timer, a first MBS DRX timeslot offset, a first MBS DRX inactivity timer, a first MBS DRX cycle length, a first MBS DRX cycle start offset, a first MBS DRX downlink (DL) retransmission timer, and a first MBS DRX Hybrid Automatic Repeat Request (HARQ) round-trip time (RTT) timer. The second MBS DRX configuration information indicates the values ​​of a second MBS DRX on-duration timer, a second MBS DRX timeslot offset, and a second MBS DRX LCID. The values ​​of the DRX inactive timer, the second MBS DRX cycle length, the second MBS DRX cycle start offset, the second MBS DRX DL retransmission timer, and the second MBS DRX HARQ RTT timer; During the first DRX active time associated with the first MBS DRX configuration information, the first G-RNTI is used to monitor the transmission of the physical downlink control channel (PDCCH), wherein the first active time includes the time during which the first MBS DRX enable duration timer, the first MBS DRX inactivity timer, or the first MBS DRX DL retransmission timer is running; During the second DRX active time associated with the second MBS DRX configuration information, PDCCH transmission is monitored using the second G-RNTI, wherein the second active time includes the time during which the second MBS DRX enable duration timer, the second MBS DRX inactivity timer, or the second MBS DRX DL retransmission timer is running; Use at least one of the first G-RNTI or the second G-RNTI to receive at least one PDCCH transmission; Based on the at least one PDCCH transmission, the transport block is decoded; At least one Media Access Control (MAC) Protocol Data Unit (PDU) is determined from the transport block. Discard the first data from the at least one MAC PDU associated with an LCID that is not one of the indicated LCIDs; and Based on the variables used to determine which PDCP packets to discard, it is determined whether to discard the second data corresponding to the PDCP PDU that comes from the at least one MAC PDU and is associated with an LCID that is one of the indicated LCIDs.

12. The method according to claim 11, wherein the MBS configuration information includes PDCP layer configuration.

13. The method of claim 11, wherein the MBS configuration information includes Media Access Control (MAC) layer configuration.

14. The method of claim 11, wherein the variable used to determine the PDCP packets to be discarded is RX_DELIV.

15. The method of claim 14, wherein determining whether to discard the second data includes a comparison between the RX_DELIV and the COUNT value.

16. The method of claim 11, wherein the transport block includes MBS service.

17. The method of claim 16, wherein the MBS service includes broadcast service, multicast service or unicast service.

18. The method of claim 11, wherein decoding the transport block includes demultiplexing the transport block at the MAC layer.

19. The method of claim 11, wherein decoding the transport block includes disassembling the transport block at the MAC layer.

20. A wireless transmit / receive unit (WTRU) comprising a processor, a memory, and a transceiver, the WTRU being configured to: receiving multicast / broadcast service (MBS) configuration information, the MBS configuration information comprising first MBS discontinuous reception (DRX) configuration information associated with a first group radio network temporary identifier (G-RNTI), second MBS DRX configuration information associated with a second G-RNTI, configuration information associated with at least a first MBS radio bearer (MRB), and an indication of one or more logical channel IDs (LCIDs) associated with the first MRB, wherein, The configuration information associated with the first MRB includes initial values ​​for variables used to determine which Packet Data Convergence Protocol (PDCP) packets to discard; the first MBS DRX configuration information indicates the values ​​of the first MBS DRX enable duration timer, the first MBS DRX slot offset, the first MBS DRX inactivity timer, the first MBS DRX cycle length, the first MBS DRX cycle start offset, the first MBS DRX downlink (DL) retransmission timer, and the first MBS DRX hybrid automatic repeat request (HARQ) round-trip time (RTT) timer; and the second MBS DRX configuration information indicates the values ​​of the second MBS DRX enable duration timer, the second MBS DRX slot offset, the second MBS DRX inactivity timer, the second MBS DRX cycle length, the second MBS DRX cycle start offset, the second MBS DRX DL retransmission timer, and the second MBS DRX HARQ RTT timer. During the first DRX active time associated with the first MBS DRX configuration information, the first G-RNTI is used to monitor the transmission of the physical downlink control channel (PDCCH), wherein the first active time includes the time during which the first MBS DRX enable duration timer, the first MBS DRX inactivity timer, or the first MBS DRX DL retransmission timer is running; During the second DRX active time associated with the second MBS DRX configuration information, PDCCH transmission is monitored using the second G-RNTI, wherein the second active time includes the time during which the second MBS DRX enable duration timer, the second MBS DRX inactivity timer, or the second MBS DRX DL retransmission timer is running; Use at least one of the first G-RNTI or the second G-RNTI to receive at least one PDCCH transmission; Based on the at least one PDCCH transmission, the transport block is decoded to obtain a Media Access Control (MAC) Protocol Data Unit (PDU). Identify at least one Media Access Control (MAC) Service Data Unit (SDU) of the MAC PDU. Discard the at least one MAC SDU associated with an LCID that is not one of the one or more LCIDs; and Based on the variables used to determine which PDCP packets to discard, it is determined whether to discard a PDCP PDU that originates from the MAC PDU and is associated with an LCID that is one or more LCIDs.

Images