CN116114272A - 5G Multicast Broadcast Service (MBS) radio access network architecture and operation - Google Patents

Abstract

Methods and apparatus for 5G MBS operation are described herein. The proposed method and procedure overcomes the limitations that have been observed in LTE and UTRAN MBMS operation, solves the unique characteristics of 5G NR, and meets the requirements imposed by the envisaged 5G MBS case by providing functions including: flexible and dynamic RAN multicast area concepts, MBS Radio Bearer (MRB) types supporting MBS services, RAN architecture supporting various MBS radio bearer types, and functions that are split across RAN nodes to support these radio bearers, procedures that allow radio bearer selection, monitoring and handover, and procedures that allow multicast area management.

Description

5G Multicast Broadcast Service (MBS) radio access network architecture and operation

Cross Reference to Related Applications

The present application claims the benefit of U.S. provisional patent application No. 63/061,764 filed 8/5/2020 and U.S. provisional patent application No. 63/168,515 filed 3/2021, the disclosures of which are incorporated herein by reference in their entireties.

Background

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. Thus, there is a need for improved multicast/broadcast services.

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. In addition, the claimed subject matter is not limited to addressing any or all of the disadvantages noted in any part of this disclosure.

Methods and procedures that allow 5G MBS operation. The proposed method and procedure overcomes the limitations already observed in LTE and UTRAN MBMS operation, solves the unique characteristics of 5G NR, and meets the requirements set forth by the envisaged 5G MBS case. Embodiments are described herein for the following: a flexible and dynamic RAN multicast (xcasting) area concept; MBS Radio Bearer (MRB) types supporting MBS services; RAN architecture supporting various MBS radio bearer types, and functionality to split across RAN nodes to support these radio bearers; design for MBS configuration; a design for mapping MBS traffic to G-RNTI; design for MBS control information; procedures allowing radio bearer selection, (re) configuration, monitoring and path switching; and a procedure that allows multicast area management.

Drawings

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

FIG. 1B illustrates a block diagram of an exemplary apparatus or device configured for wireless communication;

fig. 1C shows a system diagram of an exemplary Radio Access Network (RAN) and core network;

fig. 1D shows a system diagram of another exemplary RAN and core network;

fig. 1E is a system diagram of another exemplary RAN and core network;

FIG. 1F illustrates a block diagram of an exemplary computing system;

FIG. 1G illustrates a block diagram of another exemplary communication system;

fig. 2 illustrates an exemplary MBSFN transmission;

fig. 3 shows a RAN multicast area;

fig. 4 shows architecture option 1;

fig. 5 shows architecture option 2;

fig. 6 shows architecture option 3;

fig. 7 shows architecture option 1: user plane architecture for SC-PTP, SC-PTM and non-SFN MC-PTM radio bearers;

fig. 8 shows architecture option 1: user plane architecture for non-SFN MC-PTM radio bearers;

fig. 9 shows architecture option 2: user plane architecture for SC-PTP;

fig. 10 shows architecture option 2: user plane architecture for SC-PTM and SFN MC-PTM;

fig. 11 shows architecture option 2: user plane architecture for non-SFN MC-PTM;

Fig. 12 shows architecture option 3: user plane architecture for SFN MC-PTM;

fig. 13 shows architecture option 3: user plane architecture for non-SFN MC-PTM;

fig. 14 shows architecture option 1: a control plane architecture;

fig. 15 shows architecture option 2: control plane architecture for SC-PTM;

fig. 16 shows architecture option 2: control plane architecture for SFN SC-PTM;

fig. 17 architecture option 2: control plane architecture for non-SFN SC-PTM;

fig. 18 shows architecture option 3: control plane architecture for SFN MC-PTM;

fig. 19 shows architecture option 3: control plane architecture for non-SFN MC-PTM;

FIG. 20 shows an L2 data structure at gNB;

fig. 21 shows the radio bearer options for MBS services;

fig. 22 shows the mapping of MBS traffic to G-RNTI;

FIG. 23 illustrates an exemplary mapping per service;

fig. 24 illustrates mapping options of MBS control information to MCCHs;

fig. 25 illustrates an exemplary radio bearer maintenance for a 5G QoS flow;

FIG. 26 illustrates an exemplary mapping of 5G MBS QoS flows to radio bearers;

fig. 27 shows a process for determining the number of branches; and is also provided with

Fig. 28 shows the UE actions when the multicast area changes.

Detailed Description

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 Radio (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 the 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 generically or collectively as WTRUs 102), a Radio Access Network (RAN) 103/104/105/103b/104b/105b, a core network 106/107/109, a Public Switched Telephone Network (PSTN) 108, the internet 110, other networks 112, and V2X servers (or ProSe functions and servers) 113, although 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. 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 computer, a tablet computer, 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 the like, 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 (BTS), node-B, eNode B, home Node B, home eNode B, site controllers, access Points (AP), 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, TRPRP 119a, 119b and RSUs 120a, 120b and the WTRUs 102c, 102d, 102e, 102f in the RAN 103/104/105 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, trp119a, 119b and/or RSUs 120a, 120b in the base station 114a and RAN103b/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, TRPRP 119a, 119b and/or RSUs 120a, 120b in the RAN103b/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 communication (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 is to 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 RAN103/104/105 and/or the RAN103b/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 RAN103/104/105 and/or RAN103b/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 illustrated 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. Additionally, 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 (enobs), 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.

Additionally, although the transmit/receive element 122 is depicted as a single element in fig. 1B, the WTRU102 may include any number of transmit/receive elements 122. More specifically, the WTRU102 may employ MIMO technology. Thus, in one embodiment, the WTRU102 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 WTRU102 may have multi-mode capabilities. For example, thus, the transceiver 120 may include multiple transceivers to enable the WTRU102 to communicate via multiple RATs (such as UTRA and IEEE 802.11).

The processor 118 of the WTRU102 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/pointer 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 WTRU102, 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 automobiles, 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 RAN103 and core network 106 according to an embodiment. As described above, RAN103 may communicate with WTRUs 102a, 102b, and 102c over air interface 115 using UTRA radio technology. RAN103 may also communicate with core network 106. As shown in fig. 1C, the RAN103 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. RAN103 may also include RNCs 142a, 142b. It should be appreciated that RAN103 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 RAN 104 and core network 107 according to an embodiment. As described 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 eNode- 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 understood 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 eNode- 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 eNode- 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 the user plane 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 conventional 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 WTRU102a, 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 understood 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 giving these entities names in some existing 3GPP specifications, but it should be understood that these entities and functions may be identified by other names in the future, and that some entities or functions may be combined in specifications that are disclosed by 3GPP in the future, including future 3GPP NR specifications. Accordingly, 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 implemented in any similar communication system, whether currently 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 illustrated in fig. 1A, 1C, 1D, and 1E, such as some nodes or functional entities in RANs 103/104/105, core networks 106/107/109, PSTN108, 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 memory includes 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.

Further, computing system 90 may include communication circuitry such as, for example, network adapter 97, which may be used to connect computing system 90 to external communication networks such as 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 computing system 90 to communicate with other nodes or functional entities of these 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.

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.

Support for MBMS over LTE networks has evolved considerably over various versions of LTE. Table 1 below shows an overview of the major changes/enhancements by 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 LTE architecture of MBSFN transmission 200. The logical entities include BM-SC 201, MBMS GW 202, MME 205 and MCE 203. In addition, each eNB 204 shown in the figure participates in MBSFN transmission. Transmissions from these enbs 204 define an MBSFN area, which is the area where UEs receive MBSFN transmissions from multiple enbs 204. The transmission is performed on a multicast transport channel (MCH) mapped to a physical channel (PMCH physical multicast channel). The PMCH is transmitted in the reserved subframe. I.e. subframes that have been set aside by the eNB for MBSFN transmission purposes. These subframes are used to carry MBMS control plane 211 information (multicast control channel MCCH) and MBS user plane 212 traffic (multicast traffic channel MTCH). From the system information, the UE determines the subframes set forth for the MBS, which of these subframes carry the MCCH, and a configuration for the PMCH that allows the UE to decode traffic received on the PMCH in the reserved subframes. The UE then reads the MCCH to obtain scheduling information for MBMS user plane 212 traffic. I.e. which of the reserved subframes contain streams from a particular multicast/broadcast stream. The UEs may then use this scheduling information to determine the multicast/broadcast streams of interest to them and to receive/decode the MBMS service. The UE monitors the MCCH to determine whether there is any change in the MBMS service provision.

Notice of MBSFN operation:

it can be used for rrc_connected and rrc_idle UEs;

only a single transport block may be transmitted in each reserved subframe;

only a single transmission is used for MCH (neither blind HARQ repetition nor RLC fast repetition); and

the MTCH and MCCH use RLC-UM mode (the configuration of which 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. This 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. Further, in release 11, for a UE in rrc_connected, the UE may inform the serving cell about the carrier frequency on which the MBMS service of interest is scheduled to be transmitted. For this purpose, the RRC layer introduces a new uplink message called the mbms interest indication message. The intention is that the eNB will use this information to select the target cell for handover.

Version 12 was introduced as one of the major enhancements: mooD (on-demand MBMS operation) that enables automatic and seamless MBMS service activation and deactivation based on a service consumption report of a UE.

The main enhancement is the introduction of single cell point-to-multipoint (SC-PTM) 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 the control channel (SC-MCCH) and the 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 a unicast service, 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 Rel' 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 simple ON and OFF periods, where the DRX active time is prolonged when the UE receives SC-PTM service. This MBMS specific DRX mode is independent of the UE specific DRX mode. Further, the notice of the SC-PTM operation:

Can be used for rrc_connected and rrc_idle UEs;

only a single transmission is used for DL-SCH (neither blind HARQ repetition nor RLC fast repetition);

the SC-MTCH and SC-MCCH 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".

Despite advances in many LTE releases, MBMS over LTE is still subject to many limitations. Several of these limitations are described below.

Air interface limitations: LTE MBSFN and SC-PTM are characterized by strict OFDM (orthogonal frequency division multiplexing) base parameters that limit the type of network deployment. A large area SFN requires a much larger cyclic prefix length than allowed by LTE.

Limitations related to coverage area: the coverage area for MBMS deployment is very static and not adaptable. This results in a number of limitations. For MBSFN transmission, the MBSFN area is statically configured regardless of user distribution. Second, it is not possible to dynamically create MBSFN areas on a cell level basis. Third, in a given coverage area, it is not possible to use point-to-point (PTP), single cell point-to-multipoint (PTM) and multi-cell (SFN) PTM to provide the same service.

Limitations provided for local/regional coverage: local/regional services can only be inserted by establishing different MBSFN service areas with TDM (time division multiplexing). Thus, these local services may each have their own MBSFN area. In addition, MBSFN is inefficient for cell area broadcast because it cannot be configured using MIMO, short CP and reduced pilot signal overhead.

Restrictions on unicast/broadcast multiplexing: for MBSFN, a subframe occupies the entire bandwidth. Multiplexing with unicast transmissions in the frequency domain is not allowed. TDM is the only multiplexing mechanism allowed in MBSFN.

Limitations on signal diversity techniques: MBSFN and SC-PTM lack frequency and time interleaving that can significantly improve the reliability of transmission in receive-only mode, which itself lacks link adaptation techniques due to the unavailability of the uplink channel.

Restriction of single frequency network operation in SC-PTM: SC-PTM cannot be configured in an SFN operation mode, which may be beneficial when multiple cells are transmitting the same content.

Limitation of resource allocation: up to Rel'14, only up to 60% of subframes may be allocated to MBSFN services. Rel-14 adds the option of using 2 additional subframes or the possibility of using all subframes for MBSFN, reaching 80% and 100% of the resources allocated to MBSFN services, respectively. In addition, MBSFN resource allocation is static and it cannot accommodate network traffic load. The subframes reserved for MBSFN operation are transmitted regardless of user demand. To overcome this limitation, LTE release 14 allows unicast data to be mapped on MBSFN subframes without available broadcast content, however, only devices with specific capabilities are able to decode this data.

Limitation of control channel size: for SC-PTM, the mapping of downlink physical channels and signals to physical resources as defined in Rel-13 has a limitation, because the number of OFDM symbols used to carry control channels (as signaled by the control format indicator CFI) is fixed to 3 for 5MHz and lower bandwidths, or to 2 for 10MHz and higher bandwidths.

Restriction of link adaptation: the possibility to feed back channel state information on MBSFN reception of uplink capable users to an eNodeB (eNB) may be useful for performing link adaptation techniques for a group of users. This feature may be of particular interest for deployment of small cells with a limited number of users requiring the same content. In the case of a receive-only mode receiver with a large cell, this feature is less relevant.

Limitations associated with feedback channels: there is no feedback from the radio access network to the core MBMS entity regarding successful establishment of the radio access bearer associated with the specific service. For both MBSFN and SC-PTM, no retransmission of Multicast Traffic Channel (MTCH)/SC-MTCH is allowed. There is no special feedback for SC-PTM link adaptation. RAN implementations may use the feedback mechanism defined for unicast transmissions in proprietary SC-PTM link adaptation solutions, but this is not optimal.

Limitation of delay: since the Multicast Control Channel (MCCH) modification period is long, the control plane takes about 5 seconds to establish the MBSFN radio bearer. The modification period was 5.12s or 10.24s before Rel-14. In Rel-14, the protocol involves a fast reconfiguration, still requiring a modification period of 10ms. Furthermore, MBSFN area configurations and available MBMS services have to be transmitted periodically on MCCH, which requires an MCCH repetition period, which may be 320ms and up to 2.56s. With the fast reconfiguration in Rel'14, the repetition period is at least 10ms. For SC-PTM, the modifications must first be published in one modification period and actually signaled in the next modification period. The modification period may be one radio frame in Rel-14 and up to 2, 4, 8 … 256 … 65536 radio frames in release 13. In addition, the provided MBMS service must be periodically transmitted on the SC-MCCH, wherein the repetition period is 1 radio frame in Rel-14 and 2, 4, 8, … 256 radio frames in Rel-13. For MBSFN, the user plane requires a minimum delay of 40ms for hybrid unicast/broadcast transmission (long multicast transmission channel scheduling period). For SC-PTM, scheduling information for each service (i.e., each SC-MTCH) is provided in system information. The UE attempts to receive the SC-MTCH continuously or according to a discontinuous reception configuration.

Limitations regarding service continuity: service continuity is limited to MBSFN service areas in MBSFN. In order to maintain service continuity in SC-PTM, the UE is allowed to switch to unicast with handover and without the new serving cell transmitting SC-PTM transmissions. This feature is relevant to mission critical services where the degree of reliability of the service must be maintained.

Limitations related to UE interest indication: in order to learn from the network side the UE's interest in a particular service, the UE must indicate this interest via an "MBMS interest indication" Radio Resource Control (RRC) message in several cases, including when a connection is successfully established, when entering or leaving a service area, when a session starts or stops, when an interest changes, when a priority between MBMS reception and unicast reception changes, or when changing to PCell broadcast. For MBSFN, MCE (multi-cell/multicast coordination entity) may use MBMS counting procedure to count the number of rrc_connected mode UEs that receive via MBS Radio Bearers (MRBs) or are interested in receiving a specified MBMS service via an MRB.

Limitations regarding inflexible control information acquisition: in order to save UE battery power while monitoring the availability of MBMS broadcasts, the trigger must come from the network side to wake up the MBMS reception. The control plane and the indication of the change of control information are shared by all MBMS services within the MBSFN area or cell. When multiple services with various delay requirements use MBMS in the same MBSFN area or the same cell, this may have a negative impact on many aspects of system and UE performance. For example, UEs interested in MBMS services that allow longer waiting times must monitor for control information changes more frequently than necessary, resulting in battery drain. A specific/explicit trigger mechanism for broadcast control information acquisition in 5G may not be necessarily specified, but may be sufficient to include MBMS notification in the paging message.

Limitations on power savings: the SC-PTM transmission may be configured with an MBMS specific DRX mode. This mode is independent of the UE-specific DRX mode configured in the UE. Thus, the UE is monitoring the PDCCH while the UE is in active time for either of the two configured DRX modes. This may lead to certain power consumption problems due to lack of coordination.

The 3GPP RAN has considered a variety of use cases that would benefit from 5G MBS support. Use cases can be categorized into 4 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 includes:

the bit rate can be very high;

the delay can be very low;

reliability must support use cases with extremely high reliability;

the density should be able to cope with extremely dense deployments;

mobility should be able to handle high mobility UEs;

flexibility:

the operator should be able to dynamically change the capacity reserved for MBS (from 0% to 100%);

the operator should be able to dynamically change the size of the service area (the service area may have a granularity as small as a cell to as large as a country);

operators should be able to provide MBS coverage over small and large areas (e.g., nationwide);

efficiency is improved;

the operator should be able to dynamically change how services (multicast, broadcast, unicast, PTP, PTM) are provided to the UE;

The UE should 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 that addresses some of the limitations of MBMS operation over LTE and attempts to meet the requirements listed above. Work items have 2 main goals:

(1) 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 changes are specified, for example, by UL feedback to improve the reliability of the broadcast/multicast service. The level of reliability should be based on the requirements of the application/service provided; and

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.

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

To maintain the maximum commonality between rrc_connected states, the required changes are specified to enable the reception of the point-to-multipoint transmission by the UE in rrc_idle/rrc_inactive state;

an RRC_IDLE/RRC_INACTIVE state for configuration of PTM reception; and

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.

The first two versions of the 5G RAN do not support MBS. Version 15 and version 16 design decisions are made to support unicast services only over the Uu interface. Based on release 16 5G design, 5G MBS requirements and LTE MBMS restrictions, the following set of problems need to be solved in order to allow the 5G RAN to support MBS.

Architecture support for 5G MBS is one problem addressed by the embodiments described herein. Current 5G architectures do not support efficient MBS transmissions. Based on UTRAN and E-UTRAN MBMS architectures, multiple functions need to be added to the 5G architecture to allow MBS operation. The architecture needs to support dynamic control of MBS transmission zones, allowing cells to be added to or removed from this zone. The architecture needs to support multiplexing of unicast QoS flows and MBS QoS flows to a specific UE. The architecture also requires a RAN delivery method that allows the gNB to dynamically change the resource allocation reserved for PTM services and to dynamically switch MBS QoS flows. This architecture needs to manage synchronization issues for SFN deployment, especially when MBS transmission areas are on multiple gnbs (e.g., nationwide MBS). Furthermore, the architecture needs to support different 5G MBS bearer types.

The radio bearer configuration option for MBS services is another problem addressed by the embodiments described herein. For single cell multi-unicast areas, the network has many radio bearer configuration options for sending MBS traffic for a service to a set of UEs of interest. A service consists of one or more MBS QoS flows. The radio bearer configuration maps MBS services to radio bearers and to C-RNTIs and/or G-RNTIs for transmission through the PDSCH. However, some details of the radio bearer configuration depend on the decision made for the open problem, and thus these details are not addressed or considered.

Mapping of MBS services to G-RNTIs has been identified as an open problem for further 5G MBS development, and this is another problem addressed by the embodiments described herein. However, at present, granularity of such packets has not yet considered that MBS services may have multiple QoS flows, which may have different QoS requirements, receiving UEs may be in different locations and have different capabilities, control traffic is needed to support these MBS services, etc. Grouping based on these other factors needs to be considered.

The embodiments described herein address the signaling design of MBS control information. The UE needs to be configured with MBS control information to know how to receive MBS services of interest to the UE. There is no definition how this MBS control information is sent to the UE, especially for the case where there is a multicast service with HARQ feedback, a service that can be multiplexed on the G-RNTI, a service with QoS flows that can be mapped to different MRBs, etc.

Bearer type selection/(reconfiguration/monitoring/switching) is addressed by the embodiments described herein. The RAN node should be allowed to select the bearer type for the MBMS QoS flow, monitor the MRB and switch bearer types based on multiple triggers if necessary. During bearer type selection, the RAN node is provided with an indication of QoS requirements of the MBS QoS flow and needs to determine how to map this MBS QoS flow to one or more of the MRB types and configure the radio bearer. As part of the monitoring, a number of problems need to be addressed, such as: who makes the decision? What auxiliary information can be used to help make the decision: from UE, from core network, from gNB (e.g., counting procedure). Finally, as part of bearer type switching, the RAN node needs to determine when to trigger the switching and how to handle the bearer changing from PTP to PTM and vice versa. For example, when PTP bearers exist, the UE is configured with SR, BSR, PHR or the like. All these configurations require uplink capabilities, which may not be available for the PTM radio bearer. In addition, it is necessary to determine how to configure the UE with MRB information.

For a single cell multi-unicast region, the gNB may select from a plurality of radio bearer configuration options. How the network makes this choice is not defined and this is addressed by the embodiments described herein. In particular, the network may need assistance information to help make this decision (from UE, CN, RAN). Second, when the radio bearer configuration option for the UE is changed, a UE action ensuring service continuity needs to be defined. Finally, in some cases, it is desirable that the UE may be configured with multiple radio bearer configurations for the same MBS service (old radio bearer configuration to new radio bearer configuration). In this case, the UE needs to trigger to decide when to change from the old radio bearer configuration to the new radio bearer configuration.

For single cell multicast areas, the gNB may dynamically change the path of the MRB split bearer (between PTP and PTM). How the network makes this choice is not defined and this is addressed by the embodiments described herein. In particular, the network may need assistance information to help make this decision (from UE, CN, RAN). Second, path switching may be transparent to the UE. In this case, the UE may be inefficient in handling traffic from the PTP and PTM legs, and rules are required to tell the UE when to monitor the PTP leg or PTM leg.

The multicast session may transition from the ACTIVE state to the INACTIVE state and vice versa. In the INACTIVE state, it is guaranteed that UEs that have joined the multicast session do not receive MBS traffic from this service. No UE actions are defined with respect to transitioning to and from the INACTIVE state. If no special action is taken, this will result in unnecessary power consumption at the UE.

The NR MBS design may differ in many ways in view of the limitations of the existing MBMS designs emphasized herein. A new bearer management procedure may be needed that includes enhancements to the legacy MBMS bearer management procedure, and this is addressed by the embodiments described herein. It is necessary to specify an NR MBS bearer management procedure such as an MBS bearer establishment procedure, an MBS bearer modification procedure, and an MBS bearer release procedure. There is a need to specify UE interest indication for counting procedures, procedures for legacy MBMS like consumption reporting, and use of MBMS on demand operation (MooD) supporting MBS bearer management. For example, in conventional systems, in order to learn from the network side the interest of a UE in a particular service, the UE must indicate this interest via an "MBMS interest indication" Radio Resource Control (RRC) message in several cases, including when a connection is successfully established, when entering or leaving a service area, when a session starts or stops, when the interest changes, when the priority between MBMS reception and unicast reception changes, or when changing to PCell broadcast. For legacy MBSFN, MCE (multi-cell/multicast coordination entity) may use MBMS counting procedure to count the number of rrc_connected mode UEs that receive or are interested in receiving a specified MBMS service via MRB. Similar mechanisms or enhancements to such mechanisms need to be specified for NR in view of NR MBS requirements.

Methods and procedures are described herein that allow 5G MBS operation. The proposed method and procedure try 1) to overcome the limitations already observed in LTE and UTRAN MBMS operation, 2) to address the unique characteristics of 5G NR, and 3) to meet the requirements set forth by the envisaged 5G MBS use case. That is, embodiments described herein relate to:

a flexible and dynamic RAN multicast area concept;

MBS Radio Bearer (MRB) types supporting MBS services;

RAN architecture supporting various MBS radio bearer types, and functionality to split across RAN nodes to support these radio bearers;

design options for MBS configuration;

design options for mapping MBS services to G-RNTIs;

design options of MBS control information;

procedures allowing radio bearer selection, (re) configuration, monitoring and path switching; and

allowing for a process of multi-unicast zone management.

Design options for MBS configurations are described herein. Embodiments are described below:

embodiment 1: a first device may be configured to receive 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 MBS radio bearer may be a non-split bearer configured with RLC-AM or RLC-UM.

Embodiment 3: the first device of embodiment 1, wherein the MBS radio bearer may be a split bearer with two legs, a PTM leg and a PTP leg. Either leg is configured with RLC-AM or RLC-UM.

Embodiment 4: the first device of embodiment 1, wherein the MRB configuration comprises an SDAP configuration, a PDCP configuration, an RLC configuration, a MAC configuration, a logical channel configuration, and a PHY configuration.

Embodiment 5: the first device of embodiment 4, wherein the SDAP layer configuration may have a single SDAP entity and comprises a mapping of MRBs to MBS services.

Embodiment 6: the first device of embodiment 4, wherein the logical channel configuration may include a mapping of logical channels to a specific G-RNTI.

Embodiment 7: the first device of embodiment 4, wherein the MAC configuration may include a DRX configuration and a HARQ configuration of an MBS service, wherein the HARQ configuration includes whether to enable/disable HARQ feedback, whether to allow HARQ retransmission through the C-RNTI.

Embodiment 8: the first device of embodiment 4, wherein the MRB configuration may include a configuration of an associated DRB for an associated PDU session of the MBS service. The associated DRB may be in a suspended state until activated.

Mapping of MBS traffic to G-RNTI is described herein. Embodiments are described below:

embodiment 9: the first device of embodiment 1, wherein the MBS service is received through a shared G-RNTI. The UE is provided with configuration details for G-RNTI: G-RNTI mapped by MBS service; a plurality of MBS services mapped to the G-RNTI; a G-RNTI used in a cell; G-RNTI used in a geographic region/zone; a G-RNTI used in a beamforming region; MBS QoS flows mapped to G-RNTI; a plurality of MBS QoS flows mapped to the G-RNTI; MBS QoS attribute mapped to G-RNTI; logical channel type mapped to G-RNTI; logical channels mapped to the G-RNTI; the UE class mapped to G-RNTI.

Embodiment 10: the first device of embodiment 9, wherein the MBS service is received through a plurality of shared G-RNTIs.

Signaling designs for MBS control information are described herein. Embodiments are described below:

embodiment 11: the first device of embodiment 1, receives MBS control information including MRB configuration and G-RNTI information through one or more MCCH logical channels.

Embodiment 12: the first device of embodiment 11, wherein the MCCH logical channel carries MBS control information per service and wherein the information per service includes an MBS service identifier and a set of one or more MRBs carrying traffic for the service. For each of the MRBs, the MCCH logical channel contains MRB configuration and G-RNTI information.

Embodiment 13: the first device of embodiment 11, wherein the MCCH logical channel carries MBS control information per G-RNTI, and wherein the information per G-RNTI includes a set of MRBs carried on this G-RNTI. For each of the MRBs, the MCCH logical channel contains an MRB configuration and an MBS service identifier.

Embodiment 14: the first device of embodiment 11, wherein the MCCH logical channels are received through dedicated signaling, common signaling using a modification and repetition period.

A procedure for radio bearer (re) configuration by a network is described herein. Embodiments are described below:

embodiment 15: a first device (e.g., a gNB): determining a radio bearer configuration option to provide the MBS service to a second device (e.g., UE) interested in receiving the service, transmitting the first radio bearer configuration to the second device, reconfiguring the radio bearer configuration for the MBS service to the second device, and transmitting the second radio bearer configuration to the second device.

Embodiment 16: the first apparatus of embodiment 15, wherein the determination is based on one or more of: mapping of MBS traffic to radio bearer configuration options, mapping of QoS attributes to radio bearer configuration options, number of UEs interested in traffic, location of UEs interested in receiving traffic, RRC state of UEs interested in receiving traffic, number of HARQ transmission failures to UEs, RLC status report received from UEs, PDCP status report received from UEs, measurement report from UEs, CSI report from UEs, request from UEs.

Embodiment 17: the second device of embodiment 15, which sends a radio bearer configuration request to the first device. The request is based on one or more of: HARQ failure of the monitored transport block, radio conditions to the serving cell, location and range to the serving cell, PDCP status, RLC status.

Embodiment 18: the second device of embodiment 15, wherein the SDAP layer maintains a receive buffer and performs duplicate detection and transmission of status reports for lost SDAP PDUs.

Embodiment 19: the second device of embodiment 15, wherein the second radio bearer configuration comprises a last PDCP SN that the second device should monitor on the first radio bearer configuration.

Embodiment 20: the second device of embodiment 19, using both the first radio bearer configuration and the second radio bearer configuration for a temporary period of time.

Embodiment 21: the second device of embodiment 15, wherein the second radio bearer configuration comprises a mapping between SNs on the first radio bearer configuration and SNs on the second radio bearer configuration.

Embodiment 22: the second device of embodiment 15, the second device using the first radio bearer configuration until one or more of the following events: receiving the second radio bearer configuration, receiving the PDCP SN of the specific value, receiving the SDAP SN of the specific value, expiration of the timer, detecting activity on the second radio bearer configuration.

A process for path switching for MRB is described herein. Embodiments are described below:

embodiment 23: a first device (e.g., a gNB): determining a split bearer radio bearer configuration option for providing an MBS service to a second device (e.g., UE) interested in receiving the service, selecting a first path for transmitting the MBS service to the second device (e.g., UE), transmitting the first radio bearer configuration to the second device, and changing to a second path for transmitting the MBS service to the second device.

Embodiment 24: the first apparatus of embodiment 23, wherein the selection is based on one or more of: mapping of MBS traffic to radio bearer configuration options, mapping of QoS attributes to radio bearer configuration options, number of UEs interested in traffic, location of UEs interested in receiving traffic, RRC state of UEs interested in receiving traffic, number of HARQ transmission failures to UEs, RLC status report received from UEs, PDCP status report received from UEs, measurement report from UEs, CSI report from UEs, request from UEs.

Embodiment 25: the second device of embodiment 23, the second device sending a path switch request to the first device. The request is based on one or more of: HARQ failure of the monitored transport block, radio conditions to the serving cell, location and range to the serving cell, PDCP status, RLC status.

Embodiment 26: the second device of embodiment 23 which determines when to stop processing transport blocks from the first path and to start processing transport blocks from the second path.

Embodiment 27: the second device of embodiment 26, wherein the determination is based on activity. For a PTM to PTP handoff, when the second device detects MBS traffic on the PTP leg, the second device stops processing transport blocks from the PTM path.

Embodiment 28: the second device of embodiment 26, wherein the determination is timer-based. For PTP-to-PTM handoff, the second device begins processing transport blocks from the PTM path after expiration of the inactivity timer.

Embodiment 29: the first device of embodiment 23, further sending a path switch request to the second device.

