CN118018965A - 5G multicast-broadcast service (MBS): multiplexing, reliability and power saving - Google Patents

Abstract

The present disclosure relates to 5G multicast-broadcast services (MBS): multiplexing, reliability and power saving. Methods and apparatus for multicast/broadcast services are described herein. The embodiments described herein relate to procedures for managing multiplexed MBS services, for prioritization between MBS-related UL services, unicast UL services and SL services, for handling HARQ retransmissions on C-RNTI, for supporting PDCP status reports for MBS services, and for having a wireless transmit/receive unit WTRU join a multicast session that has been started/activated. 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 de-multiplexing of traffic may be performed at the SDAP layer. The WTRU may be configured to demultiplex multiple logical channels across different MBS services, where the logical channels are received on the same transport block.

Description

5G multicast-broadcast service (MBS): multiplexing, reliability and power saving

The application is characterized in that the international application date is 2022, 3 and 31, the national application number is 202280033749.9, and the application is 5G multicast-broadcast service (MBS): multiplexing, reliability and power saving "to PCT application at the national stage of china.

The present application claims the benefit of U.S. provisional patent application No. 63/168,710, filed 3/31 in 2021, and U.S. provisional patent application No. 63/185,726, filed 5/7 in 2021, which are hereby incorporated by reference in their entireties.

Background

Multicast/broadcast services (MBS) may be provided over a new air interface (NR) and are intended to have various QoS requirements. The delivery of this traffic to the UE of interest is intended to be very flexible and adaptable as well. The network may be able to dynamically change the manner in which traffic is delivered to the UE. However, this flexibility and the varying QoS requirements that are expected to be supported lead to a number of problems with respect to efficient transmission of such MBS services. The problems experienced by MBS relate to how to configure MBS radio bearers for services, how to multiplex MBS services efficiently, how to improve reliability of MBS transmissions, and how to cope with starting to receive MBS services already received by other UEs. Thus, improved MBS techniques are needed.

Disclosure of Invention

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to solving any or all disadvantages noted in any part of this disclosure.

Methods and apparatus for multicast/broadcast services (MBS) are described herein. The embodiments described herein relate to procedures for managing multiplexed MBS traffic, for prioritization between MBS-related UL traffic, unicast UL traffic and SL traffic, for handling HARQ retransmissions on cell radio network temporary identifiers (C-RNTIs), for supporting PDCP status reports for MBS services, and for joining wireless transmit/receive units (WTRUs) to multicast sessions that have been started/activated. 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 the MBS services, and the demultiplexing of traffic may be performed at the SDAP layer. The SDAP entity can de-multiplex multiple MBS quality of service (QoS) streams across different MBS services. The WTRU may de-multiplex traffic at the MAC layer. The WTRU may be configured to demultiplex multiple logical channels across different MBS services, where the logical channels are received on the same transport block.

Drawings

The foregoing summary, as well as the following detailed description of the invention, will be better understood when read in conjunction with the appended drawings. To demonstrate the disclosure, various aspects of the disclosure are shown. However, the present disclosure is not limited to the specific aspects discussed. In the drawings:

FIG. 1A illustrates one embodiment of an exemplary communication system in which the methods and apparatus described and claimed herein may be embodied;

Fig. 1B is a block diagram of an example apparatus or device configured for wireless communication, such as, for example, a wireless transmit/receive unit (WTRU), in accordance with embodiments shown herein;

fig. 1C is a system diagram of a RAN and a core network according to one embodiment;

fig. 1D is a system diagram of a RAN and a core network according to one embodiment;

fig. 1E is a system diagram of a RAN and a core network according to one embodiment;

FIG. 1F is a block diagram of an exemplary computing system in which one or more devices of the communication networks shown in FIGS. 1A, 1C, 1D, and 1E may be implemented;

FIG. 1G illustrates one embodiment of an exemplary communication system in which the methods and apparatus described and claimed herein may be embodied;

Fig. 2 shows an example of MBSFN transmission;

fig. 3A and 3B illustrate examples of multiplexing of MBS services;

fig. 4 shows an example of multiplexing of MBS service and unicast service;

Fig. 5 shows an example of a new MAC header;

Fig. 6 shows an example of initial transmission on a group radio network temporary identifier (G-RNTI) and HARQ retransmission on a C-RNTI;

fig. 7 shows an example of an MBS HARQ process alternative;

fig. 8 illustrates an exemplary RLC UM window;

Fig. 9 illustrates an exemplary RLC AM window;

fig. 10 shows an example of HARQ feedback;

FIG. 11 shows an example of preempting MBS transmissions; and

Fig. 12 shows an example of HARQ RTT and retransmission timer.

Detailed Description

Methods and apparatus for multicast/broadcast services (MBS) are described herein. For illustrative purposes, the techniques described herein may be described as being performed in a UE or a gNB, but 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 a WTRU or a base station.

The following abbreviations and definitions may be used herein:

5QI 5G QoS identifier

AM acknowledged mode

ARQ automatic repeat request

BM-SC broadcast multicast service center

CRC cyclic redundancy check

DCI downlink control information

DL downlink

DL SCH DL shared channel

DRB data radio bearer (unicast)

DRX discontinuous reception

EMBB enhanced moving broadband

EMTC enhanced machine type communication

ENBE-UTRAN node B

GNB NR node B

G-RNTI group RNTI

GBR guaranteed bit rate

GW gateway

Hybrid HARQ ARQ

IoT (Internet of things)

ITS intelligent transportation system

L2 layer 2

LTE long term evolution

MAC medium access control

MBMS multicast/broadcast multimedia service

MBS multicast/broadcast service

MBSFN multicast broadcast single frequency network

MCE multi-cell/multicast coordination entity

MCH multicast transmission channel

MMTC Large Scale machine type communication

MooD on-demand MBMS operation

MRB MBS radio bearer

MTCH multicast traffic channel

NB-IoT narrowband IoT

NR new air interface

PDCP packet data convergence protocol

PDCCH physical downlink control channel

PDSCH physical downlink shared channel

PMCH physical multicast channel

PTP point-to-point

PTM point-to-multipoint

QoS or QOS quality of service

RAN radio access node

RLC radio link control

RoHC robust header compression

ROM receive-only mode

RSRP reference signal received power

SC single cell

SDAP service data adaptation protocol

SL side-links

TB transport block

UCI uplink control information

UE user equipment

UM unacknowledged mode

URLLC ultra-reliable low-delay communications

V2X vehicle universal article

The following terms are used herein:

Multicast service: unidirectional point-to-multipoint services in which data is effectively transmitted from a single source to a multicast group in an associated multicast service area. The multicast service may only be received by such users that subscribe to a particular multicast service and have joined the multicast group associated with the particular service.

Broadcast service: unidirectional point-to-multipoint services in which data is effectively transmitted from a single source to multiple UEs in an associated broadcast service area. The broadcast service may be received by all users that have enabled a particular broadcast service locally on their UEs and are in a broadcast area defined for that service.

PTP: the term used in a radio access network indicates that over-the-air transmissions are from a single RAN node to a single UE.

PTM: the term used in a radio access network indicates that over-the-air transmissions are from a single RAN node to multiple UEs. PTM transmissions from multiple cells may be combined to create a multi-cell PTM transmission

MBS session: core network delivery mechanism for MBS services

Multicast session: core network delivery mechanism for multicast sessions

Broadcast session: core network delivery mechanism for broadcast sessions

MBS radio bearers: radio bearers for MBS services. The MBS radio bearer may be of split bearer type with PTP leg/path and PTM leg/path. Alternatively, the MBS radio bearer may be a non-split bearer of the PTM type.

Splitting the bearer: a radio bearer of the type having two branches/paths. In the case of MBS, one of these legs is the PTP leg and the other leg is the PTM leg. The anchor to split the bearer may be at different layers: SDAP, PDCP, RLC, MAC.

Group RNTI: RNTI for a group of UEs. May also be referred to as a group common RNTI.

PTP path or PTP leg: splitting one leg of a bearer, wherein a transport block is transmitted to a single UE using a C-RNTI

PTM path of PTM leg: one leg of the bearer is split, where the transport block is transmitted to multiple UEs, all sharing the same G-RNTI.

PTP transmission: the gNB delivers separate copies of MBS data packets to each UE separately, i.e., the gNB uses a UE-specific PDCCH with CRC scrambled by a UE-specific RNTI (e.g., C-RNTI) to schedule a UE-specific PDSCH scrambled with the same UE-specific RNTI.

PTM transmission: the gNB delivers a single copy of the MBS data packet to a group of UEs, i.e., the gNB uses the group common PDCCH with CRC scrambled by the group common RNTI to schedule the group common PDSCH scrambled with the same group common RNTI.

MBS transmission: transmission of MBS services.

Unicast transmission: transmission of unicast services.

MBS group: a group of UEs receiving MBS transmissions and sharing G-RNTI.

LTE MBMS overview and restriction

Multicast/broadcast multimedia services (MBMS) are characterized by the distribution of content of common interest from one source entity to a plurality of receiving entities interested in the service. Mobile networks are designed mainly for unicast services and are therefore not optimized for multicast/broadcast services. Therefore, providing multicast/broadcast services requires optimizing how traffic from these services is transmitted through the core network and through the radio access network.

The 3 rd generation partnership project (3 GPP) developed technical standards for cellular telecommunication network technology including radio access, core transport network and service capabilities, including research on codec, 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 standards. The 3GPP has begun to address the standardization of the next generation cellular technology (also referred to as "5G") known as new air interface (NR). The development of the 3GPP NR standard is expected to include the definition of the next generation radio access technology (new RAT), which is expected to include providing new flexible radio access below 6GHz and providing new ultra mobile broadband radio access above 6 GHz. The flexible radio access is intended to include new non-backward compatible radio access in a new spectrum below 6GHz and to include different modes of operation that can be multiplexed together in the same spectrum to address a broad set of 3GPP NR use cases with different requirements. Ultra mobile broadband is expected to include the centimeter and millimeter wave spectrum that would provide opportunities for ultra mobile broadband access such as indoor applications and hotspots. In particular, ultra mobile broadband is expected to share a common design framework with flexible radio access below 6GHz, with centimeter wave and millimeter wave specific design optimizations.

3GPP has identified a variety of use cases that NR expects to support, resulting in a wide variety of user experience requirements for data rate, delay, and mobility. The use cases include the following general categories: enhanced mobile broadband (e.g., broadband access in dense areas, indoor ultra-high broadband access, broadband access at crowds, 50+mbps everywhere, ultra-low cost broadband access, mobile broadband in vehicles); critical communication; large-scale machine type communication; network operations (e.g., network slicing, routing, migration and interworking, power saving); and enhanced internet of vehicles (eV 2X) communications, which may include any of vehicle-to-vehicle communications (V2V), vehicle-to-infrastructure communications (V2I), vehicle-to-network communications (V2N), vehicle-to-pedestrian communications (V2P), and vehicle-to-other entity communications. Specific services and applications in these categories include, for example: monitoring and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, cloud-based wireless office, first responder connection, automotive electronic call, disaster alert, real-time gaming, multi-person video call, autopilot, augmented reality, haptic internet and virtual reality, and so forth. All of these and other uses are contemplated herein.

Fig. 1A illustrates one embodiment of an exemplary communication system 100 in which the methods and apparatus described and claimed herein may be embodied. 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 be referred to generally or collectively as WTRUs 102), radio Access Networks (RANs) 103/104/105/103b/104b/105b, core networks 106/107/109, public Switched Telephone Networks (PSTN) 108, the internet 110, other networks 112, and V2X servers (or ProSe functions and servers) 113. It should be understood that any number of WTRUs, base stations, networks, and/or network elements are contemplated by the disclosed embodiments of the invention. Each of the WTRUs 102a, 102b, 102c, 102d, 102e, 102f, 102g may be any type of apparatus or device configured to operate and/or communicate in a wireless environment. Each of the WTRUs 102a, 102b, 102c, 102d, 102e, 102f, 102g may be configured to perform any of the methods described herein. Although each WTRU 102a, 102b, 102c, 102d, 102E, 102f, 102G is depicted in fig. 1A-1E as a handheld wireless communication device, it should be appreciated that each WTRU may include or be embodied in any type of apparatus or device configured to transmit and/or receive wireless signals, including by way of example only, a User Equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a Personal Digital Assistant (PDA), a smart phone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, a consumer electronic device, a wearable device (such as a smart watch or smart garment), a medical or electronic health device, a robot, industrial equipment, a drone, a vehicle (such as an automobile, truck, train or airplane), and so forth, utilizing a wide variety of use cases contemplated for 5G wireless communication.

Communication system 100 may also include a base station 114a and a base station 114b. The base station 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c to facilitate access to one or more communication networks, such as the core networks 106/107/109, the internet 110, and/or other networks 112. The base station 114b may be any type of device configured to interface, either wired and/or wireless, with at least one of the RRHs (remote radio heads) 118a, 118b, trps (transmission and reception points) 119a, 119b and/or RSUs (roadside units) 120a and 120b to facilitate access to one or more communication networks, such as the core network 106/107/109, the internet 110, other networks 112, and/or V2X servers (or ProSe functions and servers) 113. The RRHs 118a, 118b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102c to facilitate access to one or more communication networks, such as the core networks 106/107/109, the internet 110, and/or other networks 112. The TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102d to facilitate access to one or more communication networks, such as the core networks 106/107/109, the internet 110, and/or other networks 112. RSUs 120a and 120b may be any type of device configured to wirelessly interface with at least one of WTRUs 102e or 102f 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. By way of example, the base stations 114a, 114B may be transceiver base stations (BTSs), node bs, evolved node bs, home evolved node bs, site controllers, access Points (APs), wireless routers, and the like. Although the base stations 114a, 114b are each depicted as a single element, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

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, and the like. 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, and the like. The base station 114a may be configured to transmit and/or receive wireless signals within a particular geographic area, which may be referred to as a cell (not shown). The base station 114b may be configured to transmit and/or receive wired and/or wireless signals within a particular geographic area, which may be referred to as a cell (not shown). The cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, e.g., one transceiver for each sector of a cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and thus may utilize multiple transceivers for each sector of a cell.

The base station 114a may communicate with one or more of the WTRUs 102a, 102b, 102c over an air interface 115/116/117, which may 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) may be used to establish the air interfaces 115/116/117.

The base station 114b may communicate with one or more of the RRHs 118a, 118b, trp 119a, 119b, and/or RSUs 120a and 120b over a wired or air interface 115b/116b/117b, which may 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.). The air interfaces 115b/116b/117b may be established using any suitable Radio Access Technology (RAT).

The RRHs 118a, 118b, trps 119a, 119b, and/or RSUs 120a, 120b may communicate with one or more of the WTRUs 102c, 102d, 102e, 102f over an air interface 115c/116c/117c, which may be any suitable wireless communication link (e.g., radio Frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). The air interfaces 115c/116c/117c may be established using any suitable Radio Access Technology (RAT).

The WTRUs 102a, 102b, 102c, 102d, 102e, 102f, and/or 102g may communicate with each other over an air interface 115d/116d/117d (not shown in the figures), which may be any suitable wireless communication link (e.g., radio Frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible, centimeter wave, millimeter wave, etc.). The air interfaces 115d/116d/117d may be established using any suitable Radio Access Technology (RAT).

More specifically, as noted above, communication system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, or the like. For example, the base station 114a in the RAN 103/104/105 and the WTRUs 102a, 102b, 102c or RRHs 118a, 118b in the RAN 103b/104b/105b, TRPs 119a, 119b and RSUs 120a, 120b and the WTRUs 102c, 102d, 102e, 102f may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) terrestrial radio access (UTRA) that may use Wideband CDMA (WCDMA) to establish the 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).

In one embodiment, the WTRUs 102a, 102b, 102c or RRHs 118a, 118b, trp 119a, 119b and/or RSUs 120a, 120b in the base station 114a and RAN 103b/104b/105b, and the WTRUs 102c, 102d may implement a radio technology such as evolved UMTS terrestrial radio access (E-UTRA), which may use Long Term Evolution (LTE) and/or LTE-advanced (LTE-a) to establish the air interfaces 115/116/117 or 115c/116c/117c, respectively. In the future, air interfaces 115/116/117 may implement 3GPP NR techniques. LTE and LTE-a technologies include LTE D2D and V2X technologies and interfaces (such as side-link communications, etc.). The 3GPP NR technology includes NR V2X technology and interfaces (such as side-link communication, etc.).

In one embodiment, the base station 114a in the RAN 103/104/105 and the WTRUs 102a, 102b, 102c or RRHs 118a, 118b, TRP 119a, 119b and/or RSUs 120a, 120b in the RAN 103b/104b/105b, and the WTRUs 102c, 102d, 102e, 102f may implement radio technologies such as IEEE 802.16 (e.g., worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000 1X, CDMA EV-DO, temporary Standard 2000 (IS-2000), temporary Standard 95 (IS-95), temporary Standard 856 (IS-856), global System for Mobile communications (GSM), enhanced data rates for GSM evolution (EDGE), GSM EDGE (GERAN), and the like.

The base station 114c in fig. 1A may be, for example, a wireless router, home node B, home evolved node B, or access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area such as a business, home, vehicle, campus, etc. In one embodiment, the base station 114c and the WTRU 102e may implement a radio technology, such as IEEE 802.11, to establish a Wireless Local Area Network (WLAN). In one embodiment, the base station 114c and the WTRU 102d may implement a radio technology, such as IEEE 802.15, to establish a Wireless Personal Area Network (WPAN). In yet another embodiment, the base station 114c and the WTRU 102e may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-a, etc.) to establish a pico cell or femto cell. As shown in fig. 1A, the base station 114b may have a direct connection with the internet 110. Thus, the base station 114c may not need to access the Internet 110 via the core network 106/107/109.

The RANs 103/104/105 and/or the RANs 103b/104b/105b may communicate with a core network 106/107/109, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102 d. For example, the core network 106/107/109 may provide call control, billing services, mobile location based services, prepaid calls, internet connections, video distribution, etc., and/or perform advanced security functions, such as user authentication.

Although not shown in fig. 1A, it should be appreciated that RANs 103/104/105 and/or RANs 103b/104b/105b and/or core networks 106/107/109 may communicate directly or indirectly with other RANs that employ the same RAT as RANs 103/104/105 and/or RANs 103b/104b/105b or a different RAT. For example, the core network 106/107/109 may communicate with another RAN (not shown) employing a GSM radio technology in addition to being connected to the RAN 103/104/105 and/or the RAN 103b/104b/105b that may be utilizing an E-UTRA radio technology.

The core networks 106/107/109 may also act as gateways for the WTRUs 102a, 102b, 102c, 102d, 102e to access the PSTN 108, the internet 110, and/or other networks 112. PSTN 108 may include circuit-switched telephone networks that provide Plain Old Telephone Services (POTS). The internet 110 may include a global system for interconnecting computer networks and devices using common communication protocols, such as Transmission Control Protocol (TCP), user Datagram Protocol (UDP), and Internet Protocol (IP) in the TCP/IP internet protocol suite. Network 112 may include a wired or wireless communication network 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 employ the same RAT as RAN 103/104/105 and/or RAN 103b/104b/105b or a different RAT.

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

Fig. 1B is a block diagram of an example apparatus or device configured for wireless communication, such as, for example, WTRU 102, in accordance with an embodiment shown herein. As shown in fig. 1B, 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 source 134, a Global Positioning System (GPS) chipset 136, and other peripherals 138. It should be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment. In addition, embodiments contemplate that base stations 114a and 114B and/or nodes that base stations 114a and 114B may represent, such as, but not limited to, transceiver stations (BTSs), node bs, site controllers, access Points (APs), home node bs, evolved home node bs (evolved node bs), home evolved node bs (henbs), home evolved node B gateways, proxy nodes, and the like, may include some or all of the elements depicted in fig. 1B and described herein.

The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, application Specific Integrated Circuits (ASICs), field Programmable Gate Arrays (FPGAs) circuits, any other type of Integrated Circuit (IC), a state machine, or the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120, which may be coupled to a transmit/receive element 122. Although fig. 1B depicts the processor 118 and the transceiver 120 as separate components, it should be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

The transmit/receive element 122 may be configured to transmit signals to and receive signals from a base station (e.g., base station 114 a) over the air interfaces 115/116/117. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In one embodiment, the transmit/receive element 122 may be an emitter/detector configured to emit and/or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF signals and optical signals. It should be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

Further, although the transmit/receive element 122 is depicted as a single element in fig. 1B, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interfaces 115/116/117.

The transceiver 120 may be configured to modulate signals to be transmitted by the transmit/receive element 122 and demodulate signals received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. For example, thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs (such as UTRA and IEEE 802.11).

The processor 118 of the WTRU 102 may be coupled to a speaker/microphone 124, a keypad 126, and/or a display/touchpad/indicator 128 (e.g., a Liquid Crystal Display (LCD) display unit or an Organic Light Emitting Diode (OLED) display unit) and may receive user input data from the foregoing components. The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad/indicator 128. Further, the processor 118 may access information from and store data in any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The 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, and the like. In one embodiment, the processor 118 may never physically locate memory access information on the WTRU 102, such as on a server or home computer (not shown), and store the data in that memory.

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

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) regarding the current location of the WTRU 102. In addition to or in lieu of information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114 b) over the air interface 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 appreciated that the WTRU 102 may obtain location information by any suitable location determination method while remaining consistent with an embodiment.

The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software modules and/or hardware modules that provide additional features, functionality, and/or wired or wireless connections. The peripheral device 138 may include various sensors, such as accelerometers, biometrics (e.g., fingerprint) sensor, electronic compass, satellite transceiver, digital camera (for photo or video), universal Serial Bus (USB) port or other interconnect interface, vibration device, television transceiver, hands-free headset,Modules, frequency Modulation (FM) radio units, digital music players, media players, video game player modules, internet browsers, and the like.

The WTRU 102 may be embodied in other apparatuses or devices such as sensors, consumer electronics, wearable devices such as smart watches or smart clothing, medical or electronic hygiene devices, robots, industrial equipment, drones, vehicles such as cars, trucks, trains, or planes. The WTRU 102 may connect to other components, modules, or systems of such apparatuses or devices via one or more interconnect interfaces, such as an interconnect interface that may include one of the peripherals 138.

Fig. 1C is a system diagram of RAN 103 and core network 106 according to one embodiment. As described above, RAN 103 may communicate with WTRUs 102a, 102b, and 102c over air interface 115 using UTRA radio technology. RAN 103 may also communicate with core network 106. As shown in fig. 1C, the RAN 103 may include node bs 140a, 140B, 140C, which may each include one or more transceivers to communicate with the WTRUs 102a, 102B, 102C over the air interface 115. The node bs 140a, 140B, 140c may each be associated with a particular cell (not shown) within the RAN 103. RAN 103 may also include RNCs 142a, 142b. It should be appreciated that RAN 103 may include any number of node bs and RNCs while remaining consistent with an embodiment.

As shown in fig. 1C, the node bs 140a, 140B may communicate with the RNC 142 a. In addition, node B140 c may communicate with RNC 142B. The node bs 140a, 140B, 140c may communicate with the respective RNCs 142a, 142B via Iub interfaces. The RNCs 142a, 142b may communicate with each other via an Iur interface. Each of the RNCs 142a, 142B may be configured to control the respective node B140a, 140B, 140c to which it is connected. Furthermore, each of the RNCs 142a, 142b may be configured to perform or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, and so forth.

The core network 106 shown in fig. 1C 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. Although each of the foregoing elements are 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.

The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and MGW 144 may provide the WTRUs 102a, 102b, 102c with access to a circuit switched network, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and conventional landline communication devices.

The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. SGSN 148 may be coupled to GGSN 150. The SGSN 148 and GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

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

Fig. 1D is a system diagram of a RAN 104 and a core network 107 according to one embodiment. As noted above, the RAN 104 may communicate with the WTRUs 102a, 102b, and 102c over the air interface 116 using an E-UTRA radio technology. RAN 104 may also communicate with core network 107.

RAN 104 may include enode bs 160a, 160B, 160c, but it should be understood that RAN 104 may include any number of enode bs while remaining consistent with an embodiment. The enode bs 160a, 160B, 160c may each include one or more transceivers to communicate with the WTRUs 102a, 102B, 102c over the air interface 116. In one embodiment, the evolved node bs 160a, 160B, 160c may implement MIMO technology. Thus, the enode B160 a may use multiple antennas to transmit wireless signals to and receive wireless signals from the WTRU 102a, for example.

Each of the evolved node bs 160a, 160B, and 160c may be associated with a particular cell (not shown) and may be configured to process radio resource management decisions, handover decisions, user scheduling in the uplink and/or downlink, and so on. As shown in fig. 1D, the enode bs 160a, 160B, 160c may communicate with each other over an X2 interface.

The core network 107 shown in fig. 1D 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 are depicted as part of the core network 107, it should be appreciated that any of these elements may be owned and/or operated by an entity other than the core network operator.

MME 162 may be connected to each of evolved node bs 160a, 160B, and 160c in RAN 104 via an S1 interface and may function as a control node. For example, the MME 162 may be responsible for authenticating the user of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, 102c, and the like. MME 162 may also provide control plane functionality for switching between RAN 104 and other RANs (not shown) employing other radio technologies, such as GSM or WCDMA.

Service gateway 164 may be connected to each of evolved node bs 160a, 160B, and 160c in RAN 104 via an S1 interface. The serving gateway 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102 c. The serving gateway 164 may also perform other functions such as anchoring user planes during inter-enode B handover, triggering paging when downlink data is available to the WTRUs 102a, 102B, 102c, managing and storing the contexts of the WTRUs 102a, 102B, 102c, and so on.

The serving gateway 164 may also be connected to a PDN gateway 166 that may provide the WTRUs 102a, 102b, 102c with access to a packet-switched network, such as the internet 110, to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices.

The core network 107 may facilitate communication with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to a circuit-switched network (such as the PSTN 108) to facilitate communications between the WTRUs 102a, 102b, 102c and legacy landline communication devices. For example, the core network 107 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to a network 112, which may include other wired or wireless networks owned and/or operated by other service providers.

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

As shown in fig. 1E, the RAN 105 may include base stations 180a, 180b, 180c and an ASN gateway 182, but it should be understood that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 180a, 180b, 180c may each be associated with a particular cell in the RAN 105 and may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In one embodiment, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, the base station 180a may use multiple antennas to transmit wireless signals to and receive wireless signals from the WTRU 102a, for example. The base stations 180a, 180b, 180c may also provide mobility management functions such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and so on. The ASN gateway 182 may act as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and so forth.

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

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

As shown in fig. 1E, the RAN 105 may be connected to a core network 109. The communication link between the RAN 105 and the core network 109 may be defined as an R3 reference point, which includes, for example, protocols for facilitating data transfer and mobility management capabilities. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. Although each of the foregoing elements are depicted as part of the core network 109, it should be appreciated that any of these elements may be owned and/or operated by an entity other than the core network operator.

The MIP-HA may be responsible for IP address management and may enable the WTRUs 102a, 102b, and 102c to roam between different ASNs and/or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, 102c with access to a packet-switched network, such as the internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. AAA server 186 may be responsible for user authentication and support for user services. Gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to a circuit-switched network, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and conventional landline communication devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the network 112, which may include other wired or wireless networks owned and/or operated by other service providers.

Although not shown in fig. 1E, it should be understood that RAN 105 may be connected to other ASNs and core network 109 may be connected to other core networks. The communication link between the RAN 105 and the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs. The communication links between the core network 109 and other core networks may be defined as R5 reference points, which may include protocols for facilitating interworking between the home core network and the visited core network.

The core network entities described herein and shown in fig. 1A, 1C, 1D and 1E are identified by the names given to those entities in certain existing 3GPP specifications, but it should be understood that those entities and functionalities may be identified by other names in the future and that certain entities or functionalities may be combined in future specifications promulgated by 3GPP, including future 3GPP NR specifications. Thus, the particular network entities and functions described and illustrated in fig. 1A, 1B, 1C, 1D, and 1E are provided by way of example only, and it should be understood that the subject matter disclosed and claimed herein may be embodied or practiced in any similar communication system, whether presently defined or defined in the future.

Fig. 1F is a block diagram of an exemplary computing system 90 that may embody one or more devices of the communication networks shown in fig. 1A, 1C, 1D, and 1E, such as some nodes or functional entities in RANs 103/104/105, core networks 106/107/109, PSTN 108, internet 110, or other networks 112. The computing system 90 may comprise a computer or server and may be controlled primarily by computer readable instructions, which may be in the form of software, wherever or by whatever means such software is stored or accessed. Such computer readable instructions may be executed within processor 91 to cause computing system 90 to operate. Processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, application Specific Integrated Circuits (ASICs), field Programmable Gate Arrays (FPGAs) circuits, any other type of Integrated Circuit (IC), a state machine, or the like. Processor 91 may perform signal encoding, data processing, power control, input/output processing, and/or any other functionality that enables computing system 90 to operate in a communication network. Coprocessor 81 is an optional processor, different from main processor 91, that may perform additional functions or assist processor 91. Processor 91 and/or coprocessor 81 may receive, generate, and process data related to the methods and apparatus disclosed herein.

In operation, processor 91 fetches instructions, decodes and executes instructions, and transfers information to and from other resources via the main data transfer path (system bus 80) of the computing system. Such a system bus connects the components in computing system 90 and defines a medium for data exchange. The system bus 80 typically includes data lines for transmitting data, address lines for transmitting addresses, and control lines for transmitting interrupts and for operating the system bus. An example of such a system bus 80 is a PCI (peripheral component interconnect) bus.

The memory coupled to the system bus 80 includes Random Access Memory (RAM) 82 and Read Only Memory (ROM) 93. Such memories include circuitry that allows information to be stored and retrieved. ROM 93 typically contains stored data that cannot be easily modified. The data stored in RAM 82 may be read or changed by processor 91 or other hardware device. Access to RAM 82 and/or ROM 93 may be controlled by memory controller 92. The memory controller 92 may provide address translation functionality that translates virtual addresses into physical addresses as instructions are executed. The memory controller 92 may also provide memory protection functions that isolate processes within the system and isolate system processes from user processes. Thus, a program running in the first mode may only access memory mapped by its own process virtual address space; unless memory sharing between processes has been set, it cannot access memory within the virtual address space of another process.

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

The display 86, controlled by the display controller 96, is used to display visual output generated by the computing system 90. Such visual outputs 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 may be implemented with a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch pad. The display controller 96 includes the electronics necessary to generate the video signals that are sent to the display 86.

In addition, the computing system 90 may contain communications circuitry, such as a network adapter 97, that may be used to connect the computing system 90 to external communications networks, such as the RANs 103/104/105, core networks 106/107/109, PSTN 108, internet 110, or other networks 112 of fig. 1A, 1B, 1C, 1D, and 1E, to enable the computing system 90 to communicate with other nodes or functional entities of those networks. Communication circuitry alone or in combination with processor 91 may be used to perform the transmit and receive steps of certain apparatus, nodes or functional entities described herein.

Fig. 1G illustrates one embodiment of an exemplary communication system 111 in which the methods and apparatus described and claimed herein may be embodied. As shown, the exemplary communication system 111 may include a wireless transmit/receive unit (WTRU) A, B, C, D, E, F, a base station, a V2X server, and RSUs a and B, but it should be understood that any number of WTRUs, base stations, networks, and/or network elements are contemplated by the disclosed embodiments of the invention. One or several or all of the WTRUs a, B, C, D, E may be outside the range of the network (e.g., outside the cell coverage boundaries as shown by the dashed lines in the figure). WTRUs a, B, C form a V2X group, where WTRU a is the group leader and WTRUs B and C are group members. The WTRUs a, B, C, D, E, F may communicate over a Uu interface or a side-link (PC 5) interface.

It will be appreciated that any or all of the apparatus, 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. In particular, any of the steps, operations, or functions described herein can be implemented in the form of such computer-executable instructions that are executed on a processor of a device or computing system configured for wireless and/or wired network communications. Computer-readable storage media include volatile and nonvolatile, removable and non-removable media implemented in any non-transitory (e.g., tangible or physical) method or technology for storage of information, but such computer-readable storage media do not include signals. Computer-readable storage media includes, but is not limited to RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital Versatile Disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible or physical medium which can be used to store the desired information and which can be accessed by a computing system.

Support for MBMS over LTE networks has evolved considerably over various versions of LTE. Table 1 shows an overview of the major changes/enhancements of the version. Additional details are provided below.

Table 1: evolution of MBMS in LTE

Since release 9, LTE networks support 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 simultaneous transmission of the same MBMS service from one or more enbs.