RAN multicast areas (RXAs) are described herein. One exemplary MBS architecture concept described herein is the concept of a multicast zone. MBS multicast areas denoted here as RAN multicast areas (RXAs) may be introduced at the RAN level. Multicast is used for multicasting or broadcasting. For example, gNB-CU level, CU-RXA may be defined. Similarly, DU-RXA may be defined for RXA regions at the DU level. The single cell broadcast area may also be defined as an SC-RXA multicast zone. Within a DU, DU-RXA is identified only by DU-RXA identification. Similarly, within a CU, CU-RXA is identified only by CU-RXA identification. It should be noted that when no gNB is partitioned into CUs and DUs, the gNB-CU multicast area and the gNB-DU multicast area may be referred to simply as gNB multicast area. The single cell multicast area is identified by an SC-RXA identity, which may be, for example, a cell identity or any other identity configured into the UE by the network for this purpose. The gNB-CU level multicast area may be composed of a collection of gNB-DU level multicast areas. Similarly, the gNB-DU level multicast area may be constituted by a collection of SC-RXA areas. Alternatively, the RAN multicast area may be defined above the level of the CU, e.g. comprising a plurality of gNB CUs (or gnbs). As another alternative, a RAN multicast area may be defined as any general cell packet that may belong to a different gNB-DU, gNB-CU or gNB. In this case, RXA may be composed of a collection of SC-RXA areas. The RAN multicast area may be defined for a single MBS service or a group of MBS services. Packets belonging to the same RXA MBS service may be determined by the RAN node based on MBS traffic patterns, similar scheduling needs, etc. Alternatively, this may be provided by the core network based on e.g. the needs of the content provider.

Fig. 3 illustrates an exemplary RXA 300.RXA may include a CU level multicast zone 301, 2 DU level multicast zones, and one SC multicast zone 303. It should be understood that this is only an example and that any possible grouping of CU-level, DU-level or single cell-level multicast areas is possible. For example, the RAN multicast area may consist of a single CU-level multicast area. Note also that the RAN multicast areas are not necessarily continuous.

RAN delivery methods and MBS bearer types are described herein. The 5G MBS may be provided by one or more of the following RAN delivery methods. The RAN delivery method may be of unicast radio bearer type or MRB type.

Single cell point-to-point (SC-PTP): the MBMS service is provided over PTP bearers on the RAN. There is a single SC-PTP bearer between the RAN node and each of the UEs receiving MBS services. The delivery method may be used when the UE is in the rrc_connected state.

Single cell point-to-multipoint (SC-PTM): the MBMS service is provided over a PTM bearer on the RAN. There is a single shared SC-PTM bearer between the RAN node and each of the UEs receiving MBS services in the cell. The delivery method may be used when the UE is in an rrc_connected state, an rrc_inactive state, or an rrc_idle state.

Multi-cell point-to-multipoint (MC-PTM): the MBMS service is provided over a PTM bearer on the RAN. A UE receiving MBS services may receive MBS services from one or more RAN nodes. The RAN nodes send the same MBS traffic and transmissions from these nodes are synchronized. The delivery method may be used when the UE is in an rrc_connected state, an rrc_inactive state, or an rrc_idle state. There is a single shared MC-PTM bearer between each of the RAN nodes transmitting MBS services and each of the UEs receiving MBS services.

The following multicast bearer model is described herein:

MC-PTM multicast in non-SFN scheme: the same MBS content data packet may be multicast from one or more cells within a multicast area, where transmissions of the same data packet are time synchronized across the transmitting cells, but transmissions from different cells may be on different radio resources including different carrier frequencies and different transmission control parameters (e.g., MCS, TBS).

Corresponding to the non-SFN MC-PTM transmission scheme is a non-SFN MC-PTM bearer type. This bearer type can be modeled as a split bearer with splitting at the SDAP or at the PDCP or at the RLC layer. The bearer is a multi-cell bearer (i.e., an inter-cell leg bearer or a multi-cell leg bearer) in design because the number of legs in this bearer type is proportional to the number of cells within the multi-unicast area providing coverage to the UE. A procedure is needed to limit how many legs a bearer can have. This may be related to UE capability or radio conditions between UE and cell. In one alternative, it is proposed to use the DL-SCH as a transport channel for this bearer type and the PDSCH as a physical downlink shared channel. The corresponding traffic logical channels and signaling control logical channels can be generally denoted as MCMF-MTCH (multi-cell multi-frequency MTCH) and MCMF-MCCH (multi-cell multi-frequency MCCH), respectively. In another alternative, it is proposed to use an MCH as transport channel, which may be mapped to PMCH physical channels.

MC-PTM multicast in SFN scheme: the same MBS content data packet is multicast from one or more cells within a multicast area, where transmissions of the same data packet are time synchronized across the transmission cells and transmissions from different cells use the same radio resources including the same carrier frequency and the same transmission control parameters (e.g., MCS, TBS).

Corresponding to the SFN MC-PTM transmission scheme is the SFN MC-PTM bearer. In this scheme, the bearer may be a bearer based on only one leg (no inter-cell leg) in the sense that the multi-cell transmission is transparent to the UE and the bearer is essentially a single-cell bearer. For this type of bearer there may be more than one intra-cell leg. It is proposed to use the MCH as a transport channel for this bearer type and the PMCH as a physical channel. The corresponding traffic logical channel and signaling control logical channel may be MCSF-MTCH (multi-cell single frequency MTCH) and MCSF-MCCH (multi-cell single frequency MCCH), respectively.

SC-PTM multicast scheme: this is a special case of non-SFN MC-PTM or SFN MC-PTM multicast schemes: MBS content data packets are multicast from one cell. The corresponding SC-PTM bearer is a single cell bearer in design. Of course, for this type of bearer, there may be more than one intra-cell leg, where the leg is used for reliability or to aid mobility. It is proposed to use DL-SCH as a transport channel for this bearer type and PDSCH as a physical downlink shared channel. Corresponding service logic channel and signaling control

Unicast PTP bearers: this is also essentially based on single cell bearers. For this bearer, control information is provided to the UE over DCCH while traffic is carried over DTCH logical channels.

The MBS Radio Bearer (MRB) type may be any of the first three bearer types defined above (i.e., non-SFN MC-PTM, SC-PTM). In addition, hereinafter, the term TrCh (transport channel) may be used with reference to the MCH or DL-SCH unless explicitly stated otherwise. Hereinafter, the terms SC-PTP bearer and unicast PTP bearer are used interchangeably. Hereinafter, the term MC-PTM bearer may be used to refer to both non-SFN MC-PTM and SFN MC-PTM. Dynamic switching between MRB types is described in the "bearer type selection/monitoring/switching" section.

Deployment architecture alternatives are described herein. Many RAN architecture deployments are likely to support 5G MBS. Each of these deployments must support a set of 5G MBS-related logical functions, as follows:

5G MBS entry point: the function must support reception of MBS services from the content provider. This may be a dedicated network function in the core network control plane or alternatively a User Plane Function (UPF).

5G MBS anchor point: the MBS service is distributed to functions of RAN nodes that can transmit the service to the UE. The anchor function may be collocated with the entry point function. It may be located in the UPF, in a dedicated MBS GW function (similar to MBMS GW entity in E-UTRAN and UTRAN), or in the RAN node.

Safety: in order to restrict access to 5G MBS contents, 5G data needs to be encrypted. In addition, the security function should have the capability of regularly changing the encryption key to prevent the UE from continuing to receive MBS contents after leaving the service.

Synchronizing: to support MC-PTM, transmissions across cells must be synchronized.

Scheduling: depending on the MBS radio bearer type, the scheduling functionality on the RAN needs to be centralized (e.g. for MC-PTM radio bearers) or distributed (especially for SC-PTP and SC-PTM radio bearers).

Management of MBS transmission zones: this function allows the network to change MBS transmission regions according to a number of metrics. The granularity of this transmission region may be from cell to DU, to CU (or gNB), to RAN announcement region, to tracking region, or to some other cell packet defined for MBS. The metric may be based on the number of UEs interested in MBS services within the MBS transmission region.

Management of RAN delivery methods: a function that allows the network to select and switch between various RAN delivery methods (SC-PTP, SC-PTM, SNF MC-PTM, and non-SNF MC-PTM).

Management of resource allocation: the RAN is allowed to dynamically change the function of allocating the amount of resources for MBS transmission in the cell. For example, the RAN may allocate from 0% to 100% of the resources to the MBS.

Fig. 4 illustrates an exemplary architecture 400. In this example, 5G MBS anchor 401 is in the core network, e.g., in UPF. The architecture is applicable to all MRB types. For the MC-PTM bearer type, a synchronization function is required to ensure that MBS transmissions from multiple cells are synchronized. For MC-PTM bearer types, a scheduling function is required to schedule simultaneous 5G MBS transmissions across multiple cells. Management of MBS transport zone functions may be located at 5G MBS anchor point 401, 5G MBS entry point 402 in control plane network functions such as access and mobility management functions (AMFs). Alternatively, this functionality may be located in the RAN node (gNB 1, gNB2 … gNBk 403 or multi-cell coordination entity (MCE) 404). The management of the RAN delivery method may be located in the core network 5G MBS anchor 401, 5G MBS entry point 402 or AMF 405. This may be the case for multicast/broadcast services transmitted over the MC-PTM radio bearer. Alternatively, the management of the RAN delivery method may be located in the RAN node (gNB 1, gNB2 … gNBk 403 or MCE 404). As a further alternative, the management of the RAN delivery method functions may be located in both the core network node as well as the RAN node. The management of the resource allocation function may be located in the RAN node (gNB 1, gNB2 … gNBk 403 or MCE 404).

Fig. 5 illustrates another exemplary architecture 500. In this example, the 5G MBS anchor is in gNB-CU 501 (gNB centralized unit) which distributes MBS traffic to gNB-DU 502 (gNB distributed unit). This example also shows 5G MBS entry point 503 and AMF 504. Transmissions from the RAN node may depend on any RAN delivery method. In particular for the MC-PTM radio bearer type, the transmission is synchronized on one or more gNB-DUs 502. Thus, for the MC-PTM bearer type, a synchronization function may be used to ensure that MBS transmissions from multiple cells are synchronized. For the MC-PTM bearer type, a scheduling function is required to schedule simultaneous 5G MBS transmissions across multiple cells. In this example, the gNB-CU 501 may host the following functions: management of MBS transport areas, management of RAN delivery methods, and management of resource allocation. Alternatively, these functions may reside in the core network (e.g., at the AMF or some network function dedicated to the 5G MBS).

Fig. 6 illustrates another exemplary architecture 600. In this example, the 5G MBS anchor is a primary or primary gNB (gNB 1, 601), which gNB1 distributes MBS traffic to other gnbs (or secondary gnbs) in a multi-connection fashion (gNB 2, gNBk 603). This example also shows 5G MBS entry point 604 and AMF 605. The transmission on the RAN node may depend on any RAN delivery method. In particular for MC-PTM radio bearer types, transmissions are synchronized on one or more gnbs. For the MC-PTM bearer type, a synchronization function is required to ensure that MBS transmissions from multiple cells are synchronized. For the MC-PTM bearer type, a scheduling function is required to schedule simultaneous 5G MBS transmissions across multiple cells. In this architecture, the master gNB (gNB 1 601) may host the following functions: management of MBS transport areas, management of RAN delivery methods, and management of resource allocation. Alternatively, some of these functions may be split between the primary gcb 601 and the secondary gcb 602, 603. In another alternative, these functions may reside in the core network (e.g., at the AMF or at some network function dedicated to the 5G MBS).

Note that the 5G MBS architecture may also be a combination of the three exemplary architectures shown in fig. 4-6. For example, the example of FIG. 4 may have gNB deployed in CU/DU fragmentation.

Fig. 7 illustrates an exemplary user plane protocol architecture 700. In the example of fig. 7, the QoS flows are mapped to SC-PTP, SC-PTM, or SFN MC-PTM radio bearers. For SC-PTP, SC-PTM, or SFN MC-PTM radio bearers, there may be a SYNC layer protocol 701 between the 5G MBS entry point 702 and the gNB 703 involved in the transmission of MBS services. This protocol is used for the SFN MC-PTM radio bearer type because it allows for synchronized MBS transmissions from multiple gnbs 703. The gNB 703 may receive multiple MBS QoS flows. At the gNB 703, these MBS QoS flows are mapped to MRB or unicast radio bearers and sent to the UE 704. The protocol stack for the user plane performs the functions described with respect to the L2 data structures described below (e.g., qoS mapping, header compression, scheduling, etc.). For MC-PTM radio bearers, all of the gnbs 703 involved in MBS transmissions may have synchronized radio frame timing such that radio frames are transmitted at the same time and have the same System Frame Number (SFN).

Fig. 8 shows an example of mapping QoS flows to non-SFN MC-PTM radio bearers 800. For non-SFN MC-PTM radio bearers, there may be a SYNC layer protocol 801 between the 5G MBS entry point 802 and the gNB 803 involved in the transmission of MBS services. This protocol allows for synchronized MBS transmissions from multiple gnbs 803. The UE 804 has multiple receive paths or legs—one for each cell that participates in a multi-cell transmission. In addition, there is a protocol layer (MC layer 805) between the MBS GW and the UE 804 to manage potential duplication of MBS packets across these different RAN receive legs. The protocol stack for the user plane performs the functions described with respect to the L2 data structures described below (e.g., qoS mapping, header compression, scheduling, etc.).

Hereinafter, the term "synchronized MBS transmission" may be used to refer to transmissions from multiple sources, which may be time synchronized, frequency synchronized, or both. Time synchronization may refer to transmissions arriving during the same subframe, slot, or minislot. Frequency synchronization may refer to transmissions arriving on the same bandwidth portion or frequency resource. The granularity of time and frequency synchronization depends on the type of MC-PTM bearers and the configuration of these bearers.

Fig. 9 illustrates another exemplary user plane protocol architecture 900. In the example of fig. 9, qoS flows are mapped to SC-PTP bearers. For SC-PTP, if the destination of MBS QoS flows to the UE 905 spans multiple gNBs, then there may be a SYNC protocol 901 layer between the 5G MBS entry point 902 and the gNB-CU 903. In addition, the layer 2 protocol stack is split between the gNB-CU 903 and the multiple gNB-DUs. The partitioning shown in FIG. 9 has SDAP and PDCP layers in the gNB-CU 903 and lower layers in the gNB-DU 904. The functionality of these layers is described with respect to the L2 data structures described below (e.g., qoS mapping, header compression, scheduling, etc.). It should be noted that the segmentation under the PDCP layer is only one option. Segmentation may be performed under the SDAP, under the RLC, or over the SDAP.

Fig. 10 illustrates another exemplary user plane protocol architecture 1000. In the example of fig. 10, the QoS flows are mapped to SC-PTM bearers or SFN MC-PTM bearers. For SC-PTM or SFN MC-PTM bearers, there may be two separate SYNC layers. This is shown as SYNC1 1001 between 5G entry point 1003 and gNB-CU 1004, and SYNC2 1002 between gNB-CU 1004 and gNB-DU 1005 involved in 5G MBS transmission to UE 1006. These SYNC protocols ensure that MBS traffic sent by the gNB-DUs 1005 between the gNB-DUs (and across the gNB-CUs 1004) is synchronized. For SFN MC-PTM radio bearers, the gNB DUs 1005 involved in MBS transmissions may be time and frequency synchronized such that radio frames are transmitted at the same time, with the same system frame number, and over the same frequency resources.