Fig. 2 shows an example of an LTE architecture 200 for MBSFN transmission. 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 participate in MBSFN transmission. The transmission may originate from, for example, the content provider 206. Transmissions from these enbs 205 define MBSFN areas that include areas where UEs may receive MBSFN transmissions from multiple enbs 205. These transmissions are via a multicast transport channel (MCH) that may be mapped to a physical channel, such as a Physical Multicast Channel (PMCH). PMCH may be allowed to be transmitted in reserved subframes. For example, the eNB may have set aside reserved subframes for MBSFN transmission purposes. These subframes may be used to carry MBMS control plane information (e.g., multicast Control Channel (MCCH)) and MBS user plane traffic (e.g., multicast Traffic Channel (MTCH)). From the system information, the UE may determine: the subframes set aside for MBS and which of these subframes carry MCCH, and configuration for PMCH. The latter may allow the UE to decode traffic received on the PMCH in the reserved subframe. The UE may read the MCCH to obtain scheduling information for the MBMS user plane service. For example, the UE may determine: which of the reserved subframes contain streams from a particular multicast/broadcast stream. The UEs may use this scheduling information to determine the multicast/broadcast streams of interest to them and to receive/decode the MBMS service. The UE may monitor the MCCH to determine whether there is any change in the MBMS service provision.

MBSFN operation may be used for rrc_connected UE and rrc_idle UE. During MBSFN operation, a single transport block may be transmitted in each reserved subframe and a single transmission may be used for the MCH (neither blind HARQ repetition nor RLC fast repetition). In addition, during MBSFN operation, MTCH and MCCH may use RLC-UM mode (the configuration of RLC-UM mode is fixed and known to the UE).

Release 10 introduces RAN-based counting of UEs in connected mode that are interested in MBMS services. This version also allows the RAN to use any unused MBSFN subframes for unicast transmission. Finally, the version enhances admission control for MBMS sessions by introducing allocation and retention priority session parameters.

Release 11 introduces service acquisition and service continuity in a multi-frequency deployment that provides MBMS services via more than one frequency. The initial version of eMBMS assumes that the MBMS feature does not affect the mobility procedure in E-UTRA. Thus, some UEs that are receiving or interested in the MBMS service cannot receive the MBMS service due to cell reselection in rrc_idle or handover in rrc_connected. To solve this problem, the network may provide assistance information to inform UEs about mapping information between carrier frequencies and MBMS services and transmission timing of MBMS services. By using the assistance information, when the UE is interested in a specific MBMS service, the UE in rrc_idle can autonomously set the carrier frequency carrying the MBMS service to the highest cell reselection priority of the scheduling time. Thus, it is likely that the UE will reselect to a cell on the carrier frequency carrying the MBMS service. Also in release 11, for a UE in rrc_connected, the UE may inform the serving cell of the carrier frequency on which the MBMS service of interest is scheduled to be transmitted. For this, the RRC layer introduces a new uplink message called MBMSInterestIndication message. The intention is that the eNB will use this information to select the target cell for handover.

Release 12 introduced one of the major enhancements, mooD (on-demand MBMS operation), which enables automatic and seamless MBMS service activation and deactivation based on the UE's service consumption report.

The main enhancement is the introduction of single cell point-to-multipoint in release 13. SC-PTM uses the same new logical entity (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 individually. These transmissions are transmitted over a downlink shared channel (DL-SCH) and carried on a Physical Downlink Shared Channel (PDSCH). Thus, unicast traffic and MBMS traffic are multiplexed on the DL-SCH, thereby enabling more flexible and dynamic radio resource allocation for MBMS transmission. Further, since scheduling is not left to the MCE to synchronize between enbs, it is expected to reduce end-to-end delay. For SC-PTM, MBMS is transmitted in the coverage of a single cell. The SC-PTM transmission carries both a control channel (SC-MCCH) and a traffic channel (SC-MTCH). The SC-MCCH and SC-MTCH transmissions are each indicated by a logical channel specific RNTI on a Physical Downlink Control Channel (PDCCH). Specifically, an SC-RNTI for the SC-MCCH and a G-RNTI for the SC-MTCH. Note that there is a one-to-one mapping between each MBMS session supported in the cell and the G-RNTI for receiving the DL-SCH to which the SC-MTCH is mapped. Even if the SC-PTM is scheduled like unicast traffic, the SC-PTM does not depend on any UL feedback and therefore the SC-PTM does not support link adaptation or HARQ operation. During the 3GPP work item phase, there are some discussions of utilizing unicast UL feedback in order to allow advanced link adaptation schemes, such as adaptive modulation and coding for groups with a small number of UEs. However, this feature is ultimately not standardized in release 13. In addition, MBMS transmissions may be configured with MBMS-specific DRX modes such that the UE does not need to continuously monitor the SC-PTM RNTI. This mode follows a simple on and off period, wherein the DRX active time is prolonged when the UE receives SC-PTM communication traffic. This MBMS specific DRX mode is independent of the UE specific DRX mode.

The SC-PTM service may be received by both rrc_connected UE and rrc_idle UE. During SC-PTM operation, a single transmission may be used for the DL-SCH (neither blind HARQ repetition nor RLC fast repetition). The SC-MTCH and SC-MCCH may use RLC-UM mode (the configuration of which is fixed and known to the UE).

Release 14 introduced MBSFN and SC-PTM for V2X (vehicle-to-outside world) communications, SC-PTM for internet of things (IoT), eMTC (enhanced machine type communications), and NB-IoT (narrowband IoT). Release 14 also introduces a number of features to enhance delivery of TV services utilizing eMBMS, extend the range of MBMS into legacy TV receivers, and enable deployment of dedicated broadcast eMBMS networks that support common broadcast requirements. The services provided may be distributed in such a way that the services may be received by all users, including those who are not mobile users. This is also referred to as Receive Only Mode (ROM) or free viewing.

Version 16 focuses on enhancements to terrestrial broadcasting (especially new frame structure, new cyclic prefix) to find a solution that allows EN-TV to meet the 5G broadcasting requirements of "terrestrial broadcasting

NR MBS requirements, use cases, and work item objectives are described herein. The 3GPP RAN has considered a variety of use cases that would benefit from 5G MBS support. Usage can be categorized into four main categories:

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

Public warning: the user may be notified with an alert carrying a multimedia message that includes a description of the type of alert and multimedia data that gives instructions, advice, and additional information to the user (e.g., a picture of the missing child, a map of the last known location, a description of what to do, etc.). This traffic is "ad-hoc" in nature, as users do not necessarily subscribe to this service.

Automobile: various V2X applications require information delivered to the vehicle from an Intelligent Transportation System (ITS) infrastructure, such as ITS roadside units and sensors. For example: road safety, signage, maps, autonomous driving, and the like.

IoT: in many cases, the firmware update may be sent to a large number of devices, or the new configuration may be sent to a large number of devices. The device itself may have reduced capabilities.

These use cases are quite different in terms of bit rate, delay, user density and reliability, but would each benefit from the PTM transmission form in the RAN. Based on these use cases, 3GPP has determined a number of requirements related to 5G MBS. Within the scope of release 17, the 3GPP RAN focuses on a set of high-level requirements expected from 5G MBS. This may include:

bit rate: can be very high;

delay: can be very low;

reliability: use cases with extremely high reliability must be supported;

density: should be able to handle extremely dense deployments;

mobility: should be able to handle high mobility UEs;

Flexibility: the operator should be able to dynamically change the reserved capacity for MBS and the size of the service area;

Efficiency is that: the operator should be able to dynamically change how services (multicast, broadcast, unicast, PTP, PTM) are provided to the UE and allow the UE to be able to receive multiple parallel services (one or more unicast services plus one or more MBS services).

Thus, the 3GPP RAN group has begun a new work item [3], which addresses some of the limitations of MBMS operation over LTE and attempts to meet the requirements listed above.

The work item has two main goals:

assigning RAN basic functions for broadcast/multicast to a UE in rrc_connected state, comprising:

Specifying a group scheduling mechanism to allow the UE to receive broadcast/multicast services (also including specifying the necessary enhancements required to achieve simultaneous operation with unicast reception;

Designating for a given UE a dynamic change in supporting broadcast/multicast service delivery between multicast (PTM) and unicast (PTP) with service continuity;

specifying support for basic mobility with service continuity;

The required change is specified by, for example, UL feedback to improve reliability of the broadcast/multicast service. The level of reliability should be based on the requirements of the application/service provided;

The support for dynamic control of the broadcast/multicast transmission area within one gNB-DU is studied and the content (if any) required to enable it is specified.

A UE in rrc_idle/rrc_inactive state is assigned a RAN basic function for broadcast/multicast [ RAN2, RAN1]:

In order to maintain the maximum commonality between the rrc_connected state and the rrc_idle/rrc_inactive state for the configuration of PTM reception, the required changes are specified to enable the UE in the rrc_idle/rrc_inactive state to receive the point-to-multipoint transmission.

Note that the work item does not include any targets related to FR2 operation, SFN operation, dynamic resource allocation up to 100% to MBS, and receive-only mode operation. Nevertheless, any design decisions generally required to be taken should not prevent the introduction of such features or operations in future versions.

NR MBS operations are described herein. As part of the development of NR MBS, several agreements have been made by the 3GPP working group regarding this operation. Several of these agreements are listed below:

the initial RAN focus may be on NR independent deployment;

for multicast services, the network supports PTP and PTM transmissions of shared traffic delivered by the 5GC, at least for the connected mode (this is not intended to exclude other cases);

for a UE, the gNB dynamically decides whether to deliver multicast data via PTM or PTP;

the RAN may support 2 delivery modes:

Delivery mode 1 for high QoS (reliability, delay) requirements is available under rrc_connected (when there is no data receiving TBD, possibly the UE can switch to other states). The method is mainly used for multicast session;

delivery mode 2 for "low" QoS requirements, where the UE may also receive data under rrc_ CONNECTED, RRC _idle and rrc_inactive. Mainly for broadcast sessions but possibly also for multicast sessions.

The RAN should be provided with information (e.g., TMGI) of MBS services/groups subscribed to by the UE and QOS requirements of the MBS services;

supported SDAP functionality: mapping from QoS flows to MBS RBs;

Supported PDCP functionality: roHC (at least U-mode); reordering and in-order delivery functions in PDCP; data transfer; maintenance of PDCP SN; repeatedly discarding; status reporting (for lossless handover) may be supported.

Supported RLC functionality: RLC-AM for PTP transmission; RLC UM for PTP transmission; RLC UM for PTM transmission of NR MBS.

For the condition that both the source cell and the target cell support MBS, lossless handover is supported;

In order to support lossless handover of 5G MBS services, the network side should guarantee DL PDCP SN synchronization and continuity between at least the source cell and the target cell.

From the network side, the source gNB may forward data to the target gNB, and the target gNB may deliver the forwarded data.

MRB may include both PTP and PTM legs;

For the split bearer case, both the PTP leg and the PTM leg are RLC-UM, supporting configuration of a PTM-PTP handover without L2ARQ and with PDCP anchor (e.g., for services that would normally be configured with RLC UM for unicast).

For rrc_idle/rrc_inactive UEs for NR MBS delivery mode 2, MBS configuration (for broadcast/delivery mode 2) is provided by a two-step based method (i.e. BCCH and MCCH) employed by LTE SC-PTM. It is assumed that this can also be used for rrc_connected UEs;

It is assumed that the MCCH change notification mechanism is used to notify of the change of the MCCH configuration due to the session start of the delivery mode 2 of the NR MBS (other case is FFS).

It is assumed that MBS interest indication is supported for UEs in connected mode for broadcast services.

The RAN defines three transmission schemes:

PTP transmission: for rrc_connected UEs, a UE-specific PDCCH with a CRC scrambled by a UE-specific RNTI (e.g., C-RNTI) is used to schedule a UE-specific PDSCH scrambled with the same UE-specific RNTI.

PTM transmission scheme 1: for rrc_connected UEs in the same MBS group, a group common PDSCH scrambled with the same group common RNTI is scheduled using a group common PDCCH with a CRC scrambled by the group common RNTI. This scheme may also be referred to as a group scheduling scheme based on a group common PDCCH.

PTM transmission scheme 2: for rrc_connected UEs in the same MBS group, a UE-specific PDCCH with a CRC scrambled by a UE-specific RNTI (e.g., C-RNTI) is used to schedule a group common PDSCH scrambled with a group common RNTI. This scheme may also be referred to as a UE-specific PDCCH-based group scheduling scheme.

For delivering MBS TB, PTM transmission scheme 1 is supported for initial transmission; other schemes are still under discussion.

For retransmission, when PTM transmission scheme 1 is used in the initial transmission, PTM transmission scheme 1 and PTP transmission are supported (when ACK/NACK-based HARQ is supported); PTM transmission scheme 2 is still under discussion.

For rrc_connected UEs, HARQ-ACK feedback is supported for multicast.

For rrc_connected UEs receiving multicast, the following are supported:

ACK/NACK-based HARQ-ACK feedback for multicast:

Orthogonal PUCCH resources are configured by the network between UEs within the same group.

If the initial transmission 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 transmitting the same TB.

FFS (FFS): NACK-only HARQ-ACK feedback for multicast:

PUCCH resources are configured by the network and may be shared among UEs within the same group.

Enabling/disabling HARQ-ACK feedback for MBS is supported.

The priority of HARQ-ACK feedback for the rrc_connected UE receiving the multicast may be lower, higher or equal to HARQ-ACK feedback for the unicast.

Based on the progress of NR MBS development, a number of unresolved problems have been identified. The first unresolved problem relates to the mapping of the UE to the G-RNTI. The G-RNTI represents an RNTI for the UE group. The MBS transport block is transmitted using the G-RNTI. However, it is still unclear which UEs are in this group. Various options have been discussed, including:

1:1 mapping between MBS services and G-RNTI. All UEs interested in the service listen to the G-RNTI;

N:1 mapping between MBS service and G-RNTI. Multiplexing a group of N services on one transport block transmitted on a single G-RNTI;

the G-RNTI is for a geographical region. All services provided in the geographical area are multiplexed on a single G-RNTI.

A second unresolved problem relates to how to achieve reliability. Some MBS services require high reliability, but how to achieve this reliability remains unresolved. Various options have been discussed: all services on PTP leg or unicast DRB requiring high reliability, layer 2 retransmission at PDCP layer, layer 2 retransmission at RLC layer, layer 1HARQ retransmission with ACK/NACK feedback are maintained.

A third unresolved problem relates to the multiple ways in which the network can provide the same multicast service. Multicast services may be provided on DRBs or MRBs, which may be split bearers or non-split bearers, and services may be replicated on more than one MRB.

Many of the resulting problems need to be resolved, based on decisions made regarding these unresolved problems. The list of questions is divided into two broad areas: multiplexing problems and reliability problems.

Multiplexing problems are described herein.

Problem 1: procedure for multiplexed MBS service:

The gNB may be permitted to multiplex MBS traffic from multiple MBS services on a single transport block. Thus, the UE may receive transport blocks with MBS services from logical channels that the UE is not interested in. There is a need to define a procedure that allows a UE to process a received multiplexed transport block. This requires consideration of multiplexing at both the SDAP and MAC layers and optimization of HARQ feedback signaling.

Furthermore, the gNB may be permitted to multiplex unicast traffic with multicast traffic on a single transport block. Unicast traffic may be destined for one of the UEs receiving a transport block transmitted on the G-RNTI. A procedure is defined herein that allows a UE to process a transport block that receives this multiplex.

Problem 2: procedure for logical channel prioritization at UE:

UEs receiving MBS services may need to send MBS-related uplink transmissions (e.g., status reports, HARQ feedback, measurement results) to support MBS services. In addition, the UE may communicate over the Uu interface and the SL interface simultaneously. The actions of the UE when MBS-related uplink transmissions overlap with Uu or SL transmissions are not defined. When the UE cannot send these transmissions simultaneously, the UE needs to choose a prioritization rule for one transmission over another.

Reliability issues are described herein.

Problem 3: procedure for HARQ retransmission on C-RNTI:

The UE may receive an initial transmission of a transport block on the G-RNTI and a retransmission on the C-RNTI. In such cases, the UE needs a mechanism to associate the transport blocks received on the C-RNTI to the same HARQ process handling the reception on the G-RNTI (this is to allow the UE to perform soft combining). Second, the UE needs rules to determine when to monitor the C-RNTI for HARQ retransmissions. Finally, a procedure to resolve potential HARQ process collisions needs to be defined. These collisions occur when the UE is receiving a transport block retransmitted on the C-RNTI but the network starts transmitting a new transport block on the G-RNTI using the same HARQ process. Consider the case where the gNB decides to send retransmissions of some MBS traffic on the C-RNTI. It is assumed that the gNB will use the same HARQ process ID for the C-RNTI transmission as was used for the initial G-RNTI transmission (so that the UE can soft combine both transmissions). The gNB continues to process MBS data and eventually may transmit a new TB on the G-RNTI on the original HARQ process. In this case, the UE may receive a retransmission of TB1 on the C-RNTI to HARQ process K and a new transmission of TB2 on the G-RNTI to HARQ process K.

Problem 4: procedure for transmitting PDCP status report:

PDCP status reports are used to guarantee lossless handover of services with high reliability requirements. The same mechanism may also be used for MBS services requiring high reliability in order to guarantee lossless PTM-PTP handover and lossless MRB reconfiguration. However, a new trigger for sending PDCP status reports needs to be defined to enable lossless PTM-PTP handover and lossless MRB reconfiguration. Second, the transmission of PDCP status reports requires an uplink path from the UE to the gNB. Such uplink paths are not always available for MBS services. In such cases, a solution capable of transmitting PDCP status reports is needed.

Problem 5: procedure for joining a UE to a multicast session that has been started/activated:

When a UE starts receiving the service of an MBS service, the service may already be active and is sending MBS service to other UEs. The active service consists of one or more MRBs, and each of these MRBs has PDCP, RLC and HARQ states and contexts. The UE is unaware of this context and this leads to certain synchronization problems. For example, the RLC UM reassembly window of the UE MRB may not be synchronized with the RLC UM transmission of this MRB. This may cause the UE to drop certain MBS services. There is a need to define UE procedures that involve the UE joining an already active MBS session.

Problem 6: procedure for UE during transition from multicast ACTIVE to multicast INACTIVE:

The multicast session may be in an ACTIVE or INACTIVE state. In the INACTIVE state, no MBS data service is transmitted to the UE, and the UE may transition to the RRC IDLE or RRC INACTIVE mode. The UE actions when transitioning a multicast service to INACTIVE are defined herein for the case where multiple MBS services are multiplexed on a single G-RNTI.

Problem 7: procedure for reliable transmission when MBS is preempted:

To support URLLC, the gNB may preempt eMBB transmissions 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.

The power saving problem is described herein.

Problem 8: DRX granularity for NR MBS:

In LTE, to save power, the UE may be configured with DRX for receiving SC-PTM. The UE monitors the G-RNTI and the SC-RNTI for the SC-PTM only during the active time of the configured DRX. DRX is configured according to SC-MTCH. Since LTE SC-PTM does not support multiplexing MBMS services on G-RNTI, in practice, DRX configuration is based on G-RNTI. For NR MBS, it is likely that: multiple MBS services will be multiplexed on a single G-RNTI and thus, it is necessary to define granularity of DRX for NR MBS.

Problem 9: DRX configuration for NR MBS

Since LTE SC-PTM does not support HARQ feedback for MBMS, DRX configuration is based on: a DRX cycle, a DRX start offset, an on duration timer, and an inactivity timer. However, since HARQ feedback and HARQ retransmissions are allowed for the NR MBS, the DRX configuration will need to take these retransmissions into account.

Problem 10: UE DRX procedure

UE DRX procedure for Uu link for NR unicast transmission assumes: 1) Transmitting HARQ feedback from the UE to the gNB; 2) The transport block includes only logical channels configured for the receiving UE. In NR MBS, these two assumptions do not hold. First, HARQ feedback may be enabled/disabled, and furthermore, the mode of HARQ retransmission may vary. RAN1 has defined three modes: PTM scheme 1, PTM scheme 2 and PTP scheme. Second, the transport block 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 process.

MBS services provided on NR are intended to have various QoS requirements. The manner in which this traffic is delivered to the UE of interest is intended to be very flexible and adaptable as well. The network can dynamically change the manner in which traffic is delivered to the UE.

However, this flexibility and the varying QoS requirements that are expected to be supported lead to a number of problems with respect to efficient transmission of such MBS services. The problems relate to how to configure MBS radio bearers for services, how to multiplex MBS services efficiently, how to improve reliability of MBS transmissions, and how to cope with starting to receive MBS services already received by other UEs.

The present disclosure attempts to solve these problems by proposing the following:

a procedure for managing multiplexed MBS services;

A procedure for prioritization between MBS-related UL traffic, unicast UL traffic and SL traffic;

a procedure for handling HARQ retransmissions on the C-RNTI;

A procedure for supporting PDCP status reporting for MBS services;

A procedure for joining the UE to an already started/activated multicast session;

a process for handling multicast transitions from active to inactive;

a process for handling MBS service preemption;

procedure for DRX operation of UE receiving MBS service.

A procedure for multiplexed MBS services is described herein.

The following embodiments are described herein:

Embodiment 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).

Embodiment 2: the first device of embodiment 1, wherein the UE is configured with a single SDAP entity for the MBS services, and multiplexing of traffic occurs at the SDAP layer. Multiple MBS QoS flows across different MBS services are multiplexed on the same MRB.

Embodiment 3: the first device of embodiment 1, wherein multiplexing of traffic occurs at the MAC layer. Multiple logical channels are multiplexed on the same transport block across different MBS services.

Embodiment 4: the first device of embodiment 3, wherein Logical Channel IDs (LCIDs) of all multiplexed logical channels are unique, and the UE is configured with a list of LCIDs related to MBS services of interest. Upon disassembly of the transport block, the disassembly and demultiplexing entity discards logical channels that are not on this list.

Embodiment 5: the first device of embodiment 3, wherein a 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 a logical channel for an MBS service corresponding to interest. When disassembling the transport block, the disassembly and demultiplexing entity uses this header to determine whether the MAC SDU is for an MBS service of interest. MAC SDUs that do not correspond to MBS services of interest are discarded.

Embodiment 6: the first device of embodiment 5, wherein the identifier is an MBS service ID (such as a TMGI or a session ID or some alternative ID identifying the MBS service), and wherein the UE is provided with a list of MBS service IDs of MBS services of interest to the UE.

Embodiment 7: the first device of embodiment 3, wherein a Logical Channel ID (LCID) of all multiplexed logical channels is not guaranteed to be unique, and wherein DCI scheduling a transport block contains a bit field for indicating which MBS services are multiplexed in the transport block.

Embodiment 8: the first device of embodiment 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.

Embodiment 9: the first device of embodiment 7, wherein the PHY layer provides the transport block and the bit field to the HARQ entity. If the bit field indicates that the transport block does not contain any MBS services of interest, the HARQ entity decides to discard the transport block.

Embodiment 10: the first device of embodiment 9, wherein if the UE discards the transport block, the UE may transmit as HARQ feedback: ACK, DTX, or Don't Care (optional).

A process for logical channel prioritization at a UE is described herein.

Embodiment 11: the first device of embodiment 1, wherein the device determines which traffic to prioritize when the MBS-related UL transmission overlaps with a unicast UL transmission or a side-link transmission and the UE is not capable of simultaneous transmission.

Embodiment 12: the first device of embodiment 11, wherein the priority of the transmission is fixed at all times.

Embodiment 13: the first device of embodiment 12, wherein MBS-related uplink transmissions are always de-prioritized relative to side uplink transmissions or unicast uplink transmissions.

Embodiment 14: the first device of embodiment 12, wherein MBS-related uplink transmissions are always prioritized with respect to side uplink transmissions or unicast uplink transmissions.

Embodiment 15: the first device of embodiment 11, wherein MBS-related uplink traffic is assigned a certain priority value.

Embodiment 16: the first device of embodiment 15, wherein the priority value of the MBS-related uplink service is equal to the priority value of the multiplexed MBS transport block.

Embodiment 17: the first device of embodiment 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.

Embodiment 18: the first device of embodiment 16, wherein the priority values of the multiplexed MBS transport blocks are set to a weighted average of the priority values of the logical channels multiplexed in the transport blocks.

Embodiment 19: the first device of embodiment 11, wherein the priority of the transmission is based on a relative priority of an MBS-related uplink transmission and a side uplink transmission or a unicast uplink transmission. The UE transmits the traffic with the highest priority (e.g., the traffic with the lowest priority value).

Embodiment 20: the first device of embodiment 11, wherein the priority of the transmission is based on a priority of MBS-related uplink transmission compared to a threshold (MBSPriorityThreshold). If the priority value of the MBS-related uplink transmission is below the threshold, the MBS-related uplink transmission is prioritized. If the priority value of the MBS-related uplink transmission is above the threshold, the MBS-related uplink transmission is de-prioritized.

Embodiment 21: the first device of embodiment 11, wherein the priority of the transmission is based on the relative priorities of the different traffic and a threshold (MBSPriorityThreshold, ULPriorityThreshold, SLPriorityThreshold) associated with each traffic. If the priority value of the uplink transmission is below ULPriorityThreshold, the uplink transmission is prioritized. If the priority value of the uplink transmission is higher than ULPriorityThreshold, the UE prioritizes traffic with a lower priority value.

Embodiment 22: the first device of embodiment 11, wherein the MBS-related uplink transmission comprises: RRC message, MAC CE, PDCP status report, PDCP control PDU, RLC status report, RLC control PDU, HARQ feedback.

Embodiment 23: the first device of embodiment 18, wherein the UE has a fixed priority between different MBS-related uplink transmissions.

A procedure for HARQ retransmission on C-RNTI is described herein.

Embodiment 24: a first device, the first device:

Receiving a configuration for one or more sets of HARQ processes: one DL HARQ process set for unicast transmission, one MBS HARQ process set for MBS transmission, broadcast HARQ process for BCCH transmission, one SL HARQ process set for SL transmission;

Receiving DCI of PDSCH scheduled for MBS transmission;

monitoring the C-RNTI for MBS retransmission;

decoding the transport block, determining a HARQ process for processing the transport block, and forwarding the transport block to the determined HARQ process.

Embodiment 25: the first device of embodiment 24, wherein the UE is configured to receive an MBS initial transmission on the G-RNTI and an MBS retransmission on the C-RNTI, and wherein the initial transmission and the retransmission are both for the same MBS HARQ process.

Embodiment 26: the first device of embodiment 24, wherein the DCI includes one or more of: HARQ process ID, G-RNTI/C-RNTI indication, NDI, MBS HARQ process indicator, MBS indicator.

Embodiment 27: the first device of embodiment 24, wherein the first device monitors the C-RNTI for MBS retransmissions only during periods of expected MBS activity.

Embodiment 28: the first device of embodiment 24, wherein the first device monitors the C-RNTI only for MBS retransmissions if the first device has sent a NACK for a transport block.

Embodiment 29: the first device of embodiment 24, wherein the first device monitors the C-RNTI for MBS retransmissions only during periods when MBS activity is expected and the first device has sent a NACK for a transport block.

Embodiment 30: the first device of embodiment 24, wherein if the first device is in rrc_idle or rrc_active, the UE monitors the C-RNTI for MBS retransmissions during a period in which MBS activity is expected and the first device has sent a NACK for a transport block.

Embodiment 31: the first device of embodiments 27, 28, 29, and 30, wherein MBS activity is expected during DRX active time of an MBS service.

Embodiment 32: the first apparatus of embodiment 24, wherein determining a HARQ process to process a transport block is based on one or more of: the presence or absence of MBS HARQ process indicator, MBS indicator, G-RNTI/C-RNTI indication.

Embodiment 33: the first device of embodiment 24, which detects HARQ process collisions-the UE may receive transport block a (retransmission) on the C-RNTI and transport block B (new transmission) on the G-RNTI. These two transport blocks are designated to be handled by the same MBS HARQ process.

Embodiment 34: the first device of embodiment 33, the first device considering only transport blocks received on the C-RNTI and discarding transport blocks received on the G-RNTI.

Embodiment 35: the first device of embodiment 33, the first device considering only transport blocks received on the G-RNTI, flushing HARQ processes, and treating the G-RNTI as a new transmission.

Described herein are procedures for joining a UE to a multicast session that has been initiated/activated.

Embodiment 36: a first device that joins an already active multicast session, and that:

Receiving a configuration with an MRB including a PTM leg with RLC-UM;

Determining initial values of RX_Next_ Reassembly and RX_Next_ Highest;

receiving UMD PDU.

Embodiment 37: the first device of embodiment 36, wherein the determination of rx_next_ Reassembly and rx_next_ Highest is based on information included in the received configuration.

Embodiment 38: the first device of embodiment 36, wherein the determination of RX_Next_ Reassembly and RX_Next_ Highest is based on a value of the SN of the first received UMD PDU.

Embodiment 39: the first device of embodiment 36, wherein the determination of rx_next_ Reassembly and rx_next_ Highest is based on a value provided by the gNB using a control PDU.

Embodiment 40: the first device of embodiment 36, wherein the determination of rx_next_ Reassembly and rx_next_ Highest is based on information carried in a header of the received UMD PDU.

Embodiment 41: a first device that joins an already active multicast session, and that:

Receiving a configuration with an MRB comprising a PTM leg with RLC-AM;

Determining an initial value of RX_Next;

An AMD PDU is received.

Embodiment 42: the first device of embodiment 41, wherein the determination of rx_next is based on information included in the received configuration.

Embodiment 43: the first device of embodiment 41, wherein the determination of RX_Next is based on a value of SN of the first received AMD PDU.

Embodiment 44: the first device of embodiment 41, wherein the determination of rx_next is based on a value provided by the gNB using a control PDU.

Embodiment 45: the first device of embodiment 41, wherein the determining of the age rx_next is based on information carried in a header of the received AMD PDU.

Embodiment 46: a first device that joins an already active multicast session, and that:

Receiving a configuration with MRBs requiring sequential delivery;

determining initial values of RX_NEXT and RX_ DELIV;

Receiving PDCP PDU.

Embodiment 47: the first device of embodiment 46, wherein the determination of rx_next and rx_ DELIV is based on information included in the received configuration.

Embodiment 48: the first device of embodiment 46, wherein the determination of RX_NEXT and RX_ DELIV is based on a value of COUNT of a first received PDCP PDU.

Embodiment 49: the first device of embodiment 46, wherein the determination of rx_next and rx_ DELIV is based on a value provided by the gNB using a control PDU.

Embodiment 50: the first device of embodiment 46, wherein the determination of rx_next and rx_ DELIV is based on information carried in a header of the received PDCP PDU.

Embodiment 51: a first device that joins an already active multicast session, and that:

Receiving a configuration with HARQ feedback enabled MRB;

Receiving a transmission block;

It is determined whether to transmit HARQ feedback.

Embodiment 52: the first device of embodiment 51, wherein the determination is based on whether the initial transmission received for the HARQ process is a new transmission or a retransmission.

Embodiment 53: the first device of embodiment 51, wherein the determination is based on whether the transport block has been ACK up to a maximum number of times.

Embodiment 54: the first device of embodiment 1, triggered to send a PDCP status report based on one or more of the following triggers: the device detects lost MBS PDUs, MBS radio bearer reconfiguration, PTM-PTP handover, PTP-PTM handover.

Embodiment 55: the first device of embodiment 54, wherein the PDCP status report is sent by one or more of the following methods: RRC signaling, NAS signaling, RACH, PTP leg over linked radio bearers on MRB.

A process for handling multicast transition from active/inactive to inactive/active:

Embodiment 56: a first device that has joined a multicast session, and that:

An indication is received that a first multicast session is transitioning from active to inactive or vice versa,

Determining whether the G-RNTI carrying the first multicast session carries a second active multicast session, and

Based on this determination and on the indication, PDCP, RLC and MAC DRX behavior is controlled.

Embodiment 57: the first device of embodiment 56, wherein the indication is received in one of an RRC message, a MAC CE, or a PHY DCI.

Embodiment 58: the first device of embodiment 57, wherein the indication in the PHY DCI is a bitmap, wherein a "1" in bit "k" indicates that an MBS session with index "k" is changing from active/inactive to inactive/active.

Embodiment 59: the first device of embodiment 56, wherein if the indication indicates a multicast activity to inactivity transition and the determination indicates that the UE is receiving a second active multicast session, the UE may further:

the DRX for MBS sessions is stopped,

Performing RLC entity re-establishment for radio bearers of inactive MBS sessions, and

PDCP entity radio bearers suspending inactive MBS sessions.

Embodiment 60: the first device of embodiment 56, wherein if the indication indicates a multicast activity to inactivity transition and the determination indicates that the UE is not receiving a second active multicast session, the UE may further:

the monitoring of the G-RNTI is stopped and the processing of transport blocks received on the G-RNTI is stopped,

The DRX for the G-RNTI is stopped,

RLC entity re-establishment is performed for radio bearers of inactive MBS sessions,

PDCP entity radio bearer suspending inactive MBS session, and

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

Embodiment 61: the first device of embodiment 56, wherein if the indication indicates a multicast inactivity to activity transition and the determination indicates that the UE is receiving a second active multicast session, the UE may further:

starting DRX for MBS session, and

The PDCP entity radio bearer of the inactive MBS session is restored.

Embodiment 62: the first device of embodiment 56, wherein if the indication indicates a multicast inactivity to activity transition and the determination indicates that the UE is not receiving a second active multicast session, the UE may further:

the G-RNTI starts to be monitored. Follow the DRX configuration for this G-RNTI, if configured, and

The PDCP entity radio bearer of the inactive MBS session is restored.

The process for handling MBS service preemption:

Embodiment 63: a first device that has joined a multicast session, and that:

the MBS transport block is received and,