Fig. 11 illustrates another exemplary user plane protocol architecture 1100. In the example of fig. 11, qoS flows are mapped to non-SFN MC-PTM bearers. The 5G anchor function resides in gNB-CU 1102. For non-SFN MC-PTM bearers, there may be two separate SYNC layers (shown as SYNC1 1101 between the 5G entry point 1103 and the gNB-CU 1104, and as SYNC2 1102 between the gNB-CU 1104 and the gNB-DUs 1105, 1106 involved in the 5G MBS transmission). These SYNC protocols ensure that MBS traffic sent by the gNB-DUs 1105, 1106 between the gNB-DUs (and across the gNB-CUs 1104) is synchronized. The gNB DUs 1105, 1106 involved in MBS transmissions may be time synchronized. The gNB DU may also be frequency synchronized if desired. UE1107 has split radio bearers across multiple legs. Here, segmentation is shown below the PDCP layer. Thus, the PDCP layer in gNB-CU 1104 is responsible for MBS packet duplication, while the PDCP layer in UE1107 is responsible for detecting duplicate MBS packets and discarding. UE1107 may use multiple legs to increase reliability of MBS transmission or increase capacity of MBS service. Note that the location of segmentation may also be selected above the SDAP layer, below the SDAP layer, or below the RLC layer.