Receive preemption indication RNTI, and

It is determined whether to send HARQ feedback for the preempted MBS transport block.

Embodiment 64: the first device of embodiment 63, wherein the determination is based on whether the MBS transmission is a new transmission or a retransmission.

Embodiment 64a: the first device of embodiment 63, wherein the determination is based on an indication in DCI that schedules MBS transmissions.

Procedure for DRX operation of UE receiving MBS service:

embodiment 65: a first device that has joined an MBS session, and that:

Receiving one or more DRX configurations for MBS transmissions, comprising: one for each MBS group (G-RNTI), one for each MCCH (SC-RNTI),

Determining active time based on DRX configuration, and

Monitoring RNTI from the following during active time: G-RNTI, SC-RNTI, C-RNTI, INT-RNTI

Embodiment 66: the first device of embodiment 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.

Embodiment 67: the first device of embodiment 65, wherein the DRX active time comprises a time when the following timers are running: drxMBS-onDurationTimer, drxMBS-INACTIVITYTIMER, DRXMBSRETRANSMISSIONTIMERDL.

Embodiment 68: the first device of embodiment 66 wherein the UE may stop the inactivity timer for the PTM scheme 1MBS transmission to the G-RNTI if the transport block does not contain any MTCH channels for the MBS session of interest to the UE.

Embodiment 69: the first device of embodiment 66, wherein the UE determines an RNTI to monitor while the retransmission timer is running.

Embodiment 70: the first apparatus of embodiment 69 wherein the UE always monitors both the C-RNTI and the G-RNTI.

Embodiment 71: the first device of embodiment 69, wherein the UE determination is based on a configuration from a network.

Embodiment 72: the first device of embodiment 69, wherein the UE determination is based on an indication of how the retransmission will be sent by the indication gNB carried in the initial transmission.

Embodiment 73: the first device of embodiment 66 wherein the UE determines whether to start a retransmission timer when the UE fails to decode a transport block.

Embodiment 74: the first device of embodiment 73, wherein the determination is based on an indication that this is a last retransmission of a transport block from the gNB and that the UE should not start a retransmission timer.

The terms branch and path are used interchangeably herein. The terms PTP leg and PTP path are used interchangeably herein. The terms PTM leg and PTM path are used interchangeably herein. The terms multicast service and multicast session are used interchangeably herein. The terms MBS service and MBS session are used interchangeably herein. The terms multicast session and MBS session are used interchangeably herein.

Retransmission of MBS traffic may be sent, for example, by one of three mechanisms:

PTP retransmission scheme: the retransmitted transport block may use a UE-specific PDCCH with a CRC scrambled by a UE-specific RNTI (e.g., C-RNTI), which schedules a UE-specific PDSCH scrambled with the same UE-specific RNTI. Hereinafter, this may also be referred to as PTP ReTx scheme or PTP scheme.

PTM retransmission scheme 1: the retransmitted transport blocks use a group common PDCCH with a CRC scrambled by the group common RNTI to schedule a group common PDSCH scrambled with the same group common RNTI. Hereinafter, this may also be referred to as PTM ReTx scheme 1 or PTM scheme 1.

PTM transmission scheme 2: the retransmitted transport blocks schedule a group common PDSCH scrambled with a group common RNTI using a UE-specific PDCCH with a CRC scrambled by the UE-specific RNTI (e.g., C-RNTI). Hereinafter, this may also be referred to as PTM ReTx scheme 2 or PTM scheme 2.

The procedure for multiplexing MBS services provides a solution to the above problem 1. The network may be allowed to multiplex MBS services from different MBS services. The multiplexing may be performed at the SDAP layer and the MAC layer. Note that the gNB may have a single SDAP entity for all MBS sessions, or it may have multiple SDAP entities, one for each MBS session. Alternatively, the gNB SDAP entity may provide services for multiple MBS sessions. Similarly, a UE may have a single SDAP entity for all MBS sessions of interest, or it may have multiple SDAP entities, one for each MBS session of interest to the UE. Alternatively, the UE SDAP entity may provide services for multiple MBS sessions. After correctly decoding the transport blocks, the decoded MAC PDUs are sent to the disassembly and de-multiplexing entity. This transport block may contain logical channel information from multiple MBS services, some of which are not of interest to the UE.

Fig. 3A and 3B illustrate an example 300 of multiplexing MBS services from different MBS services at an SDAP or MAC layer. Fig. 3A shows an example in which MBS services from MTCH1 303, MTCH3 304, and MTCH5 305 are multiplexed at a MAC layer 320. Fig. 3B shows an example of multiplexing services from MBS service 1 301 and MBS service 2302 at the SDAP layer 312. Thus, in fig. 3A and 3B, the network has multiplexed traffic from MBS service 1 301 and MBS service 2 302. The UE may be interested in MBS service 1 only 301 and, therefore, the UE is not interested in logical channel MTCH5 303. At the disassembly and de-multiplexing entity, the UE needs to recover the MAC SDUs for each of the logical channels and discard any MAC SDUs associated with the logical channel MTCH5 303. To achieve this functionality, the following alternatives may be used:

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

In a second alternative, the network may not be able to guarantee: all logical channels multiplexed in a transport block have unique logical channel IDs, e.g., 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 the MBS service of interest. For example, the MAC PDU header may include an MBS service ID (such as a TMGI or session ID or some alternative ID identifying the MBS service). The UE may obtain a list of MBS service IDs of interest to the UE during UE configuration. Upon receiving and decoding the MAC PDU, the UE forwards the MAC PDU to the disassembly and de-multiplexing entity. Then, when the MAC PDU is disassembled, the MAC SDU having the MBS service ID not on the configuration list is discarded.

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

The UE PHY layer may be informed of MBS services 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.

The UE PHY may indicate the presence of a downlink assignment and deliver the associated HARQ information to the HARQ entity along with the bit field. The HARQ entity may then evaluate whether the HARQ information contains data from the MBS service of interest.

If the UE configuration requires the UE to send HARQ feedback to the gNB and the UE receives transport blocks without MBS services of interest, the UE may be configured to: always respond with an ACK, regardless of whether the transport block was decoded correctly; always respond with DTX regardless of whether the transport block was decoded correctly; or with Don't Care (DC) regardless of whether the transport block is decoded correctly.

A UE receiving MBS service may be configured with one or more G-RNTIs. For services that do not require HARQ retransmissions, the UE may have zero, one or multiple G-RNTIs. This may be typical for multicast services where the broadcast service and QoS requirements are less stringent. For services requiring HARQ retransmissions, the UE may have zero, one or multiple G-RNTIs. Furthermore, the UE may also have a unicast C-RNTI if in RRC connection.

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, there may be additional resources available when allocating resources to the logical channels. For example, after all MBS services including services that can be multiplexed on a transport block, this transport block may not be filled. In such cases, the gNB may multiplex unicast traffic into this transport block. Unicast traffic is destined for the UE that receives the transport block. Multiplexing may be performed at the MAC layer.

Fig. 4 shows an example 400 in which transport blocks include MBS services as well as unicast services. In this example, the transport block includes MBS traffic from MBS service 1 401 via MTCH1 410 and MTCH3 411. This example also shows that transport blocks may include unicast traffic from unicast PDU session 402 to UE1 (logical channel DTCH1 412) and unicast traffic to UE2 (logical channel DTCH2 413). Not all UEs may support multiplexing multicast logical channels with unicast logical channels. The UE may share its support for multiplexed unicast and MBS services on a single transport block with the network. This information may be provided to the network through subscription, UE capability transfer, or new dedicated RRC MBS capability transfer.

After correctly decoding the transport blocks, the decoded MAC PDUs may be sent to a disassembly and de-multiplexing entity. This transport block may contain logical channel information from multiple MBS services and zero or more unicast logical channels. At the disassembly and de-multiplexing entity, the UE may recover the MAC SDUs for each logical channel carried in the transport block and may discard any MAC SDUs related to MBS logical channels from services not of interest. The UE may use the alternatives described above. Further, the UE may discard any MAC SDUs from the unicast logical channel for services destined to that UE. To achieve this latter functionality, the UE may use one or more of the following alternatives.

In a 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 does not configure unicast logical channels, the UE may immediately discard all unicast logical channels it receives in the transport block.

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

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, a C-RNTI, or some other identifier known to both the network and the UE. Upon receiving the DCI, the UE may determine whether the transport block contains an MBS logical channel from a service of interest and a unicast logical channel for a service destined to the UE. As an alternative to the UE ID, an index of the UE ID list may be used. For services requiring HARQ retransmissions, the gNB may determine the identity of the UE that is the target of the transport block transmitted on the G-RNTI. The gNB may also determine which of these UEs may be able to receive transport blocks with multiplexed unicast and MBS services. The gNB may also determine which of the UEs are in RRC connected state and have C-RNTI. Transmissions to the G-RNTIs may 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 the multiplexed transport block is transmitted on the G-RNTI, the DCI scheduling the transport block may include a bitmap of indexes of UEs having unicast traffic multiplexed in this transmission. For example, if bit "k" in the bitmap is 1, this indicates that the UE identified with index "k" has unicast logical channels multiplexed in the transport block.

In a fourth alternative, the network may include a new field in the MAC header that helps identify the multiplexed logical channels. For example, the MAC header may include a UE ID field and a Logical Channel ID (LCID) field for each multiplexed logical channel.

Fig. 5 shows an exemplary MAC header 500. The example of fig. 5 shows LCID field 501, UE ID field 502, and UE ID field 503. The UE ID fields 502, 503 may identify the recipient of the logical channel. The receiver may be a G-RNTI or a C-RNTI, or some other identifier known to both the network and the UE. The logical channel identity may be an LCID or some other identifier known to both the network and the UE. Upon receiving the transport block, the disassembly and de-multiplexing entity may determine whether the logical channel corresponds to an MBS service or a unicast service. For MBS services, the disassembly and demultiplexing entity may determine whether the MBS service is a service of interest. For unicast traffic, the UE ID field may be used by the disassembly and demultiplexing entity to determine whether the UE is the recipient of this logical channel. If so, the UE may continue to process the logical channel. If not, the logical channel may be discarded. Alternatively, the MAC header may include a multicast/unicast field for each multiplexed logical channel. The multicast/unicast field may be a 1-bit indication (e.g., "0" = multicast and "1" for unicast). For a logical channel for which the multicast/unicast field indicates that the traffic is unicast traffic, only the UE ID may be included. As an alternative to the UE ID, an index of the UE ID list may be used. For services requiring HARQ retransmissions, the gNB may determine the identity of the UE that is the target of the transport block transmitted on the G-RNTI. The gNB may also determine which of these UEs may be able to receive transport blocks with multiplexed unicast and MBS services. The gNB may also determine which of the UEs are in RRC connected state and have C-RNTI. Transmissions to the G-RNTIs may 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 the multiplexed transport block is transmitted on the G-RNTI, the MAC header may include a field for 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 with index "k" has unicast logical channels multiplexed in the transport block.

Described herein is a process for logical channel prioritization at a UE that provides a solution to problem 2. The UE may receive MBS traffic simultaneously and involve unicast reception and transmission and side-link reception and transmission. These UEs may unicast uplink transmissions and sidelink transmissions for both user plane data and control plane data. The UE may be (pre) configured with a priority list allowing the UE to determine which of the transmissions to prioritize when two or more of the different unicast uplink transmissions and/or side uplink transmissions overlap. This priority list may be based on the priority of the logical channels, the priorities of the different MAC CEs, the priorities of the MAC CEs relative to certain logical channels, and whether the transmission is uplink or sidelink. In addition, the UE may also be required to transmit Uplink Control Information (UCI) to the gNB. This information may be transmitted on the PUCCH physical channel or it may be multiplexed in the PUSCH physical channel.

When the UE relates to an MBS service, the UE may have multiple MBS-related uplink transmissions (i.e., uplink transmissions bonded to the MBS service). These MBS-related uplink transmissions may include:

Uplink MCCH: the MBS service may have uplink MCCHs for MBS-related UL RRC messages and the handling of these RRC messages may be different on the UL.

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

PDCP status report: due to handover or MRB (re) configuration, the UE may send PDCP status reports to aid service continuity.

PDCP control PDU: the UE may send PDCP control PDUs to support certain features.

RLC status report: the UE may send RLC status reports for any MBS service transmitted on the RLC-AM.

RLC control PDU: the UE may send RLC control PDUs to support certain features.

HARQ feedback: if HARQ feedback is enabled for MBS services, the UE may send HARQ feedback for such services and the UE may be required to send the feedback.

In the following, MBS services may be assigned a certain priority value. In the following, it may be assumed that lower priority values represent higher priority traffic. However, alternative interpretations may also be possible (i.e. higher priority values represent higher priority traffic). Further, note that MBS services from multiple services may be multiplexed in each MBS transmission (multiplexed in a single transport block). Each of the multiplexed MBS logical channels may have a different priority. The priority value of the multiplexed traffic may correspond to the priority value of the highest priority logical channel that may be multiplexed in the transport block. Alternatively, the priority value of the multiplexed traffic may correspond to a weighted average of priority values of MBS logical channels multiplexed in the transport block. The priority of the MBS-related uplink transmission may correspond to the priority of the MBS service for which the uplink transmission is being transmitted. For example, if the MBS-related uplink transmission is a PDCP status report for an MRB having a priority value of "k", the MBS-related uplink transmission may also have the same priority value of "k". Alternatively, the priorities of MBS-related uplink transmissions may be (pre) configured or fixed/standardized.

When MBS-related UL transmissions overlap with unicast UL transmissions or side-link transmissions, and the UE may not be able to transmit simultaneously, then one of these transmissions must take precedence over the other. The overlap may be a full overlap or a partial overlap. Another scenario may be that two transmissions occur in the same slot without time domain (e.g., symbol level) overlap, and the UE may not be able to transmit simultaneously in the slot, then one of these transmissions must take precedence over the other. The following embodiments may be used to prioritize one transmission over another. Note that in the following, the term "overlapping" may be used to denote the case where transmissions may have full or partial overlap (i.e., where transmissions occur on one or more identical symbols), as well as the case where transmissions occur on the same time slot (or minislot) but transmissions do not occur on one identical symbol.

In the first embodiment, some transmission types always take precedence over others. For example, MBS-related uplink transmissions may always be prioritized relative to side uplink transmissions or unicast uplink transmissions. Alternatively, MBS-related uplink transmissions may always be prioritized relative to side uplink transmissions or unicast uplink transmissions.

In a second embodiment, the prioritized transmissions may be based on relative priorities of MBS-related uplink transmissions and side uplink transmissions or unicast uplink transmissions. In case of overlapping, the UE may compare priorities of overlapping traffic and transmit traffic with higher priority. In the case where overlapping traffic has the same priority, the UE may decide which traffic to prioritize randomly, or may use any of the other embodiments described herein to decide which traffic to prioritize, or may depend on the UE implementation.

In a third embodiment, the prioritized transmissions may be based on relative priorities of MBS-related uplink transmissions and a threshold (MBSPriorityThreshold). In case of overlap, the UE may compare the priority value of the MBS-related uplink transmission with MBSPriorityThreshold. If the priority value is less than MBSPriorityThreshold, MBS-related uplink transmissions may be prioritized and transmitted. If the priority value is higher than MBSPriorityThreshold, MBS-related uplink transmissions may be de-prioritized and side uplink transmissions or unicast uplink transmissions may be prioritized. If the priority value is equal to MBSPriorityThreshold, the UE may decide at random which traffic to prioritize, or may use any of the other embodiments described herein to decide which traffic to prioritize, or may depend on the UE implementation. Note that the value of MBSPriorityThreshold may be (pre) configured or fixed/standardized.

In a fourth embodiment, prioritized transmissions may be based on the relative priorities of the transmissions with respect to a threshold. Each of the UL/SL traffic types has a certain priority value and a priority threshold (MBSPriorityThreshold, ULPriorityThreshold, SLPriorityThreshold). In case of overlap between MBS-related uplink transmissions and unicast uplink transmissions, the UE first checks the relative priority of the unicast uplink transmissions by comparing the priority value of the unicast uplink transmissions with ULPriorityThreshold. Unicast uplink transmissions may be prioritized if they have a high priority (priority value < = ULPriorityThreshold). If the unicast uplink transmission has a low priority (priority value > ULPriorityThreshold), the UE relies on a relative priority comparison between the MBS-related uplink transmission and the unicast uplink transmission. The UE transmits higher priority traffic. In case of overlap between MBS-related uplink transmissions and side-uplink transmissions, the UE first checks the relative priority of the side-uplink transmission by comparing its priority value with SLPriorityThreshold. If the side-link transmission has a high priority (priority value < = SLPriorityThreshold), the side-link transmission may be prioritized. If the side-uplink transmission has a low priority (priority value > SLPriorityThreshold), the UE relies on a relative priority comparison between the MBS-related uplink transmission and the side-uplink transmission. The UE transmits higher priority traffic.

Some types of MBS-related uplink transmissions may not have an associated priority value. For example, UL MCCH traffic and UL MAC CE traffic may not be associated with priority values. For these types of MBS-related uplink transmissions, the priority of this service may be fixed/standardized. A typical example may include the highest priority listed first in the example list below. For example, UL MCCH has highest priority among MBS-related uplink transmissions (higher priority than any MBS MAC CE, any PDCP status/control PDU and any RLC status/control PDU). The relative priorities of MBS traffic and other unicast uplink traffic and side uplink traffic are also shown in the example list below.

C-RNTI MAC CE or data from UL-CCCH;

data from UL-MCCH;

The configured grant confirmation MAC CE or BFR MAC CE or multi-entry configured grant confirmation MAC CE;

the side-uplink configured grant acknowledges the MAC CE;

MBS MAC CE；

LBT failure MAC CE;

a MAC CE for a SL-BSR prioritized according to TS 38.321 clause 5.22.1.6;

MAC CEs for BSR, except BSR included for padding;

single-entry PHR MAC CE or multi-entry PHR MAC CE;

a MAC CE for the number of desired guard symbols;

a MAC CE for preempting the BSR;

MAC CE for SL-BSR except for SL-BSR prioritized according to TS 38.321 clause 5.22.1.6 and SL-BSR included for padding;

Data from any logical channel, except data from the UL-CCCH;

A MAC CE for recommending bit rate queries;

MAC CEs for BSR included for padding;

for being included for the MAC CE of the padded SL-BSR.

Note that the above list is provided as an example. In one alternative above, the relative priority of the UL-MCCH and MBS MAC CEs may be based on the type of MBS service the UE is receiving. UL-MCCH priority may be higher or lower depending on whether the UE is receiving MBS services. The MBS MAC CE priority may be based on specific MAC CE commands sent by the UE, some of which have higher or lower priority.

Although shown as separate embodiments, it should be understood that these embodiments may be used in any combination and may target certain MBS-related UL transmissions. For example, UL MCCH information may be transmitted over other UEs, while MBMS-related PDCP status reports may be prioritized based on the priority of the MBR for which the status report is being sent.

Described herein is a procedure for HARQ retransmission on C-RNTI, which provides a solution to problem 3 described above.

Fig. 6 illustrates an exemplary transmission 600 of an HARQ feedback enabled MBS service. In the example of fig. 6, multiple UEs may have joined MBS services (UE 1 601, UE2 602, UE3603, UE4 604 … … UEk 605) and have been configured with an MRB configuration for receiving MBS services. HARQ feedback may also be enabled for this MBS service. TB 610 may be initially transmitted from the gNB 606 to UEs (UE 1, UE2 602, UE3603, UE4 604 … … UEk 605) on G-RNTI 611. UEs interested in service can correctly receive the transport block, except for UEk 605. UEk605 may send back a NACK 612 to the gNB 606. Other UEs (UE 1, UE2 602, UE3603, UE4 604) may send back ACKs (not shown in fig. 6) to the gNB 606. Since only UEk605 has not received TB 610, the gNB 606 may send a retransmission TB 613 to UEk605 using only the C-RNTI 614 of UEk 605.

At the UE, there may be multiple HARQ entities. Each of these entities may have multiple sets of HARQ processes. One DL HARQ process set for unicast transmission, one MBS HARQ process set for MBS transmission, and broadcast HARQ process for BCCH transmission. There may also be another set of side-uplink HARQ processes for SL transmission, and these processes may be in separate HARQ entities. In one example, the same MBS HARQ process may handle all transmissions of a single transport block, regardless of whether the transport block is received on a G-RNTI or a C-RNTI.

Fig. 7 shows an example 700 of MBS transmission in which TBs are handled by the same MBS HARQ process. As shown in fig. 7, the 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 may handle transmission 720 of TBs including PDSCH reception 730 on G-RNTI and PDSCH reception 740 on C-RNTI.

DCI scheduling PDSCH may include one or more of the following:

HARQ process ID: an identifier of a HARQ process of the received transport block should be processed;

G-RNTI/C-RNTI indication: an indication of whether PDSCH is being received on the G-RNTI or C-RNTI;

NDI: a new data indicator for indicating whether the transport block is a first transmission;

MBS HARQ process indicator: an indication of whether the HARQ process ID corresponds to an MBS HARQ process or a DL HARQ process;

MBS indicator: the transport block carries an indication of MBS services.

To receive the retransmission, the UE may monitor the C-RNTI. However, it may not be clear when the UE has to monitor the C-RNTI: whether always monitored or monitored only when the UE expects a retransmission from the gNB on the C-RNTI. The UE has many options for monitoring the C-RNTI.

If the UE is in RRC connected mode, the UE may always monitor the C-RNTI for potential MBS retransmissions from the gNB.

If the UE is in RRC connected mode and during a period in which MBS activity may be expected (e.g., during MBSDRX active periods), the UE may monitor the C-RNTI for potential MBS retransmissions from the gNB.

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

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

The UE may monitor the C-RNTI for potential MBS retransmissions from the gNB in all states and during periods in which MBS activity may be expected. For example, during MBSDRX active periods.

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

During periods when MBS activity may be expected, the UE may monitor the C-RNTI for potential MBS retransmissions from the gNB while in RRC idle and RRC inactive. For example, during MBSDRX active periods.

The UE may monitor the C-RNTI for potential MBS retransmissions from the gNB only after sending a NACK as HARQ feedback for a transport block transmission or retransmission while in RRC idle and RRC inactive.

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

If G-RNTI, the UE forwards the transport block to the identified MBS HARQ process.

In case of the C-RNTI, the UE may need to first determine whether a transport block corresponds to MBS service and needs to be transmitted to an MBS HARQ process or whether a transport block corresponds to DL unicast transmission and needs to be transmitted to a DL HARQ process. The UE may use the MBS indicator to determine whether the transport block corresponds to an MBS service or a DL unicast service. Alternatively, the UE may implicitly determine this based on the presence or absence of the G-RNTI/C-RNTI indication. For example, if there is a G-RNTI/C-RNTI indication, the UE may assume that the transport block corresponds to MBS traffic. If there is no G-RNTI/C-RNTI indication, the UE may assume that the transport block corresponds to DL unicast traffic. As another example, the UE may 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 may forward the transport block to the identified MBS HARQ process. For example, if the indicator indicates a DL HARQ process, the UE may forward the transport block to the identified DL HARQ process. Alternatively, the network and the UE may be configured such that the HARQ process ID of each of the HARQ processes is different according to the MBS HARQ process indicator. For example, DL HARQ process IDs may be in range 0..15, and MBS HARQ process IDs may be in range 16..32. The actual range may be part of the MRB configuration. In this case, the HARQ process ID implicitly informs the UE whether the transport block is to be processed by the DL HARQ process or the MBS HARQ process.

In case transport blocks are transmitted on both the G-RNTI and the C-RNTI and these transport blocks are handled by the same HARQ process, there may be cases where the network starts transmitting new transport blocks on the G-RNTI using the same HARQ process. This effectively causes HARQ process collisions. In such cases, the UE may receive transport block a (retransmission) on the C-RNTI and transport block B (new transmission) on the G-RNTI. These two transport blocks are designated to be handled by the same MBS HARQ process. To solve the HARQ process collision problem, the UE may use one or any combination of the following HARQ process collision methods:

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

In the second HARQ process collision method, the UE may consider only transport blocks received on the G-RNTI. The UE may flush the HARQ process and treat the G-RNTI as a new transmission.

In the third HARQ process collision method, the UE may process a transport block received on the C-RNTI and temporarily store the transport block received on the G-RNTI. The UE may move the temporarily stored transport block to the HA to RQ procedure when: 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 scheduling a TB on the C-RNTI.

In the fourth HARQ process collision method, after transmitting a NACK for a transport block received on the G-RNTI, the UE may start to monitor only the C-RNTI. In this case, if the UE is receiving a retransmission on the C-RNTI, the UE may not monitor the G-RNTI. The UE may resume monitoring the G-RNTI when: 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 scheduling a TB on the C-RNTI.

As another example, different MBS HARQ processes may be used for one MBS HARQ process in case the same transport block is received on the G-RNTI and a second MBS HARQ process in case the transport block is received on the C-RNTI.

Techniques for sending PDCP status reports are described herein that provide a solution to problem 4 described above. After handover, the UE may lose some PDCP SDUs. For services requiring reliability and service continuity, the receiver entity may send PDCP status reports to the transmitter entity so that the transmitter entity can know which PDCP SDUs need to be retransmitted. According to TS38.323, for an AM DRB configured by an upper layer to transmit a PDCP status report, a receiving PDCP entity may trigger the PDCP status report when:

The upper layer requests the PDCP entity to reconstruct;

the upper layer requests PDCP data recovery;

The upper layer requests uplink data handover;

The upper layer reconfigures the PDCP entity according to the version DAPS and may configure DAPS-SourceRelease as described in TS 38.331.

For UM DRBs configured by the upper layer to transmit PDCP status reports in the uplink, the receiving PDCP entity may trigger PDCP status reports when the upper layer requests uplink data handover.

The PDCP status reporting mechanism may be extended to provide lossless handover for MBS services, as well as lossless dynamic PTM-PTP handover and lossless MRB reconfiguration. In order to send PDCP status reports, it is proposed to add the following new triggers:

after expiration of the timer;

When the UE detects a lost PDCP PDU;

After MBS radio bearer reconfiguration;

After MBS radio bearer reconfiguration, and the UE detects lost PDCP PDUs;

After PTM-PTP handoff;

after the PTM-PTP handover, and the UE detects the missing PDCP PDU;

After a PTP-PTM handoff;

After a PTP-PTM handover, and the UE detects a lost PDCP PDU;

When the PDCP reordering timer expires;

The MBS radio bearer configuration may include a change of MRB type. Examples of MRB bearer type changes include, but are not limited to, PTM-PTP handoff, PTP-PTM handoff, or a change in MRB type.

When the UE is triggered to send a PDCP status report, the MRB may not have an UL path (either on RLC AM or RLC UM) to send this report. In the following, a new mechanism is presented as to how to send PDCP status reports.

The PDCP layer may notify a higher layer (RRC or NAS) of a need to transmit a status report. The higher layer may request to establish an uplink path for the MRB. For example, the gNB may reconfigure the MRB to have RLC AM PTP legs. Alternatively, the UE may include the PDCP status report in an RRC or NAS layer message sent to the network.

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

The UE may include the PDCP status report on a linked radio bearer with an uplink path. The UE may be provided with an identification of the linked radio bearer when configuring the MRB. If the UE needs to send a PDCP status report for this MRB, the PDCP status report may be sent via a linked radio bearer.

The UE may send PDCP status reports on the RACH.

The UE may include the PDCP status report on the PTP leg of another MRB split bearer. The UE may be provided with an identification of the split bearer when configuring the MRB.

Solution to problem 5: described herein is a procedure for a UE to join a multicast session that has been started/activated that provides a solution to problem 5 described above. Note that this problem may be described as the UE joining a multicast session that has been activated/started. The presented embodiments focus on the case where the UE receives MBS configuration while MBS services may already be started/activated. However, it should be understood that the embodiments are more generally applicable to any case where a UE starts receiving MBS traffic for a service that may already be in operation. For example, the same embodiment may be applied to the case where the UE performs path switching from the PTP leg to the PTM leg. For example, the same embodiment may be applied in the case of a PTM leg or a PTM radio bearer where a split bearer may be reconfigured.

MRB having a PTM leg configured with RLC-UM is described herein. Any PTM leg (e.g., MRB with a single PTM leg or split bearer with PTP leg and PTM leg) may be configured with RLC-UM. For RLC-UM transmission, the transmitting side may add a sequence number. For NR, for example, RLC-UM adds sequence numbers to all segmented RLC SDUs. The same sequence number may be added for each of the segments of the RLC SDU. On the receiving side, RLC-UM may maintain a reassembly window to allow the segmented PDUs to be reconstructed. The Window may be maintained by 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 may be defined as: (rx_next_ Highest-um_window_size) <=sn < rx_next_ Highest