Fig. 12 illustrates another exemplary user plane protocol architecture 1200. In the example of fig. 12, the QoS flows are mapped to SFN MC-PTM bearers. For an SFN MC-PTM bearer, there may be two separate SYNC layers (shown as SYNC1 1201 between the 5G entry point 1203 and the primary gNB (gNB 1 1204) and SYNC2 1202 between the primary gNB 1204 and the secondary gNB 1205 involved in the 5G MBS transmission, these SYNC protocols ensure that MBS traffic sent by gNBs between the gNBs to the UE 1206 is time synchronized and frequency synchronized.

Fig. 13 illustrates another exemplary user plane protocol architecture 1300. In the example of fig. 13, the QoS flows are mapped to non-SFN MC-PTM bearers. The 5G anchor function resides in the gNB1 1304 (primary gNB). For non-SFN MC-PTM bearers, there may be two separate SYNC layers (shown as SYNC1 1301 between the 5G entry point 1303 and the primary gcb (gNB 1 1304), and SYNC21302 between the primary gcb 1304 and the secondary gcb 1305 involved in the 5G MBS transmission these SYNC protocols ensure that MBS traffic sent by the gcb between the gcbs is time synchronized.

Fig. 14 illustrates another exemplary control plane protocol architecture 1400. In the example of fig. 14, MCE 1401 may be used for MC-PTM radio bearers. The multi-cell layer (MC layer) may be responsible for scheduling across different gnbs 1402, 1403, 1404. Control plane traffic may be sent simultaneously across the gnbs 1402, 1403, 1404 according to a schedule provided by the MC layer.

Fig. 15 illustrates another exemplary control plane protocol architecture 1500. In the example of fig. 15, control plane traffic to UE 1503 is generated by the gNB-CU 1501 and sent to the gNB-DU1502. For MC-PTM radio bearers, the gNB-CU 1501 may have a multi-cell layer (MC layer 1504) responsible for scheduling across different gNB-DUs 1502. In addition, control plane traffic passes through SYNC protocol 1505.

Fig. 16 illustrates another exemplary control plane protocol architecture 1600. In the example of fig. 16, control plane traffic to UE 1603 is generated by the gNB-CU 1601 and sent to the gNB-DUs 1602, 1603. For MC-PTM radio bearers, the gNB-CU 1601 may have a multi-cell layer (MC layer 1604) responsible for scheduling across different gNB-DUs 1602, 1603. In addition, control plane traffic passes through SYNC protocol 1605.

Fig. 17 illustrates another exemplary control plane protocol architecture 1700. In the example of fig. 17, control plane traffic to the UE 1703 is generated by the gNB-CU 1701 and sent to the gNB- DUs 1702, 1703. For MC-PTM radio bearers, the gNB-CU 1701 may have a multi-cell layer (MC layer 1704) responsible for scheduling across different gNB- DUs 1702, 1703. In addition, control plane traffic passes through SYNC protocol 1705.

Fig. 18 illustrates another exemplary control plane protocol architecture 1800. In the example of fig. 18, control plane traffic to the UE 1803 is generated by the primary gcb 1801 and sent to the secondary gcb 1802. For MC-PTM radio bearers, the primary gcb 1801 may have a multi-cell layer (MC layer 1804) responsible for scheduling across different secondary gcbs 1802. In addition, control plane traffic passes through SYNC protocol 1805.

Fig. 19 illustrates another exemplary control plane protocol architecture 1900. In the example of fig. 19, control plane traffic to the UE 1903 is generated by the primary gcb 1901 and sent to the secondary gcb 1902. For MC-PTM radio bearers, the primary gNB 1901 may have a multi-cell layer (MC layer 1904) responsible for scheduling across the different secondary gnbs 1902. In addition, control plane traffic passes through SYNC protocol 1905.

Fig. 20 illustrates an exemplary L2 data structure 2000. Traffic from the multicast/broadcast service arrives at the RAN node through one or more 5G MBS QoS flows. The L2 data structure handles these QoS flows 2001 so that MBS traffic for these flows can be transported over the air interface. Note that fig. 20 does not show MC-PTM radio bearers split across RAN nodes for ease of presentation. However, it should be appreciated that the MC-PTM bearer is transmitted over multiple cells. In the SFN case, RLC, MAC and PHY functions/configurations may be the same across all cells. In the non-SFN case, RLC, MAC and PHY functions/configurations need not be the same across all cells. Processing tasks are required at the various layers as described below.

PDCP 2002: the main MBS-related services and functions of the PDCP layer may include:

header compression: for a particular MBS service, the header may need to be compressed:

Safety: including encryption and integrity protection. This functionality may be shared with higher layer nodes, such as nodes hosting 5G entry point functionality. In some cases, the PDCP layer is a transparent (or transparent) layer that does not process any header or add any header to the incoming PDCP SDU;

packet duplication and packet discard;

routing;

RLC 2003: the main MBS-related services and functions of the RLC layer may include:

error correction by ARQ (AM only);

segmentation (AM and UM) and re-segmentation (AM only) of RLC SDUs;

reassembly of SDUs (AM and UM);

repeated detection (AM only);

MAC 2004: the MBS-related services and functions of the MAC layer may include:

mapping between MBS logical channels and transmission channels;

multiplexing/de-multiplexing MAC SDUs belonging to one or different MBS logical channels into/from a Transport Block (TB). The MBS logical channels may be destined for different multicast group members. For example: multiplexing only logical channels having the same multicast group member; multiplexing logical channel a with logical channel B if the multicast group members of logical channel a are a subset of the group members of logical channel B; logical channels with different group members are multiplexed. The final set is a union of all members from all multiplexed logical channels. Upon reception, upon demultiplexing, the UE needs to determine whether the logical channel is of interest;

Error correction by HARQ;

priority handling between multicast/broadcast services and unicast services by means of dynamic scheduling;

priority handling between MBS logical channels by means of logical channel prioritization; and

priority handling between overlapping resources of one UE.

In addition to the above, the following functions may be required in the L2 data structure/protocol stack. This functionality may be located at various layers of the stack:

selection of RAN delivery method type for 5G MBS QoS flows: the 5G QoS flows may be mapped to one or more unicast radio bearers and/or MRBs. The selection may be made at the SDAP layer or at a lower layer (PDCP, or RLC or MAC). Alternatively, the selection may be made at the RRC layer. The selection may be made at the beginning of the 5G QoS flow. Additionally, the MRB type may be reselected depending on the base conditions and/or metrics. Many metrics may be used for selection (as described in the "bearer type selection/monitoring/handover" section).

Mapping of 5G MBS QoS flows to selected bearer types: once the MRB type selection is made, the 5G QoS flows need to be mapped to the selected MRB. Mapping may be performed at the SDAP layer 2005 or at a lower layer (PDCP 2002, RLC 2003, or MAC 2004).

L2 Forward Error Correction (FEC): in order to improve the reliability of 5G MBS transmissions, an FEC scheme may be used between the UE and the peer RAN node entity. This FEC may be applied to a specific MBS logical channel. This layer may be located above the MAC layer (operating at granularity of MBS logical channels). Alternatively, this FEC layer may be part of the MAC layer (operating at the granularity of transport blocks). In the MAC layer, existing techniques such as repetition may be used.

Mapping between MCCH message and MRB: this involves determining the MRB that maps the MCCH message. For example, a UE may have multiple active MCCH logical channels, each MCCH logical channel controlling one or more MBS services. These services may be on different MRBs. The MCCH message for a particular service needs to be mapped to the MAC of the associated service.

MBS cell/BWP operation may be on the following:

MBS private cells: these are cells dedicated to MBS transmissions; and

MBS/unicast hybrid cell: cells performing both MBS and unicast transmissions.

For MBS/unicast hybrid cells:

the MC-MTCH and MC-MCCH are mapped to MCH or DL-SCH for MC-PTM transmission;

the SC-MTCH and the SC-MCCH are mapped to the DL-SCH for the SC-PTM transmission; and is also provided with

The transmissions of both unicast and MBMS in a cell are done in a coordinated manner.

In the case of a hybrid cell, the transmission of the MBS service may be in a dedicated bandwidth part (BWP) reserved for the MBS. Unicast and MBS transmissions may then be in different BWPs. For example, this BWP may have a longer cyclic prefix, making the BWP more suitable for MC-PTM operation.

Fig. 21 illustrates an exemplary radio bearer 2100 for an MBS service. An MBS session may have multiple QoS flows 2101, 2102, 2103, 2104. Each of these flows has its own QoS requirements including, but not limited to: a priority; delay in terms of Packet Delay Budget (PDB), and reliability in terms of Packet Error Rate (PER). Based on the QoS requirements of the flow and the UE interested in receiving the service, the network determines how to transmit the service using one or more of the following radio bearer configuration options:

a Data Radio Bearer (DRB) using RLC-AM 2105;

DRB using RLC-UM 2106;

one or more MRBs having split radio bearers including but not limited to:

a PTM leg using RLC-AM 2111 and a PTP leg using RLC-AM 2112;

a PTM leg using RLC-AM 2113 and a PTP leg using RLC-UM 2114;

A PTM leg using RLC-UM 2115 and a PTP leg using RLC-AM 2116;

a PTM leg using RLC-UM 2117 and a PTP leg using RLC-UM 2118;

MRB with a single PTM leg using RLC-AM 2119;

MRB with a single PTM leg using RLC-UM 2120.

In addition to the above, other alternatives are possible for the MRB split bearer. For example, two branches of a split bearer may also be anchored in the RLC or at the MAC. In the RLC anchored case, the two branches share a common RLC entity, but may have different MAC entities. In the case of MAC anchoring, the two legs share a common RLC entity as well as a common MAC entity, however, segmentation of MBS traffic on the two legs is handled within the MAC layer.

The UE configuration for receiving MBS service depends on how MBS service is mapped to G-RNTI and how MRB is configured. The configuration for the UE may include:

SDAP configuration 2107 may include a mapping of MBS service QoS flows to MRB mappings. When traffic for the MRB is received, the SDAP configuration allows the UE to know which service the received data belongs to and which QoS flow within that service. If the UE has a single SDAP entity for MBS services, the data is forwarded to this SDAP entity. Alternatively, if the UE has a single SDAP entity per MBS service/session, the SDAP configuration informs the UE of the correct SDAP entity to which the received data should be forwarded.

The PDCP configuration 2108 may include details of split bearer operations.

RLC configuration 2109 for each MRB may include the logical channel identity of the MRB.

Logical channel configuration 2110, which may include a mapping of logical channels to specific G-RNTIs.

MAC configuration 2121, which may include DRX configuration related to MBS services transmitted through this G-RNTI. Alternatively, the MAC configuration may also include HARQ-related configurations related to MBS services transmitted through this G-RNTI. For example, this configuration may specify that traffic received through this G-RNTI has HARQ feedback enabled or disabled, a maximum number of HARQ retransmissions for a transport block, or a fixed number of HARQ retransmissions is used. The MAC configuration may also include an indication of whether transport block retransmissions are allowed over the C-RNTI. This configuration may also include a C-RNTI.

PHY configuration, which may include details regarding PDSCH channels transmitting MBS traffic, G-RNTI and/or C-RNTI, PUCCH configuration for any HARQ feedback, etc.

For multicast sessions, in addition to the above configuration, the UE may be configured with an associated DRB for an associated PDU session for MBS services. The associated PDU session may support mobility to the gNB without 5G MBS support. However, the SA2 working group has agreed that when a UE joins an MBS session, the associated PDU session may be updated with the associated QoS flow. Thus, the network can configure or reconfigure the associated DRBs for this associated PDU session. This associated DRB may be in a suspended state until activated by the gNB. Alternatively, this associated DRB may be one of the DRBs (default or dedicated) that have been established for the UE.

The G-RNTI is a group-based radio network temporary identifier for transmitting PTM MBS services to a group of UEs. The G-RNTI is a shared RNTI because many UEs may receive using the same RNTI. The MBS service may be one or more G-RNTIs as described herein.

Fig. 22 shows a system architecture 2200 from the perspective of G-RNTIs at the gNB and at the UE. The gNB may have as input one or more multicast sessions 2201, 2202, 2203; one or more broadcast sessions as input 2204; and for each multicast session, one or more associated PDU sessions 2205. One or more MBS QoS flows exist in each of multicast session 2201 and broadcast session 2202. Each of these MBS QoS flows is associated with QoS attributes regarding delay, reliability, etc.

The UE may be interested in one or more MBS services 2201, 2202, 2203. Such services are transmitted from the gNB over one or more MBS radio bearers (MRB 1, MRB2 …). To receive MBS services 2201, 2202, 2203, the ue should receive all MRBs associated with the service. In the case that some MRBs may carry the same QoS flows, the UE 2206, 2207 need only receive a single one of the flows. However, if the service has multiple QoS flows and the QoS flows are mapped to different MBs, the UE may receive each of the MRBs to recover the different QoS flows.

The UEs 2206, 2207 receive MBS traffic for multicast sessions 2201, 2202, 2203 and/or broadcast session 2204. The UEs 2206, 2207 may receive the service through the PTP leg or the PTM leg. Each of the PTM legs may be associated with a G- RNTI 2208, 2209, 2210, 2211. There are many different alternatives for mapping MBS services on MBS QoS flows to PTM legs. The mapping may be based on service type, qoS of the service, UE location, UE type, traffic type, etc.

Fig. 23A shows an exemplary mapping 2300 that may be per MBS service. In this example, each MBS service may be mapped to one PTM leg using a single G-RNTI 2301.

Fig. 23B shows an example in which each MBS service may be mapped to more than one PTM leg, each PTM leg using its own G- RNTI 2310, 2311.

Fig. 23C shows an example in which each MBS service may be mapped to one PTM leg and may be transmitted through a plurality of G- RNTIs 2312, 2313. The alternative shown in fig. 23C may be used for a gNB that wants to divide the UEs into subgroups (e.g., to manage HARQ feedback), but does not require separate radio bearers for each of these groups. In this case, the UE will have only one HARQ entity. This can also be applied to the case where the G-RNTI1 2312 and the G-RNTI2 2313 are on different carriers. In this case, the UE may have a plurality of HARQ entities. MBS services may be identified by a TMGI or source IP multicast address.

In another example, the mapping may be performed in multiple MBS services. A single G-RNTI may be used to map a set of MBS services to one PTM leg. Alternatively, a set of MBS services may be mapped to more than one PTM leg, each PTM leg using its own G-RNTI. Alternatively, a set of MBS services may be mapped to one PTM leg and may be transmitted over multiple G-RNTIs.

In yet another example, the mapping may be per cell. The cell may have one or more G-RNTIs for the PTM leg. All MBS services in a cell may use the same G-RNTI.

In yet another example, the mapping may be by geographic region. A cell may be divided into one or more geographical areas. These areas may be based on distance/range to the gNB. For example, for a UE in the range of K1 meters, the PTM leg may use G-RNTI1; for UEs in the range between K1 and K2 meters, the PTM leg may use G-RNTI2; and for UEs in the range exceeding K2 meters, the PTM leg may use G-RNTI3. Alternatively, in each of the geographical areas, the MBS service may use multiple PTM legs, each PTM leg using its own G-RNTI.

In yet another example, the mapping is per MBS QoS flows. The MBS QoS flow may be mapped to one PTM leg using a single G-RNTI. Alternatively, each MBS QoS flow may be mapped to more than one PTM leg, each PTM leg using its own G-RNTI. Alternatively, each MBS QoS flow may be mapped to one PTM leg and may be transmitted over multiple G-RNTIs.

In yet another example, the mapping may be per multiple MBS QoS flows. A single G-RNTI may be used to map a set of MBS QoS flows to one PTM leg. Alternatively, a set of MBS QoS flows may be mapped to more than one PTM leg, each PTM leg using its own G-RNTI. Alternatively, a set of MBS QoS flows may be mapped to one PTM leg and may be transmitted over multiple G-RNTIs.

In yet another example, the mapping may be per QoS attributes of MBS traffic. The MBS QoS attributes may be mapped to one PTM leg using a single G-RNTI. For example, the attribute may relate to reliability or delay of MBS service. The attribute may be based on 5QI. Alternatively, a set of MBS QoS attributes may be mapped to a single G-RNTI. Alternatively, a set of MBS QoS attributes may be mapped to more than one PTM leg, each PTM leg using its own G-RNTI.

In yet another example, the mapping is by logical channel type. For example, a logical channel carrying control plane information may be mapped to a first G-RNTI, and a logical channel carrying user plane information may be mapped to a second G-RNTI. Alternatively, logical channels carrying control plane information may be mapped to the first group G-RNTI, and logical channels carrying user plane information may be mapped to the second group G-RNTI.

In yet another example, the mapping is performed on a logical channel basis. The gNB and the UE may be configured with a mapping of logical channels to G-RNTI. One or more logical channels may be configured to map to a G-RNTI. Alternatively, the logical channel may be mapped to a plurality of G-RNTIs.

In yet another example, the mapping is supported by UE category or UE type or UE feature. The gNB and UE may be configured with a mapping of UE class/type/feature to G-RNTI. For example, all UEs supporting HARQ feedback for MBS may be mapped to the first G-RNTI. As another example, all UEs of the type MTC may be mapped to the second G-RNTI. Alternatively, the UE category/type/feature may be mapped to multiple G-RNTIs.

In yet another example, the mapping may be based on some (pre) configured identities. For example, all devices of the local utility company may be (pre) configured with an identity from which the UE and the gNB may determine the public G-RNTI. All MBS services sharing a (pre) configured identity may use the same G-RNTI.

In yet another example, the mapping may be random: the cell may have one or more G-RNTIs for the PTM leg. The MBS service or MBS QoS flow or logical channel may be randomly selected among G-RNTIs available in the cell.

In yet another example, the mapping may be per beam or per beam forming region (beam specific geographic region): the gNB may transmit MBS traffic through multiple beamforming areas. For example, one beam forming area (beam 1) PTM leg may use G-RNTI1, another beam forming area (beam 2), PTM leg may use G-RNTI2, and so on. The UE received from beam1 may use G-RNTI1 to receive the PTM leg. Alternatively, in each of the beamforming regions, the MBS service may use multiple PTM legs, each leg using its own G-RNTI.

Solution to problem 4: signaling design of MBS control information

In LTE, a cell has a single eMBMS control channel (SC-MCCH) for MBMS services. The channel is transmitted using a modification period and a repetition of the modification period. The control channel carries control, scheduling and configuration information for all MBMS services carried in the cell.

For NR MBS, MBS services are expected to be very different (with different QoS requirements) and also mapping of services to radio bearers is expected to be very flexible.

The UE needs to obtain configuration information for receiving MBS services of interest. Each of the MBS services may have an associated MBS configuration.

Fig. 24 illustrates an example 2400 of mapping MBS control information to an MCCH. Each MCCH2401, 2402 may have MBS control information per service. The MCCHs 2401, 2402 may have a list of MBS services 2410, 2411. For each of the MBS services, the MCCH includes an identifier for the services 2412, 2413, 2424, 2425, 2426, 2427. PDCP configuration, RLC configuration, MBS logical channel configuration, MAC configuration (including DRX configuration) and PHY configuration may also be included. Since MBS services may be carried over multiple MBS radios and transmitted over multiple G-RNTIs, MRB configurations 2414, 2415, 2416, 2417, 2420, 2421, 2422, 2423 and G-RNTI and/or C- RNTI configurations 2418, 2419, 2420, 2421, 2422, 2423 may be included.

Each MCCH may have MBS control information per G-RNTI. The MCCH may have a list of G-RNTIs for carrying a set of MBS services. For each of the G-RNTIs, the MCCH includes an identifier of the service, PDCP configuration, RLC configuration, MBS logical channel configuration, MAC configuration (including DRX configuration), and PHY configuration. Since the G-RNTI may carry multiple MBS radio bearers, each for a different MBS service, a configuration for each of these MBS radio bearers may be included.

Various options for receiving MBS configurations are possible. These options may be used alone or in some combination.

In one example, a UE in RRC connection receives MBS control information through DCCH logical channel through dedicated signaling. The network may be aware of the services that the UE has joined and is interested in. The gNB may signal MBS control information for a service of interest to the UE using an existing RRC message (e.g., RRC reconfiguration request) or using a new RRC message (e.g., RRC MBS reconfiguration request). These messages may contain RRC configurations for MBS services of interest to the UE. If the UE is in RRC idle or RRC inactive mode, the UE may be paged to transfer MBS configuration. After receiving the configuration, the UE may remain in the RRC connected mode if at least one of the MBS services of interest is active. Alternatively, the UE may remain in RRC connected mode even if no MBS service of interest is active. Alternatively, if no MBS service of interest is active, the UE may transition back to RRC idle or RRC inactive but maintain MBS configuration. That is, the UE may not clear the received MBS configuration.

In another example, the network may transmit MBS configurations of MBS services over a single MCCH logical channel. A single MCCH carries MBS configurations for all MBS services in a cell. The MCCH logical channels may be multiplexed with MBS services.

In another example, the network may transmit MBS configurations of MBS services over a single MCCH logical channel. A single MCCH carries MBS configurations for all MBS services in a cell. The MCCH logical channel may be repeatedly transmitted using a modification period. In this case, the UE needs to know how to receive this MCCH, including the scheduling of the MCCH and the logical channel configuration for this MCCH. This information may be included in the system information broadcast in the cell. Alternatively, dedicated signaling may be used to provide this information to UEs that have joined the service.

In another example, the network may transmit MBS configurations of MBS services over more than one MCCH logical channel (MCCH 1, MCCH2 … MCCHk). Each of these logical channels carries an MBS configuration for a set of MBS services in a cell or for a set of G-RNTIs in a cell. The MCCH logical channel may be repeatedly transmitted using a modification period. In this case, the UE needs to know how to receive this MCCH, including the scheduling of the MCCH and the logical channel configuration for this MCCH. This information may be included in the system information broadcast in the cell. Alternatively, dedicated signaling may be used to provide this information to UEs that have joined the service.

Fig. 25 illustrates an example procedure 2500 for radio bearer maintenance. Radio bearer maintenance may include bearer type selection/(re) configuration, monitoring or handover. At step 2510, the radio bearer types that may be required for MBS QoS flows and the configuration of those flows at the UE are determined. For example, an initial mapping of MBS QoS flows may be performed. UE assistance may be provided to assist the RAN node in making this determination. Core network assistance may also be provided to assist the RAN node in making this determination. At step 2511, the affected UEs may be configured or reconfigured. After a period of time (step 2512), the RAN node may monitor the status of the radio bearer (step 2513). At step 2514, the RAN node may decide to change/modify the RAN delivery method. Again, this decision may be made with the help of UE assistance information and/or core network assistance information.

The 5G MBS QoS flows arriving at the RAN node are transmitted over the multicast area using one or more radio bearers. Some of these radio bearers may be unicast radio bearers and others may be multicast/broadcast radio bearers. In addition, for each cell that is part of the multicast area, MBS traffic from this 5G QoS flow may be carried over one or more radio bearers. Thus, for example, a cell may carry MBS traffic over an SC-PTP bearer for one UE and over an SC-PTM bearer for a second UE.

Fig. 26 shows an example 2600 of MBS QoS flows mapped to multiple SC-PTP bearers of a cell across a RAN multicast area. The RAN multicast areas may include Cell12601, cell22602, cell3 2604, and Cell4 2605. This MBS QoS flow 2610 may also be mapped to SC-PTM bearers 2611 in Cell12601 and SFN MC- PTM bearers 2612, 2613, 2614 in Cell22602, cell3 2604 and Cell4 2605 d.

UE assistance information is described herein. The following assistance information may be provided by the UE to help the RAN node determine the RAN delivery method:

UE measurement. This may include RSRP, RSRQ or SINR measurements. These measurements may be based on synchronization signals carried in the cell or CSI reference signals carried in the cell. The RAN node may use the measurement results to determine the quality of the signal received from the cell. For example, for a UE in poor signal conditions, the RAN node may decide that it would be better to use the SC-PTP bearer for this UE. The UE may be configured to periodically transmit measurement reports upon entering a cell supporting MBS services of interest, upon entering a cell supporting MBS services, upon starting to interest MBS services, upon a measured change in quantity exceeding a configured threshold, etc.

UE counting result: this may include a list of MBS services that the UE is interested in receiving or is receiving. The RAN node may send an RRC message to signal the need for the counting result. This message may contain a list of services that request count information. The message may further contain an indication of whether the counting response is for all UEs or for UEs in a particular state. The message may contain an indication of whether a one-time response is desired or a periodic response is desired. The message may contain an indication of the persistence of the request. For example, the UE may be required to provide a response in the next K subframes. The RAN node may use the number of UEs interested in the MBS service to determine the RAN delivery method for the service.

UE location information: the UE may provide an indication of the location of the UE to the RAN node. The RAN node may use the geographic location of the UE to determine a RAN delivery method that provides MBS services to the UE. In one example, the RAN node may not be able to provide MBS services to UEs in the multicast area. In this case, the RAN node may provide services to the UE over the SC-PTP bearer.

UE capability: the UE may provide MBS capabilities of the UE to the RAN node. For example, support a specific MRB type: non-SFN MC-PTM, SC-PTM. This may also include information about whether the UE is able to determine its location information (e.g., whether the UE is GPS-capable).

UE power state: the UE may provide an indication of its current power state. For example, the UE may indicate whether it is associated with a power source or a battery. If the latter, the UE may indicate its current power state. This power state may be a percentage or general indication such as low/medium/high. The RAN node may use this information, as well as some other UE context information, to help decide the RAN delivery method to use for this UE.

UE mobility state: the UE may provide an indication of its mobility state: stationary, low mobility, high mobility. The RAN node may use this information to select a RAN delivery method that will be more suitable for the mobility state. For example, if the UE needs MBS services with strict service continuity, the RAN node may support SC-PTP bearer types.

UE context information is described herein. The RAN node may have a UE context that may help the RAN node determine the RAN delivery method. For example, this information may include:

UE serving cell: the RAN node may use the current serving cell to select an appropriate RAN delivery method. For example, the UE may be in a cell that has been served by the MC-PTM bearer, and the RAN node may select this bearer.

DRX state: the RAN node may be aware of the DRX state and cycle of all UEs interested in a particular MBS service. Thus, for example, the RAN node will know whether the UE has an enabled DRX cycle, whether the UE is in eDRX, or whether the UE is in PSM. Based on this information, the RAN node may select an appropriate RAN delivery method. For example, the RAN node may select an SC-PTP bearer type for the UE to allow the UE to utilize its configured power saving mechanism. The RAN node may also use UE power state assistance information to help make this decision.

RRC state: the RAN node may be aware of the RRC states of all UEs interested in a particular MBS service. Thus, for example, the RAN node will know whether the UE is in RRC IDLE, rrc_inactive or rrc_connected state. Based on this information, the RAN node may select an appropriate RAN delivery method.

UE capability: the RAN node may obtain some UE capability information from the core network. This may include, for example, supporting a particular MRB type: non-SFN MC-PTM, SC-PTM. This may also include information about whether the UE is able to determine its location information (e.g., whether the UE is GPS-capable).

UE mobility state: the RAN node may know whether the UE is stationary, moving slowly or moving fast. The RAN node may use this information to help select a RAN delivery method.

Triggers for changing RAN delivery modes are described herein. Multiple triggers may occur at the RAN node to initiate the RAN delivery mode change. The trigger may be implicit. For example, when a RAN node initially receives an MBMS QoS flow, the RAN node may not know the number of UEs interested in this MBS service. Thus, the RAN node may initially map the MBMS QoS flow to the SC-PTM radio bearer. Similarly, the UE may implicitly decide to change the RAN delivery method. For example, the UE may want to save power and the UE may want to use the MC-PTM radio bearer without feedback.

The trigger may be based on one or more of the monitored metrics. A number of metrics may be used for RAN delivery method selection. In one alternative, the RAN node uses the count results to select between RAN delivery methods. If the number of UEs interested in the service is above the threshold, the RAN node may decide to use the SC-PTM bearer. If these UEs are spread over multiple cells, the RAN node may decide to use a non-SFN MC-PTM bearer or an SFN MC-PTM bearer. In a second alternative, the RAN node may use the measurements from the UE to select the RAN delivery method. If the UE is in poor coverage, the RAN node may support SC-PTP radio bearers. In a third alternative, the RAN node may rely on HARQ feedback statistics to select the RAN delivery method. For example, the RAN node may monitor NACK feedback from the UE, and based on this monitored feedback, the RAN node may decide to use the SC-PTP bearer for the UE. The RAN node may monitor the number of NACKs in the time window, the number of consecutive NACKs, etc.

The trigger may be based on conditions or characteristics of the MBS QoS flow. In one alternative, the RAN node may rely on the QoS requirements of the MBS QoS flows to determine the MRB bearer type. For example, MBS services may require strict service continuity, thereby facilitating SC-PTP bearer types. In another alternative, the RAN node may rely on the RRC state of the UE to select the RAN delivery method. For example, a UE interested in MBS services may be in RRC-IDLE or RRC-INACTIVE, thereby facilitating MC-PTM bearer types. In another alternative, the RAN node relies on the need for feedback to select a RAN delivery method that supports feedback. In another alternative, the RAN node selects between SC-PTP bearer and PTM bearer types depending on the need for transmission of the application layer FEC stream. In another alternative, the RAN node relies on the need for L2 FEC to select a RAN delivery method that supports L2 feedback.

The trigger may be based on a specific request from the UE. For example, the UE may request that the RAN node select a certain RAN delivery method. Alternatively, the trigger may be based on a request from the core network. For example, the AMF may request that certain QoS flows be mapped to certain RAN delivery methods.

(re) configuration of MBS radio bearers is described herein. When the RAN node decides to transmit one or more radio bearers of the 5G MBS QoS flow, the RAN node may configure this/these radio bearers in the UE.

The SC-PTP radio bearer may have a configuration for PDCP, RLC, MAC and PHY layers. This configuration may include an indication of which other bearers are configured in the cell for the same 5G MBS QoS flow. For example, the radio bearer may have a radio bearer ID and an MBS QoS flow ID. The MBS QoS flow ID may be shared by all radio bearers transmitting the same MBS QoS flow. Alternatively, the radio bearer may have a list of radio bearer IDs and alternative radio bearer IDs. These alternative radio bearer IDs identify other radio bearers that may be used to transport the 5G MBS QoS flows. The configuration may be sent to the UE through dedicated signaling.

The SC-PTM radio bearer may have a configuration for PDCP, RLC, MAC and PHY layers. This configuration may include an indication of which other bearers are configured in the cell for the same 5G MBS QoS flow. For example, the radio bearer may have a radio bearer ID and an MBS QoS flow ID. The MBS QoS flow ID may be shared by all radio bearers transmitting the same MBS QoS flow. Alternatively, the radio bearer may have a list of radio bearer IDs and alternative radio bearer IDs. These alternative radio bearer IDs identify other radio bearers that may be used to transport the 5G MBS QoS flows. The configuration may be sent to the UE through dedicated signaling. Alternatively, the configuration may be transmitted through system information. Alternatively, the configuration may be sent partly by dedicated signaling and partly by system information.

The SFN MC-PTM radio bearer may have a configuration for a single leg. The configuration may include PDCP, RLC, MAC and PHY layer configurations. This configuration may include an indication of which other bearers are configured in the cell for the same 5G MBS QoS flow. For example, the radio bearer may have a radio bearer ID and an MBS QoS flow ID. The MBS QoS flow ID may be shared by all radio bearers transmitting the same MBS QoS flow. Alternatively, the radio bearer may have a list of radio bearer IDs and alternative radio bearer IDs. These alternative radio bearer IDs identify other radio bearers that may be used to transport the 5G MBS QoS flows. The configuration may be transmitted to the UE through system information.

The non-SFN MC-PTM radio bearer may have a configuration for multiple legs. The configuration may include configurations for a plurality of PDCP, RLC, MAC and PHY layers depending on where the bearer is split. This configuration may include an indication of the cells involved in the multi-cell transmission. This may be, for example, a list of cell IDs. This configuration may also include an indication of which other bearers are configured in the cell for the same 5G MBS QoS flow. For example, the radio bearer may have a radio bearer ID and an MBS QoS flow ID. The MBS QoS flow ID may be shared by all radio bearers transmitting the same MBS QoS flow. Alternatively, the radio bearer may have a list of radio bearer IDs and alternative radio bearer IDs. These alternative radio bearer IDs identify other radio bearers that may be used to transport the 5G MBS QoS flows. The configuration may be transmitted to the UE through system information. Note that the UE may not support all legs of the non-SFN MC-PTM radio bearer. This may be due to, for example, a lack of UE capabilities. The UE may only be able to receive simultaneously through a certain number of cells. Alternatively, this may be due to poor radio conditions. The UE may not be able to receive DL transmissions from all cells transmitting non-SFN MC-PTM radio bearers. In this case, the UE may need to determine which of the legs to configure.

Fig. 27 illustrates an exemplary process 2700 for determining the number of branches. At step 2710, the UE may be in a waiting state. At step 2711, an event may trigger the UE to configure non-SFN MBS radio bearers. For example, a UE may be interested in MBS services provided in its current serving cell; the UE may change serving cell and the new serving cell provides non-SFN MBS bearers of interest to the UE; or the UE may receive MBS services over one radio bearer (e.g., SCPTM) and autonomously determine to start receiving the same bearer over another radio bearer (e.g., non-SFN MC-PTM). At step 2712, the UE may determine the cell quality of each of the cells involved in the multi-cell transmission. The determination may be based on RSRP, RSRQ, or SINR measurements. At step 2713, the UE may rank the cells based on the strongest cell quality. At step 2714, the UE may select from the ranked cells. This selection may be based on the strongest K cells, where K is configured or established based on UE capabilities (in advance). This selection may be based on a threshold (thresh). The cell is selected only if the measured cell quality is higher than thresh. Alternatively, the UE may use both the limit K and the threshold thresh.

The UE may have multiple radio bearer configurations for the same MBS QoS flow. For example, the UE may have a dedicated SC-PTP bearer configuration, a common SC-PTM radio bearer configuration, and a common SFN MC-PTM configuration. In this case, only one of these radio bearers may be active at a time. Other radio bearers may be suspended.

A multicast area radio bearer configuration may be determined, which may be common across a multicast area. The multicast area may provide MBS QoS flows over multiple radio bearers. The combination of the plurality of radio bearers includes a multicast area radio bearer. For example, a multicast area may have 2 DU-level multicast areas, each DU-RXA having its own radio bearer. In other words, DU RXA1 may have an SFN MC PTM radio bearer, while DU RXA2 may have a different SFN MC PTM radio bearer. The multicast area radio bearer consists of an SFN MC PTM radio bearer for DU RXA1 and an SFN MC PTM radio bearer for DU RXA 2. In this case, the multicast area radio bearer configuration may include a configuration for each of a plurality of radio bearers associated with MBS QoS flows across the RAN multicast area. Thus, as long as the UE moves within the RAN multicast area, the UE will know the details of the radio bearers transporting the MBS QoS flows. To achieve this, the UE may be configured with a multicast area radio bearer. This multicast area radio bearer may include an indication of the identity of the multicast area and a list of radio bearer configurations. Each of the configurations in this list may include a radio bearer ID, MBS QoS flow ID, cell ID, DU RXA ID, CU RXA ID, SCA RXA ID.

If a RAN delivery method change is triggered at the RAN node, the affected UE may be notified using the following mechanism.

The RAN node may send a dedicated RRC message to the affected UE. The message may include new radio bearer configuration details. If the UE already has new radio bearer configuration details (e.g., the new radio bearer may have been previously configured but placed in a suspended state), the RRC message only includes an indication to activate the suspended bearer.

If the UE already has new radio bearer configuration details (e.g., the new radio bearer may have been previously configured but placed in a suspended state), the RAN node may send a MAC CE message to the UE with an indication of which suspended radio bearer is activated. At the UE, the current radio bearer may be moved to a suspended state.

If the UE already has new radio bearer configuration details (e.g., the new radio bearer may have been previously configured but placed in a suspended state), the RAN node may send a DCI signal to the UE with an indication of which suspended radio bearer is activated. At the UE, the current radio bearer may be moved to a suspended state.

RAN delivery method changes may also be triggered at the UE. This change may occur due to:

RRC state change: for example, when the UE transitions to rrc_idle or rrc_inactive, the UE may autonomously transition to a radio bearer without UL feedback (such as a non-SFN MC-PTM, or SFN MC PTM bearer, or SC-PTM radio bearer).

Mobility: the UE may change serving cells; and

power saving: the UE may want to use the power saving feature. To take advantage of this feature, SC-PTP bearers may be preferably used.

In the event that a RAN delivery method change is triggered at the UE, the UE may need to notify the network of the change or wish to change the RAN delivery method. For example, the UE may send an RRC message to the network using a preferred delivery method.

In the case where the UE transitions from a RAN delivery method supporting uplink feedback to a RAN delivery method not supporting uplink feedback, the UE may perform one or more of:

if the UE has any pending SRs or BSRs, the timers associated with these SRs or BSRs are stopped:

the UE also cancels any pending SRs and/or BSRs;

if the UE has traffic in the HARQ buffer, clearing the traffic;

The UE stops any PHR timer; and

the UE stops any CSI timer.

A process of radio bearer configuration selection by a network is described herein. For single cell multi-unicast areas, the gNB has many radio bearer configuration options for sending MBS traffic to the UEs interested in the service. The gNB may additionally decide to change the radio bearer configuration for a particular UE. The gNB can use the following inputs to assist it in radio bearer configuration selection.

The radio bearer configuration options may be associated with MBS services. The gNB may have a mapping of MBS services to radio bearer configuration types or a mapping of MBS service types to radio bearer configuration types. For example, MBS services with high reliability with a large number of interested UEs may use MRBs with segmented radio bearers: a PTM leg using RLC-UM and a PTP leg using RLC-AM.

The radio bearer configuration options may be related to QoS attributes of MBS services. The gNB may have a mapping of QoS attributes to radio bearer configuration types, or a mapping of MBS service types to radio bearer configuration types. For example, MBS services with very high reliability requirements may use MRB with a single radio bearer using RLC-AM. QoS attributes may be one or more of priority, reliability, latency, 5QI (5G QoS identifier), resource type (GBR versus non-GBR).

The radio bearer configuration options may relate to the number of UEs interested in the service. The gNB may obtain this information from the core network, e.g. based on the number of UEs that have joined the MBS service. Thus, if this number is above a certain threshold, the gNB selects a radio bearer configuration with PTM legs.

The radio bearer configuration options may be related to the location of the UE of interest. If the UE is very far away, the gNB may decide to use a radio bearer configuration with PTP leg.

The radio bearer configuration options may relate to the RRC state of the UE. If the UE is in RRC idle or RRC connection, the UE may use a radio bearer configuration with PTM leg and without configured HARQ feedback.

The radio bearer configuration option may be associated with a number of HARQ transmission failures of the UE. The gNB may change the radio bearer configuration if the number of HARQ failures of the UE exceeds a threshold. The gNB MAC layer may monitor the number of HARQ failures for transport block transmissions of the UE. This monitoring may be for all UEs configured with G-RNTIs. Alternatively, the monitoring may be for only those UEs supporting split bearers. Alternatively, the monitoring may be for all UEs with configured split bearers. In case a TB may have a multiplexed MBS service, not all transport blocks carry MBS services of interest to the UE. For this case, the monitoring at the gNB may also track the UE for which feedback is expected.

The radio bearer configuration options may be linked to RLC status reports received from the UE. The gNB may change the radio bearer configuration if the number of RLC status reports for the UE exceeds a threshold. Alternatively, this may be based on the content of the RLC status report.

The radio bearer configuration options may be linked to PDCP status reports received from the UE. The gNB may change the radio bearer configuration if the number of PDCP status reports for the UE exceeds a threshold. Alternatively, this may be based on the content of the PDCP status report. This may be based on the number of PDCP SDUs that need to be retransmitted by the gNB, for example.

The radio bearer configuration options may be linked to measurement reports received from the UE. The gNB may use existing measurements or new measurements. For example, the UE may report some MBS signal quality.

The radio bearer configuration options may be linked to CSI reports received from the UE. The radio bearer configuration option may be based on a request from the UE. The UE may send this radio bearer configuration request using PHY layer signals (through UCI), using MAC CE, or through RRC messages. The request may be a simple indication to change the radio bearer configuration options or the request may provide additional information such as the requested configuration options. The UE may send this request based on:

The HARQ failure of the transport block is monitored. For example, if the number of HARQ failures exceeds a threshold, the UE requests a handover to a radio bearer configuration with PTP leg;

radio conditions for the serving cell. For example, if RSRP is below a first threshold, the UE requests a handover to a radio bearer configuration with PTP leg. Similarly, if the RSRP is above the second threshold, the UE requests a handover to a radio bearer configuration with a PTM leg;

location and range to the serving cell;

RLC status;

PDCP status.

If the radio bearer configuration for the MBS service is changed (referred to as radio bearer reconfiguration), the UE may stop receiving MBS service on the old radio bearer configuration and begin receiving MBS service on the new radio bearer configuration. The UE procedure resulting from radio bearer reconfiguration from DRB to MRB is described below. In this case, the UE is receiving MBS service for the service through the data radio bearer and is then reconfigured to receive MBS service for the service through the MRB, which may have been transmitting MBS service for the service but is transmitted to other UEs. In this case, at the gNB, the PDCP for DRB and the PDCP for MRB can receive SDAP SDUs simultaneously. However, due to the independent scheduling of the two radio bearers and the different multiplexing for the two radio bearers, the UE may not necessarily receive these SDAP PDUs at the same time. That is, the transmission of the same SDAP PDU across different radio bearers is not synchronized. Thus, there is a possibility that: after radio bearer reconfiguration, the UE may lose the SDAP PDUs or may receive copies of some of these SDAP PDUs. In order to solve this synchronization problem, the following solutions are proposed:

In a first example, a new function is added to the SDAP layer. The new functions may include sequence number, duplicate detection/processing, and status reporting. In this case, the transmitting SDAP layer may add an SN to each transmitted SDAP PDU (included in the SDAP header), and the receiving SDAP layer may examine the incoming SDAP SN to determine whether the SDAP PDU is lost or received repeatedly. Any duplicate SDAP PDUs are discarded. If the SDAP PDU is lost, the UE can send a status report to the gNB with the SN of the lost SDAP PDU.

In another example, when a UE is reconfigured, the UE may be informed of the last PDCP SN (prior to the reconfiguration message) that should be monitored over the old radio bearer configuration. The UE may use both radio bearer configurations during the transition period. The UE may stop using the old radio bearer configuration when the last PDCP SN is received over the old radio bearer configuration. Any PDCP PDUs received over the new radio bearer configuration are buffered until the UE stops using the old radio bearer configuration. The timer may also be configured to limit the duration of the transition period.

In yet another example, when the UE is reconfigured, a mapping between SNs on the old radio bearer configuration and SNs on the new radio bearer configuration may be notified. For example, the UE may be informed of the PDCP SN with an offset 'K'. This tells the UE that the PDCP sn=x received over the old radio bearer configuration corresponds to the same PDCP with sn=x+k received over the new radio bearer configuration. After reconfiguration, the UE uses the offset 'K' to determine whether the PDCP PDU is lost or received as a duplicate. The UE may then discard any duplicate PDCP PDUs. The UE may also send a PDCP status report to request retransmission of the lost PDCP PDU. In addition, upon receiving the radio bearer reconfiguration with the offset information, the PDCP entity associated with the old radio bearer configuration may transmit contents of a reception buffer of the PDCP entity to the PDCP entity of the new radio bearer configuration. In this procedure, the state variable of the PDCP entity may be updated to reflect the offset in the PDCP SN.

The UE may be configured with multiple radio bearer configurations for MBS services of the service. In some cases, both may be active at the same time for one transition period. In other cases, only one of these may be active at a time, the other may be in a suspended mode. In this mode, the UE maintains radio bearer configuration details, but the UE may clear all state variables associated with the radio bearer.

The UE may have multiple triggers to decide when to change from an old radio bearer configuration to a new radio bearer configuration. For example, one or a combination of the following triggers may be used:

based on the receipt of the reconfiguration message.

Based on the received PDCP SN value. The UE may be configured with the last PDCP SN that the UE should monitor on the old radio bearer configuration.

Based on the received SDAP SN value. The UE may be configured with the last SDAP SN that it should monitor on the old radio bearer configuration.

Based on expiration of the timer. After receiving the reconfiguration message, the UE may be configured to use both the old and new radio bearer configurations during the transition period. After this transition period, the UE may cease using the old radio bearer configuration.

The UE may also use the reception activity on the DRB to stop using the old MRB radio bearer configuration if the old radio bearer configuration is from MRB to DRB.

Described herein are procedures for path switching of MRB (PTP < - > PTM). For a single cell multicast area, the UE may be configured with radio bearer configuration options: MBS Radio Bearers (MRBs) with split radio bearers. For such radio bearers, the gNB may dynamically perform path switching, thereby switching the leg/path through which MBS traffic is sent to the UE.

The gNB may use the following inputs to help it select a path for transmitting MBS traffic to the UE and to help make decisions to perform path switching (from PTP leg/path to PTM leg/path and from PTM leg/path to PTP leg/path).

The path may be associated with an MBS service. The gNB may have a MBS service-to-path mapping or MBS service type-to-path mapping. For example, an MBS service for multicast TV may initially use PTM legs/paths.

The path may be associated with QoS attributes of MBS services. The gNB may have a mapping of QoS attributes to paths, or a mapping of MBS service types to paths. For example, an MBS service with low reliability requirements may initially use the PTM leg/path. QoS attributes may be one or more of priority, reliability, latency, 5QI (5G QoS identifier), resource type (GBR versus non-GBR).

The path may relate to the number of UEs interested in the service. The gNB may obtain this information from the core network, e.g. based on the number of UEs that have joined the MBS service. Thus, if this number is above a certain threshold, the gNB selects the PTM leg/path.

The path may relate to the location of the UE of interest. If the UE is very far from the serving cell, the UE may initially decide to use the PTP leg/path. Similarly, if the UE moves very far, the gNB may decide to switch to the PTP leg/path.

The path may be related to the RRC state of the UE. The gNB may decide to use the PTP leg/path if the UE is in RRC connection.

The path may be linked to the number of HARQ transmission failures for the UE. The gNB may change paths if the number of HARQ failures of the UE exceeds a threshold. The gNB MAC layer may monitor the number of HARQ failures for transport block transmissions of the UE. This monitoring may be for only those UEs supporting split bearers. Alternatively, the monitoring may be for all UEs with configured split bearers. In case a TB may have a multiplexed MBS service, not all transport blocks carry MBS services of interest to the UE. For this case, the monitoring at the gNB may also track the UE for which feedback is expected.

The path may be linked to RLC status reports received from the UE. The gNB may change paths if the number of RLC status reports for the UE exceeds a threshold. Alternatively, this may be based on the content of the RLC status report.

The path may be linked to a PDCP status report received from the UE. The gNB may change paths if the number of PDCP status reports for the UE exceeds a threshold. Alternatively, this may be based on the content of the PDCP status report. This may be based on the number of PDCP SDUs that need to be retransmitted by the gNB, for example. In one implementation, the network may configure the UE with a lost PDCP threshold. This threshold may be the number of lost PDCP PDUs, the number of consecutive lost PDCP PDUs, or the percentage of lost PDUs observed over the observation window. When the PDCP entity at the UE observes that the number of lost PDCP PDUs exceeds this threshold, the PDCP entity triggers the UE to send a PDCP status report to the gNB.

The path may be linked to a measurement report received from the UE. The gNB may use existing measurements or new measurements. For example, the UE may report some MBS signal quality.

The path may be linked to CSI reports received from the UE.

The path may be based on a request from the UE. The UE may send this path request using PHY layer signals (through UCI), using MAC CE, or through RRC messages. The request may be a simple indication to change the radio bearer configuration options or the request may provide additional information such as the requested configuration options. The UE may send this request based on:

the HARQ failure of the transport block is monitored. For example, if the number of HARQ failures exceeds a threshold, the UE requests a handover to a radio bearer configuration with PTP leg.

Radio conditions for the serving cell. For example, if RSRP is below a first threshold, the UE requests a handover to a radio bearer configuration with PTP leg. Similarly, if the RSRP is higher than the second threshold, the UE requests a handover to a radio bearer configuration with a PTM leg.

To the location and range of the serving cell.

RLC status.

PDCP status.

The path switching may be transparent to the UE. In the case of transparent path switching, the UE may need to monitor both paths and may determine when to stop processing one path instead of the other. For example, after a PTM to PTP path switch, the UE should receive the MBS service of the UE on the PTP path. However, the gNB may still transmit on the G-RNTI configured for the PTM path (since this PTM path is used by multiple UEs). In this case, the UE may be receiving a transport block through two paths, transmitting HARQ feedback through two paths, demultiplexing MAC PDUs through two paths, and so on. This results in unnecessary processing and power consumption at the UE and may result in wasting air resources.

Therefore, rules need to be defined for the UE to determine which of the two branches/paths the UE should 'handle'. Here, the term 'processing' is used to denote receiving a transport block through the C-RNTI for the PTP path or receiving a transport block through the G-RNTI for the PTM path. These rules may include one or more of the following:

activity-based: if the UE detects that there is traffic on the C-RNTI, the UE starts processing the C-RNTI. When processing the C-RNTI, the UE does not process the G-RNTI, effectively shutting off the processing of the G-RNTI. Alternatively, if the UE detects the presence of 'MBS service' on the C-RNTI, the UE starts to process the C-RNTI. The MAC header may include a field indicating that the MAC header contains MBS services. As another alternative, if the UE detects that 'MBS traffic for MBS service of interest' exists on the C-RNTI, the UE starts to process the C-RNTI. The MAC header may include a bit field to indicate which services are carried in the C-RNTI.

Timer-based: if the UE is handling traffic from the PTP leg/path but no traffic is received on this leg during the inactivity time, the UE may start handling G-RNTI (effectively turning on the PTM leg). This inactivity time may be (pre) configured by RRC signaling as part of the MRB radio bearer configuration. Alternatively, if the UE is handling traffic from the PTP leg/path, but does not receive any 'MBS traffic' on this leg during the inactivity time, the UE may start handling G-RNTI. As another alternative, if the UE is handling traffic from the PTP leg/path, but does not receive any 'MBS traffic for MBS service of interest' on this leg during the inactivity time, the UE may start handling G-RNTI.

The path switch may be explicitly signaled to the UE. The gNB may send the handover request through PHY mechanism (DCI), MAC CE, or RRC signaling. Alternatively, the handover request may be sent in the MAC header field of the current leg/path. For example, the MAC header may include a 1-bit NewPathIndicator. When this indicator is switched, this may indicate that the UE should change paths. Alternatively, the value of the bit field may indicate that the UE should change paths. For example, when the UE receives a MAC PDU of newpathindicator=1, the UE changes the receive leg/path of the associated MRB.

After path switching, the UE may change its RLC configuration from the old RLC entity to the new RLC entity. The old RLC entity may have RLC PDUs stored in its receive buffer. The UE may have a transport block containing MBS services received at the PHY layer. After the PTP-PTM path switching, the UE may clear the contents of the HARQ buffer of the PTP leg; de-multiplexing the MAC PDUs but discarding any RLC PDUs from the PTP leg/path; for PTP leg/path, clearing RLC layer receive buffer contents; for PTP leg/path, delivering the content of RLC layer to PDCP layer; the contents of the receive buffer are transferred from the PTP leg/path to the PTM leg/path.

After the PTM-PTP path switch, it is suggested that the UE can clear the contents of the HARQ buffer of the PTP leg; de-multiplexing the MAC PDUs but discarding any RLC PDUs from the PTM leg/path; for the PTM leg/path, clearing the RLC layer of the contents of the receive buffer; delivering the content of the RLC layer to the PDCP layer for the PTM leg/path; transmitting the contents of the receive buffer from the PTM leg/path to the PTP leg/path; the RLC entity suspending the PTM leg/path.

Upon switching from PTM to PTP, the gNB may ensure that the logical channels of the traffic multiplexed in the C-RNTI may have a unique LCID. Alternatively, if an LCID collision is possible, the MAC header may include a new field to indicate whether the logical channel belongs to a DRB or an MRB split bearer. The new field may also indicate which MRB split bearer.

Another alternative to path switching is to have the UE receive MBS traffic over the selected path but continue to monitor another path. For example, in a PTM-PTP switch, after the UE determines that the UE should begin monitoring traffic on the PTP leg, the UE may continue to additionally monitor MBS traffic on the deactivated PTM leg because this traffic is still being transmitted. The UE may continue to process MBS PDUs received on the PTM leg and continue to perform HARQ combining. The UE may even collect HARQ feedback statistics for the PTM leg. The network may configure the UE not to send HARQ feedback for the deactivated PTM leg. The UE may discard any recovered transport blocks on the deactivated PTM leg. Alternatively, the UE may continue to process the recovered transport block and forward the transport block to higher layers. In this case, PDCP PDUs may be received through both PTP and PTM legs. The PDCP layer relies on its duplicate detection function to eliminate duplicate PDCP PDUs. The UE may use the HARQ statistics of the PTM leg to determine when to perform path switching between the PTP leg and the PTM leg. The network may configure the UE with a threshold related to HARQ statistics to support PTM-to-PTP path switch decisions in the UE. The UE may autonomously decide to switch back to the PTM leg. For example, the UE may determine that the number of HARQ ACKs on the PTM path exceeds a configured threshold. In this case, the UE may send an indication to the network that the UE has switched back to the PTM leg. This indication may be explicit (e.g., by PHY layer signaling, by MAC signaling, or by RRC signaling). Alternatively, the indication may be implicit. For example, the UE may start transmitting HARQ feedback for the traffic it receives on the PTM leg. In either case, the network receives this explicit or implicit indication and determines that the network should cease scheduling MBS services for the UE over the PTP leg. As another alternative, the gNB may decide to switch back to the PTM leg. The gNB may base this decision on some indication from the UE. In this case, the UE may send an indication to the network that the UE will prefer to switch back to the PTM leg. This indication may be explicit (e.g., by PHY layer signaling, by MAC signaling, or by RRC signaling).

Multicast changes to state procedures are described herein. MBS QoS flows for MBS services may be transmitted over one or more MRBs and one or more DRBs. The UE may need to receive multiple MRBs and/or DRBs to properly receive MBS services. In order for the UE to know which MRBs and/or DRBs are linked to which MBS services, it is suggested to identify all services by a unique MBS service ID (or MBS session ID). The unique MBS service ID may be a TMGI or different from a TMGI. The unique MBS service ID may be part of MBS control information for the service. The unique MBS service ID may be part of the MRB configuration and/or the DRB configuration. This allows the UE to know which MRBs and DRBs are associated with MBS services.

The multicast session may change from an active state to an inactive state.

Active multicast session: an established multicast session in an active state. Multicast data is transmitted to UEs joining the multicast session. The 5GC resources for the multicast session are reserved. Corresponding radio resources are reserved according to the participating UE locations. The UE joining the multicast session is in the CM CONNECTED or CM IDLE state. The UE is allowed to join the multicast session (subject to authorization checks).

Inactive multicast session: 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 is allowed to join the multicast session (subject to authorization checks).

Upon transitioning from the ACTIVE state to the INACTIVE state, the gNB may send an indication to the UE that the multicast service is transitioning to the INACTIVE state. The gNB may send this indication to the UE via a paging message. Alternatively, the gNB may send this indication with MBS traffic through PHY signaling, MAC signaling, or RRC signaling. The gNB may include duration information in the indication. The UE may use this duration information to determine how long the service will be INACTIVE. Alternatively, the UE may autonomously determine that the service is INACTIVE. The UE may make this determination based on inactivity on the MRB associated with the MBS service. To assist the UE in this determination, the gNB may configure the UE with inactivity timer related information. The gNB may include this inactivity timer related information in MBS control information of the MBS service.

When the multicast service transitions to INACTIVE, the UE may use the unique MBS service ID to identify all MRBs and DRBs associated with this multicast session. For MRBs with a single PTM leg, if no other MBS services are multiplexed with the G-RNTI, the UE may cease monitoring PTM transmissions with the configured G-RNTI. For MRBs with split bearers, the UE may stop monitoring the transmission of the configured G-RNTI through the PTM leg if no other MBS services are multiplexed through the G-RNTI. The UE may transition all MRBs and DRBs associated with the multicast session to an "inactive" state. In this state, the UE maintains the configuration of radio bearers, but the UE does not maintain any timers or windows associated with these radio bearers. Thus, the timer is stopped and the buffer is refreshed. Prior to transitioning these radio bearers to "inactive", the UE may perform actions to facilitate transitioning these radio bearers back to "active" state. For example, the RLC layer may forward all RLC PDUs in its reception/reordering window to the PDCP entity. The PDCP entity may forward all PDCP PDUs in its receive/reorder window to the SDAP entity. In addition, if the PDCP entity determines that there are lost PDCP PDUs, the PDCP entity may send a PDCP status report to the gNB so that these lost PDCP PDUs may be retransmitted. RLC and PDCP entities may also maintain/store the values/contents of their state variables. That is, when the radio bearer is transitioned to "inactive", state variables of the RLC and PDCP layers are not cleared.

When this multicast service later transitions to ACTIVE, it is necessary to make the affected UE aware. The network may page UEs in rrc_idle and rrc_inactive. The paging message may include a unique MBS service ID. The gNB may also page the UE in the RRC_CONNECTED state. Alternatively, the gNB may notify the UEs through dedicated signaling. The UE uses the unique MBS service ID to identify the MRB and DRB associated with this multicast session. For MRBs with a single PTM leg, the UE may start monitoring PTM transmissions. For MRBs with split bearers, the UE may start monitoring transmissions over the PTM leg. The UE may transition all MRBs and DRBs associated with the multicast session to an "active" state. For the state variables maintained by the PDCP and RLC layers, the following options are possible:

initial values of these state variables for all MRBs and DRBs associated with the multicast session may be provided to the UE. The network may provide these initial values through dedicated signaling and/or through paging messages.

The UE may use the stored value of the state variable (stored when the radio bearer is switched to inactive).

The UE may use default initial values for these state variables, which are known to both the UE and the network.

Multicast area management procedures are described herein. The multicast area is a packet of a cell through which MBS service is provided. The multicast area may provide MBS services through one or more of RAN delivery methods (SC-PTM, non-SFN MC-PTM, SFN MC-PTM). The multicast area may consist of a grouping of individual cells, or a grouping of a collection of cells (e.g., all cells under a DU, all cells under a CU, etc.). The multicast area may be a packet of a single cell level multicast unicast area, a packet of a CU level multicast unicast area, a packet of a DU level multicast unicast area, or a hybrid packet of a single cell level multicast unicast area, a CU level multicast unicast area, and a DU level multicast unicast area. The multicast area may be represented as a set of cell IDs, a set of CU IDs, and/or a set of DU IDs. For example: xcast-area=set { cell_id1, …, cell_idk, cu_id1, … cu_idj, du_id1, …, du_idm }.

The multicast areas may be maintained for MBS services or MBS service groups (typically with similar QoS requirements, traffic patterns, coverage requirements, etc.). An initial multicast area for an MBS service or an MBS service group may be defined. The core network may provide this initial multicast area to the RAN. For example, the initial multicast area may be provided at the start of an MBS session. The initial multicast area may be based on the geographic area that the MBS content provider wants to cover. After defining this initial multicast area, the multicast area may be dynamically changed according to a number of conditions:

UE state change: a UE receiving an MBS service through a multicast area may change from rrc_connected to rrc_idle or rrc_inactive. If this is the first UE in the cell receiving the MBS service, the RAN node may decide to add the cell to the multicast area (and configure the appropriate PTM radio bearers (SC-PTM, non-SFN MC-PTM, SFN MC-PTM) for this cell). Alternatively, if this is the first UE in a DU receiving an MBS service, the RAN node may decide to add this DU to the multicast area (and configure appropriate PTM radio bearers (SC-PTM, non-SFN MC-PTM, SFN MC-PTM) for this DU). Alternatively, if this is the first UE in a CU receiving MBS services, the RAN node may decide to add this CU to the multicast area (and configure appropriate PTM radio bearers (SC-PTM, non-SFN MC-PTM, SFN MC-PTM) for this CU).

UE mobility: a UE receiving MBS service through a multicast area may change a serving cell. A new serving cell may be added to the multicast area. In some cases, this may be the last UE in the old serving cell to receive MBS services over the PTM radio bearer. In this case, the old serving cell may be removed from the multicast area.

RAN transport method change: the RAN node may decide to change the RAN transport method to the UE. For example, the RAN node may change the delivery method to PTP radio bearers for a given cell (SC-PTP). If this is the last UE in a cell using a PTM radio bearer, the RAN node may decide to remove the cell from the multicast area. If this is the last UE in the DU using the PTM radio bearer, the RAN node may decide to remove the DU from the multicast area. If this is the last UE in the CU using the PTM radio bearer, the RAN node may decide to remove the CU from the multicast area.

The UE loses interest in MBS services: the UE in a given cell may decide that the UE is no longer interested in MBS services. If this is the last UE in a given cell using this service, that cell can be removed from the multicast area.

The UE is interested in MBS services: the UE in a given cell may decide that the UE is interested in MBS services. If this is the first UE in a given cell using this service, that cell can be added to the multicast area.

The UE is powered on.

Requests from the core network: the content provider may request a change in the multicast area (e.g., to decrease the coverage area or increase the coverage area).

Note that the RAN node may also use other metrics/conditions to determine the multicast area. These metrics/conditions are the same metrics/conditions used by the RAN node to make the RAN delivery method decision. For example, the RAN node may use multiple UEs interested in MBS services. In addition, the UE may provide further assistance to the RAN node to help determine the multicast area. For example, this information may be provided in the following RRC message: MBSInterestIndication, RRCSetupRequest, RRCResumeRequest.

The multicast area may be provided to the UE using an Information Element (IE) (e.g., xcastarea). This IE will include a set of cell_id, cu_id, and/or du_id. This IE may be sent as part of the system information in a new MBS SIB (e.g., systemInformationBlockTypeX). In this case, the change in the multicast area will be effected by the SI change indication procedure, as defined in TS 38.331, nr; radio Resource Control (RRC); protocol specification, V16.1.0. The system information may include a plurality of xcastarea IEs, one xcastarea IE for each multicast area to which the cell belongs (since the cell may belong to more than one multicast area).

Alternatively, this IE may be sent as part of a multicast area configuration transmitted through the SC-MCCH, MCSF-MCCH or MCMF-MCCH in an xcastarea configuration message. In this case, the change in the multicast area will be implemented through the MCCH change notification procedure. Note that separate messages and/or IEs may be used for each of the MCCH logical channels.

As another alternative, this IE may be sent as part of the rrcrecon configuration message on DCCH. As yet another alternative, an indication to read the xcastarea configuration message carried over the MCCH may be sent to the UE.

Fig. 28 illustrates an example 2800 of UE actions when changing over a multicast area. At step 2810, the UE may determine an affected MBS service. At step 2811, the UE may update its multicast area maintained for this MBS service. For example, the UE may be currently receiving MBS services over the SC-PTP bearer, and the current serving cell may be newly added to the multicast area. At step 2812, the UE may read the system information and may then obtain an xcastarea configuration message to determine a multicast area radio bearer configuration or an MBS radio bearer configuration in the current serving cell. For example, the MBS service may be provided through the SC-PTM radio bearer in the current serving cell. At step 2813, the UE may decide to change the RAN delivery method for MBS services. For example, the UE may decide to continue to receive service over the SC-PTM bearer. At step 2814, the UE may inform the RAN node that the UE may be receiving service over an SC-PTM bearer and, thus, that the UE no longer needs an SC-PTP connection. After a period of time, the UE receives another multicast area update (step 2815). The UE may then repeat steps 2810 and 2811. For example, the UE may be currently receiving MBS services over the SC-PTM bearer and may remove the current serving cell from the multicast area. At step 2816, the UE may decide to change the RAN delivery mode for MBS services. For example, the UE may decide to send a service request NAS message in order to establish an SC-PTP bearer to obtain MBS service. Alternatively, the UE may decide to stop receiving MBS services and notify upper layers.

The following abbreviations and definitions are used herein:

3GPP third Generation partnership project

Fifth generation of 5G

5GS 5G system

AMF access and mobility management functions

ARQ automatic repeat request

BM-SC broadcast multicast service center

CFI control format indicator

CP cyclic prefix

CN core network

CU central unit

CU-RXA central unit RXA

DCI downlink control information

DL-SCH uplink shared channel

DRX discontinuous reception

DU distributed unit

DU-RXA distributed unit RXA

eNBs evolved node B

EN TV enhanced television

EPS evolution grouping system

E-UTRA evolved UMTS terrestrial radio access

eMBMS enhanced MBMS

FeMBMS further enhanced MBMS

FR2 frequency range 2 (frequency band from 24.25GHz to 52.6 GHz)

gNB 5G node B

GPRS general packet radio service

G-RNTI group RNTI

GW gateway

Hybrid HARQ ARQ

ID identification

IE information element

IoT (Internet of things)

ITS intelligent transportation system

LTE long term evolution

MAC medium access control

MBMS multimedia broadcast multicast system

MBMS GW MBMS gateway

MBS multicast/broadcast service

MBS GW multicast/broadcast service GW

MBSFN multicast broadcast single frequency network

MCCH multicast control channel

MCE multi-cell/multicast coordination entity

MCH multicast transmission channel

MCMF-MCCH multi-cell multi-frequency MCCH

MCMF-MTCH multi-cell multi-frequency MTCH

MCSF-MCCH multi-cell single frequency MCCH

MCSF-MTCH multi-cell single frequency MTCH

MC-PTM multi-cell PTM

MC-RXA multi-cell RXA

MCS modulation and coding scheme

MIMO multiple input multiple output

MooD on-demand MBMS operation

MRB multicast/broadcast radio bearer

MTCH multicast traffic channel

NAS non-access stratum

OFDM orthogonal frequency division multiplexing

PDCCH physical downlink control channel

PDCP packet data convergence protocol

PDSCH physical uplink shared channel

PMCH physical multicast channel

PSM power saving mode

PTP point-to-point

QoS point-to-multipoint

RAN radio access network

RLC radio link control

ROM receive-only mode

RNL radio network layer

RNTI radio network temporary identifier

RSRP reference signal received power

RSRQ reference signal reception quality

RXA RAN multicast area

SC-MCCH single cell MCCH

SC-MTCH single cell MCTH

SC-PTP single cell PTP

SC-PTM single cell PTM

SC-RNTI single cell RNTI

SC-RXA single cell RXA

SDAP service data adaptation protocol

SFN single frequency network

SFN system frame number

SIM user identity module

SINR signal-to-noise-and-interference ratio

STMGI super TMGI

STU system time unit

STUN system time unit number

TBS transport block size

TDM time division multiplexing

TMGI temporary mobile group identification

TNL transport network layer

UE user equipment

UL uplink

UM unacknowledged mode

UPF user plane functionality

V2X vehicle to everything the following terms/definitions 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.

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

Regarding service continuity of MBS: service continuity means that the UE will continue to receive MBS services (with no or little service interruption) despite changing serving cell, changing RRC state, or changing RAN delivery method for MBS services.

Single frequency network: a set of cells operating on the same frequency. In the context of MBMS, a single frequency network also means that transmissions from all cells are synchronized and use the same transport format (MCS, TBS …).

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. 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: 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. 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 region: through which a transmission area of the MBS service is provided.

RAN delivery method: the RAN node transmits MBS business through Uu interface. The RAN delivery method may be a unicast radio bearer type or an MBS Radio Bearer (MRB) type.

Multicast area: the RAN multicast area may be considered to provide packets of one or more cells of an MBS service or group of MBS services by one or more RAN delivery methods known to or determinable by the UE. In other words, a UE receiving an MBS service (or MBS service group) in one cell (e.g., cell 1) of RXA may also know how to receive the same MBS service (or MBS service group) in another cell (e.g., cell 2) of RXA.

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

Splitting the bearer: type of radio bearer with two legs. 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.

MBS transmission: transmission of MBS services.

Unicast transmission: transmission of unicast services.

Claims (20)

1. A wireless communication device comprising a processor and a memory, the wireless communication device further comprising computer-executable instructions stored in the memory of the wireless communication device, which when executed by the processor of the wireless communication device, cause the wireless communication device to:

receiving multicast/broadcast service (MBS) control information from a base station and via one or more Multicast Control Channel (MCCH) logical channels to enable receipt of MBS services via one or more MBS Radio Bearers (MRBs) or one or more unicast Data Radio Bearers (DRBs), wherein the MBS control information comprises:

at least one MRB configuration, and

mapping of said MBS service to one or more group radio network temporary identifiers (G-RNTIs); and

The configuration of the protocol stack of the wireless communication device is caused based on the received MBS control information.

2. The wireless communication device of claim 1, wherein the MRB comprises a split bearer having two legs, wherein the two legs comprise a point-to-multipoint (PTM) leg and a point-to-point (PTP) leg,

wherein the PTM leg is configured with a radio link control acknowledged mode (RLC-AM) or a radio link control unacknowledged mode (RLC-UM), wherein the PTP leg is configured with RLC-AM or RLC-UM.

3. The wireless communication device of claim 2, wherein the computer-executable instructions, when executed by the processor of the wireless communication device, further cause the wireless communication device to:

it is determined when to stop processing transport blocks from the first leg and to start processing transport blocks from the second leg.

4. The wireless communication device of claim 3, wherein the determining when to stop processing transport blocks from the first leg and to begin processing transport blocks from the second leg is based on detecting activity on the second leg, and wherein the activity comprises detecting MBS traffic on the second leg.

5. The wireless communications apparatus of claim 3, wherein the determining when to stop processing transport blocks from the first leg and begin processing transport blocks from the second leg is based on expiration of a timer maintained for the first leg, and wherein the timer is started each time MBS traffic is received on the first leg.

6. The wireless communications apparatus of claim 1, wherein the at least one MRB configuration comprises at least one of: a Service Data Adaptation Protocol (SDAP) layer configuration, a Packet Data Convergence Protocol (PDCP) layer configuration, a Radio Link Control (RLC) layer configuration, a Medium Access Control (MAC) layer configuration, a logical channel configuration, or a Physical (PHY) layer configuration.

7. The wireless communications apparatus of claim 6, wherein the SDAP layer configuration comprises a single SDAP entity and a mapping of MRBs to MBS services.

8. The wireless communications apparatus of claim 6, wherein the logical channel configuration comprises a mapping of logical channels to G-RNTIs.

9. The wireless communications apparatus of claim 6, wherein the at least one MRB configuration comprises a configuration of the one or more unicast DRBs for an associated Protocol Data Unit (PDU) session of the MBS service, wherein the one or more unicast DRBs are in a suspended state until activated.

10. The wireless communications apparatus of claim 6, wherein the MAC configuration comprises a Discontinuous Reception (DRX) configuration and a hybrid automatic repeat request (HARQ) configuration of the MBS service.

11. The wireless communications device of claim 10, wherein the HARQ configuration indicates whether HARQ feedback is enabled or disabled and whether HARQ retransmission is allowed through a cell radio network temporary identifier (C-RNTI).

12. The wireless communications apparatus of claim 1, wherein the mapping is based on at least one of: single MBS service mapped to G-RNTI.

13. The wireless communications apparatus of claim 1, wherein the mapping is based on at least one of: multiple MBS services mapped to G-RNTI, single G-RNTI per cell, single G-RNTI used in geographical area, single G-RNTI used in beam forming area, single MBS quality of service (QoS) flow mapped to G-RNTI, multiple MBS QoS flow mapped to G-RNTI, MBS QoS attribute mapped to G-RNTI, logical channel type mapped to G-RNTI, logical channel mapped to G-RNTI, user Equipment (UE) category mapped to G-RNTI.

14. The wireless communications apparatus of claim 13, wherein the MBS service is received via a plurality of shared G-RNTIs.

15. The wireless communications apparatus of claim 1, wherein the one or more MCCH logical channels carry the MBS control information per service, wherein the MBS control information per service includes an MBS service identifier and the one or more MRBs carrying traffic for the MBS service, wherein the one or more MCCH logical channels include at least one MRB configuration and the mapping for each of the one or more MRBs.

16. The wireless communications apparatus of claim 1, wherein the one or more MCCH logical channels carry the MBS control information per G-RNTI, wherein the MBS control information per G-RNTI includes a plurality of MRBs carried on the G-RNTI, wherein the one or more MCCH logical channels include at least one MRB configuration and MBS service identifier for each of the one or more MRBs.

17. The wireless communications apparatus of claim 1, wherein the one or more MCCH logical channels are received through dedicated signaling or through common signaling using a modification and repetition period.

18. The wireless communication device of claim 1, wherein the computer-executable instructions, when executed by the processor of the wireless communication device, further cause the wireless communication device to:

Sending a radio bearer configuration request to the base station, wherein the radio bearer configuration request is based on at least one of: a monitored hybrid automatic repeat request (HARQ) failure for a transport block, radio conditions to a serving cell, location or range to the serving cell, packet Data Convergence Protocol (PDCP) status or Radio Link Control (RLC) status.

19. The wireless communication device of claim 1, wherein the computer-executable instructions, when executed by the processor of the wireless communication device, further cause the wireless communication device to:

receiving second MBS control information from the base station, wherein the second MBS control information comprises a last Packet Data Convergence Protocol (PDCP) Sequence Number (SN) monitored by the wireless communication device when using the MBS control information, wherein the MBS control information and the second MBS control information are both used for a temporary period, wherein the second MBS control information comprises a mapping between SNs on the MBS control information and the second MBS control information; or alternatively

Using the MBS control information until one or more of the following events occur: the method further includes receiving the second MBS control information, receiving the pdcppsn of a particular value, receiving a Service Data Adaptation Protocol (SDAP) SN of a particular value, expiration of a timer, detecting activity on a second radio bearer configuration.

20. A network node comprising a processor and a memory, the network node further comprising computer-executable instructions stored in the memory of the network node, which when executed by the processor of the network node, cause the network node to:

determining multicast/broadcast service (MBS) control information to enable reception of an MBS service by a User Equipment (UE) via one or more MBS Radio Bearers (MRBs) or one or more unicast Data Radio Bearers (DRBs), wherein the MBS control information comprises:

at least one MRB configuration, and

mapping of said MBS service to one or more group radio network temporary identifiers (G-RNTIs); and

the MBS control information is transmitted to the UE and via one or more Multicast Control Channel (MCCH) logical channels, wherein the transmitting causes configuration of a protocol stack of the UE based on the MBS control information.

Images