Fig. 8 shows an example in which a reassembly window is shown generally on a round space 800 due to modulo arithmetic on SN. Fig. 8 shows that a 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 the example of fig. 8, the window moves when the receiving entity receives a UMD PDU with an SN outside the reassembled window. For example, if the receiver entity obtains sn=x that may be outside the reassembly window (region 1 801), the receiver entity sets rx_next_ Highest =x+1 (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 to be reassembled. If the receiving entity obtains sn=x, which may be inside the reassembly Window, which may be in one of 2 regions (region 2 802 or region 3 803), any UMD PDU received by the receiving entity with SN between (rx_next_ Highest-um_window_size 812) <=sn < rx_next_ Reassembly 810 may be in region 2 802. This UMD PDU belongs to an RLC SDU that has been reassembled by the recipient entity and forwarded to the upper layer, and thus, this UMD PDU may be discarded.

Any UMD PDU received by the receiving entity with SN between rx_next_ Reassembly 810< = SN < rx_next_ Highest 811 may be in region 3 803. This UMD PDU may be stored in a receive buffer and the UE may attempt to reassemble the RLC PDU. If all segments have been received, the RLC PDU may be forwarded to an upper layer.

One particular problem occurs when the UE is initially configured with RLC UM and the UE starts with initial values of rx_next_ Reassembly and rx_next_ Highest (i.e., set to 0). For this initial setting, region 2 802 and region 3 803 completely overlap. Since the MRB may already be in operation, the UE may not know which SN the gNB may be currently transmitting. When the UMD PDU arrives at the RLC-UM entity, it may have any SN. If this SN falls in region 2 802, this UMD PDU can be discarded, which may not be obviously an expected behavior. Although the UE RLC UM may eventually synchronize with the gNB RLC UM, many segmented UMD PDUs may be discarded before this occurs. In order to solve this problem, the following embodiments are proposed.

In a first embodiment, as part of the MRB configuration of the UE RLC UM, the UE may be provided with values of initial values of rx_next_ Reassembly 810 and rx_next_ Highest 811. For example, the gNB may set these values to values according to the SN of the last RLC SDU being segmented. Or the gNB may set these values according to the SN value of the next RLC SDU that may be segmented. Upon receiving the configuration, the UE may set up a reassembly window based on the configuration values of rx_next_ Reassembly 810 and rx_next_ Highest 811.

In the second embodiment, the UE RLC UM may set the values of rx_next_ Reassembly 810 and rx_next_ Highest 811 according to the value of SN of the first received UMD PDU. For example, after MRB configuration, the UE may not set up a reassembly window (set up no values for rx_next_ Reassembly 810 and rx_next_ Highest 811). Upon receiving the first UMD PDU for MRB, RLC UM may extract sn=x, and set rx_next_ Reassembly =x and rx_next_ Highest =x. Thus, the reassembly window may be set up upon receipt of the first UMD PDU.

In a third embodiment, the gNB may periodically transmit a control PDU containing a value of SN of the last RLC SDU segmented by the gNB. Alternatively, the gNB may periodically transmit a control PDU of SN of the next RLC SDU that may be segmented. The UE RLC UM will receive this control PDU and recover the SN information to initialize or reinitialize the rx_next_ Reassembly 810 and the rx_next_ Highest 811 according to the value of SN contained in the control PDU.

In a fourth embodiment, each unsegmented UMD PDU transmitted by the gNB may include in its header the value of SN of the last RLC SDU segmented by the gNB. Alternatively, each unsegmented UMD PDU transmitted by the gNB may include an SN of the next RLC SDU in its header that may be segmented. The UMD PDU may contain an indication that the UMD PDU includes an SN and that the UMD PDU contains a complete RLC SDU (no segmentation). This indication may allow the UE to know that the UMD PDU contains SN in the header, which SN corresponds to the value to be used by the UE to (re) initialize rx_next_ Reassembly 810 and rx_next_ Highest 811.

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

In an alternative to any of these five embodiments, the UE may discard any RLC SDU segments received that may not be initial segments and until the UE receives the first initial segment. When the UE first starts receiving MBS traffic for an ongoing MBS session, the gNB may have completed its transmission of the first segment of the RLC SDU. Thus, these segments may not be received by the UE, and thus, the UE may never reassemble the RLC SDU. In such a case, any UMD PDU received for this RLC SDU may be immediately discarded. The UE may use a Segmentation Information (SI) field and/or a Segmentation 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 an initial segmentation of any RLC SDU is received.

MRB with a PTM leg configured with RLC-AM is described herein. Any PTM leg (e.g., MRB with a single PTM leg or split bearer with PTP leg and PTM leg) may be configured with RLC-AM. For RLC-AM transmission, the transmitting side may add a sequence number for each RLC SDU. The transmitting side may also add an indication of which bytes of the original RLC SDU are contained in the segmentation if any RLC SDU is segmented. This information is all contained in the AMD PDU header. In addition, the receiving side may send RLC status reports to the transmitting entity to inform the transmitting entity to retransmit certain AMD PDUs.

Fig. 9 shows another example 900 in which a reception window is maintained at the receiving side RLC-AM to allow reconstruction of segmented PDUs and to allow transmission of status report information to the transmitting side. The window may be represented by a state variable: RX_Next 910 and window size: am_window_size. Initially, RX_Next may be set to 0. The receive window may be defined as:

RX_Next<＝SN<RX_Next+AM_Window_Size 911

Whenever the UE receives an AMD PDU with SN inside the receive window (region 4 901), the UE can check if the UE has all segments of this RLC SDU. If so, the UE may forward the RLC SDU to an upper layer. If not, the UE may store the AMD PDU in the receive buffer, may check to see if all segments of the RLC SDU have been received, and may check if the receive window can be moved. The lower edge of the window may represent the SN of the next RLC SDU to be received and transmitted to the upper layer. When the receiving entity receives all segments of RLC SDU with sn=rx_next 910, the window moves. In this case, the lower edge may be set to the expected next SN.

Whenever the UE receives an AMD PDU with SN outside the receive window (region 5, 902), the AMD PDU may be discarded.

One particular problem occurs when the UE may be initially configured with RLC AM and the UE starts with an initial value of rx_next set to 0. For this initial setting, the receive window may be determined according to the following equation:

0<＝SN<AM_Window_Size

Since the MRB is already in operation, the UE may not know which SN the gNB is currently transmitting. When an AMD PDU arrives at an RLC-AM entity, it can have any SN. If this SN falls within region 5 902, this AMD PDU may be discarded, which may not be obviously the expected behavior. Although the UE RLC AM may eventually synchronize with the gNB RLC AM, many AMD PDUs may be discarded before this occurs. In order to solve this problem, the following embodiments are proposed.

In a first embodiment, the value of the initial value of RX_Next 910 may be provided to the UE as part of the MRB configuration of the UE RLC AM. For example, the gNB may set the value according to the value of SN of the last RLC SDU transmitted. Or the gNB may set these values according to the value of SN of the next RLC SDU that may be transmitted. Upon receiving the configuration, the UE may set up a receive window based on the configuration value of rx_next 910.

In a second embodiment, the UE RLC AM may set the value of rx_next 910 according to the value of SN of the first received AMD PDU. For example, after MRB configuration, the UE may not set up a receive window (e.g., not set up the value of rx_next 910). Upon receiving the first AMD PDU for MRB, RLC AM may extract sn=x and set rx_next=x. Thus, the reception window may be set up upon receipt of the first AMD PDU.

In a third embodiment, the gNB may periodically transmit a control PDU containing a value of SN at the lower edge of the gNB transmit window. Alternatively, the gNB may periodically send a control PDU containing the SN at the lower edge of the gNB transmit window. The UE RLC AM may receive this control PDU and recover the SN information to initialize or reinitialize the rx_next 910 according to the value of SN contained in the control PDU.

In a fourth embodiment, each AMD PDU transmitted by the gNB may include in its header a value of SN at the lower edge of the gNB transmission window. Alternatively, each AMD PDU transmitted by the gNB may include the SN of 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 may allow the UE to know that the AMD PDU contains a first SN identifying the SN of the RLC SDU being transmitted and a second SN identifying the lower edge of the gNB transmission window. The UE will use this second SN to (re) initialize rx_next 910.

In an alternative to any of these four embodiments, the UE may discard any RLC SDU segments received that may not be initial segments and until the UE receives the first initial segment. When the UE first starts receiving MBS traffic for an ongoing MBS session, the gNB may have completed its transmission of the first segment of the RLC SDU. Thus, these segments may not be received by the UE, and thus, the UE may never reassemble the RLC SDU. In such a case, any AMD PDUs received for this RLC SDU may be immediately discarded. The UE may use a Segmentation Information (SI) field and/or a Segmentation 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 an initial segmentation of any RLC SDU can be received.

MRBs with PDCP reordering are described herein. PDCP may ensure that traffic can be delivered to higher layers in sequence if required by the service. To enable this functionality, the PDCP layer may maintain two variables rx_next and rx_ DELIV, and may use a receive buffer to store PDCP PDUs while waiting for them to be delivered in sequence. The UE may calculate rcvd_count for each received PDCP PDU. Rcvd_count may be based on a Hyper Frame Number (HFN) and SN of the received PDCP PDU. The variable rx_next may include a COUNT value of the NEXT PDCP PDU expected to be received. The initial value may be 0. For example, upon receiving a PDCP PDU with count=x, rx_next may be set to x+1. The variable RX DELIV may represent the COUNT value of the last PDCP PDU delivered by the PDCP to a higher layer. This may be the COUNT value of the last sequentially delivered PDCP PDU.

The PDCP entity may wait for PDCP PDUs having a COUNT value greater than rx_ DELIV. Any received PDCP PDU with a COUNT value less than RX DELIV may be considered to have been received and delivered. Therefore, the PDCP layer may discard the PDCP PDUs.

One particular problem occurs when 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 in operation, 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 the PDCP PDU arrives at the PDCP entity, it may have any SN1 value. If the UE assumes that HFN starts at 0, this value may be less than rx_ DELIV when the UE determines the COUNT value. In this case, PDCP PDUs may be discarded, which may obviously not be the expected behavior. Although the UE PDCP may eventually synchronize with the gNB PDCP, many PDCP PDUs may be discarded before this occurs. In order to solve this problem, the following embodiments are proposed.

In a first embodiment, initial values of rx_next and/or rx_ DELIV may be provided to the UE as part of the MRB configuration of the UE PDCP. For example, the gNB may set the value of TX NEXT according to the value of the transmitted last PDCP PDU. Or the gNB may set these values according to the value of tx_next of the NEXT PDCP PDU that may be transmitted. Upon receiving the configuration, the UE may set up variables based on the received configuration. Alternatively, the MRB configuration may contain a value of tx_next. As another example, the MRB configuration may include separate configurations for HFN and SN. The gNB may set these values according to the following:

HFN: the HFN part set to tx_next (i.e., the number of most significant bits is equal to the HFN length);

SN: the SN portion set to tx_next (i.e., the number of least significant bits is equal to PDCP SN length).

The UE may then determine initial values of rx_next and/or rx_ DELIV based on the configured HFN and SN. For example:

RX_NEXT＝[HFN,SN]

RX_DELIV＝[HFN,SN]

In a second embodiment, the UE PDCP may set the value of rx_next and/or rx_ DELIV according to the value of COUNT 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, PDCP may determine rcvd_count=x, and set rx_next=x and/or rx_ DELIV =x. Thus, the reception window may be set up when the first PDCP PDU is received.

In a third embodiment, the gNB may periodically transmit control PDUs 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 value contained in the control PDU. Alternatively, the gNB may periodically transmit a control PDU containing a value of TX_NEXT. This may be the value of the next PDCP PDU that may be transmitted or the value of the last PDCP PDU transmitted. Upon receiving the configuration, the UE may set up variables based on the received configuration. Alternatively, the gNB may periodically transmit a control PDU containing values of HFN and SN. The UE may then determine initial values of rx_next and/or rx_ DELIV based on the received HFN and SN.

In a fourth embodiment, each PDCP PDU transmitted by the gNB may include a value of tx_next in its header. The PDCP PDU may contain an indication that the PDCP PDU includes a value of tx_next. This indication may allow 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 a value of tx_next. The UE will (re) initialize rx_next and/or rx_ DELIV using the second field. Alternatively, the gNB may include in its header the values of HFN and SN associated with tx_next. The UE may then determine initial values of rx_next and/or rx_ DELIV based on the received HFN and SN.

In some cases, the above embodiments may be used in combination. The HFN portion of the state variable may be determined by using one embodiment (e.g., configured by the gNB), and the SN portion of the state variable may be determined by using another embodiment (e.g., based on the value of COUNT of the first received PDCP PDU).

MRB with HARQ feedback enabled is described herein.

Some MRBs may have HARQ feedback enabled. For these MRBs, the UE may send ACK and/or NACK feedback to the gNB, depending on whether or not the Transport Block (TB) may be successfully decoded by the UE. Typically, if MBS transmissions use PTM legs, these transmissions are destined for multiple UEs. For each transmission, zero, one, or more of these UEs may fail to decode the TB. The UE may send HARQ feedback to the gNB so that the gNB may decide whether to send a retransmission and, if so, how to send this retransmission. The transport block is transmitted for the HARQ process and the UE may be informed when to start a new transmission for this HARQ process-via a New Data Indicator (NDI) carried in the PDCCH control signalling.

One particular problem occurs when HARQ feedback is enabled and the UE starts receiving transport blocks from one or more HARQ processes from the gNB. Since the MRB may already be in operation, the UE may not know the number of times the transport block has been transmitted. For example, the gNB may have transmitted the transport block K times, but when the UE starts receiving MBS services, the UE receives only one of these K times that its decoding failed. In such cases, the UE may continue to attempt to decode subsequently received transport blocks for the HARQ process, but the UE may decide not to send any HARQ feedback for these transport blocks. For example, consider the case where the gNB may be making a third transmission of a transport block when the UE starts to monitor MBS services. The UE may just initiate listening and thus the UE receives the third transmission but may not receive the first two transmissions. In such cases, it may be better not to have the UE send a NACK for this TB, as it may not be desirable for the gNB to have to repeat the TB, as this UE just starts listening and has missed the first two transmissions. The UE may continue to decide not to send HARQ feedback for a given HARQ process until the UE receives an indication that the HARQ process has started a new transmission. At this time, the UE may transmit HARQ feedback for the HARQ process.

Fig. 10 shows an example 1000 of a UE receiving an MRB. In the example of fig. 10, the UE may begin MRB reception 1010 at time t 0. The UE may receive the retransmission for HARQ process 1 1001, but may not send any feedback 1011 to the gNB. At time t2, the UE may receive the new transmission and begin transmitting HARQ feedback 1012.

In another example of HARQ operation, when MBS traffic is destined for a group of interested UEs, transport blocks may be transmitted multiple times to ensure that all interested UEs successfully receive the transport blocks. In such cases, the UE may receive transport blocks that it may have successfully decoded. How the UE responds to these additional MBS HARQ retransmissions may not be defined in NR and therefore, once the UE successfully decodes a transport block, the UE may send positive HARQ feedback for each subsequent retransmission of the transport block. This may lead to unnecessary uplink transmission and may also lead to problems regarding PUCCH resources carrying MBS HARQ feedback. In order to solve this problem, the following embodiments are proposed.

In the first embodiment, if the UE has successfully acknowledged receipt of a transport block, the UE may decide not to send any HARQ feedback for this transport block.

In a second embodiment, the UE may decide to transmit HARQ feedback, but only up to a maximum number of times. The maximum number of times may be (pre) configured. For example, the UE may be (pre) configured to send a successful HARQ feedback indication up to a maximum of K times.

The HARQ feedback problem and HARQ processes are described herein. When a transmission occurs for a 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 described in clause 5.3.2.2 of the TS 38.321 specification is as follows:

For each received TB and associated HARQ information, the HARQ process should be:

1> if the HARQ process can be equal to the MBS HARQ process

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

3> treat this transmission as a new MBS transmission.

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

3> treat this transmission as an initial MBS transmission.

2> Otherwise:

3> treat this transmission as MBS retransmission

1> Otherwise:

2> if NDI has been switched when provided compared to the value of the previously received transmission corresponding to this TB; or alternatively

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 RRC; or alternatively

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

3> treat this transmission as a new transmission.

2> Otherwise:

3> treat this transmission as a retransmission.

The MAC entity will then:

1> if this is a new transmission or a new MBS transmission or an initial MBS transmission:

2> attempt to decode the received data.

1> Otherwise, if this is a retransmission or a new MBS transmission or an initial MBS transmission:

2> if the data of this TB has not been successfully decoded:

3> instructs the physical layer to combine the received data with the data of this TB currently in the soft buffer and to attempt to decode the combined data.

1> If the data that the MAC entity tries to decode is successfully decoded for this TB; or alternatively

1> If the data of this TB was successfully decoded before:

2> if HARQ process equals broadcast process:

3> delivers the decoded MAC PDU to an upper layer.

2> Otherwise, if this is the first successful decoding of the data for this TB:

3> delivering the decoded MAC PDU to the disassembly and de-multiplexing entity.

1> Otherwise:

2> instructs the physical layer to replace the data of this TB in the soft buffer with the data that the MAC entity tries to decode.

1> If the HARQ process is associated with a transmission indicated with a temporary C-RNTI and the contention resolution has not been successful (see clause 5.1.5); or alternatively

1> If the HARQ process is associated with a transmission indicated with MSGB-RNTI and the random access procedure has not been completed successfully (see clause 5.1.4a); or alternatively

1> If the HARQ process is equal to the broadcast process; or alternatively

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

1> if the HARQ process is equal to the MBS HARQ process and this is not the first successful decoding of the data for this TB, or;

1> if HARQ process is associated with initial MBS transmission:

2> does not instruct the physical layer to generate an acknowledgement of the data in this TB.

1> Otherwise:

2> indicates that the physical layer generates an acknowledgement of the data in this TB.

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

Note that: if the MAC entity receives a retransmission of a TB size different from the last TB size signaled for this TB, the UE behavior may be made dependent on the UE implementation.

Described herein is a procedure for a UE during a transition from multicast ACTIVE to multicast INACTIVE that provides a solution to problem 6 described above. The UE may be interested in one or more multicast sessions. These multicast sessions may be multiplexed on one or more G-RNTIs. Furthermore, these multicast sessions may be in two states: alternating between active and inactive.

The active multicast session may be an established multicast session in an active state. Multicast data may be transmitted to UEs joining a multicast session. 5G core network resources are reserved for multicast sessions. Corresponding radio resources are reserved according to the participating UE locations. The UE joining the multicast session is in the CM CONNECTED state. The UE may be allowed to join the multicast session (subject to authorization checks). For reception of an active multicast session, the UE may be in RRC connected or RRC inactive state.

The inactive multicast session may be an established multicast session in an inactive state. Multicast data is not transmitted. The UE joining the multicast session may be in a CM CONNECTED or CM IDLE state. The UE may be allowed to join the multicast session (subject to authorization checks). For an inactive multicast session, the UE may be in an RRC connected state, an RRC inactive state, or an RRC idle state.

The multicast session may transition from active to inactive and vice versa when the UE is in RRC connected or RRC inactive state. The UE may be indicated that the service has transitioned to an active or inactive mode. In the following, it can be assumed 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 may be received using one or more of the following embodiments.

In the first embodiment, the UE may receive an RRC message including an MBS session that has transitioned to an active or inactive mode. This RRC message may be carried in the system information on the BCCH. As another example, this RRC message may be carried in MBS control signaling on the MCCH. As another example, this RRC message may be carried on DCCH in dedicated signaling to all UEs receiving MBS sessions.

In a second embodiment, the UE may receive a MAC CE including an index of MBS sessions that have transitioned to an active or inactive mode. 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 the MBS session. Alternatively, the MAC CE may be included in a MAC PDU sent to an SC-RNTI configured to carry control information for the MBS session. 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 group of MBS sessions (including MBS sessions that may be transitioning to active or inactive modes) or all MBS sessions.

In a third embodiment, the UE may receive DCI including a bitmap indicating MBS sessions that have transitioned to an active or inactive mode. The UE may be configured with an index value for each MBS session. For example, "1" in bit position "k" may indicate that an MBS session with index 'k' has transitioned to active or inactive mode. The DCI may target a G-RNTI configured to carry an MBS session. 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 active or inactive modes, or all MBS sessions. Alternatively, the DCI may target the C-RNTI of each of the UEs that may be interested in receiving an MBS session, which may be transitioning to active or inactive mode.

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

Stopping the DRX for the MBS session if the DRX is configured according to the MBS session;

performing RLC entity re-establishment for radio bearers of the inactive MBS session;

PDCP entity radio bearers suspending inactive MBS sessions.

When the multicast session transitions from active to inactive, the UE may check if it is receiving any other MBS session on the G-RNTI. If not, the UE may:

stopping monitoring the G-RNTI and processing transport blocks received on the G-RNTI;

Stopping DRX for the G-RNTI;

performing RLC entity re-establishment for radio bearers of the inactive MBS session;

Suspending PDCP entity radio bearers of the inactive MBS session;

HARQ processes associated with the G-RNTI (e.g., those HARQ processes that are recovering transport blocks whose destination may be G-RNTI) are cleared.

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

starting DRX for MBS session if DRX is configured according to MBS session;

the PDCP entity radio bearer of the inactive MBS session is restored.

When the multicast session transitions from active to inactive, the UE checks if it is receiving any other MBS session on the G-RNTI. If not, the UE may:

the G-RNTI starts to be monitored. Following the DRX configuration for this G-RNTI, if configured;

the PDCP entity radio bearer of the inactive MBS session is restored.

Although described above for multicast sessions and transitions from active/inactive to inactive/active, these procedures may also be applied to broadcast sessions and transitions from start/stop to stop/start.

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

First, the UE may obtain an indication of whether the cell is broadcasting or multicasting an MBS session. Based on this indication, the UE may support cell reselection to those cells transmitting MBS sessions. This may be based on the priority of the MBS session.

Second, the UE may be configured to send an indication to the network if it detects a problem with broadcast or multicast reception while being RRC inactive. For example, the UE may be configured with a HARQ threshold, and the UE may monitor the number of failed transport blocks. If the UE observes that the percentage of transport blocks that fail reception exceeds this threshold, the UE may send an indication to the network. As a second example, the UE may be configured with a minimum required level of reception in the cell (e.g., minimum RSRP) or a minimum required level of quality in the cell (e.g., RSRQ). If the observed cell reception level or quality is below this threshold, the UE may send an indication to the network. The UE may send the indication while in RRC inactivity or the UE may transition to an RRC connection to send this indication. Upon receiving this indication, the gNB may decide to take some action to assist the UE in receiving MBS traffic. For example, modifying MCS, increasing transmit power, increasing the number of blind HARQ retransmissions, etc.

Described herein is a procedure for reliable transmission when MBS is preempted, which provides a solution to problem 7 described above. When there is URLLC a service request, the gNB can immediately transmit URLLC packets, either in the scheduling period or in the middle of an eMBB, mctc, or MBS transmission. In other words, to support URLLC packet transmissions, an ongoing eMBB, mctc, or MBS transmission packet may be stopped without notification.

Fig. 11 shows an exemplary transport block 1100. In the example of fig. 11, when a TB including three code blocks 1111, 1112, 1113 (e.g., a TB including MBS data 1101) is transmitted for an MBS service, each code block 1111, 1112, 1113 may be sequentially mapped to scheduled time-frequency resources. Thus, when the URLLC traffic is initiated in the middle of the MBS transport block 1101, a portion of the symbols in the second code block are replaced by symbols of the URLLC packet 1114.

As another example, transport blocks of MBS transmissions may be preempted by some higher priority transmission from the gNB. The UE receiving the MBS group of the preempted transport block needs to be informed of the preemption. The gNB may inform the UE that transmission has been preempted by using an INT-RNTI (preemption indication RNTI).

The UEs in the MBS group may also monitor the INT-RNTI. If the new transmission is preempted, it is apparent that all UEs in the MBS group will fail to decode the transport block. This may lead to problems with the uplink if all UEs in the MBS group send HARQ feedback. Since the gNB can determine that the initial transmission is to be NACK, it may not be beneficial to have all UEs in the MBS group send HARQ feedback.

Some UEs in the MBS group may be able to decode the transport block if the retransmission is preempted. Using the example from fig. 11, some UEs may be waiting to decode code block 1 1111 and may have already decoded code block 2 1112. Thus, preemption of code block 2 1112 will not have an impact on these UEs.

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

The DRX granularity for NR MBS is described herein, which provides a solution to problem 8 described above. In the following, the term DRX MBS configuration is used to refer to a DRX configuration for MBS traffic in order to distinguish it from a DRX configuration for unicast traffic. Similarly, the term MBS DRX operation is used to refer to DRX related actions at the UE related to reception of MBS traffic. Similarly, in order to distinguish between DRX timers for unicast service reception and MBS service reception, a qualifier is sometimes added to a timer name. For example, the MBS retransmission timer may refer to a retransmission timer for MBSDRX operations.

The granularity of DRX for unicast transmissions may be per UE per DRX group, where a DRX group may be a set of serving cells. That is, the UE may have a single DRX configuration for each DRX group. For LTE eMBMS transmissions, the granularity of DRX may be according to 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 a UE having MBSDRX granularity per G-RNTI. For NR MBS, many MBS services may be mapped to G-RNTI and multiplexed in the same transport block. MBSDRX particles may be one or a combination of the following.

Per MTCH logical channel: each logical channel may have its own DRX configuration;

Per MBS session: each MBS session may have its own DRX configuration. In the case where an MBS session may be transmitted on multiple logical channels, MBSDRX configurations will be applied to each of these logical channels;

group-wise RNTI (G-RNTI): each G-RNTI may have its own DRX configuration. Since the G-RNTI may multiplex multiple MTCHs, the DRX configuration will be the same for each logical channel;

Per group RNTI (SC-RNTI) for MCCH: each SC-RNTI may have its own DRX configuration.

Where MBSDRX granularity may be defined per MTCH logical channel or per MBS session, the gNB may determine a single MBSDRX configuration for the G-RNTI. This single MBSDRX configuration is based on the combined DRX requirement of the MTCH logical channel and MBS session multiplexed on the G-RNTI.

The UE may be configured with MBSDRX configurations for each G-RNTI that it may be monitoring, MBSDRX configurations for each SC-RNTI that it may be monitoring, and unicast DRX configurations for each DRX group.

A DRX configuration for NR MBS is described herein, which provides a solution to problem 9.

The following DRX configuration parameters may be applied to MBSDRX:

drxMBS-onDurationTimer: duration at the beginning of MBSDRX cycles;

drxMBS-SlotOffset: the delay before starting the drx-onduration timer;

drxMBS-InactivityTimer: duration after PDCCH occasion where PDCCH indicates new DL or MBS transmission of MAC entity;

drxMBS-RetransmissionTimerDL (per DL HARQ process): the maximum duration until a SL retransmission can be received;

drxMBS-LongCycleStartOffset: drxMBS-StartOffset for long MBSDRX cycles and subframes defining long MBSDRX cycles and short MBSDRX cycles;

drxMBS-ShortCycle (optional): MBSDRX cycles;

drxMBS-ShortCycleTimer (optional): the UE should follow the duration of the short MBSDRX cycles;

drxMBS-HARQ-RTT-TimerDL (per DL HARQ process): the MAC entity may expect a minimum duration before DL assignment for HARQ MBS retransmissions.

A separate MBSDRX configuration may be applied to each G-RNTI configured in the UE. A separate MBSDRX configuration may be applied to each SC-RNTI configured in the UE.

The MAC entity may be configured with MBSDRX functionality by RRC, which MBSDRX functionality controls PDCCH monitoring activity of the UE on the G-RNTI and SC-RNTI of the MAC entity. In case the MBS transmission uses PTP scheme or PTM scheme 2, then MBSDRX functionality also controls the PDCCH monitoring activity of the UE on the C-RNTI of the MAC entity. Furthermore, MBSDRX functionality may also control the PDCCH monitoring activity of the UE on the INT-RNTI of the MAC entity. While in rrc_connected, if MBSDRX is configured, the MAC entity may discontinuously monitor the PDCCH using MBSDRX operation for all active serving cells.

When MBSDRX cycles are configured, the active time includes the time when:

drxMBS-onDurationTimer or drxMBS-InactivityTimer configured for G-RNTI or SC-RNTI or C-RNTI may be running; or alternatively

DrxMBSRetransmissionTimerDL may be running.

A UE DRX procedure is described herein, which provides a solution to problem 10. In the following examples, descriptions may be based on MBS transmissions on G-RNTI. It should be appreciated that this may simplify the description and that the procedure may be applied to any group RNTI for MBS transmissions. Therefore, the procedure can also be applied to MBS transmission on SC-RNTI.

The MBS transmission to the G-RNTI is to a group of UEs (hereinafter referred to as MBS group). If MBSDRX configuration is G-RNTI based, then each UE in this MBS group has the same MBSDRX configuration. For MBS services, the gNB has various options for MBS HARQ transmission and retransmission, such as:

PTP scheme: for rrc_connected UEs, a UE-specific PDCCH with a CRC scrambled by a UE-specific RNTI (e.g., C-RNTI) is used to schedule a UE-specific PDSCH that may be scrambled with the same UE-specific RNTI.

PTM scheme 1: for rrc_connected UEs in the same MBS group, a group common PDCCH with CRC scrambled by the group common RNTI is used to schedule a group common PDSCH that can be scrambled with the same group common RNTI. This scheme may also be referred to as a group scheduling scheme based on a group common PDCCH.

PTM scheme 2: for rrc_connected UEs in the same MBS group, a UE-specific PDCCH with a CRC scrambled by a UE-specific RNTI (e.g., C-RNTI) is used to schedule a group common PDSCH that may be scrambled with a group common RNTI. This scheme may also be referred to as a UE-specific PDCCH-based group scheduling scheme.

Furthermore, the UE may have the following options for HARQ feedback for multicast (the options used may be configured by the gNB):

no HARQ feedback;

HARQ-ACK feedback based on ACK/NACK;

HARQ-ACK feedback based on NACK only.

To utilize the DRX configuration, the gNB and all UEs in the MBS group may be synchronized in terms of when to start and stop the various timers, including the inactivity timer, HARQ RTT timer, and retransmission timer.

The inactivity timer may be started for each new MBS transmission received by the UE. An inactivity timer at the UE may be started:

When the UE receives DCI indicating a PTP scheme MBS transmission with the C-RNTI of the UE as a destination;

When the UE receives DCI indicating a PTM scheme 1MBS transmission to the G-RNTI of the UE, the DCI may be scrambled with a group common RNTI;

When the UE receives DCI indicating a PTM scheme 2MBS transmission to the G-RNTI of the UE, the DCI may be scrambled by a UE-specific RNTI (e.g., C-RNTI).

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

Fig. 12 illustrates various exemplary options 1200 for a UE. It may be assumed that UE1 and UE2 are in the same MBS group and have the same DRX configuration for G-RNTI.

Step 1201: UE1 and UE2 may be in the same MBS group and share DRX configuration.

Step 1202: during MBSDRX active times of the DRX configuration, UE1 and UE2 receive DCI which schedules MBS transmissions. According to the transmission scheme (PTP scheme, PTM scheme 1, PTM scheme 2), the UE monitors one or more of C-RNTI, G-RNTI or SC-RNTI configured for UE1 and UE 2.

Step 1203a: UE1 may start an inactivity timer for this DRX configuration.

Step 1204a: UE1 may successfully decode the transport block.

Step 1205a: according to the HARQ feedback configuration, UE1 may send an ACK to the gNB.

Step 1206a: if UE1 determines that the transport block does not contain the MTCH of interest, UE1 may stop the inactivity timer for PTM scheme 1.

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: the transport block is received correctly but is not of interest to UE 1.

Step 1203b: UE2 may start an inactivity timer for this DRX configuration.

Step 1204b: UE2 may not be able to decode the transport block.

Step 1205b: according to the HARQ feedback configuration, UE2 may send a NACK to the gNB and start a HARQ RTT timer for the HARQ process.

Step 1206b: upon expiration of the HARQ RTT timer, UE2 may start a retransmission timer.

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 retransmission. In a first alternative, UE2 may monitor both the C-RNTI and the G-RNTI while the retransmission timer is running. In a second alternative, the UE2 may monitor the C-RNTI or G-RNTI while the retransmission timer is running. UE2 may make this determination based on the configuration. For example, UE2 may be configured to know which retransmissions are using the PTP scheme. Alternatively, UE2 may make this determination based on an indication in the initial transmission indicating how the gNB will send a retransmission (if any is needed). For example, the initial transmission DCI may contain a 1-bit field indicating that the retransmission will use PTM scheme 1. Note that the indication may also be included in the DCI scheduling each retransmission to inform the UE how any subsequent or future retransmissions will be sent. In a third alternative, UE2 monitors the C-RNTI during unicast DRX active time. The gNB may ensure that it will send all DCI scheduling MBS retransmissions during unicast DRX active time.

The second problem to be solved may be related to the retransmission timer. Note that a single MBS transmission as described above results in potentially different actions at the UE, depending on whether or not the transport block can be successfully decoded. Those UEs that have not successfully decoded the transport block expect retransmission. These UEs may start HARQ RTT timers. The UEs may also start a retransmission timer that receives retransmissions. However, for those UEs that have successfully decoded the transport block, retransmission is not desirable. These UEs will not start the HARQ RTT timer or the retransmission timer. Since not all UEs in the MBS group will start the retransmission timer, it has been proposed that the gNB may refrain from sending new transmissions while the retransmission timer is running, otherwise UEs that have not started the retransmission timer may not be able to obtain these new transmissions. However, there may be problems for those UEs that do start the retransmission timer. The gNB cannot schedule new transmissions using the time during which the retransmission timer may be running. The gNB can only schedule retransmissions. The gNB is likely to schedule only a certain number of retransmissions. Thereafter, the gNB is likely to attempt to schedule a new transmission. In this case, if the UE sends a NACK for this last retransmission, the UE may trigger a retransmission timer, but no transmission from the gNB may be imminent. This may waste power saving opportunities. This triggered retransmission timer may expire, however, UE behavior upon expiration of the retransmission timer may not be specified. To avoid these two problems, it is proposed that the gNB may 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 may decide not to start the HARQ RTT timer. The UE may also decide not to start the retransmission timer. Alternatively, UE behavior upon expiration of the retransmission timer may be specified. For example, upon expiration of the retransmission timer, the UE may:

2> if short MBSDRX cycles are configurable:

3> starts or restarts drxMBS-ShortCycleTimer for this G-RNTI in the first symbol after drxMBS-RetransmissionTimer expires;

3> short MBSDRX cycles are used for this G-RNTI.

2> Otherwise:

3> long MBSDRX cycles are used for this G-RNTI.

Claims (15)

1. A wireless transmit/receive unit, WTRU, comprising a transceiver and one or more processors, the WTRU configured to:

receiving a configuration for receiving a multicast-broadcast service, MBS, service, wherein the configuration indicates:

values of variables to be processed at packet data convergence PDCP layer, and

One or more logical channels associated with the MBS service;

Initializing the variable based on the value;

Receiving a transport block including MBS service;

decoding the received transport block comprising the MBS service; and

Based on decoding the received transport block:

Discarding data at a medium access control, MAC, layer not associated with the one or more logical channels associated with the MBS service, and

Data associated with the one or more logical channels associated with the MBS service is processed at the PDCP layer and based on the initialized variables.

2. The WTRU of claim 1 wherein the variable is rx_ DELIV.

3. The WTRU of any of claims 1-2, wherein the MBS service comprises a broadcast service, a multicast service, or a unicast service.

4. The WTRU of any one of claims 1-3, wherein the decoding comprises:

and de-multiplexing the transport block at the MAC layer.

5. The WTRU of any one of claims 1-4, wherein the decoding comprises:

The transport blocks are disassembled at the MAC layer.

6. The WTRU of any one of claims 1-5 wherein rx_ DELIV indicates a COUNT value of a last PDCP protocol data unit PDU delivered by the PDCP layer to a higher layer.

7. The WTRU of any one of claims 1-6, wherein the configuration comprises a PDCP layer configuration.

8. The WTRU of any one of claims 1-7, wherein the configuration comprises a MAC layer configuration.

9. The WTRU of any one of claims 1 to 8, wherein the MBS service is multiplexed on a single group radio network temporary identifier, G-RNTI.

10. The WTRU of any one of claims 1 to 9, wherein hybrid automatic repeat request, HARQ, feedback is not sent for the discarded data.

11. A method for use in a wireless transmit/receive unit, WTRU, the method comprising:

receiving a configuration for receiving a multicast-broadcast service, MBS, service, wherein the configuration indicates:

values of variables to be processed at packet data convergence PDCP layer, and

One or more logical channels associated with the MBS service;

Initializing the variable based on the value;

Receiving a transport block including MBS service;

decoding the received transport block comprising the MBS service; and

Based on decoding the received transport block:

Discarding data at a medium access control, MAC, layer not associated with the one or more logical channels associated with the MBS service, and

Data associated with the one or more logical channels associated with the MBS service is processed at the PDCP layer and based on the initialized variables.

12. The method of claim 11, wherein the variable is rx_ DELIV.

13. The method of any of claims 11 to 12, wherein the MBS service comprises a broadcast service, a multicast service or a unicast service.

14. The method of any of claims 11 to 13, wherein rx_ DELIV indicates a COUNT value of a last PDCP protocol data unit PDU delivered by the PDCP layer to a higher layer.

15. The method according to any of claims 11 to 14, wherein the MBS service is multiplexed on a single group radio network temporary identifier, G-RNTI.