Bearer structure and method and apparatus for supporting multicast in next generation mobile communication system

Abstract

The disclosure relates to: a communication technology of fusing IoT technology with a 5G communication system supporting a data transmission rate higher than that of a 4G system; and a system thereof. The disclosure can be applied to intelligent services (e.g., smart home, smart building, smart city, smart car or connected car, health care, digital education, retail industry, security and safety-related services, etc.) based on 5G communication technology and IoT technology. Also, in the disclosure, a method and apparatus for a terminal to appropriately receive an MBS service in various scenarios are proposed.

Description

Technical Field

[0001] This disclosure relates to bearer structures, methods, and apparatuses that support multicast or unicast in next-generation mobile communication systems. Background Technology

[0002] To meet the increased demand for wireless data services due to the deployment of 4G communication systems, efforts have been made to develop improved 5G or near-5G communication systems. Therefore, 5G or near-5G communication systems are also referred to as "super-4G network" communication systems or "post-LTE" systems. 5G communication systems are considered for implementation in ultra-high frequency (mmWave) bands (e.g., the 60GHz band) to achieve higher data rates. To reduce radio wave propagation loss and increase transmission distance in the ultra-high frequency band, beamforming, massive MIMO, full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and massive MIMO technologies are discussed in 5G communication systems. Furthermore, in 5G communication systems, development is underway for system network improvements based on advanced small cells, cloud radio access networks (RAN), ultra-density networks, device-to-device (D2D) communication, wireless backhaul, mobile networks, cooperative communication, cooperative multipoint (CoMP), and receiver interference cancellation. In 5G systems, hybrid FSK and QAM modulation (FQAM) and sliding window superposition coding (SWSC) have been developed as advanced coding and modulation (ACM), while filter bank multicarrier (FBMC), non-orthogonal multiple access (NOMA) and sparse code multiple access (SCMA) have been developed as advanced access technologies.

[0003] The Internet (a human-centric network of connectivity where humans generate and consume information) has now evolved into the Internet of Things (IoT), in which distributed entities, such as things, exchange and process information without human intervention. The Internet of Everything (IoE) has emerged, a combination of IoT technologies and big data processing technologies made through connections to cloud servers. With the technological elements already required for IoT implementation, such as sensing technology, wired / wireless communication and network infrastructure, service interface technology, and security technology, sensor networks, machine-to-machine (M2M) communication, and machine-type communication (MTC) are currently under investigation. Such an IoT environment can provide intelligent Internet technology (IT) services that create new value for human life by collecting and analyzing data generated in connected objects. Through the convergence and combination of existing information technology (IT) and various industrial applications, IoT can be applied to a wide range of fields, including smart homes, smart buildings, smart cities, smart or connected cars, smart grids, healthcare, smart appliances, and advanced medical services.

[0004] Accordingly, various attempts have been made to apply 5G communication systems to IoT networks. For example, technologies such as sensor networks, machine-type communication (MTC), and machine-to-machine (M2M) communication can be implemented through beamforming, MIMO, and array antennas. The application of cloud radio access networks (cloud RAN), which serve as the big data processing technologies described above, can also be considered as an example of the convergence of 5G and IoT technologies.

[0005] Recently, research is underway on technologies for broadcast (broadcast / multicast) services, mission-critical services, or public safety network services in next-generation mobile communication systems, and at this time, methods and devices to support MBS services are needed. Summary of the Invention

[0006] Technical issues

[0007] Next-generation mobile communication systems can support MBS services (Multicast, Broadcast, Multimedia Broadcast and Multicast Services (MBMS), or Multicast and Broadcast Services (MBS)) to support services such as broadcast (broadcast / multicast) services, mission-critical services, and public safety services. MBS services can be provided to terminals via multicast or unicast bearers.

[0008] Because a structure or method is needed to configure a multicast or unicast bearer that supports MBS services, as well as a data processing method for a PHY layer device, MAC layer device, RLC layer device, or PDCP layer device that receives and processes MBS data in order to support MBS services, this disclosure proposes methods and apparatuses to meet such requirements.

[0009] In the RRC connected mode, RRC idle mode, or RRC inactive mode used for MBS services, or when switching between these modes, since it is necessary to specify the signaling procedure for the terminal to continue supporting MBS services, another aspect of this disclosure proposes methods and apparatus to meet this necessity.

[0010] Since methods for reconfiguring MBS support from multicast bearers to unicast bearers or vice versa may be required depending on the handover between base stations or networks supporting MBS services or the mobility of terminals, another aspect of this disclosure proposes methods and apparatus to meet such necessity.

[0011] Another aspect of this disclosure provides methods and apparatus for a terminal to normally receive MBS services in the various scenarios described above.

[0012] Solution to the problem

[0013] In a method performed by a terminal in a wireless communication system according to an embodiment of the present disclosure to solve the above-mentioned problems, the method may include: establishing a radio resource control (RRC) connection with a base station; receiving first multicast and broadcast service (MBS) data and second MBS data from the base station via a physical layer; transmitting the first MBS data from the physical layer to a first radio link control (RLC) layer and the second MBS data to a second RLC layer via a media access control (MAC) layer; transmitting the first MBS data from the first RLC layer to a packet data convergence protocol (PDCP) layer and the second MBS data from the second RLC layer to the PDCP layer; and transmitting the first MBS data and the second MBS data from the PDCP layer to an upper layer, wherein a first bearer including the first RLC layer is configured as a unicast bearer, and a second bearer including the second RLC layer is configured as a multicast bearer. Furthermore, in a method performed by a base station in a wireless communication system according to an embodiment of this disclosure to solve the above-mentioned problems, the method may include: establishing a Radio Resource Control (RRC) connection with a terminal; obtaining first multicast and broadcast service (MBS) data and second MBS data from an upper layer at a Packet Data Convergence Protocol (PDCP) layer; obtaining the first MBS data from the PDCP layer at a first Radio Link Control (RLC) layer, and obtaining the second MBS data from the PDCP layer at a second RLC layer; obtaining the first MBS data from the first RLC layer and the second MBS data from the second RLC layer at the physical layer via a Media Access Control (MAC) layer; and transmitting the first MBS data and the second MBS data to the terminal via the physical layer, wherein a first bearer including the first RLC layer is configured as a unicast bearer, and a second bearer including the second RLC layer is configured as a multicast bearer.

[0014] Furthermore, in a terminal of a wireless communication system according to embodiments of the present disclosure, the terminal may include: a transceiver; and a controller configured to: establish a Radio Resource Control (RRC) connection with a base station; control the transceiver to: receive first multicast and broadcast service (MBS) data and second MBS data from the base station via a physical layer; transmit the first MBS data from the physical layer to a first radio link control (RLC) layer and the second MBS data to a second RLC layer via a media access control (MAC) layer, transmit the first MBS data from the first RLC layer to a packet data convergence protocol (PDCP) layer and the second MBS data from the second RLC layer to the PDCP layer; and transmit the first MBS data and the second MBS data from the PDCP layer to an upper layer, wherein a first bearer including the first RLC layer is configured as a unicast bearer, and a second bearer including the second RLC layer is configured as a multicast bearer.

[0015] Furthermore, in a base station of a wireless communication system according to embodiments of the present disclosure, the base station may include: a transceiver; and a controller configured to: establish a Radio Resource Control (RRC) connection with a terminal; obtain first multicast and broadcast service (MBS) data and second MBS data from an upper layer at a Packet Data Convergence Protocol (PDCP) layer; obtain the first MBS data from the PDCP layer at a first Radio Link Control (RLC) layer and the second MBS data from the PDCP layer at a second RLC layer; obtain the first MBS data from the first RLC layer and the second MBS data from the second RLC layer at the physical layer via a Media Access Control (MAC) layer; and control the transceiver to transmit the first MBS data and the second MBS data to the terminal via the physical layer, wherein a first bearer including the first RLC layer is configured as a unicast bearer, and a second bearer including the second RLC layer is configured as a multicast bearer.

[0016] Beneficial effects of the present invention

[0017] According to embodiments of this disclosure, this disclosure provides a structure or configuration method for a multicast or unicast bearer that supports MBS services and efficiently performs data processing by PHY layer devices, MAC layer devices, RLC layer devices, or PDCP layer devices that receive and process MBS data, so as to support MBS services in next-generation mobile communication systems.

[0018] Furthermore, according to embodiments of this disclosure, there is an effect that enables the signaling process or terminal to continue supporting MBS services in RRC connected mode, RRC idle mode, or RRC inactive mode, or when MBS services switch between modes.

[0019] Furthermore, according to embodiments of this disclosure, for MBS support, it may be feasible to reconfigure from a multicast bearer to (or switch to) a unicast bearer or from a unicast bearer to (or switch to) a multicast bearer, depending on the handover between base stations or networks supporting MBS services or the mobility of the terminal. Attached Figure Description

[0020] Figure 1 This is a diagram illustrating the structure of an LTE system to which this disclosure can be applied.

[0021] Figure 2 This is a diagram illustrating the wireless protocol structure that can be applied to the LTE system disclosed herein.

[0022] Figure 3 This is a diagram illustrating the structure of a next-generation mobile communication system to which this disclosure can be applied.

[0023] Figure 4 This is a diagram illustrating the wireless protocol structure of a next-generation mobile communication system to which this disclosure can be applied.

[0024] Figure 5 This diagram illustrates the process of providing services to terminals by efficiently using a very wide frequency bandwidth in the next-generation mobile communication system disclosed herein.

[0025] Figure 6 The figure illustrates the process of a terminal switching from RRC idle mode to RRC connected mode in the next-generation mobile communication system disclosed herein, and proposes a method for configuring multiple partial bandwidths (bandwidth portions, BWP) and configuring a default bandwidth (default BWP) or a first active bandwidth (first active BWP).

[0026] Figure 7 This diagram illustrates the structure of the bearer configured by the terminal for MBS service, or configured by the terminal for receiving MBS service, when the base station or network supports MBS service for the terminal in RRC connection mode, RRC deactivation mode, or RRC idle mode. This can be found in system information, RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined RRC message), or control messages of the MBS channel.

[0027] Figure 8This illustrates how a terminal in RRC connection mode, RRC deactivation mode, or RRC idle mode can use the method described in this disclosure. Figure 7 The figure shows a method for demultiplexing the received MBS data in the MAC layer device when the proposed bearer structure supports multicast or unicast bearers for MBS services to receive MBS data (e.g., MBS control data, MBS user data, or general data other than MBS data).

[0028] Figure 9 This illustrates how a terminal in RRC connection mode, RRC deactivation mode, or RRC idle mode can access the terminal through the interface described in this disclosure. Figure 7 The figure shows a method for multiplexing the MBS data to be transmitted in the MAC layer device when the proposed bearer structure supports multicast or unicast bearers for MBS service to transmit MBS data (e.g., MBS control data, MBS data when transmitting user data, or general data other than MBS data).

[0029] Figure 10 This is a diagram illustrating the first signaling process for MBS service support as proposed in this disclosure.

[0030] Figure 11 This is a diagram illustrating the second signaling process for MBS service support as proposed in this disclosure.

[0031] Figure 12 This is a diagram illustrating the third signaling process for MBS service support as proposed in this disclosure.

[0032] Figure 13 This is a diagram illustrating the fourth signaling process for MBS service support as proposed in this disclosure.

[0033] Figure 14 This is a diagram illustrating the operation of the terminal proposed in this disclosure.

[0034] Figure 15 This is a diagram illustrating the structure of a terminal to which embodiments of the present disclosure can be applied.

[0035] Figure 16 This is a diagram illustrating the block configuration of TRP in a wireless communication system to which embodiments of the present disclosure can be applied. Detailed Implementation

[0036] The operating principles of this disclosure will be described in detail below with reference to the accompanying drawings. In describing this disclosure below, detailed descriptions of known functions or configurations incorporated herein will be omitted where it is determined that the description might unnecessarily obscure the subject matter. The terminology described below is defined in consideration of the functions in this disclosure and may vary depending on the user, the user's intent, or habits. Therefore, the definitions of the terms should be based on the content throughout the specification.

[0037] In the following description of this disclosure, detailed descriptions of known functions or configurations incorporated herein will be omitted where it is determined that the description may unnecessarily obscure the subject matter of this disclosure. Hereinafter, embodiments of this disclosure will be described with reference to the accompanying drawings.

[0038] In the following description, for convenience, terms identifying access nodes, terms relating to network entities, terms relating to messages, terms relating to interfaces between network entities, terms relating to various identifying information, etc., are used illustratively. Therefore, this disclosure is not limited to the terms used below, and other terms relating to entities with equivalent technical meanings may be used.

[0039] In the following description, for convenience, the terms and names defined in the 3GPP LTE standard will be used to describe this disclosure. However, this disclosure is not limited to these terms and names and can be applied in the same manner to systems conforming to other standards. In this disclosure, the term "eNB" may be used interchangeably with the term "gNB". That is, a base station described as "eNB" may indicate "gNB".

[0040] Figure 1 This is a diagram illustrating the structure of an LTE system to which this disclosure can be applied.

[0041] refer to Figure 1 As shown, the radio access network of the LTE system includes next-generation base stations (Evolved Node B, hereinafter referred to as ENB, Node B, or base station) 1a-05, 1a-10, 1a-15, and 1a-20, Mobility Management Entity (MME) 1a-25, and Serving Gateway (S-GW) 1a-30. User terminals (User Equipment, hereinafter referred to as UE or terminal) 1a-35 can connect to external networks through ENB 1a-05 to 1a-20 and S-GW 1a-30.

[0042] exist Figure 1In this context, ENBs 1a-05 to 1a-20 correspond to existing Node Bs in the UMTS system. The ENB connects to terminal 1a-35 via a radio channel and performs more complex functions compared to existing Node Bs. In LTE systems, because all user services are served through a shared channel, including real-time services via Internet Protocol (IP) such as VoIP, a scheduling mechanism is needed that collects status information such as the terminal's buffer status, available transmission power status, and channel status. ENBs 1a-05 to 1a-20 are responsible for this. A single ENB typically controls multiple cells. For example, to achieve a transmission rate of 100 Mbps in a 20 MHz bandwidth, the LTE system uses, for instance, Orthogonal Frequency Division Multiplexing (hereinafter referred to as OFDM) as the radio access technology. Additionally, an Adaptive Modulation and Coding (hereinafter referred to as AMC) scheme is applied, which determines the modulation scheme and channel coding rate based on the terminal's channel status.

[0043] The S-GW 1a-30 is an apparatus that provides, generates, or removes data carriers under the control of the MME 1a-25. The MME is an apparatus responsible for various control functions and terminal mobility management functions, and is connected to multiple base stations.

[0044] Figure 2 This is a diagram illustrating the wireless protocol structure that can be applied in an LTE system according to this disclosure.

[0045] refer to Figure 2 The LTE system's wireless protocols include Packet Data Convergence Protocol (PDCP) 1b-05 and 1b-40, Radio Link Control (RLC) 1b-10 and 1b-35, and Media Access Control (MAC) 1b-15 and 1b-30. PDCP 1b-05 and 1b-40 are responsible for operations such as IP header compression / reconstruction. The main functions of PDCP are summarized below.

[0046] -Header compression and decompression: ROHC only

[0047] -Transmission of user data

[0048] - Sequential transfer of upper-layer PDUs during the PDCP reconfiguration process of RLC AM

[0049] - For split bearers in the DC (RLC AM only): PDCP PDU routing for transmission and PDCP PDU reordering for reception.

[0050] - Repeated detection of lower-layer SDUs during the PDCP reconfiguration process of RLC AM

[0051] - Retransmission of PDCP SDUs during handover, and for separate bearers in the DC, retransmission of PDCP PDUs during the PDCP data recovery process of the RLC AM.

[0052] - Encryption and decryption

[0053] -Timer-based SDU dropping in the uplink

[0054] The Radio Link Control (hereinafter referred to as RLC) 1b-10 and 1b-35 reconfigure PDCP Protocol Data Units (PDUs) to the appropriate size and perform ARQ operations, etc. The main functions of the RLC are summarized below.

[0055] -Transmission of upper-layer PDUs

[0056] - Error correction via ARQ (for AM data transmission only)

[0057] - Cascading, segmentation, and reassembly of RLC SDUs (for UM and AM data transmission only)

[0058] - Resegmentation of RLC data PDUs (for AM data transmission only)

[0059] - Reordering of RLC data PDUs (for UM and AM data transfer only)

[0060] - Duplicate detection (only for UM and AM data transfers)

[0061] - Protocol error detection (for AM data transmission only)

[0062] -RLC SDU discard (only for UM and AM data transfers)

[0063] -RLC Re-establishment

[0064] MAC 1b-15 and 1b-30 connect to several RLC layer devices configured in a terminal and perform operations such as multiplexing RLC PDUs into MAC PDUs and demultiplexing RLC PDUs from MAC PDUs. The main functions of the MAC are summarized below.

[0065] - Mapping between logical channels and transmission channels

[0066] - Multiplexing MAC SDUs belonging to one or different logical channels into a transport block (TB) / demultiplexing MAC SDUs belonging to one or different logical channels from a transport block (TB), which is then passed to the physical layer on the transport channel / from the physical layer.

[0067] - Scheduling Information Report

[0068] - Error correction via HARQ

[0069] Priority processing between logical channels of a UE

[0070] - Prioritize UEs through dynamic scheduling

[0071] -MBMS service identifier

[0072] -Transmission format selection

[0073] -filling

[0074] Physical layers 1b-20 and 1b-25 perform channel coding and modulation on upper-layer data, create OFDM symbols, and transmit them via wireless channels, or perform channel decoding on OFDM symbols received via wireless channels and transmit them to the upper layer.

[0075] Figure 3 This is a diagram illustrating the structure of a next-generation mobile communication system to which this disclosure can be applied.

[0076] refer to Figure 3 As shown, the radio access network of the next-generation mobile communication system (hereinafter, NR or 5G) includes the next-generation base station (new radio node B, hereinafter referred to as NR gNB or NR base station) 1c-10 and the new radio core network (NR CN) 1c-05. User equipment (new radio user equipment, hereinafter referred to as NR UE or terminal) 1c-15 accesses the external network through NR gNB 1c-10 and NR CN 1c-05.

[0077] exist Figure 3In this context, NR gNB 1c-10 corresponds to the Evolved Node B (eNB) of the existing LTE system. The NR gNB connects to NR terminal 1c-15 via a radio channel and can provide services superior to those of the existing Node B. In next-generation mobile communication systems, because all user services are served through a shared channel, a device is needed for scheduling by collecting state information such as the terminal's buffer state, available transmission power state, and channel state, and NR gNB 1c-10 is responsible for this. An NR gNB typically controls multiple cells. To achieve ultra-high-speed data transmission compared to current LTE, it can have bandwidth exceeding the current maximum bandwidth and can incorporate additional beamforming techniques by using Orthogonal Frequency Division Multiplexing (hereinafter referred to as OFDM) as the radio access technology. Additionally, an Adaptive Modulation and Coding (AMC) scheme is applied, which determines the modulation scheme and channel coding rate based on the terminal's channel state. NR CN 1c-05 performs functions such as mobility support, bearer settings, and QoS settings. The NR CN is responsible for various control functions and terminal mobility management functions and connects to multiple base stations. In addition, the next-generation mobile communication system can link with the existing LTE system, and the NR CN connects to the MME 1c-25 via a network interface. The MME connects to the existing base station eNB 1c-30.

[0078] Figure 4 This is a diagram illustrating the wireless protocol structure of a next-generation mobile communication system to which this disclosure can be applied.

[0079] refer to Figure 4 The wireless protocols of the next-generation mobile communication system include NR SDAP1d-01 and 1d-45, NR PDCP 1d-05 and 1d-40, NR RLC 1d-10 and 1d-35, and NR MAC 1d-15 and 1d-30 in the terminal and NR base station, respectively.

[0080] The main functions of NR SDAP 1d-01 and 1d-45 may include some of the following functions.

[0081] -Transmission of user plane data

[0082] - Mapping between QoS flows and DRB for both DL and UL

[0083] - Mark QoS flow IDs in both DL and UL packets.

[0084] - Reflective QoS flow mapping to DRB for UL SDAP PDU.

[0085] Regarding SDAP layer devices, the terminal can be configured with RRC messages to specify whether to use the SDAP layer device header for each PDCP layer device, each bearer, or each logical channel, or whether to use the functions of the SDAP layer device. When the SDAP header is set, the NAS QoS reflection configuration 1-bit indicator and AS QoS reflection configuration 1-bit indicator in the SDAP header can indicate to the terminal that it can update or reconfigure the mapping information between uplink and downlink QoS flows and data bearers. The SDAP header can include QoS flow ID information indicating QoS. QoS information can be used as data processing priority and scheduling information to support smooth service.

[0086] The main functions of NR PDCP 1d-05 and 1d-40 may include some of the following functions.

[0087] -Header compression and decompression: ROHC only

[0088] -Transmission of user data

[0089] - Sequential transmission of upper-layer PDUs

[0090] -Disordered transmission of upper-layer PDUs

[0091] - Reordering received PDCP PDUs

[0092] -Duplicate detection of lower-level SDUs

[0093] -PDCP SDU retransmission

[0094] - Encryption and decryption

[0095] -Timer-based SDU dropping in the uplink

[0096] In the above text, the reordering of the NR PDCP device refers to the function of reordering PDCP PDUs received from the lower layer in order based on the PDCP sequence number (SN). It may include the ability to pass data to the upper layer in the reordered order, or it may include the function of passing data directly without considering the order. It may include the function of reordering the order to record lost PDCP PDUs, the function of reporting the status of lost PDCP PDUs to the transmitting side, and the function of requesting retransmission of lost PDCP PDUs.

[0097] The main functions of NR RLC 1d-10 and 1d-35 may include some of the following functions.

[0098] -Transmission of upper-layer PDUs

[0099] - Sequential transmission of upper-layer PDUs

[0100] -Disordered transmission of upper-layer PDUs

[0101] - Error correction via ARQ

[0102] Cascading, segmentation, and reassembly of RLC SDUs

[0103] - Resegmentation of RLC data PDUs

[0104] - Reordering of RLC data PDUs

[0105] -Duplicate detection

[0106] -Protocol error detection

[0107] -RLC SDU discard

[0108] -RLC Re-establishment

[0109] In the above text, the sequential transmission of NR RLC devices refers to the function of sequentially transmitting RLC SDUs received from the lower layer to the upper layer. This may include the function of reassembling and transmitting when an RLC SDU is initially divided into several RLC SDUs and received; the function of rearranging received RLC PDUs based on RLC sequence number (SN) or PDCP sequence number (SN); the function of reordering to record lost RLC PDUs; the function of reporting the status of lost RLC PDUs to the transmitting side; the function of requesting retransmission of lost RLC PDUs; the function of sequentially transmitting only the RLC SDUs before the lost RLC SDU to the upper layer when a lost RLC SDU exists or when a predetermined timer expires even if a lost RLC SDU exists; the function of sequentially transmitting all RLC SDUs received before the timer starts or when a predetermined timer expires even if a lost RLC SDU exists; and the function of sequentially transmitting all RLC SDUs received up to this point to the upper layer. Additionally, RLC PDUs can be processed and delivered out of order to the PDCP device in the order they are received (arrival order, regardless of sequence number and order number), and in the case of fragments, fragments stored in the buffer or to be received later are received, reconstructed into a complete RLC PDU, processed, and delivered to the PDCP device. The NR RLC layer may not include cascading functionality, and this functionality can be performed in the NR MAC layer or replaced by multiplexing functionality of the NR MAC layer.

[0110] In the above text, the out-of-order transmission of NR RLC devices can refer to the function of transmitting RLC SDUs received from the lower layer to the upper layer regardless of the order. It can include the function of reassembling and transmitting RLC SDUs when an initial RLC SDU is divided into several RLC SDUs and received. It can also include the function of storing the RLC SN or PDCP SN of the received RLC PDUs, arranging the order, and recording the lost RLC PDUs.

[0111] NR MAC 1d-15 and 1d-30 can be connected to several NR RLC layer devices configured in a terminal, and the main functions of the NR MAC can include some of the following functions.

[0112] - Mapping between logical channels and transmission channels

[0113] - MAC SDU multiplexing / demultiplexing

[0114] - Scheduling Information Report

[0115] - Error correction via HARQ

[0116] Priority processing between logical channels of a UE

[0117] - Prioritize UEs through dynamic scheduling

[0118] -MBMS service identifier

[0119] -Transmission format selection

[0120] -filling

[0121] The NR PHY layers 1d-20 and 1d-25 can perform: channel coding and modulation of upper-layer data, generating OFDM symbols and transmitting them to the radio channel, or demodulating OFDM symbols received through the radio channel, decoding the channel and passing it to the upper layer.

[0122] Because next-generation mobile communication systems can use very high frequency bands, the frequency bandwidth can also be very wide. However, supporting all such wide bandwidths in terminal implementations requires high implementation complexity and incurs high costs. Therefore, in next-generation mobile communication systems, the concept of partial bandwidth (BWP) can be introduced. Multiple partial bandwidths (BWPs) can be configured in a single cell (Spcell or Scell), and data can be transmitted / received in one or more partial bandwidths according to instructions from the base station.

[0123] The key feature of this disclosure is that, when introducing the hibernation portion bandwidth proposed herein, it considers the state of the SCell and multiple portion bandwidths configured in the SCell, and proposes a state transition method or portion bandwidth switching method and specific operations. Furthermore, this disclosure proposes methods for managing hibernation modes on a portion bandwidth basis (at the BWP level) and for transitioning states or switching portion bandwidths, and proposes specific portion bandwidth operations that depend on the state of each SCell or the state or mode (active, deactivated, or hibernating) of each portion bandwidth.

[0124] Furthermore, this disclosure features the configuration of multiple partial bandwidths for each downlink or uplink in a cell (Spcell, Pcell, Pscell, or Scell), and the ability to configure and operate active partial bandwidths (active DL or UL BWP), dormant partial bandwidths (dormant BWP or dormant DL BWP), or inactive partial bandwidths (inactive or deactivated DL / UL BWP) by switching partial bandwidths. In other words, data transmission rates can be increased in methods similar to carrier aggregation, where downlink or uplink partial bandwidths are converted to active states for a single cell; battery life can be saved by preventing the terminal from performing PDCCH listening on the cell through conversion or switching of downlink partial bandwidths to dormant partial bandwidths; and activation of fast cells or partial bandwidths can be supported later by enabling the terminal to perform channel measurements on downlink partial bandwidths and report the channel measurement results. Moreover, battery life can be saved by converting downlink (or uplink) partial bandwidths to inactive states within a cell. As mentioned above, state transition indications or partial bandwidth switching indications for each cell can be configured and indicated through Radio Resource Control (RRC) messages, Media Access Control (MAC) control elements (CE), or Downlink Control Information (DCI) of the Physical Downlink Control Channel (PDCCH).

[0125] In this disclosure, partial bandwidth (BWP) can be used without distinguishing between uplink and downlink, whereby partial bandwidth (BWP) may refer to uplink partial bandwidth and downlink partial bandwidth respectively, depending on the context.

[0126] In this disclosure, a link may be used without distinguishing between uplink and downlink, and the link may refer to each of the uplink and downlink depending on the context.

[0127] In this disclosure, a dormant partial bandwidth (dormant BWP) can be configured or introduced for a terminal's SCell performing carrier aggregation technology. In the dormant partial bandwidth, PDCCH can be ignored to reduce battery consumption. Channel measurements (e.g., Channel State Information (CSI) or Channel Quality Information (CQI) measurements or reports) can be performed and reported, or beam measurements, beam tracking, or beam manipulation can be performed. When data transmission is required, the dormant partial bandwidth is switched or activated to a normal partial bandwidth (normal BWP), allowing for rapid data transmission initiation. As described above, the dormant partial bandwidth can be configured or applied not only for SpCells (PCells in MCGs or PCells (or PSCells) in SCGs) that require continuous signal monitoring, or for sending or receiving feedback, or for checking and maintaining synchronization, or for SCells with a configured PUCCH.

[0128] This disclosure proposes that the terminal's SCell operates based on DCI, MAC CE, or RRC messages of the PDCCH in order to run various embodiments of the hibernation portion bandwidth described above.

[0129] A network or base station can configure Spcells (Pcells and PScells) and multiple Scells for a terminal. As mentioned above, an Spcell can indicate the Pcell used when the terminal communicates with one base station, and can indicate the Pcell of the primary base station or the PScell ​​of the secondary base station when the terminal communicates with two base stations (a primary base station and a secondary base station). A Pcell or PScell ​​can indicate the primary cell used when the terminal and base station communicate in each MAC layer device, and can refer to the cell that adjusts timing to perform synchronization, performs random access, sends HARQ ACK / NACK feedback to the PUCCH transmission resources, and exchanges most control signals. The technique by which a base station increases transmission resources and uplink or downlink data transmission resources by operating multiple Scells together with Spcells is called carrier aggregation.

[0130] When configuring a Spcell and multiple SCells for a terminal via RRC messages, the state or mode of each SCell, or a portion of the bandwidth of each SCell, can be configured via RRC messages of the PDCCH, MACCE, or DCI. As described above, the state or mode of an Scell ​​can be configured as active mode, activated state, and deactivated mode or deactivated state. In the above description, an active mode or active state of an Scell ​​can mean that the terminal can exchange uplink or downlink data with the base station in a portion of the bandwidth other than the activated portion, activated normal portion, or activated dormant portion of the Scell ​​in active mode or active state; can listen to the PDCCH to check the base station's indication; can perform channel measurements on the downlink of an active mode or active state Scell ​​(or the activated portion, activated normal portion, or activated dormant portion of the Scell) and periodically report the measurement information to the base station; and periodically send pilot signals (sound reference signals, SRS) to the base station, enabling the terminal to measure the uplink channel through the base station.

[0131] However, SCell being in an inactive mode or inactive state can mean that: the terminal is in an inactive state of a portion of the bandwidth configured in the Scell, or the configured portion of the bandwidth is not activated, the terminal cannot send and receive data with the base station (because there is no active portion of the bandwidth in the configured portion), does not perform listening to the PDCCH to check the base station's instructions, does not perform channel measurements, does not perform measurement reports, and does not send pilot signals.

[0132] Therefore, to activate an Scell ​​in deactivated mode, the base station can first configure frequency measurement configuration information for the terminal using RRC messages, and the terminal can perform cell or frequency measurements based on the frequency measurement configuration information. Furthermore, the base station can activate the deactivated Scell ​​based on frequency / channel measurement information after receiving the terminal's cell or frequency measurement report. Due to this, a significant delay occurs at base stations that activate carrier aggregation technology for the terminal and begin data transmission or reception.

[0133] This disclosure proposes a sleep mode or sleep state for a portion of the bandwidth of each activated Scell ​​(activated SCell or active SCell), or proposes configuring or introducing a sleep bandwidth portion (BWP) for each activated SCell to save the terminal's battery and quickly start sending or receiving data.

[0134] The key feature is that, in the dormant portion bandwidth or dormant BWP of an activated SCell, or when the dormant portion bandwidth is activated, the terminal cannot exchange data with the base station, does not perform PDCCH listening to check the base station's instructions, or sends pilot signals. However, it performs channel measurements and reports the measured frequency / cell / channel measurement results periodically or when events occur according to the base station configuration. Therefore, because the terminal does not listen to the PDCCH and does not send pilot signals in the dormant BWP of an activated SCell, battery life is saved compared to the normal portion bandwidth (or non-dormant portion bandwidth) of an activated SCell or when the normal portion bandwidth (or non-dormant portion bandwidth) of an activated SCell is activated. Furthermore, since the terminal's channel measurement report differs from when the SCell is deactivated, the base station can quickly activate the normal portion bandwidth of the activated SCell based on the measurement report or the measurement report of the dormant portion bandwidth of the activated SCell, enabling rapid use of carrier aggregation technology and thereby reducing transmission latency.

[0135] Therefore, in this disclosure, "Scell ​​in active mode or active state" can mean that the terminal can exchange uplink or downlink data with the base station in the portion of the bandwidth other than the activated portion, activated normal portion, or activated dormant portion of the Scell ​​in active mode or an activated Scell; can listen to the PDCCH to check the base station's indication; can perform channel measurements on the downlink of the Scell ​​in active mode or active state (or the activated portion of the Scell's bandwidth, or the activated normal portion, or the activated dormant portion) and periodically report the measurement information to the base station; and can periodically send pilot signals (sound reference signals, SRS) to the base station so that the base station can measure the uplink channel. Furthermore, in this disclosure, when the Scell ​​is in active mode or active state, it means that the terminal cannot send or receive uplink or downlink data with the base station in the active dormant portion of the Scell ​​in active mode or an activated Scell. Alternatively, this means that instead of listening to the PDCCH to check the base station's instructions, channel measurements of the downlink for the active dormant portion of the bandwidth of the Scell ​​in active mode or active state can be performed, and the measurement information can be periodically reported to the base station.

[0136] Furthermore, in this disclosure, the term "dormant portion bandwidth" can indicate the state of a portion of bandwidth, or it can be used as a name for a logical concept indicating a specific portion of bandwidth. Therefore, the dormant portion bandwidth can be activated, deactivated, or switched. For example, an instruction to switch a second portion of bandwidth activated in a first SCell to dormant portion bandwidth, an instruction to convert a first SCell to dormant or sleep mode, or an instruction to activate the dormant portion bandwidth of a first SCell can be interpreted as having the same meaning.

[0137] Furthermore, in this disclosure, the general partial bandwidth can indicate a portion of the partial bandwidth configured in each SCell of the terminal that is not the dormant partial bandwidth as an RRC message. The terminal can exchange uplink or downlink data with the base station in the normal partial bandwidth, listen to the PDCCH to check the base station's indication, perform channel measurements for the downlink, periodically report measurement information to the base station, and periodically send pilot signals (Sound Reference Signals (SRS)) to the base station, enabling the base station to measure the uplink channel. Additionally, the normal partial bandwidth can indicate a first active partial bandwidth, a default partial bandwidth, or an initial partial bandwidth activated from dormancy.

[0138] Furthermore, of the portion of bandwidth configured in each Scell ​​of the terminal, only one sleep portion of bandwidth can be configured and can be used for the downlink. Alternatively, of the portion of bandwidth configured for each Scell ​​of the terminal, one sleep portion of bandwidth can be configured for either the uplink or the downlink.

[0139] Figure 5 This is a diagram illustrating the process of providing services to terminals by efficiently using a very wide frequency bandwidth in the next-generation mobile communication system disclosed herein.

[0140] Figure 5 This demonstrates how next-generation mobile communication systems can efficiently utilize very wide frequency bandwidths to provide services to terminals with different performance (capabilities or categories) while saving battery power.

[0141] A base station can provide a very wide frequency band, such as 1e-05, within a single cell. However, to provide services to terminals with different capabilities, the wide frequency band can be divided into multiple bandwidth segments and managed as a single cell.

[0142] First, the initially activated terminal can search the entire frequency band provided by the operator (PLMN) in units of resource blocks (e.g., 12 RBs). That is, the terminal can begin searching the entire system bandwidth for the Primary Synchronization Sequence (PSS) / Secondary Synchronization Sequence (SSS) in units of resource blocks 1e-10. If a signal is detected while searching for PSS / SSS 1e-01 or 1e-02 in units of resource blocks, the terminal can read and interpret (decode) the signal to determine the boundary between the subframe and the radio transmission resource frame (radio frame). Therefore, subframes can be segmented in 1ms increments, and synchronization between the base station and downlink signals can be matched. As described above, a resource block (RB) can be defined as a two-dimensional unit with a predetermined frequency resource and a predetermined time resource. For example, the time resource can be defined in 1ms increments, and as the frequency resource, 12 subcarriers (1 carrier x 15kHz = 180kHz) can be defined.

[0143] Upon completion of synchronization as described above, the terminal can check the Master System Information Block (MIB) or Minimum System Information (MSI) to examine the Control Resource Set (CORESEST) information, and can also check the Initial Access Bandwidth Part (BWP) information 1e-15 and 1e-20. In the above context, CORESEST information refers to the location of time / frequency transmission resources from the base station for transmitting control signals, and for example, indicates the resource location for transmitting the PDCCH channel. That is, CORESEST information can indicate the information for transmitting the first system information (System Information Block 1 (SIB1)) and can indicate in which frequency / time resources the PDCCH is transmitted. As described above, when the terminal reads the first system information, it can check information regarding the Initial Partial Bandwidth (Initial BWP). As stated above, when the terminal completes downlink signal synchronization with the base station and is able to receive control signals, the terminal can perform a random access procedure, request RRC connection configuration, and receive RRC messages to perform RRC connection configuration within the Initial Partial Bandwidth (Initial BWP) of the cell where the terminal is camped.

[0144] In RRC connection configuration, multiple partial bandwidths can be configured for each cell (Pcell, Pscell, Spcell, or Scell). Multiple partial bandwidths can be configured for the downlink within a cell, and multiple partial bandwidths can be configured separately for the uplink.

[0145] Multiple partial bandwidths can be indicated and configured via partial bandwidth identifiers (BWP identifiers) to be used as the initial BWP, default BWP, first active BWP, dormant BWP, or first active BWP from dormant.

[0146] As described above, the initial partial bandwidth (initial BWP) can be used as a cell-level determined partial bandwidth (cell-specific), with one for each cell. It can be used by terminals accessing the cell for the first time to configure a connection to the cell via a random access procedure, or by terminals performing synchronization during connection configuration. Furthermore, as described above, the base station can configure initial downlink partial bandwidth for each cell to be used in the downlink and initial uplink partial bandwidth to be used in the uplink. Additionally, the initial partial bandwidth configuration information can be broadcast in the first system information (SIB1) indicated by CORESET, and the base station can reconfigure the connection for the terminal using RRC messages. Furthermore, the initial partial bandwidth can be used by specifying the partial bandwidth identifier as 0 in both the uplink and downlink. That is, all terminals accessing the same cell can use the same initial partial bandwidth by specifying the partial bandwidth identifier as 0. This is because the base station can use the initial partial bandwidth that all terminals can read during the random access procedure to send a random access response (RAR) message, thus offering the advantage of facilitating contention-based random access procedures.

[0147] A first active partial bandwidth (first active BWP) can be configured differently for each terminal (UE-specific), and the first active partial bandwidth (first active BWP) among multiple partial bandwidths can be specified and indicated by a partial bandwidth identifier. The first active partial bandwidth can be configured separately for the downlink and uplink, and can be configured as a partial bandwidth identifier as the first active downlink partial bandwidth (first active downlink BWP) and the first active uplink partial bandwidth (first active uplink BWP), respectively. The first active partial bandwidth can be used to indicate which partial bandwidth is initially activated when multiple partial bandwidths are configured in a cell. For example, if a Pcell, Pscell, or Scell ​​is activated when a Pcell or Pscell and multiple Scells are configured in the terminal, and multiple partial bandwidths are configured in each of the Pcell, Pscell, or Scell, the terminal can activate and use the first active BWP among the multiple partial bandwidths configured in the Pcell, Pscell, or Scell. In other words, for the downlink, the first active downlink portion of bandwidth (first active downlink BWP) can be activated and used, and for the uplink, the first active uplink portion of bandwidth (first active uplink BWP) can be activated and used.

[0148] As described above, when the Scell ​​or a portion of the bandwidth is in a deactivated state and an instruction to activate it is received via RRC message, MAC control information, or DCI, the terminal can perform the following operations: switch the currently active downlink portion of the Scell ​​and activate it as the first active downlink portion of the bandwidth (or the portion of bandwidth configured or indicated via RRC message), or switch the currently active uplink portion of the bandwidth and activate it as the first active uplink portion of the bandwidth (or the portion of bandwidth configured or indicated via RRC message). Furthermore, this operation can be performed when an instruction to put the Scell ​​or a portion of the bandwidth into a dormant state is received via RRC message, MAC control information, or DCI. Because even when Scell ​​or a portion of the bandwidth is activated, the terminal switches the currently active downlink portion of the bandwidth and activates it using the first active downlink portion of the bandwidth (or the portion of the bandwidth configured or indicated by an RRC message), or switches the uplink portion of the bandwidth to activate it using the first active uplink portion of the bandwidth (or the portion of the bandwidth configured or indicated by an RRC message), and because even when performing channel measurement reporting in a dormant state, the base station can effectively use carrier aggregation technology only when measuring and reporting frequencies / channels for the first active downlink or uplink portion of the bandwidth.

[0149] As described above, a default partial bandwidth (default BWP) (UE-specific) can be configured differently for each terminal, and this default partial bandwidth (default BWP) can be indicated among multiple partial bandwidths using a partial bandwidth identifier. A default partial bandwidth can be configured only for downlink. The default partial bandwidth can be used as the partial bandwidth to which an active partial bandwidth among multiple downlink partial bandwidths will fall back after a predetermined time. For example, a partial bandwidth inactivity timer (bwp inactivity timer) can be configured for each cell or partial bandwidth using RRC messages. This timer can be started or restarted when data transmission / reception occurs in an active partial bandwidth other than the default partial bandwidth, or when the active partial bandwidth is switched to another partial bandwidth.

[0150] When the timer expires, the terminal can either roll back the activated downlink portion of bandwidth in the cell or switch to the default bandwidth. In the above context, "handover" can refer to the process of deactivating a currently activated portion of bandwidth and activating a portion of bandwidth indicated by the handover signal. This handover can be triggered by RRC messages, MAC control elements, or L1 signaling (Downlink Control Information (DCI) of the PDCCH). Furthermore, the handover can be triggered by indicating the portion of bandwidth to be switched or activated, and this portion of bandwidth can be indicated by a portion bandwidth identifier (e.g., 0, 1, 2, 3, or 4).

[0151] The rationale for using the default partial bandwidth only for downlink is that the base station facilitates base station scheduling by allowing terminals to fall back to the default partial bandwidth and receive instructions from the base station (e.g., DCI of the PDCCH) for each cell after a certain period of time has elapsed. For example, when a base station configures the default partial bandwidth for a terminal accessing a cell as the initial partial bandwidth, the base station can continue executing scheduling instructions only within the initial partial bandwidth after a predetermined time. If the default partial bandwidth is not configured in the RRC message, the initial partial bandwidth can be considered the default partial bandwidth and fall back to the initial partial bandwidth when the partial bandwidth deactivation timer expires.

[0152] As an alternative approach, to increase the implementation flexibility of the base station, a default portion of the uplink bandwidth can be defined and configured, similar to the default portion of the downlink bandwidth, so that it can be used like the default portion of the downlink bandwidth.

[0153] In the foregoing, the characteristic is that the dormant partial bandwidth (dormant BWP) means the partial bandwidth of the dormant mode of the activated SCell or the dormant partial bandwidth (dormant BWP in the activated SCell), or when the dormant partial bandwidth is activated, the terminal cannot send and receive data with the base station, or perform listening to the PDCCH to check the base station's instructions, or send pilot signals, but performs channel measurements and periodically or when events occur according to the base station configuration report the measured frequency / cell / channel measurement results.

[0154] Therefore, because the terminal does not listen to the PDCCH or transmit pilot signals in the dormant BWP of the activated SCell, battery power is saved compared to the normal portion of the bandwidth of the activated SCell (or the portion of the bandwidth other than the dormant portion) or when the normal portion of the bandwidth of the activated SCell (or the portion of the bandwidth other than the dormant portion) is activated. Furthermore, since the execution of channel measurement reports differs from when the SCell is deactivated, the base station can quickly activate the normal portion of the activated SCell's bandwidth based on the measurement report or based on the measurement report of the dormant portion of the activated SCell. Thus, transmission latency can be reduced by allowing the rapid use of carrier aggregation technology.

[0155] The first active portion bandwidth (or the first active non-dormant portion bandwidth or the portion bandwidth configured or indicated by the RRC message) activated by switching from a dormant state or dormant portion bandwidth can be the portion bandwidth activated by switching the currently active portion bandwidth of a SCell activated by the terminal according to the corresponding indication, or the portion bandwidth activated from a dormant state configured in the RRC message in the following cases: when the terminal operates the portion bandwidth of an active SCell as a dormant portion bandwidth; when the active portion bandwidth in an active SCell is a dormant portion bandwidth; or when the SCell is switched to a dormant portion bandwidth, the terminal instructs the base station to switch the portion bandwidth of the SCell activated by the DCI or MAC CE or RRC message of the PDCCH from the dormant portion bandwidth to the normal portion bandwidth (or the portion bandwidth other than the dormant portion bandwidth); or the terminal instructs to switch or switch the active portion bandwidth to the normal portion bandwidth in the dormant portion bandwidth; or the terminal instructs to switch or switch or activate the active portion bandwidth in the dormant portion bandwidth to the normal portion bandwidth (e.g., the first active portion bandwidth activated from dormancy).

[0156] Figure 6 The diagram illustrates the process by which a terminal switches from RRC idle mode to RRC connected mode in the next-generation mobile communication system disclosed herein, and proposes a method for configuring multiple partial bandwidths (bandwidth portions, BWP) and configuring a default bandwidth (default BWP) or a first active bandwidth (first active BWP).

[0157] A base station can provide a very wide frequency band within a single cell. First, the terminal can search the entire frequency band provided by the operator (PLMN) in units of resource blocks (e.g., 12 RBs). That is, the terminal can begin searching for the Primary Synchronization Sequence (PSS) / Secondary Synchronization Sequence (SSS) in resource blocks across the entire system bandwidth. If a signal is detected while searching the PSS / SSS in resource blocks, the signal can be read and interpreted (decoded) to determine the boundary between subframes and radio transmission resource frames.

[0158] As described above, upon completion of synchronization, the terminal can read the system information of the currently camped cell. Specifically, the terminal can check the Master System Information Block (MIB) or Minimum System Information (MSI) to examine the Control Resource Set (CORESEST) information, and read the system information to check the Initial Partial Bandwidth (BWP) information (1f-01, 1f-05). In this context, CORESEST information refers to the location of time / frequency transmission resources from the base station for transmitting control signals, and for example, indicates the location of resources for transmitting the PDCCH channel.

[0159] As described above, when the terminal completes the synchronization of the downlink signal with the base station and can receive control signals, the terminal can perform a random access procedure in the initial partial bandwidth, receive a random access response, request RRC connection configuration, and receive RRC messages to perform RRC connection configuration (1f-10, 1f-15, 1f-20, 1f-25, 1f-30).

[0160] When the default RRC connection configuration is completed as described above, the base station can send an RRC message (UECapabilityEnquiry, 1f-35) to query the terminal's capabilities in order to check the terminal's capabilities (UE capabilities). Alternatively, the base station can query the MME or AMF to check the terminal's capabilities. This is because the MME or AMF may have already stored the terminal's capability information when the terminal has previously connected. When the terminal capability information that the base station expects is not available, the base station can request the terminal capability information from the terminal.

[0161] The reason a base station sends an RRC message to a terminal to check the terminal's performance is because it can check the terminal's capabilities. For example, it can check which frequency bands or regions of those bands the terminal can read. After checking the terminal's performance, it can configure an appropriate Partial Bandwidth (BWP) for the terminal. When the terminal receives an RRC message inquiring about its capabilities, in response, the terminal can indicate the range of bandwidth it supports or the range of bandwidth supported by the current system bandwidth as an offset from the reference center frequency, or directly indicate the start and end points of the supported frequency bandwidth, or it can indicate the center frequency and bandwidth (1f-40).

[0162] As described above, partial bandwidth can be configured using the RRCSetup, RRCResume (1f-25), or RRCReconfiguration (1f-45) messages established during RRC connection setup. RRC messages can include configuration information for PCell, Pscell, or multiple Scells, and multiple partial bandwidths can be configured for each cell (PCell, Pscell, or Scell). When configuring multiple partial bandwidths for each cell, multiple partial bandwidths will be set for use in the downlink of each cell. In the case of FDD systems, multiple partial bandwidths will be configured separately from the downlink partial bandwidths for use in the uplink of each cell. In the case of TDD systems, multiple partial bandwidths will be set for shared use in both the downlink and uplink of each cell.

[0163] Information used to configure a portion of the bandwidth for each cell (PCell, Pscell, or Scell) may include some of the following information.

[0164] - Downlink bandwidth configuration information for the cell

[0165] ■ Initial Downlink Bandwidth Configuration Information (Initial Downlink BWP)

[0166] ■ Multiple bandwidth configuration information and the corresponding Bandwidth Part Identifier (BWP ID) for each bandwidth part.

[0167] ■ Initial state configuration information of the downlink bandwidth of the cell (e.g., active, dormant, or inactive state).

[0168] ■ Partial bandwidth identifier indicating the first active downlink portion of bandwidth (first active downlink BWP)

[0169] ■ Partial bandwidth identifier indicating the default partial bandwidth (default BWP)

[0170] ■ Configuration information for PDCCH monitoring for each bandwidth segment. This includes, for example, CORESET information, search space resource information, or PDCCH transmission resources, period, subframe number information, etc.

[0171] ■ A 1-bit indicator that indicates the dormant portion bandwidth or indicates the dormant portion bandwidth for each portion bandwidth in the portion bandwidth configuration information.

[0172] ■ A partial bandwidth identifier indicating the first active portion of bandwidth activated from hibernation, or a 1-bit indicator in the partial bandwidth configuration information indicating the first active portion of bandwidth activated from hibernation for each portion of bandwidth.

[0173] ■Disable timer configuration and timer values ​​for partial bandwidth usage

[0174] - Uplink bandwidth configuration information for the cell

[0175] ■ Initial Uplink Bandwidth Configuration Information (Initial Uplink BWP)

[0176] ■ Multiple bandwidth configuration information and the corresponding Bandwidth Part Identifier (BWP ID) for each bandwidth part.

[0177] ■ Initial state configuration information of the downlink bandwidth of the cell (e.g., active, dormant, or inactive state).

[0178] ■ A 1-bit indicator that indicates the dormant portion bandwidth, or indicates the dormant portion bandwidth for each portion bandwidth in the portion bandwidth configuration information.

[0179] ■ Partial bandwidth identifier indicating the first active uplink portion of bandwidth (first active uplink BWP)

[0180] The configured initial partial bandwidth (initial BWP), default partial bandwidth (default BWP), or first active partial bandwidth (first active BWP) can be used for the following purposes and can be operated as follows according to the purpose.

[0181] As described above, the initial partial bandwidth (initial BWP) can be used as a cell-level determined partial bandwidth (cell-specific), with one for each cell. It can be used as the partial bandwidth for terminals accessing the cell for the first time to configure a connection to the cell via a random access procedure, or for terminals already configured with a connection to perform synchronization. Furthermore, as described above, the base station can configure initial downlink partial bandwidth (initial downlink BWP) for use in the downlink and initial uplink partial bandwidth for use in the uplink for each cell. Additionally, the initial partial bandwidth configuration information can be broadcast in the first system information (System Information 1, SIB1) indicated by CORESET, and the base station can reconfigure the connection for terminals accessing it using RRC messages. Furthermore, the initial partial bandwidth can be used by specifying the partial bandwidth identifier as 0 in both the uplink and downlink. That is, all terminals accessing the same cell can use the same initial partial bandwidth by specifying the same partial bandwidth identifier 0. This is because the base station can use the initial partial bandwidth that all terminals can read when performing the random access procedure to send a random access response (RAR) message, thus offering the advantage of facilitating contention-based random access procedures.

[0182] As described above, a first active partial bandwidth (first active BWP) can be configured differently for each terminal (UE-specific), and this first active partial bandwidth can be indicated among multiple partial bandwidths by specifying a partial bandwidth identifier. The first active partial bandwidth can be configured separately for the downlink and uplink, and can be configured as a partial bandwidth identifier as the first active downlink partial bandwidth (first active downlink BWP) and the first active uplink partial bandwidth (first active uplink BWP), respectively. The first active partial bandwidth can be used to indicate which partial bandwidth is initially activated and used when multiple partial bandwidths are configured in a cell. For example, when a terminal is configured with a Pcell or Pscell and multiple Scells, and multiple partial bandwidths are configured for each Pcell, Pscell, or Scell, if the Pcell, Pscell, or Scell ​​is activated, the terminal can activate and use the first active BWP among the multiple partial bandwidths configured in the Pcell, Pscell, or Scell. In other words, the first active downlink portion of bandwidth (first active downlink BWP) can be activated and used for the downlink, and the first active uplink portion of bandwidth (first active uplink BWP) can be activated and used for the uplink.

[0183] When an instruction is given to activate a portion of the bandwidth of an inactive or dormant Scell, or an activated Scell, or when an instruction is received via an RRC message, MAC control information, or DCI message from the PDCCH to switch from a deactivated or dormant portion of bandwidth to a normal portion of bandwidth, the terminal can perform the following operations: The terminal switches the currently active downlink portion of the Scell ​​and activates it with a first active downlink portion of bandwidth (or a portion of bandwidth configured or indicated via an RRC message), or switches the currently active uplink portion of bandwidth to activate a first active uplink portion of bandwidth (or a portion of bandwidth configured or indicated via an RRC message). Additionally, when the terminal receives an instruction via an RRC message, MAC control information, or DCI message from the PDCCH to convert an activated Scell ​​or portion of bandwidth to a dormant state, or to switch to or activate a dormant portion of bandwidth, it can switch or activate that portion of bandwidth as a dormant portion of bandwidth, or put that portion of bandwidth into dormancy.

[0184] In the foregoing, switching to dormant or dormant partial bandwidth, or activating dormant partial bandwidth, can mean performing the operations described in this disclosure during the dormant state. That is, the operation of measuring the channel's downlink partial bandwidth (or dormant partial bandwidth) and reporting it to the base station can be performed without performing PDCCH monitoring. In another approach, similarly, when the active Scell ​​or partial bandwidth is activated or switched to normal partial bandwidth, because the downlink partial bandwidth will be switched to be activated as the first active downlink partial bandwidth, and the uplink partial bandwidth will be switched to be activated as the first active uplink partial bandwidth, the dormant partial bandwidth can be configured as the first active downlink bandwidth, the uplink partial bandwidth, or the default partial bandwidth.

[0185] As described above, a default partial bandwidth (default BWP) (UE-specific) can be configured differently for each terminal, and this default partial bandwidth can be indicated among multiple partial bandwidths by specifying a partial bandwidth identifier. A default partial bandwidth can be configured only for downlink. The default partial bandwidth can be used as the partial bandwidth to which an active partial bandwidth among multiple downlink partial bandwidths will fall back after a predetermined time. For example, a partial bandwidth inactivity timer (BWP inactivity timer) can be configured for each cell or partial bandwidth using RRC messages. This timer can be started or restarted when data transmission / reception occurs in an active partial bandwidth other than the default partial bandwidth, or when an active partial bandwidth is switched to another partial bandwidth.

[0186] When the timer expires, the terminal can either roll back the activated downlink portion of bandwidth in the cell or switch to the default bandwidth. In the above context, "handover" can refer to the process of deactivating a currently activated portion of bandwidth and activating a portion of bandwidth indicated by the handover signal. This handover can be triggered by RRC messages, MAC control elements, or L1 signaling (Downlink Control Information (DCI) of the PDCCH). Furthermore, the handover can be triggered by indicating the portion of bandwidth to be switched or activated, and this portion of bandwidth can be indicated by a portion bandwidth identifier (e.g., 0, 1, 2, 3, or 4).

[0187] The rationale for using the default partial bandwidth only for downlink is that the base station can facilitate scheduling by allowing terminals to fall back to the default partial bandwidth for each cell after a certain period of time and receive instructions from the base station (e.g., DCI of PDCCH). For example, when a base station configures the default partial bandwidth for a terminal accessing a cell as the initial partial bandwidth, the base station can continue executing scheduling instructions only within the initial partial bandwidth after a predetermined time. When the default partial bandwidth is not configured in the RRC message, the initial partial bandwidth can be considered the default partial bandwidth and fall back to the initial partial bandwidth when the partial bandwidth deactivation timer expires.

[0188] As an alternative approach, to increase the implementation flexibility of the base station, a default portion of the uplink bandwidth can be defined and configured to be used in the same way as the default portion of the downlink bandwidth.

[0189] In the above text, the dormant portion bandwidth (dormant BWP) can refer to a portion of the bandwidth in a dormant mode within an activated SCell, or a dormant portion bandwidth (a dormant BWP within an activated SCell). It can be characterized in that, when the dormant portion bandwidth is activated, the terminal cannot send or receive data with the base station, does not perform PDCCH listening for base station instructions, or transmit pilot signals, but performs channel measurements and periodically or when events occur according to base station configuration. Therefore, since the terminal does not listen to the PDCCH and does not transmit pilot signals in the dormant BWP of an activated SCell, battery life can be saved compared to the normal portion bandwidth of an activated SCell (or a portion of the bandwidth that is not dormant) or when the normal portion bandwidth of an activated SCell (or a portion of the bandwidth that is not dormant) is activated. Furthermore, since the channel measurement reporting is performed differently than when the SCell is deactivated, the base station can quickly activate the normal portion bandwidth of an activated SCell based on the measurement report or the measurement report of the dormant portion bandwidth of an activated SCell, enabling rapid use of carrier aggregation technology, thereby reducing transmission latency.

[0190] In the above context, when a portion of the bandwidth of an active SCell of a terminal is used as a dormant portion bandwidth, when the active portion bandwidth in an active SCell is a dormant portion bandwidth, or when a SCell is switched to a dormant portion bandwidth, in which case the terminal uses the DCI, MAC CE, or RRC message of the PDCCH to instruct the base station to switch the portion of the active SCell's bandwidth from the dormant portion bandwidth to the normal portion bandwidth (or a portion of the bandwidth other than the dormant portion bandwidth), the terminal instructs to perform a switch or switch the active portion bandwidth from the dormant portion bandwidth to the normal portion bandwidth, or the terminal instructs to perform a switch or switch or activate the active portion bandwidth in the dormant portion bandwidth to the normal portion bandwidth (e.g., the first active portion bandwidth activated from dormancy), the first active portion bandwidth activated from dormancy (or the first active non-dormant portion bandwidth) can be the first active portion bandwidth activated from dormancy configured in the RRC message. The terminal needs to switch or activate the portion bandwidth of the active SCell according to the above instructions.

[0191] In this disclosure, switching the first portion of bandwidth to the second portion of bandwidth can be interpreted as activating the second portion of bandwidth, or as deactivating the activated first portion of bandwidth and activating the second portion of bandwidth.

[0192] Furthermore, state transition timers can be configured in the RRCSetup, RRCResume (1f-25), or RRCReconfiguration (1f-45) messages configured for RRC connection configuration. This allows the terminal to perform state transitions itself even if it does not receive an indication from the base station's PDCCH via RRC messages, MAC control information, or DCI. For example, a cell deactivation timer (ScellDeactivationTimer) can be configured for each Scell, and the Scell ​​can transition to a deactivated state when the cell deactivation timer expires. Alternatively, by configuring a downlink (or uplink) portion bandwidth hibernation timer (DLBWPHibernationTimer or ULBWPHibernationTimer) for each SCell or for each portion of bandwidth of each SCell, and by configuring a cell hibernation timer (ScellHibernationTimer) for each Scell, the Scell ​​or downlink (or uplink) portion bandwidth can transition to a hibernation state or switch to hibernation portion bandwidth when the cell hibernation timer or downlink (or uplink) portion bandwidth hibernation timer expires. For example, it may be characterized in that when the cell sleep timer or the downlink (or uplink) portion bandwidth sleep timer expires, the active Scell ​​or downlink (or uplink) portion bandwidth is converted to a sleep state or switched to a sleep portion bandwidth, and the inactive or sleep Scell ​​or downlink (or uplink) portion bandwidth is not converted to a sleep state or a sleep portion bandwidth.

[0193] Additionally, a partial bandwidth dormancy timer can be started when a handover or activation instruction for a portion of the bandwidth is received via an RRC message from the PDCCH, MAC CE, or DCI; or it can be stopped when a handover instruction to the dormant portion of the bandwidth, a handover instruction to dormancy, or an activation instruction for the dormant portion of the bandwidth is received via an RRC message from the PDCCH, MAC CE, or DCI. Furthermore, by configuring a dormant cell deactivation timer (dormantScellDeactivationTimer) or a dormant state or downlink (or uplink) dormant portion bandwidth deactivation timer (dormantDLDeactivationTimer dormantULDeactivationTimer) for each Scell ​​or downlink (or uplink) portion of the bandwidth, an Scell ​​in the dormant state or downlink (or uplink) dormant portion of the bandwidth can be converted to an inactive state. Its characteristic is that when the deactivation timer for a dormant cell or the deactivation timer for a dormant portion of the downlink (or uplink) bandwidth expires and the Scell ​​or downlink (or uplink) bandwidth in an active or inactive state has not been converted to an inactive state, only the dormant Scell ​​or the dormant portion of the downlink (or uplink) bandwidth is converted to an inactive state. Additionally, the dormant portion bandwidth dormant timer can be started when an instruction to switch the dormant portion bandwidth or activate the dormant portion bandwidth is received via an RRC message from PDCC H, or via DCI, or via MACCE; or it can be stopped when an instruction to deactivate or activate a portion of the bandwidth or SCell, or to activate a normal portion of the bandwidth (e.g., a portion of the bandwidth other than the dormant portion bandwidth configured via RRC), is received via an RRC message from PDCCH, or via MAC CE, or via DCI.

[0194] Its key feature is that when both the cell deactivation timer (ScellDeactivationTimer) (or downlink (or uplink) partial bandwidth hibernation timer) and the cell hibernation timer (ScellHibernationTimer) (or downlink (or uplink) partial bandwidth deactivation timer) are configured, the cell hibernation timer (ScellHibernationTimer) (or downlink (or uplink) partial bandwidth hibernation timer) is prioritized. In other words, when the cell hibernation timer (ScellHibernationTimer) (or downlink (or uplink) partial bandwidth hibernation timer) is set, even if the cell deactivation timer (ScellDeactivationTimer) (or downlink (or uplink) partial bandwidth hibernation timer) expires, the corresponding Scell ​​or downlink (or uplink) partial bandwidth will not be deactivated. In other words, its characteristic lies in the fact that when a cell sleep timer (or a downlink (or uplink) portion bandwidth sleep timer) is configured, the Scell ​​or downlink (or uplink) portion bandwidth first transitions from an active state to a sleep state or switches to a sleep portion bandwidth due to the expiration of the timer. Furthermore, cells or portions of bandwidth that have transitioned to a sleep state due to the expiration of the sleep state cell or portion bandwidth deactivation timer gradually transition back to an inactive state. Therefore, when a cell sleep timer or a portion bandwidth sleep timer is configured, the cell deactivation timer or the sleep portion bandwidth deactivation timer does not affect the state transition of the Scell ​​or downlink (or uplink) portion bandwidth, and even if the cell deactivation timer or the sleep portion bandwidth deactivation timer expires, if the cell sleep timer or the portion bandwidth sleep timer is configured, the Scell ​​or downlink (or uplink) portion bandwidth does not immediately transition to an inactive state.

[0195] When the cell deactivation timer (or downlink (or uplink) partial bandwidth sleep timer) is not configured in the RRC message, the terminal may consider that the cell deactivation timer (or downlink (or uplink) partial bandwidth sleep timer) is configured to an infinite value.

[0196] Furthermore, frequency measurement configuration information and frequency measurement interval configuration information can be configured in the RRCSetup message, RRCResume message (1f-25), or RRCReconfiguration message (1f-45) for establishing an RRC connection, and frequency measurement object information can be included. Additionally, functions (power-saving modes) for reducing terminal power consumption can be configured in the aforementioned RRCSetup message, RRCResume message (1f-25), or RRCResetting message (1f-45) for establishing an RRC connection. These functions can be used to configure configuration information or timing information such as discontinuous reception (DRX) cycle intervals or offsets, or on-duration intervals, or timing information regarding when to listen to or detect the PDCCH from the base station before the on-duration interval (the interval in which the terminal needs to listen to the PDCCH) within the DRX cycle interval, or short time period information, to reduce power consumption.

[0197] When the functions for reducing terminal power consumption are configured as described above, the terminal can configure the DRX cycle interval, detect the Wake-Up Signal (WUS) signal during the interval configured to listen to the base station's PDCCH before the aforementioned on-duration interval, and use the DCI of the PDCCH of the WUS signal to instruct the terminal to skip (or not perform) or perform PDCCH listening in the immediately following on-duration period. Although the terminal should listen to the PDCCH continuously during the on-duration period, the WUS signal as described above allows the base station to instruct the terminal not to listen to the PDCCH during the on-duration period to save the terminal's battery consumption.

[0198] Once the RRC connection configuration is completed as described above, the terminal can configure multiple partial bandwidths according to the instructions configured in the RRC message. Furthermore, to conserve battery power, one or a small portion of the configured partial bandwidths can be activated. For example, a partial bandwidth to be activated can be indicated. Additionally, the base station can use RRC messages or MAC control information (MAC CE) or L1 signaling (PHY layer control signals such as DCI of PDCCH, etc.) to indicate the activation of the partial bandwidth to switch from the initial access partial bandwidth to the new partial bandwidth.

[0199] As an alternative approach, new bitmap information can be defined in the DCI of the PDCCH to indicate whether it is active, dormant, or deactivated. Alternatively, the bitmap can indicate whether to activate the normal portion of the bandwidth (e.g., the first active portion of the bandwidth activated from dormancy), activate the dormant portion of the bandwidth, switch to the dormant portion of the bandwidth, or perform a portion bandwidth switch. Because many other newly accessed users can exist in the initial access portion of the bandwidth, it may be more advantageous from a scheduling perspective to allocate new portion bandwidth and manage connected users individually. This is because the initial access portion of the bandwidth is not configured for each terminal, but can be shared and used by all terminals. Furthermore, to reduce signaling overhead, the default portion of the bandwidth can be dynamically indicated via MAC control information, L1 signaling, or system information.

[0200] In this disclosure, when a base station or network supports MBS services for a terminal, it can configure bearer configuration information or transmission resource information (e.g., time or frequency resources, bandwidth, frequency, partial bandwidth (or partial bandwidth identifier), subcarrier spacing, transmission resource period, RNTI identifier for each MBS service, or logical channel identifier for each MBS service) for the terminal in system information, RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined RRC message) or control messages for the MBS channel. Alternatively, the bearer configuration information for MBS services can be retained and designated as the default configuration. In the above context, from the perspective of the base station or terminal, the bearer for MBS services can be considered as a multicast bearer or a unicast bearer. In another approach, in system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRC Release, or a newly defined RRC message) or control messages for the MBS channel, a separate identifier or indicator can be configured to distinguish and configure the terminal for a multicast bearer or a unicast bearer for MBS services.

[0201] The bearer, multicast bearer, or unicast bearer described in this disclosure for MBS services can be interpreted as a multicast bearer or a unicast bearer.

[0202] The downlink shared channel (DL-SCH) described in this disclosure may include or indicate a common control channel (CCCH), a dedicated control channel (DCCH), or a dedicated traffic channel (DTCH).

[0203] In this disclosure, the term "bearer" can refer to both SRB and DRB, where SRB stands for Signaling Radio Bearer and DRB stands for Data Radio Bearer. SRBs are primarily used for sending and receiving RRC messages from RRC layer devices, while DRBs are primarily used for sending and receiving user layer data. Furthermore, UM DRB refers to a DRB using RLC layer devices operating in Negative Acknowledgment Mode (UM), while AM ​​DRB refers to a DRB using RLC layer devices operating in Acknowledgment Mode (AM).

[0204] The MBS data for the MBS service described in this disclosure can be interpreted as MBS channel configuration information, bearer configuration, or MBS control data for service configuration, or MBS user data supporting the MBS service.

[0205] The Radio Network Temporary Identifier (RNTI) described in this disclosure is an identifier used by a terminal to: listen to the Physical Downlink Control Channel (PDCCH) in a PHY layer device, descramble or check the Cyclic Redundancy Check (CRC) of the received PDCCH, determine whether it is an RNTI value configured in the terminal or an RNTI value corresponding to the PDCCH that the terminal intends to receive, and determine whether the terminal is the PDCCH to be read.

[0206] Figure 7 This diagram illustrates the structure of the bearer configured by the terminal for MBS services, or configured by the terminal for receiving MBS services, when the base station or network supports MBS services in RRC connected mode, RRC deactivated mode, or RRC idle mode. This can be found in system information, RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined RRC message), or control messages of the MBS channel. Furthermore, even when supporting general data services, this can be extended and applied or configured in... Figure 7 The load-bearing structure proposed in [the document / article].

[0207] exist Figure 7 In this context, the bearer structure configured for MBS services can have one or more of the following bearer structures. Alternatively, regarding the configuration information of the bearer used for MBS services, one or more of the following bearer structures can be determined or specified as the default configuration. Furthermore, the following bearer structures can be configured or applied to terminals or base stations.

[0208] - First Bearer Structure (1g-01): If the unicast or multicast bearer used for MBS services is configured with Figure 7The first bearer structure (1g-01) shown allows the terminal to configure a bearer structure used for directly connecting MAC layer devices to upper-layer MBS application layer devices as a bearer for MBS services. In the first bearer structure, HARQ ACK or NACK transmissions, HARQ retransmission processes, or HARQ processing by the MAC layer device may not be applied to the first bearer structure. Alternatively, in the first bearer structure, the terminal may transmit MBS data (MBS control data or MBS user data) received through the PHY layer device or MAC layer device to the upper-layer MBS application layer device. In the first bearer structure, MBS data may not include a MAC header. For example, this is because if a separate physical channel or transport channel is configured for MBS services and separate transmission resources (frequency or time resources or transmission period) are configured, the MAC layer device can distinguish MBS data even without a MAC header. In another approach, for example, this is because, when a separate physical channel or transport channel is configured for MBS service and separate transport resources (frequency or time resources, or transport period) are configured, if a first RNTI for MBS data is allocated or determined, MBS data can be distinguished even if a MAC header is not present in the PHY layer or MAC layer. As stated above, the RNTI for MBS data can be assigned or specified as a 1-1 RNTI for MBS control data (or the MBS control data channel) or a 1-2 RNTI for MBS user data (or the MBS user data channel). In the first bearer structure, the MAC layer may substantially not apply HARQ ACK or NACK transmissions, HARQ retransmission procedures, or HARQ processing procedures to the bearer supporting MBS service. Alternatively, the configuration information of the SDAP layer device for the first bearer structure may not be configured in the system information or RRC message (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined RRC message) or the control message of the MBS channel, and the SDAP layer device can directly transmit the data of the first bearer to the MBS application layer device without processing (e.g., bypassing) the data. In another approach, the SDAP layer device configuration information for the bearer may be configured in the system information or RRC message (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined RRC message) or the control message of the MBS channel, and the mapping information between QoS flows and bearers may be configured or reconfigured. Furthermore, the presence or absence of the SDAP header for downlink data or uplink data may be configured in the SDAP layer device configuration information.Additionally, reconfiguration or handover processes between unicast or multicast bearers can be supported by using QoS flow-bearer mapping information. Furthermore, in the bearer's SDAP configuration information, QoS flows used for MBS services can be mapped to bearers supporting MBS services. MBS data that can be received or transmitted in the first bearer structure can have a 1g-11 or 1g-12 structure. For example, based on configuration information from system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined RRC message) or control messages of the MBS channel, MBS data that can be received or transmitted in the first bearer structure can have a 1g-11 or 1g-12 structure. As described above, overhead due to headers can be reduced.

[0209] -Second Bearer Structure (1g-02): If the unicast or multicast bearer used for MBS services is configured with Figure 7The second bearer structure 1g-02 shown allows the terminal to be configured to connect to an MBS control data channel, an MBS user data channel, or an RLC layer device corresponding to the logical channel identifier (or MBS service) of the MBS user data channel. Additionally, a bearer structure for directly connecting the RLC layer device to the upper-layer MBS application layer device can be configured as a bearer for MBS service. In the second bearer structure, the transmission of HARQ ACK or NACK, HARQ retransmission, or HARQ processing may not be required from the MAC layer device. Alternatively, in the second bearer structure, the terminal can transmit MBS data (MBS control data or MBS user data) received through the PHY layer device or MAC layer device to the higher-layer MBS application layer device via the RLC layer device. In the second bearer structure, MBS data may not include a MAC header. For example, when a separate physical channel or transport channel is configured for MBS service and separate transmission resources (frequency or time resources or transmission period) are configured, the MAC layer device can distinguish MBS data even without a MAC header. In another approach, when a separate physical channel or transport channel is configured for MBS service and separate transport resources (frequency, time, or transmission period) are configured, MBS data can be distinguished even if a MAC header is absent in the PHY or MAC layer devices if a first RNTI for MBS data is allocated or determined. In the above, for the RNTI of MBS data, a 1-1 RNTI for MBS control data (or MBS control data channel) or a first 1-2 RNTI for MBS user data (or MBS user data channel, logical channel identifier, or per MBS service) can be assigned or specified respectively. In another approach, a separate physical channel or transport channel for MBS services is configured in the second bearer structure, or MBS services are supported in the DL-SCH (Downlink Shared Channel) for general data services, or separate transport resources (frequency or time resources or transmission period) are configured. MBS data may include a MAC header, MBS control data (or MBS control data channel), or MBS user data (or MBS user data channel or logical channel identifier or per MBS service), or MBS services may be distinguished based on the logical channel identifier included in the MAC header, or may be distinguished to be demultiplexed and delivered to each RLC layer device.In another approach, when a separate physical channel or transport channel for MBS service is configured in the second bearer structure, or MBS service is supported in the downlink shared channel (DL-SCH) for general data service, or a separate transport resource (frequency, time resource, or transmission period) is configured, MBS data can be received from the transport resource. When a first RNTI for MBS data is allocated or determined, MBS data with the RNTI can be received from the transport resource according to the PDCCH indication. The MBS data may include a MAC header, MBS control data (or MBS control data channel) or MBS user data (or MBS user data channel, logical channel identifier, or per MBS service). The MBS service can be distinguished based on the logical channel identifier included in the MAC header, or distinguished for demultiplexing and delivery to each RLC layer device. That is, different logical channel identifiers can be configured or defined for each MBS control data channel, MBS user data channel, or MBS service as a logical channel, and MBS service can be supported. The RLC layer device configured in the second bearer structure can be configured in transparent mode (TM) and can be characterized by not including an RLC header in the MBS data. Alternatively, the RLC sequence number length can be omitted from the RLC layer device. Alternatively, the RLC layer device can refrain from applying data processing procedures to the MBS data. Furthermore, the RLC layer device configured in the second bearer structure in TM mode can refrain from applying data partitioning or data reassembly procedures for the MBS data. Alternatively, the RLC layer device configured in the second bearer structure can configure the RLC receive window size to 0, or can refrain from running the RLC receive window. In the second bearer structure, the MAC layer device can substantially refrain from applying HARQ ACK or NACK transmissions, HARQ retransmission procedures, or HARQ processing procedures to the bearer supporting MBS service. Alternatively, in system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined RRC message) or control messages of the MBS channel, configuration information for the SDAP layer device may not be configured for the second bearer structure, and the SDAP layer device may directly transmit the data of the second bearer to the MBS application layer device without processing (e.g., bypassing) the data. Alternatively, in system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined RRC message) or control messages of the MBS channel, configuration information for the SDAP layer device of the bearer may be configured, and the mapping information between QoS flows and bearers may be configured or reconfigured.Furthermore, the presence or absence of SDAP headers for downlink data or uplink data can be configured in the SDAP layer device configuration information. Additionally, reconfiguration or handover processes between unicast and multicast bearers can be supported by using QoS flow-bearer mapping information. Moreover, in the bearer's SDAP configuration information, QoS flows for MBS services can be mapped to bearers supporting MBS services. MBS data that can be received or transmitted in the second bearer structure can have a 1g-21 structure. For example, based on the configuration information of system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined new RRC message) or control messages of the MBS channel, MBS data that can be received or transmitted in the above second bearer structure can have a 1g-21 structure. As described above, overhead caused by headers can be reduced.

[0210] -Third Bearer Structure (1g-03): If the unicast or multicast bearer used for MBS services is configured with Figure 7The third bearer structure (1g-03) shown allows the terminal to be configured with an RLC layer device corresponding to the logical channel identifier (or MBS service) of the MBS control data channel, MBS user data channel, or MBS user data channel connected to a MAC layer device. Additionally, a bearer structure for directly connecting the RLC layer device to the upper-layer MBS application layer device can be configured as a bearer for MBS services. In the third bearer structure, the transmission of HARQ ACK or NACK, HARQ retransmission, or HARQ processing of the MAC layer device may not be applied to the third bearer. In another approach, the transmission of HARQ ACK or NACK, HARQ retransmission, or HARQ processing of the MAC layer device can be configured as an indicator indicating whether it should be executed in the control messages or RRC messages of system information (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined new RRC message) or the control messages of the MBS channel. For example, in system information control messages or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined RRC message) or MBS channel control messages, if an indicator (indicator value indicating a specific value or the indicator field not existing) is configured to perform HARQ ACK or NACK transmission, HARQ retransmission, or HARQ processing, it can be executed. Alternatively, if an indicator (indicator value indicating a specific value or the indicator field not existing) is configured to prevent the aforementioned HARQ ACK or NACK transmission, HARQ retransmission, or HARQ processing from being performed, it cannot be performed, or HARQ ACK or NACK transmission, HARQ retransmission, or HARQ processing can be substantially omitted from the application of HARQ ACK or NACK transmission, HARQ retransmission, or HARQ processing to bearers supporting MBS services in the MAC layer device. Alternatively, the indicator can be configured separately for the MBS control data channel or MBS user data channel or logical channel identifier (or MBS service) or bearer identifier of the MBS user data channel.In another approach, when a MAC layer device sends a HARQ ACK or NACK, or a HARQ retransmission procedure, or a HARQ processing procedure is executed or configured, or a specific logical channel identifier or MBS service or bearer is configured, an indicator (indicator value indicating a specific value or absence of an indicator field) can be configured in the control message or RRC message of system information (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined new RRC message) or the control message of the MBS channel to perform HARQ reordering or RLC reordering (or sequential transmission) of the RLC layer device configured for the MBS control data channel or MBS user data channel or logical channel identifier (or MBS service) or bearer identifier of the MBS user data channel. Alternatively, the RLC receive window size can be configured to a value greater than 0 (e.g., 2^(RLC sequence number length - 1)). This is because the order of data may be mixed when HARQ processing or retransmission is performed on MBS data. Because the data order may be mixed, it is necessary to rearrange the MBS data based on the RLC receive window or based on the RLC sequence number, or to run a reordering timer to support MBS service. In another approach, when the MAC layer device does not perform HARQ ACK or NACK transmission or HARQ retransmission, or the HARQ processing is not performed, or is configured not to be performed, the control messages or RRC messages in the system information (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined new RRC message) or the control messages of the MBS channel can be configured by setting an indicator (indicator value indicating a specific value or no indicator field) to prevent the RLC layer device from performing the function configured for the MBS control data channel or MBS user data channel or logical channel identifier (or MBS service) or the bearer identifier of the MBS user data channel, thus avoiding HARQ reordering or RLC reordering (or sequence transmission). Alternatively, by default not applying HARQ ACK or NACK transmissions, HARQ retransmission procedures, or HARQ processing procedures to bearers supporting MBS services in the MAC layer devices, even RLC layer devices configured in bearers supporting MBS services may essentially not perform HARQ reordering or RLC reordering functions (or sequential delivery). Alternatively, the RLC receive window size can be configured to 0 without running a receive RLC window. For example, with no or essentially no configuration information, the terminal can send data to upper-layer devices using an out-of-order delivery method, regardless of the order in which data is always received from the RLC layer devices.Alternatively, in the third bearer architecture, the terminal can transmit MBS data (MBS control data or MBS user data) received through the PHY layer or MAC layer to a higher-layer MBS application layer via an RLC layer device. In the third bearer architecture, the MBS data may include a MAC header. Alternatively, a logical channel identifier included in the MAC header can be configured or defined to indicate the MBS control data channel, the MBS user data channel, or each MBS service. For example, when a separate physical channel or transport channel is configured for MBS services and separate transmission resources (frequency or time resources, or transmission period) are configured, if a first RNTI for the MBS data is allocated or determined, the MBS data can be distinguished as MBS control data or MBS user data, or data from which MBS service in the PHY layer or MAC layer, based on the RNTI or logical channel identifier, or it can be distinguished for demultiplexing and transmission to each RLC layer device. In the above, for the RNTI of MBS data, a 1-1 RNTI of MBS control data (or MBS control data channel) or a 1-2 RNTI of MBS user data (or MBS user data channel, logical channel identifier, or MBS service-specific RNTI) can be assigned or specified respectively. In another approach, in the third bearer structure, a separate physical channel or transport channel is configured for MBS service, or MBS service is supported in the downlink shared channel (DL-SCH) for general data service, or separate transmission resources (frequency or time resources or transmission period) are configured. MBS data may include a MAC header. MBS control data (or MBS control data channel) or MBS user data (MBS user data channel, logical channel identifier, or MBS service) or MBS service can be distinguished, demultiplexed, and transmitted to each RLC layer device based on the logical channel identifier included in the MAC header. In another approach, in the third bearer architecture, MBS data can be received from the transport resources when a separate physical channel or transport channel is configured for MBS service, or MBS service is supported in the downlink shared channel (DL-SCH) for general data service, or a separate transport resource (frequency or time resource or transport period) is configured. If a first RNTI for MBS data is allocated or determined, MBS data can be received from the transport resources for the RNTI indicated by the PDCCH. MBS data may include a MAC header, MBS control data (MBS control data channel) or MBS user data (or MBS user data channel, logical channel identifier, or MBS service). MBS service may be distinguished based on the logical channel identifier included in the MAC header, or be distinguished to be demultiplexed and delivered to each RLC layer device.In other words, different logical channel identifiers can be configured or defined for each MBS control data channel, MBS user data channel, or MBS service as a logical channel, and MBS services can be supported. The RLC layer device configured in the third bearer structure can be configured in Transparent Mode (TM), Negative Acknowledgment Mode (UM), or a one-way mode of UM mode, a two-way mode of UM mode, or Acknowledgment Mode (AM). In RLC TM mode, the RLC header may not be included in the MBS data, while in RLC UM mode or AM mode, the RLC header may be included. Furthermore, in RLC TM mode, the RLC layer device may not apply data processing procedures to the MBS data (e.g., data partitioning or reassembly procedures may not be applied), while in RLC UM mode or RLC AM mode, data processing procedures may be applied to the MBS data. Alternatively, configuration information for the SDAP layer device may not be configured for the third bearer structure in system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined RRC message) or control messages of the MBS channel, and the SDAP layer device may not process (e.g., bypass) the data of the third bearer and may directly send it to the MBS application layer device. In another approach, SDAP layer device configuration information may be configured in system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined RRC message) or control messages of the MBS channel, and the mapping information between QoS flows and bearers may be configured or reconfigured. Furthermore, the presence or absence of SDAP headers for downlink data or uplink data may be configured in the SDAP layer device configuration information. Additionally, reconfiguration or handover processes between unicast or multicast bearers can be supported by using QoS flow-bearer mapping information. Furthermore, in the SDAP configuration information of the bearer, the QoS flow for MBS service can be mapped to the bearer supporting MBS service. MBS data that can be received or transmitted in the third bearer structure can have a 1g-31 or 1g-32 structure. For example, based on the configuration information of system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined RRC message) or control messages of the MBS channel, MBS data that can be received or transmitted in the above third bearer structure can have a 1g-31 or 1g-32 structure. As described above, overhead caused by headers can be reduced.When configured to perform HARQ ACK or NACK transmission, HARQ retransmission, or HARQ processing in a MAC layer device, or when configured as an indicator in system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined RRC message) or control messages of the MBS channel, transmission resource information (e.g., time or frequency resources, transmission channel, frequency interval, etc.) for transmitting HARQ ACK or NACK can be transmitted together. When a terminal in RRC connected mode, RRC deactivated mode, or RRC idle mode is configured to perform the aforementioned HARQ ACK or NACK transmission, HARQ retransmission, or HARQ processing, it can utilize the above-configured transmission resources (e.g., physical transmission resources) to receive downlink MBS data and send HARQ ACK or NACK. In the above context, if the base station detects even one NACK in the transmission resources or detects that at least one terminal has sent a NACK, the base station can perform a retransmission of the MBS data. Alternatively, the base station can perform a retransmission so that all terminals can receive it through the MBS channel. In another approach, RRC connected mode terminals, RRC deactivated mode terminals, or RRC idle mode terminals can receive the aforementioned downlink MBS data and then define MAC control information (RLC control information, PDCP control information, or RRC messages). They can also send MAC control information including a terminal identifier, MBS service identifier, logical channel identifier, RNTI identifier, or bearer identifier, allowing the base station to indicate which terminal failed to receive the data (e.g., the MAC control information (or RLC control information, PDCP control information, or RRC messages) can be sent in the transmission resources configured above). The base station can retransmit MBS data only to RRC connected mode, RRC idle mode, or RRC deactivated mode terminals that indicate a NACK has been sent or that the MBS data was not successfully received in the transmission resources. Alternatively, the base station can perform a retransmission of MBS data when it detects even one NACK or detects that at least one terminal has sent a NACK in the transmission resources. Alternatively, a retransmission can be performed so that all terminals can receive it through the MBS channel.

[0211] -Fourth Bearer Structure 1g-04: When a unicast or multicast bearer used for MBS services is configured with Figure 7In the fourth bearer structure 1g-04 shown, the terminal can be configured with an RLC layer device connected to the MAC layer device, corresponding to the logical channel identifier (or MBS service) of the MBS control data channel or MBS user data channel. Additionally, the terminal can be configured with a PDCP layer device connected to the RLC layer device, and the bearer structure used to connect the PDCP layer device to the higher-layer MBS application layer device can be configured as a bearer for MBS service. In the fourth bearer structure, the transmission of HARQ ACK or NACK, HARQ retransmission, or HARQ processing procedures of the MAC layer device may not be applied to the fourth bearer. In another method, whether to execute the transmission of HARQ ACK or NACK, HARQ retransmission, or HARQ processing procedures of the MAC layer device can be configured as an indicator in system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined new RRC message) or control messages of the MBS channel. For example, an indicator (indicator value indicating a specific value or absence of the indicator field) can be configured in system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined RRC message) or control messages of the MBS channel to perform HARQ ACK or NACK transmission, HARQ retransmission, or HARQ processing. Alternatively, an indicator (indicator value indicating a specific value or absence of the indicator field) can be configured so that the aforementioned HARQ ACK or NACK transmission, HARQ retransmission, or HARQ processing is not performed, or HARQ ACK or NACK transmission, HARQ retransmission, or HARQ processing may not be applied to bearers supporting MBS services in the MAC layer apparatus. Alternatively, an indicator can be configured for the MBS control data channel or MBS user data channel or logical channel identifier (or MBS service) or bearer identifier of the MBS user data channel, respectively.In another approach, when a MAC layer device sends a HARQ ACK or NACK, or a HARQ retransmission procedure or HARQ processing procedure is executed or configured, or for a specific logical channel identifier or MBS service or bearer is configured, an indicator (indicator value indicating a specific value or absence of an indicator field) can be configured in system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined new RRC message) or control messages for the MBS channel to perform HARQ reordering or RLC reordering (sequential delivery) of the RLC layer device configured for the MBS control data channel, or MBS user data channel, or logical channel identifier (or MBS service), or bearer identifier of the MBS user data channel. Alternatively, the RLC receive window size can be configured to a value greater than 0 (e.g., 2^(RLC sequence number length - 1)). This is because the order of data may be mixed when HARQ processing or retransmission is performed on MBS data. Therefore, it is necessary to rearrange the MBS data based on the RLC receive window or based on the RLC sequence number, or to run a reordering timer to support MBS service. In another approach, when the MAC layer device does not perform HARQ ACK or NACK transmission, or when the HARQ retransmission process or HARQ processing process is not performed or configured not to be performed, an indicator (indicator value indicating a specific value or absence of an indicator field) can be configured in system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined new RRC message) or control messages for the MBS channel. This prevents the RLC layer device from performing HARQ reordering or RLC reordering functions (RLC reordering or sequential delivery) for the MBS control data channel or MBS user data channel or logical channel identifier (or MBS service) or bearer identifier of the MBS user data channel. Alternatively, by not applying HARQ ACK or NACK transmissions, HARQ retransmission procedures, or HARQ processing procedures to bearers supporting MBS services in the MAC layer device, even RLC layer devices configured in bearers supporting MBS services may essentially not perform HARQ reordering or RLC reordering functions (or sequential delivery). Alternatively, the RLC receive window size can be configured to 0 without running a receive RLC window. For example, without or with virtually no configuration information, the terminal can send data received from the RLC layer device to the upper layer device in an out-of-order delivery manner, regardless of order.Alternatively, in the fourth bearer architecture, the terminal can transmit MBS data (MBS control data or MBS user data) received through the PHY layer or MAC layer to a higher-layer MBS application layer via an RLC layer device or a PDCP layer device. In the fourth bearer architecture, the MBS data may include a MAC header. Alternatively, a logical channel identifier included in the MAC header can be configured or defined to indicate an MBS control data channel, an MBS user data channel, or each MBS service. For example, with separate physical channels or transport channels configured for MBS services and separate transmission resources (frequency or time resources, or transmission period) configured, when the first RNTI of the MBS data is allocated or determined, it is possible to distinguish whether the MBS data is MBS control data, MBS user data, or MBS service data based on the RNTI or logical channel identifier in the PHY layer or MAC layer device, and it can be demultiplexed and delivered to each RLC layer device after classification. As for the RNTI of MBS data, 1-1 RNTIs of MBS control data (or MBS control data channels) or 1-2 RNTIs of MBS user data (by MBS user data channel, logical channel identifier, or MBS service) can be assigned or specified separately. In another approach, a separate physical channel or transport channel for MBS service can be configured in the fourth bearer structure, or MBS service can be supported in the downlink shared channel (DL-SCH) for general data service, or MBS data can include a MAC header when separate transmission resources (frequency, time resources, or transmission period) are configured. MBS control data (or MBS control data channels) or MBS user data (by MBS user data channel, logical channel identifier, or MBS service) or MBS service can be distinguished based on the logical channel identifier included in the MAC header, or can be distinguished for demultiplexing and delivery to each RLC layer device. In another approach, MBS data can be received from the transport resources when a separate physical channel or transport channel for MBS service is configured in the fourth bearer structure, or when MBS service is supported in the downlink shared channel (DL-SCH) for general data service, or when separate transport resources (frequency, time resources, or transport period) are configured. If a first RNTI for MBS data is allocated or determined, MBS data can be received from the transport resources for the RNTI indicated by the PDCCH. MBS data may include a MAC header, and MBS control data (or MBS control data channel) or MBS user data (or MBS user data channel, or logical channel identifier, or per MBS service) or MBS service can be distinguished based on the logical channel identifier included in the MAC header, or distinguished to be demultiplexed and transmitted separately to each RLC layer device.Furthermore, by dividing MBS control data or MBS user data MBS services, only some services can be demultiplexed and delivered to each RLC layer device, or some services can be demultiplexed and delivered to each RLC layer device in addition to some. That is, different logical channel identifiers can be configured or defined as logical channels for each MBS control data channel, MBS user data channel, or MBS service, and MBS services can be supported. The RLC layer devices configured in the fourth bearer structure can be configured in Transparent Mode (TM), Negative Acknowledgment Mode (UM), or a one-way mode of UM mode, a two-way mode of UM mode, or Acknowledgment Mode (AM). In RLC TM mode, the RLC header may not be included in the MBS data, while in RLC UM mode or RLC AM mode, the RLC header may be included. Furthermore, in RLC TM mode, the RLC layer devices may not apply data processing procedures to the MBS data (e.g., data partitioning or reassembly procedures may not be performed), while in RLC UM mode or RLC AM mode, data processing procedures may be applied to the MBS data. In system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined RRC message) used for the fourth bearer structure or control messages for the MBS channel, the overhead of MBS data can be reduced by configuring the RLC layer device to TM mode (e.g., by reducing overhead by not using the RLC header). Alternatively, in system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined RRC message) used for the fourth bearer structure or control messages for the MBS channel, out-of-order delivery functionality in the PDCP layer device can be configured to prevent MBS data transmission delays. As another approach, in the fourth bearer structure used for MBS bearers, the PDCP layer device can default to implementing out-of-order delivery functionality (e.g., always configuring the out-of-order delivery indicator to true) to prevent MBS data transmission delays. This is because, when HARQ retransmission or HARQ processing is not performed on MBS data and RLC retransmission is not performed, the reordering function in the PDCP layer device may cause transmission delays when data loss occurs. Alternatively, the PDCP layer device can essentially perform the PDCP reordering function, determine the size of the receive window based on the PDCP receive window length of the PDCP sequence number (e.g., PDCP sequence number length 16 bits, window size 2^(16-1)), and drive a reordering timer.Alternatively, in the fourth bearer structure, SDAP layer device configuration information can be configured in system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined RRC message) or control messages of the MBS channel, and the mapping information between QoS flows and bearers can be configured or reconfigured. Furthermore, the presence or absence of SDAP headers for downlink data or uplink data can be configured in the SDAP layer device configuration information. Additionally, reconfiguration or handover processes between unicast and multicast bearers can be supported by using the mapping information between QoS flows and bearers. Alternatively, when SDAP layer device configuration information is not configured for the third bearer structure, the SDAP layer device can directly transmit the fourth bearer data to the MBS application layer device without processing (e.g., bypassing) the data, in system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined RRC message) or control messages of the MBS channel. Furthermore, in the SDAP configuration information of the bearer, the QoS flow for MBS service can be mapped to the bearer supporting MBS service. MBS data that can be received or transmitted in the fourth bearer structure can have a 1g-41, 1g-42, 1g-43, or 1g-44 structure. For example, based on the configuration information of system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined RRC message) or control messages of the MBS channel, MBS data that can be received or transmitted in the fourth bearer structure can have a 1g-41, 1g-42, 1g-43, or 1g-44 structure. As described above, overhead due to headers can be reduced. In system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined RRC message) or control messages of the MBS channel, when the transmission resource information (e.g., time or frequency resources, transmission channel, frequency interval, etc.) used to send HARQ ACK or NACK is configured to perform HARQ ACK or NACK transmission, or HARQ retransmission procedure, or HARQ processing procedure of the MAC layer device, or when configured as an indicator, it can be sent together.When a terminal in RRC connected mode, RRC deactivated mode, or RRC idle mode is configured to perform the aforementioned HARQ ACK or NACK transmission, HARQ retransmission procedure, or HARQ processing procedure, it can use the above-configured transmission resources (e.g., physical transmission resources) to send a HARQ ACK or NACK after receiving downlink MBS data. The base station can retransmit the MBS data even when a NACK is detected in the transmission resources or even when at least one terminal has sent a NACK. Alternatively, retransmission can be performed so that all terminals can receive it through the MBS channel. In another approach, RRC connected mode, RRC deactivated mode, or RRC idle mode terminals can receive the aforementioned downlink MBS data, define MAC control information (or RLC control information, PDCP control information, or RRC messages), and send MAC control information (or RLC control information, PDCP control information, or RRC messages) to allow the base station to indicate which terminal has not successfully received data including the terminal identifier, MBS service identifier, logical channel identifier, RNTI identifier, or bearer identifier (e.g., MAC control information (or RLC control information, PDCP control information, or RRC messages) can be sent in the transmission resources configured above). The base station can perform MBS data retransmission only for RRC connected mode, RRC idle mode, or RRC deactivated mode terminals that indicate a NACK has been sent or that MBS data has not been successfully received in the transmission resources. Alternatively, the base station can perform MBS data retransmission when it detects even one NACK or detects that at least one terminal has sent a NACK in the transmission resources. Or, retransmission can be performed so that all terminals can receive it through the MBS channel.

[0212] When a terminal receives the above system information, when a terminal attempts to receive a service of interest, when a service of interest appears or is identified, when a terminal is in or enters a cell or area that supports the MBS service in the system information, when a terminal configures or connects to the MBS service (or session), or when a terminal receives or broadcasts configuration information or bearer configuration information for the MBS service in system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined new RRC message) or control messages of the MBS channel (e.g., sent in the MBS control data channel), the terminal can configure a unicast bearer, multicast bearer, or MBS bearer with the bearer structure proposed above for receiving the MBS service.

[0213] Figure 8 This illustrates how a terminal in RRC connection mode, RRC deactivation mode, or RRC idle mode can use the method described in this disclosure. Figure 7 The proposed method describes a method for demultiplexing received MBS data in a MAC layer device when a multicast or unicast bearer supporting MBS services receives MBS data (e.g., MBS control data, MBS user data, or general data other than MBS data). Furthermore, a method is proposed for a terminal to transmit uplink MBS data (e.g., MBS control data, MBS user data, or general data other than MBS data).

[0214] Figure 8 The method for receiving MBS data or the method for receiving and demultiplexing MBS data can be one or more of the following methods. Alternatively, different methods can be applied depending on whether the terminal is in RRC connection mode, RRC deactivation mode, or RRC idle mode.

[0215] - Part (1-1) MBS reception method 1h-10: In Figure 8In the (1-1) MBS reception method (1h-10), a separate physical channel or transport channel (e.g., MBCH, MBS channel) for MBS service is configured, and separate transmission resources (frequency or time resources, transmission period, partial bandwidth (or partial bandwidth identifier), bandwidth, dedicated frequency (frequency information or SCell identifier), or subcarrier spacing, etc.) can be configured or defined in system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined new RRC message) or control messages of the MBS channel (e.g., transmitted in the MBS control data channel). A MAC header is always attached to the MBS data transmitted for MBS service, and the logical channel identifier included in the MAC header is assigned to the MBS control data channel (e.g., MBCCH, MBS control channel), or can be assigned differently to the MBS user data channel (e.g., MBTCH, MBS traffic channel). Furthermore, a different logical channel identifier can be assigned to each MBS service served in the MBS user data channel. A first identifier or a second identifier for each MBS service can be configured or broadcast in system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined RRC message) or control messages for the MBS channel (e.g., transmitted in the MBS control data channel). Furthermore, each logical channel identifier corresponding to the first or second identifier for each MBS service can be configured or broadcast. In the foregoing, the first identifier may indicate the Public Land Mobile Network (PLMN) serving the MBS or may indicate the MBS service type or session. In the foregoing, the second identifier may indicate a more specific MBS service session or type. Logical channel identifiers that can be allocated to bearers in the DL-SCH channel for general data services (voice, Internet, or video services) can be allocated as a predetermined bit (e.g., 6-bit) combination in a first logical channel identifier space that can be generated using predetermined bits (e.g., 6 bits). The logical channel identifier for each service of the MBS control data channel, MBS user data channel, or MBS user data channel can be allocated as a predetermined combination of bits (e.g., 6 bits) in the first logical channel identifier space. Alternatively, MAC control information (MAC CE (control element), such as a MAC CE indicating that the network has stopped the MBS service or that a terminal has stopped receiving the MBS service from the network) or logical channel identifiers used for padding inserted into the MBS data used to support the MBS service can be allocated as a predetermined combination of bits (e.g., 6 bits) in the first logical channel identifier space.In another approach, to double the logical channel identifier space, the logical channel identifier for each service of the MBS control data channel, MBS user data channel, or MBS user data channel can be allocated as a predetermined combination of bits (e.g., 6 bits) in the new second logical channel identifier space. Alternatively, MAC control information (MAC CE (control element), such as a MAC CE indicating that the network has stopped receiving MBS service or that a terminal has stopped receiving MBS service) used to support MBS service, or logical channel identifiers used to fill in MBS data used to support MBS service, can be allocated as a predetermined combination of bits (e.g., 6 bits) in the new second logical channel identifier space. The first and second logical channel identifier spaces can be distinguished in the MAC layer apparatus as MBS channels or DL-SCH channels or transport resources (frequency or time transport resources, frequency information, partial bandwidth identifiers, partial bandwidth configuration information, dedicated carrier or dedicated cell (SCell) identifiers or dedicated cell information), or they can be distinguished by using different RNTIs. Therefore, when the terminal's MAC layer device receives MBS data through a channel or transmission resource used for receiving MBS services, the terminal's MAC layer device can classify or demultiplex the MBS data based on the received transmission channel (e.g., MBCH, DL-SCH, or BCH), partial bandwidth identifier, SCell identifier, logical channel identifier, or RNTI identifier, and send the data to the corresponding upper-layer device. The 1-1 MBS reception method can be applied to terminals in RRC connected mode, RRC deactivated mode, or RRC idle mode.

[0216] - MBS reception method 1h-10 (1-2): In Figure 8In the (1-2) MBS receiving method, a separate physical channel or transport channel (e.g., MBCH, MBS channel) for MBS service is configured in system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined new RRC message) or control messages of the MBS channel (e.g., transmitted in the MBS control data channel). Separate transmission resources (frequency or time resources, transmission period, partial bandwidth (or partial bandwidth identifier), bandwidth, dedicated frequency (frequency information or SCell identifier), or subcarrier spacing, etc.) can be configured or defined. A MAC header can be attached to the MBS data transmitted for MBS service, and the logical channel identifier included in the MAC header can be assigned differently to the MBS control data channel (e.g., MBCCH, MBS control channel) or the MBS user data channel (e.g., MBTCH, MBS traffic channel). Furthermore, a different logical channel identifier can be assigned to each MBS service served in the MBS user data channel. Furthermore, different RNTI identifiers can be assigned to MBS control data channels (e.g., MBCCH, MBS control channel) or MBS user data channels (e.g., MBTCH, MBS traffic channel). Additionally, a different RNTI identifier can be assigned to each MBS service serving in the MBS user data channel. Therefore, because the RNTI identifier can distinguish each MBS service serving in the MBS control data channel (e.g., MBCCH, MBS control channel) or MBS user data channel, the same logical channel identifier can be assigned to each MBS service serving in the MBS control data channel or MBS user data channel. In another approach, the same RNTI identifier can be assigned to each MBS service serving in the MBS control data channel (e.g., MBCCH, MBS control channel) or the MBS user data channel. More specifically, channel or data classification can be distinguished by assigning different logical channel identifiers to each MBS service serving in the MBS control data channel (e.g., MBS control channel (MBCCH)), the MBS user data channel, or the MBS user data channel. The RNTI identifier of the MBS service can be configured differently from the RNTI identifier of the DL-SCH (e.g., C-RNTI, MCS-C-RNTI, or CS-RNTI). In another approach, as described above, the RNTI identifier of the MBS service can be configured to be the same as the RNTI identifier of the DL-SCH (e.g., C-RNTI, MCS-C-RNTI, CS-RNTI, etc.), and the logical channel identifier can be used to perform the distinction.Furthermore, for each MBS service served in the MBS user data channel, a first identifier or a second identifier for each MBS service can be configured or broadcast in system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined RRC message) or control messages of the MBS channel (e.g., sent in the MBS control data channel). Each logical channel identifier or each RNTI identifier corresponding to the first or second identifier of each MBS service can also be configured or broadcast. The first identifier may indicate the Public Land Mobile Network (PLMN) serving the MBS or may indicate the MBS service type or session. As mentioned above, the second identifier may indicate a more specific MBS service session or type. Logical channel identifiers that can be allocated to bearers in the DL-SCH channel for general data services (voice, Internet, or video services) can be allocated as a predetermined bit (e.g., 6-bit) combination in a first logical channel identifier space that can be generated using predetermined bits (e.g., 6 bits). The logical channel identifier for each service of the MBS control data channel, MBS user data channel, or MBS user data channel can be allocated as a predetermined combination of bits (e.g., 6 bits) in a first logical channel identifier space. Alternatively, MAC control information (MAC CE (control element), such as an instruction from the network to stop MBS service or from the terminal to stop receiving MBS service) used to support MBS service, or logical channel identifiers used for padding inserted into MBS data used to support MBS service, can also be allocated as a predetermined combination of bits (e.g., 6 bits) in the first logical channel identifier space. In another approach, to double the aforementioned logical channel identifier space, the logical channel identifier for each service of the MBS control data channel, MBS user data channel, or MBS user data channel can be allocated as a predetermined combination of bits (e.g., 6 bits) in a new second logical channel identifier space. Alternatively, MAC control information (MAC CE (control element), such as an instruction from the network to stop MBS service or from the terminal to stop receiving MBS service) used to support MBS service can be allocated as a predetermined combination of bits (e.g., 6 bits) in a new second logical channel identifier space.The first and second logical channel identifier spaces can be distinguished in the MAC layer device by MBS channel, DL-SCH channel, or transmission resources (frequency or time transmission resources, frequency information, partial bandwidth identifier, partial bandwidth configuration information, dedicated carrier or dedicated cell (SCell) identifier, or dedicated cell information), or by using different RNTIs. Therefore, when the terminal's MAC layer device receives MBS data through a channel or transmission resource used for receiving MBS services, the MAC layer device can divide or demultiplex the MBS data based on the received transmission channel (e.g., MBCH, DL-SCH, or BCH) or partial bandwidth identifier, SCell identifier, logical channel identifier, or RNTI identifier, and send the data to the corresponding upper-layer device. The (1-2) MBS reception method can be applied to terminals in RRC connected mode, RRC deactivated mode, or RRC idle mode.

[0217] - MBS reception method 1h-10 (1-3): In Figure 8In MBS reception methods 1h-10 (1-3), separate physical channels or transport channels (e.g., MBCH, MBS channels) for MBS service can be configured in system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or newly defined new RRC messages) or control messages for the MBS channel (e.g., transmitted in the MBS control data channel). Separate transport resources (frequency or time resources, transmission period, partial bandwidth (or partial bandwidth identifier), bandwidth, dedicated frequency (frequency information or SCell identifier), or subcarrier spacing, etc.) can also be configured or defined. The MAC header may not be appended to the MBS data transmitted for MBS service, and the MBS control data channel (e.g., MBCCH, MBS control channel) or MBS user data channel (e.g., MBTCH, MBS service channel) can be distinguished from each other based on the RNTI identifier. Furthermore, different RNTI identifiers can be assigned to MBS control data channels (e.g., MBCCH, MBS control channel) or MBS user data channels (e.g., MBTCH, MBS traffic channel). Additionally, a different RNTI identifier can be assigned to each MBS service serving in the MBS user data channel. Therefore, because the RNTI identifier can distinguish each MBS service serving in the MBS control data channel (e.g., MBCCH, MBS control channel) or MBS user data channel, it is not necessary to configure a logical channel identifier for each MBS service serving in the MBS control data channel or MBS user data channel, and the MAC header does not need to be included in the MBS data. Furthermore, for each MBS service served in the MBS user data channel, a first identifier or a second identifier for each MBS service can be configured or broadcast in system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined RRC message) or control messages for the MBS channel (e.g., transmitted in the MBS control data channel). Each RNTI identifier corresponding to the first identifier or second identifier for each MBS service can also be configured or broadcast. As stated above, the first identifier may indicate the Public Land Mobile Network (PLMN) serving the MBS or may indicate the MBS service type or session. As stated above, the second identifier may indicate a more specific MBS service session or type.Therefore, when MBS data is received through a channel or transmission resource used to receive MBS services, the terminal's MAC layer device can divide or demultiplex the MBS data based on the received transmission channel (e.g., MBCH, DL-SCH, or BCH) or a partial bandwidth identifier, SCell identifier, or RNTI identifier, and send the data to the corresponding upper-layer device. The MBS reception methods (1-3) can be applied to terminals in RRC connected mode, RRC deactivated mode, or RRC idle mode.

[0218] – Part (2-1) MBS Reception Method 1h-20: In Figure 8In the (2-1) MBS receiving method 1h-20, the physical channel or transport channel (e.g., MBCH, MBS channel, or DL-SCH channel) for MBS service can be configured in system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined new RRC message) or control messages for the MBS channel (e.g., transmitted in the MBS control data channel). Alternatively, in an existing DL-SCH channel, separate transmission resources (frequency or time resources, transmission period, partial bandwidth (or partial bandwidth identifier), bandwidth, dedicated frequency (frequency information or SCell identifier), or subcarrier spacing, etc.) can be configured or defined. The MAC header can always be attached to the MBS data transmitted for MBS service, and the logical channel identifier included in the MAC header can be assigned differently for the MBS control data channel (e.g., MBCCH, MBS control channel) or the MBS user data channel (e.g., MBTCH, MBS service channel). Furthermore, different logical channel identifiers can be assigned to each MBS service serving in the MBS user data channel. A first identifier or a second identifier for each MBS service can be configured or broadcast in system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined RRC message) or control messages for the MBS channel (e.g., transmitted in the MBS control data channel), and each logical channel identifier corresponding to the first identifier or second identifier for each MBS service can be configured or broadcast. In the foregoing, the first identifier may indicate the Public Land Mobile Network (PLMN) serving the MBS or may indicate the MBS service type or session. In the foregoing, the second identifier may indicate a more specific MBS service session or type. Logical channel identifiers that can be assigned to bearers in the DL-SCH channel for general data services (voice, Internet, or video services) can be allocated as a predetermined bit (e.g., 6-bit) combination in a first logical channel identifier space that can be generated using predetermined bits (e.g., 6 bits). As described above, the logical channel identifier for each service of the MBS control data channel or MBS user data channel or MBS user data channel is allocated as a predetermined combination of bits (e.g., 6 bits) in the first logical channel identifier space.Alternatively, MAC control information (MAC CE (control element), such as a MAC CE indicating that the network has stopped the MBS service or that a terminal has stopped receiving the MBS service from the network) or logical channel identifiers used for padding the MBS data used to support the MBS service can be allocated as a predetermined combination of bits (e.g., 6 bits) in a first logical channel identifier space. In another approach, to double the aforementioned logical channel identifier space, the logical channel identifiers for each service of the MBS control data channel or MBS user data channel can be allocated as a predetermined combination of bits (e.g., 6 bits) in a new second logical channel identifier space. Alternatively, MAC control information (MAC CE (control element), such as a MAC CE indicating that the network has stopped the MBS service or that a terminal has stopped receiving the MBS service from the network) or logical channel identifiers used for padding the MBS data used to support the MBS service can be allocated as a predetermined combination of bits (e.g., 6 bits) in a new second logical channel identifier space. As described above, the first and second logical channel identifier spaces can be distinguished by the MAC layer device as MBS channels, DL-SCH channels, or transmission resources (frequency or time transmission resources, frequency information, partial bandwidth identifiers, partial bandwidth configuration information, dedicated carrier or dedicated cell (SCell) identifiers, or dedicated cell information), or by using different RNTIs. Therefore, when MBS data is received through a channel or transmission resource used to receive MBS services, the terminal's MAC layer device can divide or demultiplex the MBS data based on the received transmission channel (e.g., MBCH, DL-SCH, or BCH), partial bandwidth identifier, SCell identifier, logical channel identifier, or RNTI identifier, and send the data to the corresponding upper-layer device. The (2-1) MBS reception method can be applied to terminals in RRC connected mode, RRC deactivated mode, or RRC idle mode.

[0219] – Part (2-2) MBS Reception Method 1h-20: In Figure 8In the (2-2) MBS reception method 1h-20, the physical channel or transport channel (e.g., MBCH, MBS channel, or DL-SCH channel) for MBS service can be configured in system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined new RRC message) or control messages for the MBS channel (e.g., transmitted in the MBS control data channel). Alternatively, in an existing DL-SCH channel, separate transmission resources (frequency or time resources, transmission period, partial bandwidth (or partial bandwidth identifier), bandwidth, dedicated frequency (frequency information or SCell identifier), or subcarrier spacing, etc.) can be configured or defined. The MAC header can always be attached to the MBS data transmitted for MBS service, and the logical channel identifier included in the MAC header can be assigned differently for the MBS control data channel (e.g., MBCCH, MBS control channel) or the MBS user data channel (e.g., MBS traffic channel (MBTCH)). Furthermore, a different logical channel identifier can be assigned to each MBS service serving in the MBS user data channel. Moreover, different RNTI identifiers can be assigned to the MBS control data channel (e.g., MBS control channel (MBCCH)) or the MBS user data channel (e.g., MBS traffic channel (MBTCH)). Therefore, because the RNTI identifier can distinguish each MBS service serving in the MBS control data channel (e.g., MBS control channel (MBCCH)) or the MBS user data channel, the same logical channel identifier can be assigned to each MBS service serving in the MBS control data channel or the MBS user data channel. In another approach, the same RNTI identifier can be assigned to each MBS service serving in the MBS control data channel (e.g., MBS control channel (MBCCH)) or the MBS user data channel. More specifically, when classifying channels or data, different logical channel identifiers can be assigned and distinguished for each MBS service serving in the MBS control data channel (e.g., MBS control channel (MBCCH)), the MBS user data channel, or the MBS user data channel. As described above, the RNTI identifier for the MBS service can be configured differently from the RNTI identifier for the DL-SCH (e.g., C-RNTI, MCS-C-RNTI, or CS-RNTI).In another approach, as described above, the RNTI identifier for the MBS service is configured to be the same as the RNTI identifier for the DL-SCH (e.g., C-RNTI, MCS-C-RNTI, or CS-RNTI, etc.), with the difference being that the logical channel identifier can be used to accomplish this. Furthermore, for each MBS service served in the MBS user data channel, a first identifier or a second identifier for each MBS service can be configured or broadcast in system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined RRC message) or control messages for the MBS channel (e.g., sent in the MBS control data channel). Each logical channel identifier or each RNTI identifier corresponding to the first or second identifier for each MBS service can be configured or broadcast. As described above, the first identifier may indicate the Public Land Mobile Network (PLMN) serving the MBS or may indicate the MBS service type or session. As described above, the second identifier may indicate a more specific MBS service session or type. Logical channel identifiers that can be allocated to bearers in the DL-SCH channel for general data services (voice, Internet, or video services) can be allocated as a combination of predetermined bits (e.g., 6 bits) in a first logical channel identifier space that can be generated using predetermined bits (e.g., 6 bits). As described above, logical channel identifiers for each service of the MBS control data channel or MBS user data channel can be allocated as a combination of predetermined bits (e.g., 6 bits) in the first logical channel identifier space. Alternatively, logical channel identifiers used for MAC control information supporting MBS services (MAC CE (control element), such as MAC CEs indicating that the network has stopped MBS services or that a terminal has stopped receiving MBS services from the network) or for padding logical channel identifiers inserted into MBS data supporting MBS services can be allocated as a combination of predetermined bits (e.g., 6 bits) in the first logical channel identifier space. In another approach, to double the aforementioned logical channel identifier space, the logical channel identifier for each service of the MBS control data channel, MBS user data channel, or MBS user data channel can be allocated as a predetermined combination of bits (e.g., 6 bits) in the new second logical channel identifier space. Alternatively, MAC control information (MAC CE (control element), such as a MAC CE indicating that the network has stopped MBS service or that a terminal has stopped receiving MBS service from the network) used to support MBS service, or logical channel identifiers used for padding inserted into MBS data used to support MBS service, can also be allocated as a predetermined combination of bits (e.g., 6 bits) in the new second logical channel identifier space.As described above, the first and second logical channel identifier spaces can be distinguished in the MAC layer device as MBS channels or DL-SCH channels or transmission resources (frequency or time transmission resources, frequency information, partial bandwidth identifiers, partial bandwidth configuration information, dedicated carrier or dedicated cell (SCell) identifiers or dedicated cell information), or they can be distinguished by using different RNTIs. Therefore, when MBS data is received through a channel or transmission resource used to receive MBS services, the terminal's MAC layer device can distinguish or demultiplex the MBS data based on the received transmission channel (e.g., MBCH, DL-SCH, or BCH), partial bandwidth identifier, SCell identifier, logical channel identifier, or RNTI identifier, and send the data to the corresponding upper-layer device. The (2-2) MBS reception method can be applied to terminals in RRC connected mode, RRC deactivated mode, or RRC idle mode.

[0220] – Part (2-3) MBS reception method 1h-20: In Figure 8In MBS reception method 1h-20 (2-3), the physical channel or transport channel (e.g., MBCH, MBS channel, or DL-SCH channel) for MBS service can be configured in system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined new RRC message) or control messages of the MBS channel (e.g., transmitted in the MBS control data channel). Alternatively, in an existing DL-SCH channel, separate transmission resources (frequency or time resources, transmission period, partial bandwidth (or partial bandwidth identifier), bandwidth, dedicated frequency (frequency information or SCell identifier), or subcarrier spacing, etc.) can be configured or defined. The MAC header may not be appended to the MBS data transmitted for MBS service, and the MBS control data channel (e.g., MBCCH, MBS control channel) or MBS user data channel (e.g., MBTCH, MBS service channel) can be distinguished from each other based on the RNTI identifier. Furthermore, different RNTI identifiers can be assigned to the MBS control data channel (e.g., MBS Control Channel (MBCCH)) or the MBS user data channel (e.g., MBS Traffic Channel (MBTCH)). Additionally, a different RNTI identifier can be assigned to each MBS service serving in the MBS user data channel. Therefore, because the RNTI identifier can distinguish each MBS service serving in the MBS control data channel (e.g., MBS Control Channel (MBCCH)) or the MBS user data channel, it is not necessary to configure a logical channel identifier for each MBS service serving in the MBS control data channel or the MBS user data channel, and the MAC header does not need to be included in the MBS data. Furthermore, for each MBS service served in the MBS user data channel, a first identifier or a second identifier for each MBS service can be configured or broadcast in system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined RRC message) or control messages of the MBS channel (e.g., sent in the MBS control data channel), and each RNTI identifier corresponding to the first identifier or second identifier of each MBS service can be configured or broadcast. As stated above, the first identifier may indicate the Public Land Mobile Network (PLMN) serving the MBS or may indicate the MBS service type or session. As stated above, the second identifier may indicate a more specific MBS service session or type.Therefore, when MBS data is received through a channel or transmission resource used to receive MBS services, the terminal's MAC layer device can distinguish or demultiplex the MBS data based on the received transmission channel (e.g., MBCH, DL-SCH, or BCH), partial bandwidth identifier, SCell identifier, or RNTI identifier, and send the data to the corresponding upper-layer device. The MBS reception method (2-3) can be applied to terminals in RRC connected mode, RRC deactivated mode, or RRC idle mode.

[0221] Figure 9 This illustrates when a terminal in RRC connection mode, RRC deactivation mode, or RRC idle mode uses the method described in this disclosure. Figure 8 The diagram illustrates a method for multiplexing MBS data to be transmitted in a MAC layer device when the proposed bearer structure supports multicast or unicast bearers for MBS services to transmit MBS data (e.g., MBS, MBS control data, or general data other than MBS data when transmitting MBS user data).

[0222] Can to Figure 9 The method for sending MBS data or the method for sending and multiplexing MBS data shall apply one or more of the following methods. Alternatively, among the following methods, different methods may be applied depending on whether the terminal is in RRC connection mode, RRC deactivation mode, or RRC idle mode.

[0223] - First MBS transmission method 1i-01: When via Figure 8 When a terminal receiving MBS service needs to send uplink MBS data based on a network request or its own necessity, the terminal, or a terminal in RRC connected mode, RRC deactivated mode, or RRC idle mode, can send uplink MBS data to the base station or network. As described above, the network or base station can send network requests to the terminal including MBS data (e.g., MBS control data, MBS user data, RRC messages, RLC control data (RLC control PDU), PDCP control data (PDCP control PDU), MAC control data (control element (MAC CE)), or newly defined messages), and can send or configure indications of MBS service status (e.g., service stopped or restarted) or response requests for MBS service (e.g., requests to determine whether the terminal is receiving a specific MBS service, whether the terminal wants to receive a specific MBS service, preferences between multicast and unicast bearers, or switching preferences (whether the terminal wants to receive MBS service via multicast or unicast bearer). As described above, as in Figure 8The proposed method allows a base station or network to transmit MBS data, including a request from the network, in system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined RRC message) or MBS channel control messages (e.g., transmitted on the MBS control data channel), or the physical channel or transport channel for MBS service (e.g., the MBS channel (MBCH)), or in a separate downlink channel configured with separate transmission resources (frequency or time resources, transmission period, partial bandwidth (or partial bandwidth identifier), bandwidth, dedicated frequency (frequency information or SCell identifier), or subcarrier spacing, etc.), to allow terminals in RRC connected mode, RRC deactivated mode, or RRC idle mode for receiving MBS to receive MBS data. By transmitting as described above, one transmission resource can be used to transmit MBS data, and multiple terminals can receive MBS data, thereby preventing the waste of transmission resources and using transmission resources efficiently. In another method, as in Figure 8As proposed above, the aforementioned base station or network can transmit MBS data only to RRC-connected terminals that receive MBS data by means of system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or newly defined RRC messages) or separate transmission resources (frequency or time resources, transmission period, partial bandwidth (or partial bandwidth identifier), bandwidth, dedicated frequency (frequency information or SCell identifier), or subcarrier spacing, etc.) or downlink channels (e.g., DL-SCH channel, CCCH, or DCCH channel) configured in SRB0 (Common Control Channel (CCCH)) or SRB1 (Downlink Control Channel (DCCH)). In the above context, uplink MBS data can be MBS control data, MBS user data, RRC messages, RLC control data (RLC control PDU), PDCP control data (PDCP control PDU), MAC control data (MAC CE, control element), or newly defined messages. In the first MBS transmission method, the terminal can transmit uplink MBS data by configuring a separate uplink channel in system information, RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined RRC message), or control messages of the MBS channel (e.g., sent in the MBS control data channel), or physical channels or transport channels used for MBS service (e.g., UL-MBCH, MBS channel), or separate transmission resources (frequency or time resources, transmission period, partial bandwidth (or partial bandwidth identifier), bandwidth, dedicated frequency (frequency information or SCell identifier), or subcarrier spacing, etc.). For example, a terminal can include a MAC header in the uplink MBS data, configure logical channel identifiers (MBS control data (channel), MBS user data (channel), MBS user data (channel) for a specific MBS service, SRB0 (Common Control Channel (CCCH)), SRB1 (Downlink Control Channel (DCCH))), DRB, or logical channel identifiers configured or assigned by MAC control for information to match the purpose of the uplink MBS data (MBS control data or MBS user data or MBS user data for a specific MBS service), and send the uplink MBS data. Alternatively, it can be based on... Figure 7Which of the proposed bearer structures is configured to include an RLC header, PDCP header, or SDAP header? In another approach, the terminal can transmit uplink MBS data in the uplink transport resources indicated by a PDCCH with an RNTI identifier (configured for MBS user data (channel) or MBS user data (channel) for a specific MBS service) suitable for the purpose of the uplink MBS data (MBS control data, or MBS user data, or MBS user data for a specific MBS service). Because uplink MBS data can be identified by the RNTI identifier, uplink MBS data may not include a MAC header or logical channel identifier. In another approach, the terminal may include a MAC header in the uplink MBS data, configure logical channel identifiers (MBS control data (channel), MBS user data (channel), MBS user data (channel) for a specific MBS service, SRB0 (Common Control Channel (CCCH)), SRB1 (Downlink Control Channel (DCCH)), DRB, or logical channel identifiers configured or assigned by MAC control for information to match the purpose of the uplink MBS data (MBS control data or MBS user data or MBS user data for a specific MBS service), and then send the uplink MBS data. Alternatively, it can be based on... Figure 7 Which of the proposed bearer structures is configured to include an RLC header, a PDCP header, or an SDAP header?

[0224] -Second MBS transmission method 1i-01: When via Figure 8 The proposed method for receiving MBS services requires terminals to send uplink MBS data based on network requests or the terminal's own needs. Only terminals in RRC connection mode can send uplink MBS data to the base station or network. As described above, the network or base station can include network requests in MBS data (e.g., MBS control data, MBS user data, RRC messages, RLC control data (RLC control PDU), PDCP control data (PDCP control PDU), MAC control data (MAC CE, control element), or newly defined messages) and send them to the terminal. It can also send or configure indications of the MBS service status (e.g., stopping or restarting the service) or requests for responses to the MBS service (e.g., requests to determine whether the terminal is receiving a specific MBS service, whether the terminal wants to receive a specific MBS service, preferences for multicast versus unicast bearers, or switching preferences (whether the terminal wants to receive MBS services via multicast or unicast bearers). As described above... Figure 8The proposed method allows a base station or network to transmit MBS data, including a request from the network, in system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined RRC message) or MBS channel control messages (e.g., transmitted on the MBS control data channel), or the physical channel or transport channel for MBS service (e.g., the MBS channel (MBCH)), or in a separate downlink channel configured with separate transmission resources (frequency or time resources, transmission period, partial bandwidth (or partial bandwidth identifier), bandwidth, dedicated frequency (frequency information or SCell identifier), or subcarrier spacing, etc.), to allow terminals in RRC connected mode, RRC deactivated mode, or RRC idle mode for receiving MBS to receive MBS data. By transmitting as described above, one transmission resource can be used to transmit MBS data, and multiple terminals can receive MBS data, thereby preventing the waste of transmission resources and using transmission resources efficiently. In another method, as in Figure 8As proposed above, the aforementioned base station or network can transmit MBS data only to RRC-connected terminals that receive MBS data by means of system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or newly defined RRC messages) or individual transmission resources (frequency or time resources, transmission period, partial bandwidth (or partial bandwidth identifier), bandwidth, dedicated frequency (frequency information or SCell identifier), or subcarrier spacing, etc.) or downlink channels (e.g., DL-SCH channel, CCCH, or DCCH channel) configured in SRB0 (Common Control Channel (CCCH)) or SRB1 (Downlink Control Channel (DCCH)). In the above context, uplink MBS data can be MBS control data, MBS user data, RRC messages, RLC control data (RLC control PDU), PDCP control data (PDCP control PDU), MAC control data (MACCE, control element), or newly defined messages. In the second MBS transmission method, the RRC connection mode terminal can transmit uplink MBS data through system information, RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined new RRC message), or control messages of the MBS channel (e.g., transmitted in the MBS control data channel), or physical channels or transport channels for MBS services (e.g., UL-SCH, uplink shared channel, channel for general data services), or separate transport resources (frequency or time resources, transmission period, partial bandwidth (or partial bandwidth identifier), bandwidth, dedicated frequency (frequency information or SCell identifier) ​​or subcarrier spacing, etc.), or a separate uplink channel configured in the transport resources allocated to the PDCCH scrambled with the RNTI identifier (e.g., C-RNTI) assigned to the RRC connection mode terminal. As described above, when an RRC connection mode terminal transmits uplink MBS data via transmission resources allocated to a PDCCH that is scrambled using an RNTI identifier (e.g., C-RNTI) assigned to the RRC connection mode terminal, the terminal can transmit uplink MBS data via SRB0 (Common Control Channel (CCCH)), SRB1 (Downlink Control Channel (DCCH)), or DRB.For example, an RRC connection-mode terminal can include a MAC header in the uplink MBS data, configure logical channel identifiers (MBS control data (channel), MBS user data (channel), MBS user data (channel) for a specific MBS service, SRB0 (Common Control Channel (CCCH)), SRB1 (Downlink Control Channel (DCCH)), DRB, or logical channel identifiers configured or assigned by MAC control for information to match the purpose of the uplink MBS data (MBS control data or MBS user data or MBS user data for a specific MBS service), and send the uplink MBS data. Alternatively, it can be based on... Figure 7 Which of the proposed bearer structures is configured to include an RLC header, PDCP header, or SDAP header? In another approach, an RRC-connected terminal can transmit uplink MBS data in uplink transport resources indicated by a PDCCH with an RNTI identifier (configured for MBS user data (channel) or MBS user data (channel) for a specific MBS service) suitable for the purpose of uplink MBS data (MBS control data, or MBS user data, or MBS user data for a specific MBS service). Because uplink MBS data can be identified by the RNTI identifier, uplink MBS data may not include a MAC header or logical channel identifier. In another approach, the terminal may include a MAC header in the uplink MBS data, configure logical channel identifiers (MBS control data (channel), MBS user data (channel), MBS user data (channel) for a specific MBS service, SRB0 (Common Control Channel (CCCH)), SRB1 (Downlink Control Channel (DCCH)), DRB, or logical channel identifiers configured or assigned by MAC control for information to match the purpose of the uplink MBS data (MBS control data or MBS user data or MBS user data for a specific MBS service), and then send the uplink MBS data. Alternatively, it can be based on... Figure 7 Which of the proposed bearer structures is configured to include an RLC header, a PDCP header, or an SDAP header?

[0225] The following sections of this disclosure provide signaling procedures for a base station or network to support MBS services to a terminal and for a terminal to receive MBS services. As provided below, a base station may provide MBS services to a terminal, or a terminal may receive MBS services, through one of a variety of signaling procedures.

[0226] Figure 10 This is a diagram illustrating the first signaling process for MBS service support as proposed in this disclosure.

[0227] The first signaling procedure for MBS service support proposed in this disclosure may be characterized by supporting MBS service to the terminal based on system information.

[0228] exist Figure 10 In this context, terminal 1j-01 can select a suitable cell by performing a cell selection or reselection process in RRC idle mode or RRC inactive mode. After camping, it can receive system information 1j-05 in RRC idle mode, RRC inactive mode, or RRC connected mode, and receive the MBS service configuration information in the system information. The MBS service configuration information may include one or more of the following configuration information. That is, the network may send one or more of the following configuration information supporting MBS service in the system information.

[0229] - Does it support MBS service?

[0230] Configuration information of the physical channel or downlink or uplink transport channel (e.g., MBCH, MBCCH, MBTCH, or DL-SCH) for MBS service.

[0231] - Transmission resource information (frequency or time resources, transmission period, partial bandwidth (or partial bandwidth identifier), bandwidth, dedicated frequency (frequency information or SCell identifier), subcarrier spacing, subframe number, or identifier indicating transmission mode, etc.) for transmitting physical channels or downlink or uplink transmission channels (e.g., MBCH or MBS control data channel (MBCCH) or MBS user data channel (MBTCH)).

[0232] - Configuration information for the MBS services supported by the current cell. For example, a list of MBS services or a first identifier (e.g., Temporary Mobile Group Identifier (TMGI)) or a second identifier (e.g., session identifier) ​​for each MBS service can be configured or broadcast, and information for each logical channel identifier, bearer identifier, or RNTI identifier corresponding to the first or second identifier of each MBS service can be configured or broadcast. In another approach, the first identifier (e.g., Temporary Mobile Group Identifier (TMGI)) or the second identifier (e.g., session identifier) ​​or RNTI identifier for the MBS service can be configured or broadcast for each bearer (or bearer identifier) ​​or each logical channel or each RLC configuration or PDCP configuration. In the above, the first identifier may indicate the Public Land Mobile Network (PLMN) serving the MBS or may indicate the MBS service type or session. In the above, the second identifier may indicate a more specific MBS service session or type. Additionally, the configuration information for the MBS service may include information such as the transmission resources (frequency or time resources, transmission period, partial bandwidth (or partial bandwidth identifier), bandwidth, dedicated frequency (frequency information or SCell identifier), subcarrier spacing, subframe number, or identifier indicating the transmission mode, etc.) for supporting, broadcasting, or transmitting each MBS service.

[0233] -In order to Figure 7 The bearer structure proposed in the document for receiving MBS services may include bearer configuration. Furthermore, it may include indicator configuration information indicating whether to use HARQ reordering, HARQ retransmission, or HARQ ACK or NACK; indicator configuration information indicating whether to use RLC reordering function; transmission resource information for sending the aforementioned HARQ ACK or NACK; indicator configuration information indicating whether to use RLC sequential delivery function; configuration information for RLC reordering timer values; or indicator configuration information regarding whether to use PDCP out-of-order delivery function. In the above, for each MBS service or for each bearer configuration, there may be indicator configuration information indicating whether to use HARQ reordering, HARQ retransmission, or HARQ ACK or NACK; indicator configuration information indicating whether to use RLC reordering function; indicator configuration information indicating whether to use RLC sequential delivery function; configuration information for RLC reordering timer values; configuration information for RLC mode (TM, UM, or AM); configuration information regarding whether to use data segmentation function in RLC layer devices; or indicator configuration information regarding whether to use PDCP out-of-order delivery function. As an alternative approach, configuration information can be defined as default configuration information, allowing the terminal to configure some functions as an MBS bearer with default functions even without configuration information.

[0234] - Indicator configuration information indicating whether the bearer or bearer identifier supporting (sending or receiving) MBS services is a unicast or multicast bearer.

[0235] - Information related to the MBS dedicated carrier or the cell (Cell, SCell, or PCell) used for MBS service (e.g., frequency or time resources or cell identifier).

[0236] -MBS-specific bandwidth information (e.g., downlink or uplink bandwidth information) or MBS service bandwidth identifier information

[0237] - In the configuration information, you can also configure the length of the PDCP serial number or RLC serial number, and as another method, you can determine the default length of the RLC serial number or PDCP serial number.

[0238] As described above, when the system information does not include the configuration information for the MBS service in the stationed cell, the terminal can send a message or indicator to the base station, cell, or network requesting that the system information for the MBS service be broadcast in the stationed cell. Upon receiving the message or indicator, the base station or network can broadcast or send the MBS service configuration information as system information. In this way, the base station can prevent the waste of transmission resources that might occur from unnecessarily broadcasting system information related to the MBS service in the system information.

[0239] Upon receiving the aforementioned system information 1j-05, the terminal can store or apply configuration information related to the MBS service, search for or determine the MBS service that the terminal is interested in or wants to receive, and receive MBS data (MBS control data or MBS user data) in the transmission resources of the MBS control data channel or MBS user data channel used to send the MBS service of interest. When the terminal receives the aforementioned system information, or when the terminal attempts to receive the service of interest, or when the service of interest is generated or determined, or when the terminal is in or enters a cell or area supporting the MBS service in the system information, or when the terminal configures or connects to the MBS service (or session), or when it receives or broadcasts the configuration information or bearer configuration information of the MBS service in the system information or RRC message (e.g., RRCSetup, RRCReconfiguration, RRCRelease, or a newly defined new RRC message), or the control message of the MBS channel (e.g., sent in the MBS control data channel), the terminal can configure a unicast bearer, multicast bearer, or MBS bearer with the bearer structure proposed above for receiving the MBS service.

[0240] As described above, the terminal receives MBS data (e.g., MBS control data) through MBS control data channel 1j-10 or transmission resources for the MBS service of interest to receive configuration information related to the MBS service.

[0241] Configuration information related to the MBS service can be sent, including one or more of the following configuration information regarding MBS service support.

[0242] - Does it support MBS service?

[0243] Configuration information for physical channels or downlink or uplink transport channels (e.g., MBCH, MBCCH, MBTCH, DL-SCH) used for MBS services.

[0244] - Transmission resource information (frequency or time resources, transmission period, partial bandwidth (or partial bandwidth identifier), bandwidth, dedicated frequency (frequency information or SCell identifier), subcarrier spacing, subframe number, or identifier indicating transmission mode, etc.) transmitted through the physical channel or downlink or uplink transmission channel (e.g., MBCH or MBS control data channel (MBCCH) or MBS user data channel (MBTCH)).

[0245] - Configuration information for the MBS services supported by the current cell. For example, a list of MBS services or a first identifier (e.g., Temporary Mobile Group Identifier (TMGI)) or a second identifier (e.g., session identifier) ​​for each MBS service can be configured or broadcast, and information for each logical channel identifier, bearer identifier, or RNTI identifier corresponding to the first or second identifier of each MBS service can be configured or broadcast. In another approach, the first identifier (e.g., Temporary Mobile Group Identifier (TMGI)) or the second identifier (e.g., session identifier) ​​or RNTI identifier for the MBS service can be configured or broadcast for each bearer (or bearer identifier) ​​or each logical channel or each RLC configuration or PDCP configuration. In the above, the first identifier may indicate the Public Land Mobile Network (PLMN) serving the MBS or may indicate the MBS service type or session. In the above, the second identifier may indicate a more specific MBS service session or type. Additionally, the configuration information for the MBS service may include information such as the transmission resources (frequency or time resources, transmission period, partial bandwidth (or partial bandwidth identifier), bandwidth, dedicated frequency (frequency information or SCell identifier), subcarrier spacing, subframe number, or identifier indicating the transmission mode, etc.) for supporting, broadcasting, or transmitting each MBS service.

[0246] -In order to Figure 7Receiving MBS services in the bearer structure proposed herein may include bearer configuration. Furthermore, it may include indicator configuration information indicating whether to use HARQ reordering, HARQ retransmission, HARQ ACK, or NACK; indicator configuration information indicating whether to use RLC reordering functionality; transmission resource information for sending HARQ ACK or NACK; indicator configuration information indicating whether to use RLC sequential delivery functionality; configuration information for RLC reordering timer values; or indicator configuration information regarding whether to use PDCP out-of-order delivery functionality. In the foregoing, for each MBS service or for each bearer configuration, there may be indicator configuration information indicating whether to use the aforementioned HARQ reordering, HARQ retransmission, HARQ ACK, or NACK; indicator configuration information indicating whether to use RLC reordering functionality; indicator configuration information indicating whether to use RLC sequential delivery functionality; configuration information for RLC reordering timer values; configuration information for RLC mode (TM, UM, or AM); configuration information regarding whether to use data segmentation functionality in the RLC layer device; or indicator configuration information regarding whether to use PDCP out-of-order delivery functionality. As an alternative approach, configuration information can be defined as default configuration information, allowing the terminal to configure some functions as an MBS bearer with default functions even without configuration information.

[0247] - Indicator configuration information that indicates whether the bearer or bearer identifier that supports (sending or receiving) MBS services is a unicast bearer or a multicast bearer.

[0248] - Information related to the MBS dedicated carrier or the cell (Cell, SCell, or PCell) used for MBS service (e.g., frequency or time resources or cell identifier).

[0249] -MBS-specific bandwidth information (e.g., downlink or uplink bandwidth information) or MBS service bandwidth identifier information

[0250] - In the configuration information, you can also configure the length of the PDCP serial number or RLC serial number, and as another method, you can determine the default length of the RLC serial number or PDCP serial number.

[0251] Upon receiving the aforementioned configuration information related to the MBS service, in order to receive the MBS service that the terminal is interested in or wants to receive, the terminal may check the first identifier, second identifier, or RNTI identifier or logical channel identifier configured or assigned for the MBS service that the terminal is interested in or wants to receive, and through the MBS user data service channel, using it, or through the application in this disclosure. Figure 7 or Figure 8The method proposed in [1j-15] is used to receive MBS data for receiving MBS services.

[0252] Figure 11 This is a diagram illustrating the second signaling process for MBS service support as proposed in this disclosure.

[0253] The second signaling procedure for MBS service support proposed in this disclosure may be characterized by checking whether the terminal is interested in or broadcasting MBS services based on system information, or by configuring the connection with the network to indicate to the base station (or network) the MBS services that the terminal is interested in or wants to receive, or sending an instruction to receive MBS services, and the configuration information related to the MBS services is received from the base station (or network), and the MBS services are received. During the second signaling procedure, the terminal may maintain RRC idle mode, RRC connected mode, or RRC deactivation mode (e.g., it may receive MBS services without switching RRC modes). In another method, the feature may be that the terminal indicates to the base station (or network) the MBS services that the terminal is interested in or wants to receive, or sends an instruction to receive MBS services and enters RRC connected mode in RRC idle mode or RRC deactivation mode to receive configuration information related to MBS services from the base station (or network). Alternatively, after receiving the aforementioned configuration information related to MBS services, the terminal may receive MBS services in RRC connected mode, or in RRC idle mode or RRC deactivation mode.

[0254] exist Figure 11 In this context, terminal 1k-01 can select a suitable cell and camp on it by performing a cell selection or reselection process in RRC idle mode or RRC inactive mode. Then, it receives system information 1k-05 in RRC idle mode, RRC deactivation mode, or RRC connection mode, and receives the MBS service configuration information within the system information. The MBS service configuration information may include one or more of the following configuration information. That is, the network may send one or more of the following configuration information supporting the MBS service in the system information.

[0255] - Does it support MBS service?

[0256] Configuration information for physical channels or downlink or uplink transport channels (e.g., MBCH, MBCCH, MBTCH, DL-SCH) used for MBS services.

[0257] - Transmission resource information (frequency or time resources or transmission period or partial bandwidth (or partial bandwidth identifier) ​​or bandwidth or dedicated frequency (frequency information or SCell identifier) ​​or subcarrier spacing or subframe number or identifier indicating transmission mode, etc.) of the physical channel or downlink or uplink transmission channel (e.g., MBCH or MBS control data channel (MBCCH) or MBS user data channel (MBTCH)).

[0258] - Configuration information for the MBS services supported by the current cell. For example, a list of MBS services or a first identifier (e.g., Temporary Mobile Group Identifier (TMGI)) or a second identifier (e.g., session identifier) ​​for each MBS service can be configured or broadcast, and information for each logical channel identifier, bearer identifier, or RNTI identifier corresponding to the first or second identifier of each MBS service can be configured or broadcast. In another approach, the first identifier (e.g., Temporary Mobile Group Identifier (TMGI)) or the second identifier (e.g., session identifier) ​​or RNTI identifier for each bearer (or bearer identifier), each logical channel, each RLC configuration information, or each PDCP configuration information can be configured or broadcast. In the above, the first identifier may indicate the Public Land Mobile Network (PLMN) serving the MBS or may indicate the MBS service type or session. In the above, the second identifier may indicate a more specific MBS service session or type. Additionally, the configuration information for the MBS service may include information about the transmission resources (frequency or time resources, transmission period, partial bandwidth (or partial bandwidth identifier), bandwidth, dedicated frequency (frequency information or SCell identifier), subcarrier spacing, subframe number, or identifier indicating the transmission mode, etc.) that support, broadcast, or transmit each MBS service.

[0259] -In order to Figure 7The bearer structure proposed in the document for receiving MBS services may include bearer configuration. Furthermore, it may include indicator configuration information indicating whether HARQ reordering, HARQ retransmission, HARQ ACK, or NACK is used; indicator configuration information indicating whether RLC reordering functionality is used; transmission resource information for sending HARQ ACK or NACK; indicator configuration information indicating whether RLC sequential delivery functionality is used; configuration information for RLC reordering timer values; or indicator configuration information regarding whether PDCP out-of-order delivery functionality is used. In the foregoing, for each MBS service or for each bearer configuration, there may be indicator configuration information indicating whether the aforementioned HARQ reordering, HARQ retransmission, HARQ ACK, or NACK is used; indicator configuration information indicating whether RLC reordering functionality is used; indicator configuration information indicating whether RLC sequential delivery functionality is used; configuration information for RLC reordering timer values; configuration information for RLC mode (TM, UM, or AM); configuration information regarding whether data segmentation functionality is used in the RLC layer device; or indicator configuration information regarding whether PDCP out-of-order delivery functionality is used. As an alternative approach, configuration information can be defined as default configuration information, allowing the terminal to configure some functions as an MBS bearer with default functions even without configuration information.

[0260] - Indicator configuration information indicating whether the bearer or bearer identifier supporting (sending or receiving) MBS services is a unicast or multicast bearer.

[0261] - Information related to the MBS dedicated carrier or the cell (Cell, SCell, or PCell) used for MBS service (e.g., frequency or time resources or cell identifier).

[0262] -MBS-specific bandwidth information (e.g., downlink or uplink bandwidth information) or MBS service bandwidth identifier information

[0263] - In the configuration information, you can also configure the length of the PDCP serial number or RLC serial number, and as another method, you can determine the default length of the RLC serial number or PDCP serial number.

[0264] As described above, when the system information does not include the configuration information for the MBS service in the stationed cell, the terminal can send a message or indicator to the base station, cell, or network requesting that the system information for the MBS service be broadcast in the stationed cell. Upon receiving the message or indicator, the base station or network can broadcast or send the MBS service configuration information as system information. In this way, the base station can prevent the waste of transmission resources that might occur from unnecessarily broadcasting system information related to the MBS service in the system information.

[0265] In the preceding text, a terminal that has received or checked information related to the MBS service as system information, or a terminal that has identified an MBS service of interest broadcast in the current cell via system information, or a terminal that wants to request an MBS service of interest from the network, can perform a random access procedure and send a first RRC message to the network. The first RRC message can be an RRC message for a newly defined MBS service, and can be defined as an RRCSetupRequest message, an RRCResumeRequest message, another existing RRC message, MAC control information, RLC control information, or PDCP control information. The terminal can include an indication that it will receive the MBS service in the first RRC message, or can include an indication that it is receiving the MBS service due to an attempt to configure an RRC connection with the network, or can indicate a first identifier or second identifier, or logical channel identifier, or RNTI identifier, or bearer identifier for the MBS service that the terminal is interested in or intends to receive. In the first RRC message described above, the terminal may include an indicator indicating the type (e.g., unicast or multicast bearer) or structure of the bearer to be applied to, configured, or used for the MBS service, or the preferred type (e.g., unicast or multicast bearer) or structure of the bearer, or an indicator indicating in which RRC mode (RRC connected mode, RRC idle mode, or RRC deactivated mode) the terminal wants to receive MBS service support. Alternatively, in the above description, the terminal may send the first RRC message by including an indicator regarding MBS services it is no longer interested in, MBS services that are about to be discontinued, or MBS services that have already been discontinued, or an indicator for changing the MBS service to another MBS service. In the above description, the indicators included by the terminal in the first RRC message may be determined or indicated based on system information received in 1k-05. Furthermore, the terminal may include terminal capability information in the first RRC message. For example, when a terminal is about to receive MBS service, the terminal can send the functions supported by its capabilities or configurable configuration information, or the functions or configuration information implemented in the terminal, in the first RRC message, and notify the base station. As mentioned above, when the terminal has already configured a connection or is storing a terminal identifier assigned from the network, or when the terminal identifier is indicated by an upper-layer device (e.g., a NAS layer device or an RRC layer device), the terminal can send a first RRC message including the terminal identifier to allow the network to distinguish or inspect the terminal. For example, the base station or network can inspect the terminal based on the terminal identifier included above, retrieve and inspect the terminal's capability information from the core network, or retrieve and inspect the terminal's configuration information from a base station with which it has previously configured a connection.As described above, when the terminal receives the aforementioned system information, attempts to receive services of interest, when the services of interest are generated or determined, when the terminal is located in or enters a cell or area that supports the MBS service in the system information, or when the terminal establishes or connects to the MBS service (or session), the terminal may configure its connection to the network and send a first RRC message.

[0266] If the base station receives the first RRC message during the above 1k-10 process, the base station can check the MBS service or terminal capability information that the terminal is interested in or intends to receive.

[0267] The base station or network can send a second RRC message 1k-15 to the terminal to support or configure MBS services for the terminal 1k-15. The second RRC message can be an RRC message for a newly defined MBS service, and can be defined as an RRCRelease message, an RRCReconfiguration message, or another existing RRC message.

[0268] The second RRC message may include configuration information for the MBS service, or configuration information for the MBS service indicated by the terminal in the first RRC message, or bearer configuration information or unicast bearer or multicast bearer or MBS bearer configuration information for receiving the MBS service.

[0269] The second RRC message may include one or more of the following configuration information regarding MBS service support and may be sent.

[0270] - Does it support MBS service?

[0271] Configuration information for physical channels or downlink or uplink transport channels (e.g., MBCH, MBCCH, MBTCH, DL-SCH) used for MBS services.

[0272] - Transmission resource information (frequency or time resources, or transmission period, or partial bandwidth (or partial bandwidth identifier), or bandwidth, or dedicated frequency (frequency information or SCell identifier), or subcarrier spacing, or subframe number, or identifier indicating transmission mode, etc.) transmitted through the physical channel or downlink or uplink transmission channel (e.g., MBCH or MBS control data channel (MBCCH) or MBS user data channel (MBTCH)).

[0273] - Configuration information for the MBS services supported by the current cell. For example, a list of MBS services or a first identifier (e.g., Temporary Mobile Group Identifier (TMGI)) or a second identifier (e.g., session identifier) ​​for each MBS service can be configured or broadcast, and information for each logical channel identifier, bearer identifier, or RNTI identifier corresponding to the first or second identifier of each MBS service can be configured or broadcast. In another approach, for each bearer (or bearer identifier), or each logical channel, or each RLC configuration information, or each PDCP configuration information, a first identifier (e.g., Temporary Mobile Group Identifier (TMGI)) or a second identifier (e.g., session identifier) ​​or RNTI identifier for the MBS service can be configured or broadcast. In the above, the first identifier may indicate the Public Land Mobile Network (PLMN) serving the MBS or may indicate the MBS service type or session. In the above, the second identifier may indicate a more specific MBS service session or type. Additionally, the configuration information for the MBS service may include information about the transmission resources (frequency or time resources, transmission period, partial bandwidth (or partial bandwidth identifier), bandwidth, dedicated frequency (frequency information or SCell identifier), subcarrier spacing, subframe number, or identifier indicating the transmission mode, etc.) that support, broadcast, or transmit each MBS service.

[0274] -In order to Figure 7 The bearer structure proposed above for receiving MBS services may include bearer configuration. Furthermore, as stated above, it may include indicator configuration information indicating whether to use HARQ reordering or HARQ retransmission or HARQ ACK or NACK, or indicator configuration information indicating whether to use RLC reordering function, or transmission resource information for sending HARQ ACK or NACK, or indicator configuration information indicating whether to use RLC sequential delivery function, or configuration information for RLC reordering timer values, or indicator configuration information for using PDCP out-of-order delivery function. The above configuration information can be configured for each MBS service or each bearer to indicate whether to use HARQ reordering, HARQ retransmission, HARQ ACK, or NACK; or to indicate whether to use RLC reordering; or to indicate whether to use RLC sequential delivery; or to configure RLC reordering timer values; or to configure RLC modes (TM, UM, or AM); or to configure whether to use data segmentation in RLC layer devices; or to configure whether to use PDCP out-of-order delivery. Alternatively, the configuration information can be defined as default configuration information, allowing the terminal to configure certain functions as an MBS bearer with default functions even without configuration information.

[0275] - Indicator configuration information indicating whether the bearer or bearer identifier supporting (sending or receiving) MBS services is a unicast or multicast bearer.

[0276] - Indicators or configuration information for switching to RRC idle mode, RRC disabled mode, or RRC connected mode.

[0277] -The MBS service configuration information or bearer configuration information proposed above for receiving MBS services in RRC idle mode

[0278] -The MBS service configuration information or bearer configuration information proposed above for receiving MBS services in RRC deactivation mode

[0279] - Information related to the MBS dedicated carrier or the cell (Cell, SCell, or PCell) used for MBS service (e.g., frequency or time resources or cell identifier).

[0280] -MBS-specific bandwidth information (e.g., downlink or uplink bandwidth information) or MBS service bandwidth identifier information

[0281] In the configuration information, you can also configure the length of the PDCP serial number or RLC serial number, and as another method, you can determine the default length of the RLC serial number or PDCP serial number.

[0282] Upon receiving the second RRC message, the terminal can store or apply configuration information related to the MBS service, search for or determine the MBS service that the terminal is interested in or wants to receive, and can receive MBS data (MBS control data or MBS user data) in the transmission resources of the MBS control data channel or MBS user data channel used to send the MBS service of interest. When the terminal receives system information or attempts to receive the service of interest, or when the service of interest is generated or determined, or when the terminal is in or enters a cell or area that supports the MBS service in the system information, or when the MBS service (or session) is configured or connected, or when the terminal receives or broadcasts configuration information or bearer configuration information of the MBS service in the system information or RRC message (e.g., RRCSetup, RRCReconfiguration, RRCRelease or a newly defined new RRC message) or control message of the MBS channel (e.g., sent in the MBS control data channel), the terminal can configure a unicast bearer, multicast bearer, or MBS bearer with the bearer structure proposed above for receiving the MBS service.

[0283] As described above, a terminal can receive MBS data (e.g., MBS control data) through the MBS control data channel or transmission resources used for the MBS service of interest to receive configuration information related to the MBS service.

[0284] In the foregoing, upon receiving configuration information related to the MBS service, in order to receive the MBS service that the terminal is interested in or intends to receive, the terminal can check the first identifier or second identifier or RNTI identifier or logical channel identifier configured or assigned for the MBS service that the terminal is interested in or wants to receive, and can use the first identifier or second identifier or RNTI identifier or logical channel identifier, through MBS user data service channel 1k-20, through the application in this disclosure. Figure 7 or Figure 8 The method proposed in the paper is used to receive MBS data.

[0285] In the above method, the feature may be that no encryption or integrity protection process is applied to the first RRC message or the second RRC message. In another method, the feature may be that, to enhance security, no encryption or integrity protection process is applied to the first RRC message or the second RRC message, and an encryption or integrity protection process is applied to the first RRC message or the second RRC message. In yet another method, the feature may be that, to further enhance security, an encryption or integrity protection process is applied to the first RRC message or the second RRC message, and an encryption or integrity protection process is applied to the first RRC message or the second RRC message.

[0286] Figure 12 This is a diagram illustrating the third signaling process for MBS service support as proposed in this disclosure.

[0287] The third signaling process for MBS service support proposed in this disclosure may be characterized by the terminal checking, based on system information, whether the MBS service that the terminal is interested in or broadcast has been broadcast or configured with a connection to the network, indicating to the base station (or network) the MBS service that the terminal is interested in or wants to receive, or sending an instruction to receive the MBS service, and receiving configuration information related to the MBS service from the base station (or network) and receiving the MBS service. During the third signaling process, the terminal may maintain RRC idle mode, RRC connected mode, or RRC deactivation mode. In another method, the terminal may indicate to the base station (or network) the MBS service that the terminal is interested in or wants to receive, or send an instruction to receive the MBS service, and enter RRC connected mode in RRC idle mode or RRC deactivation mode to receive configuration information related to the MBS service from the base station (or network). Alternatively, after receiving the aforementioned configuration information related to the MBS service, the terminal may receive the MBS service in RRC connected mode, or in RRC idle mode or RRC deactivation mode.

[0288] exist Figure 12 In the process of performing cell selection or reselection in RRC idle mode or RRC deactivation mode to select a suitable cell and camp on it, terminal 1l-01 can receive system information (1l-05) in RRC deactivation mode or RRC connection mode, and can receive MBS service configuration information in the system information. MBS service configuration information may include one or more of the following configuration information. That is, the network can send one or more of the following configuration information supporting MBS service in the system information.

[0289] - Does it support MBS service?

[0290] Configuration information for physical channels or downlink or uplink transport channels (e.g., MBCH, MBCCH, MBTCH, DL-SCH) used for MBS services.

[0291] - Transmission resource information (frequency or time resources, transmission period, partial bandwidth (or partial bandwidth identifier), bandwidth, dedicated frequency (frequency information or SCell identifier), subcarrier spacing, subframe number, or identifier indicating transmission mode, etc.) transmitted through the physical channel or downlink or uplink transmission channel (e.g., MBCH or MBS control data channel (MBCCH) or MBS user data channel (MBTCH)).

[0292] - Configuration information for the MBS services supported by the current cell. For example, a list of MBS services or a first identifier (e.g., Temporary Mobile Group Identifier (TMGI)) or a second identifier (e.g., session identifier) ​​for each MBS service can be configured or broadcast, and information for each logical channel identifier, bearer identifier, or RNTI identifier corresponding to the first or second identifier of each MBS service can be configured or broadcast. Alternatively, the first identifier (e.g., Temporary Mobile Group Identifier (TMGI)) or the second identifier (e.g., session identifier) ​​or RNTI identifier for each bearer (or bearer identifier), each logical channel, each RLC configuration information, or each PDCP configuration information can be configured or broadcast. In the above context, the first identifier may indicate the Public Land Mobile Network (PLMN) serving the MBS or may indicate the MBS service type or session. In the above context, the second identifier may indicate a more specific MBS service session or type. In addition, the configuration information for the MBS service may include information on the transmission resources (frequency or time resources, transmission period, partial bandwidth (or partial bandwidth identifier), bandwidth, dedicated frequency (frequency information or SCell identifier), subcarrier spacing, subframe number, or identifier indicating the transmission mode, etc.) used to support, broadcast, or transmit each MBS service.

[0293] -exist Figure 7 The proposed bearer structure may include bearer configurations for receiving MBS services. Furthermore, it may include indicator configuration information indicating whether HARQ reordering, HARQ retransmission, HARQ ACK, or NACK is used; indicator configuration information indicating whether RLC reordering functionality is used; transmission resource information for sending HARQ ACK or NACK; indicator configuration information indicating whether RLC sequential delivery functionality is used; configuration information for RLC reordering timer values; or indicator configuration information regarding whether PDCP out-of-order delivery functionality is used. In the above, for each MBS service or for each bearer configuration, there may be indicator configuration information indicating whether HARQ reordering, HARQ retransmission, or HARQ ACK or NACK is used; indicator configuration information indicating whether RLC reordering functionality is used; indicator configuration information indicating whether RLC sequential delivery functionality is used; configuration information for RLC reordering timer values; configuration information for RLC mode (TM, UM, or AM); configuration information regarding whether data segmentation functionality is used in the RLC layer device; or indicator configuration information regarding whether PDCP out-of-order delivery functionality is used. As an alternative approach, configuration information can be defined as default configuration information, allowing the terminal to configure some functions as an MBS bearer with default functions even without configuration information.

[0294] - Indicator configuration information indicating whether the bearer or bearer identifier supporting (sending or receiving) MBS services is a unicast or multicast bearer.

[0295] - Information related to the MBS dedicated carrier or the cell (Cell, SCell, or PCell) used for MBS service (e.g., frequency or time resources or cell identifier).

[0296] -MBS-specific bandwidth information (e.g., downlink or uplink bandwidth information) or MBS service bandwidth identifier information

[0297] - In the configuration information, you can also configure the length of the PDCP serial number or RLC serial number, and as another method, you can determine the default length of the RLC serial number or PDCP serial number.

[0298] As described above, if the system information does not include the configuration information for the MBS service in the cell where the terminal is camped, the terminal can send a message or indicator to the base station, cell, or network requesting that the system information for the MBS service be broadcast in the camped cell. Upon receiving the message or indicator, the base station or network can broadcast or send the MBS service configuration information as system information. In this way, the base station can prevent the waste of transmission resources that might occur from unnecessarily broadcasting system information related to the MBS service in the system information.

[0299] A terminal that has received or acknowledged information related to the MBS service as system information as described above, or a terminal that has acknowledged that an interested MBS service has been broadcast in the current cell via system information, or a terminal that intends to request an interested MBS service from the network, may perform a random access procedure and send a first RRC message to the network. The first RRC message may be an RRC message for a newly defined MBS service, and may be defined as an RRCSetupRequest message, an RRCResumeRequest message, or another existing RRC message. The terminal may include an indicator indicating that it will receive MBS services in the first RRC message, or may include an indicator indicating that it will receive MBS services due to an attempt to configure an RRC connection with the network. Alternatively, as described above, when the terminal has already previously configured a connection or is storing a terminal identifier assigned from the network (e.g., a terminal identifier assigned to the core network (5G-S-TMSI) or a terminal identifier assigned from the base station for RRC connection recovery (short I-RNTI or I-RNTI)), or when the terminal identifier is indicated by an upper-layer device (e.g., a NAS layer device or an RRC layer device), the terminal may send a first RRC message including the terminal identifier to allow the network to distinguish or identify the terminal. For example, the base station or network may check the terminal based on the terminal identifier included above, retrieve and confirm the terminal's capability information from the core network, or retrieve and check the terminal's configuration information or terminal capability information from a base station with which it has previously configured a connection. As described above, when the terminal receives the aforementioned system information, attempts to receive services of interest, when the services of interest are generated or determined, when the terminal is located in or enters a cell or area that supports the MBS service in the system information, or when the terminal establishes or connects to the MBS service (or session), the terminal may configure its connection to the network and send a first RRC message.

[0300] When the base station receives the first RRC message during the process described in 1l-10 above, the base station can check the MBS service or terminal capability information that the terminal is interested in or intends to receive.

[0301] The base station or network can send a second RRC message (11-15) to the terminal to support or configure MBS services (11-15). The second RRC message can be an RRC message for a newly defined MBS service, and can be defined as an RRCSetup message, an RRCResume message, or another existing RRC message.

[0302] The second RRC message may include configuration information for the MBS service, configuration information for the MBS service indicated by the terminal in the first RRC message, and bearer configuration information or unicast bearer or multicast bearer or MBS bearer configuration information for receiving MBS services.

[0303] The second RRC message may include one or more of the following configuration information regarding MBS service support and may be sent.

[0304] - Does it support MBS service?

[0305] Configuration information for physical channels or downlink or uplink transport channels (e.g., MBCH, MBCCH, MBTCH, DL-SCH) used for MBS services.

[0306] - Transmission resource information (frequency or time resources, transmission period, partial bandwidth (or partial bandwidth identifier), bandwidth, dedicated frequency (frequency information or SCell identifier), subcarrier spacing, subframe number, or identifier indicating transmission mode, etc.) transmitted through the physical channel or downlink or uplink transmission channel (e.g., MBCH or MBS control data channel (MBCCH) or MBS user data channel (MBTCH)).

[0307] - Configuration information for the MBS services supported by the current cell. For example, a list of MBS services or a first identifier (e.g., Temporary Mobile Group Identifier (TMGI)) or a second identifier (e.g., session identifier) ​​for each MBS service can be configured or broadcast, and information for each logical channel identifier, bearer identifier, or RNTI identifier corresponding to the first or second identifier of each MBS service can be configured or broadcast. In another approach, a first identifier (e.g., Temporary Mobile Group Identifier (TMGI)) or a second identifier (e.g., session identifier) ​​or RNTI identifier can be configured or broadcast for each bearer (or bearer identifier) ​​or each logical channel or each RLC configuration information or each PDCP configuration information of the MBS service. In the above, the first identifier may indicate the Public Land Mobile Network (PLMN) serving the MBS or may indicate the MBS service type or session. In the above, the second identifier may indicate a more specific MBS service session or type. Additionally, the configuration information for the MBS service may include information on the transmission resources (frequency or time resources, transmission period, partial bandwidth (or partial bandwidth identifier), bandwidth, dedicated frequency (frequency information or SCell identifier), subcarrier spacing, subframe number, or identifier indicating transmission mode, etc.) that support, broadcast, or transmit for each MBS service.

[0308] -In order to Figure 7The bearer structure proposed in the document for receiving MBS services may include bearer configuration. Furthermore, it may include indicator configuration information indicating whether HARQ reordering, HARQ retransmission, HARQ ACK, or NACK is used; indicator configuration information indicating whether RLC reordering functionality is used; transmission resource information for sending HARQ ACK or NACK; indicator configuration information indicating whether RLC sequential delivery functionality is used; configuration information for RLC reordering timer values; or indicator configuration information regarding whether PDCP out-of-order delivery functionality is used. In the above, for each MBS service or for each bearer configuration, there may be indicator configuration information indicating whether HARQ reordering, HARQ retransmission, HARQ ACK, or NACK is used; indicator configuration information indicating whether RLC reordering functionality is used; indicator configuration information indicating whether RLC sequential delivery functionality is used; configuration information for RLC reordering timer values; configuration information for RLC mode (TM, UM, or AM); configuration information regarding whether data segmentation functionality is used in the RLC layer device; or indicator configuration information regarding whether PDCP out-of-order delivery functionality is used. As an alternative approach, configuration information can be defined as default configuration information, allowing the terminal to configure some functions as an MBS bearer with default functions even without configuration information.

[0309] - Indicator configuration information indicating whether the bearer or bearer identifier supporting (sending or receiving) MBS services is a unicast or multicast bearer.

[0310] - Information related to the MBS dedicated carrier or the cell (Cell, SCell, or PCell) used for MBS service (e.g., frequency or time resources or cell identifier).

[0311] -MBS-specific bandwidth information (e.g., downlink or uplink bandwidth information) or MBS service bandwidth identifier information

[0312] - In the configuration information, you can also configure the length of the PDCP serial number or RLC serial number, and as another method, you can determine the default length of the RLC serial number or PDCP serial number.

[0313] As described above, when a terminal receives system information or attempts to receive a service of interest, or when a service of interest is generated or determined, or when the terminal is in or enters a cell or area that supports the MBS service in the system information, or when the terminal configures or connects to the MBS service (or session), or when it receives or broadcasts configuration information or bearer configuration information for the MBS service in system information or RRC messages (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease, or a newly defined new RRC message), or control messages for the MBS channel (e.g., sent in the MBS control data channel), the terminal can configure a unicast bearer, multicast bearer, or MBS bearer with the bearer structure proposed above for receiving the MBS service.

[0314] When the terminal receives the second RRC message, the terminal can apply the configuration information included in the second RRC message (e.g., RRCSetupComplete or RRCResumeComplete) and send a third RRC message to the base station or network in response (11-20).

[0315] In the third RRC message, the terminal may include an indication that it will receive MBS services in the first RRC message, or it may include an indication that it is receiving MBS services due to an attempt to configure an RRC connection with the network, or it may indicate which MBS service the terminal is interested in or intends to receive by including a first identifier or a second identifier or a logical channel identifier or an RNTI identifier or a bearer identifier for the MBS service. As described above, the terminal may include in the first RRC message an indication of the type (e.g., unicast or multicast bearer) or structure of the bearer to be applied to, configured, or used for the MBS service, or the preferred type (e.g., unicast or multicast bearer) or structure of the bearer, or an indication of which RRC mode (RRC connected mode, RRC idle mode, or RRC deactivated mode) the terminal wants to receive MBS services. Alternatively, as described above, the terminal may send a first RRC message including an indication of an MBS service it is no longer interested in or wants to stop receiving, or an indication of an MBS service it has already stopped receiving, or an indication of changing the MBS service to another MBS service. As stated above, the indicator included by the terminal in the first RRC message can be determined or indicated based on the system information received in 1l-05.

[0316] The base station may send a fourth RRC message (e.g., RRCReconfiguration(1l-30)) to the aforementioned terminal based on preferences reported by the terminal or indicated indicators, or the base station implementation, to configure or reconfigure the bearer used by the terminal to support MBS services, or to configure or reconfigure configuration information related to MBS services. For example, the fourth RRC message may include configuration information for changing the bearer type (e.g., an indicator for switching from a unicast bearer to a multicast bearer, an indicator for switching from a multicast bearer to a unicast bearer, or corresponding bearer configuration information), logical channel identifier information changed or updated for each MBS service, RNTI identifier information for the MBS service, or first identifier or second identifier information, etc.

[0317] The fourth RRC message may include or include some of the following information.

[0318] - Does it support MBS service?

[0319] Configuration information for the physical channels or downlink or uplink transport channels (e.g., MBCH, MBCCH, MBTCH, or DL-SCH) of the MBS service.

[0320] - Transmission resource information (frequency or time resources, transmission period, partial bandwidth (or partial bandwidth identifier), bandwidth or dedicated frequency (frequency information or SCell identifier), subcarrier spacing, subframe number, or identifier indicating transmission mode, etc.) transmitted through the physical channel or downlink or uplink transmission channel (e.g., MBCH or MBS control data channel (MBCCH) or MBS user data channel (MBTCH)).

[0321] - Configuration information for the MBS services supported by the current cell. For example, a list of MBS services or a first identifier (e.g., Temporary Mobile Group Identifier (TMGI)) or a second identifier (e.g., session identifier) ​​for each MBS service can be configured or broadcast, and information for each logical channel identifier, bearer identifier, or RNTI identifier corresponding to the first or second identifier of each MBS service can be configured or broadcast. In another approach, the first identifier (e.g., Temporary Mobile Group Identifier (TMGI)) or the second identifier (e.g., session identifier) ​​or RNTI identifier for the MBS service can be configured or broadcast for each bearer (or bearer identifier) ​​or each logical channel or each RLC configuration or PDCP configuration. In the above, the first identifier may indicate the Public Land Mobile Network (PLMN) serving the MBS or may indicate the MBS service type or session. In the above, the second identifier may indicate a more specific MBS service session or type. Additionally, the configuration information for the MBS service may include information about the transmission resources (frequency or time resources, transmission period, partial bandwidth (or partial bandwidth identifier), bandwidth, dedicated frequency (frequency information or SCell identifier), subcarrier spacing, subframe number, or identifier indicating the transmission mode, etc.) that support, broadcast, or transmit each MBS service.

[0322] -In order to Figure 7 The bearer structure proposed in the document for receiving MBS services may include bearer configuration. Furthermore, it may include indicator configuration information indicating whether HARQ reordering, HARQ retransmission, HARQ ACK, or NACK is used; indicator configuration information indicating whether RLC reordering is used; transmission resource information for sending HARQ ACK or NACK; indicator configuration information indicating whether RLC sequential delivery is used; configuration information for RLC reordering timer values; or indicator configuration information regarding whether PDCP out-of-order delivery is used. For each MBS service or each bearer configuration, it may include indicator configuration information indicating whether to use the aforementioned HARQ reordering, HARQ retransmission, HARQ ACK, or NACK; indicator configuration information indicating whether to use RLC reordering; indicator configuration information indicating whether to use RLC sequential delivery; configuration information for RLC reordering timer values; configuration information for RLC mode (TM, UM, or AM); configuration information regarding whether to use data segmentation in the RLC layer device; or indicator configuration information regarding whether to use PDCP out-of-order delivery. As an alternative approach, configuration information can be defined as default configuration information, allowing the terminal to configure some functions as an MBS bearer with default functions even without configuration information.

[0323] - Indicator configuration information that indicates whether the bearer or bearer identifier that supports (sending or receiving) MBS services is a unicast bearer or a multicast bearer.

[0324] - Indicates whether the bearer or bearer identifier supporting (sending or receiving) MBS services is a unicast or multicast bearer.

[0325] - Indicators or configuration information for switching to RRC idle mode, RRC disabled mode, or RRC connected mode.

[0326] -The MBS service configuration information or bearer configuration information proposed above for receiving MBS services in RRC idle mode

[0327] -The MBS service configuration information or bearer configuration information proposed above for receiving MBS services in RRC deactivation mode

[0328] - Information related to the MBS dedicated carrier or the cell (Cell, SCell, or PCell) used for MBS service (e.g., frequency or time resources or cell identifier).

[0329] -MBS-specific bandwidth information (e.g., downlink or uplink bandwidth information) or MBS service bandwidth identifier information

[0330] - In the configuration information, you can also configure the length of the PDCP serial number or RLC serial number, and as another method, you can determine the default length of the RLC serial number or PDCP serial number.

[0331] After receiving the fourth RRC message and storing or applying configuration information related to MBS services, the terminal can configure a fifth RRC message (e.g., RRCReconfigurationComplete(1l-35)) to indicate successful configuration or reconfiguration and send it to the base station.

[0332] Upon receiving the aforementioned configuration information related to the MBS service, in order to receive the MBS service of interest or intended to be received in RRC connection mode, the terminal can check the first identifier or second identifier or RNTI identifier or logical channel identifier configured or assigned for the MBS service of interest or intended to be received, and using them, the terminal can access the MBS user data service channel through the application disclosed herein. Figure 7 or Figure 8 The method proposed in [the paper] is used to receive MBS data (1l-40).

[0333] As described above, a terminal can receive MBS data (e.g., MBS control data) through the MBS control data channel or transmission resources used for the MBS service of interest to receive configuration information related to the MBS service.

[0334] As described above, when a base station (e.g., according to its implementation or at the request of the terminal or instruction from the terminal) attempts to switch the terminal to RRC deactivation mode or RRC idle mode, the base station may configure a sixth RRC message (e.g., RRC Release message (1l-45)) and send it to the terminal to switch to RRC idle mode or RRC deactivation mode. The sixth RRC message (1l-45) may include one or more of the following information, enabling the terminal to continue receiving MBS services even in RRC idle mode or RRC deactivation mode.

[0335] - Does it support MBS service?

[0336] Configuration information for the physical channels or downlink or uplink transport channels (e.g., MBCH, MBCCH, MBTCH, or DL-SCH) of the MBS service.

[0337] - Transmission resource information (frequency or time resources, transmission period, partial bandwidth (or partial bandwidth identifier), bandwidth or dedicated frequency (frequency information or SCell identifier), subcarrier spacing, subframe number, or identifier indicating transmission mode, etc.) transmitted through the physical channel or downlink or uplink transmission channel (e.g., MBCH or MBS control data channel (MBCCH) or MBS user data channel (MBTCH)).

[0338] - Configuration information for the MBS services supported by the current cell. For example, a list of MBS services or a first identifier (e.g., Temporary Mobile Group Identifier (TMGI)) or a second identifier (e.g., session identifier) ​​for each MBS service can be configured or broadcast, and information for each logical channel identifier, bearer identifier, or RNTI identifier corresponding to the first or second identifier of each MBS service can be configured or broadcast. In another approach, the first identifier (e.g., Temporary Mobile Group Identifier (TMGI)) or the second identifier (e.g., session identifier) ​​or RNTI identifier for the MBS service can be configured or broadcast for each bearer (or bearer identifier) ​​or each logical channel or each RLC configuration or PDCP configuration. In the above, the first identifier may indicate the Public Land Mobile Network (PLMN) serving the MBS or may indicate the MBS service type or session. In the above, the second identifier may indicate a more specific MBS service session or type. Additionally, the configuration information for the MBS service may include information about the transmission resources (frequency or time resources, transmission period, partial bandwidth (or partial bandwidth identifier), bandwidth, dedicated frequency (frequency information or SCell identifier), subcarrier spacing, subframe number, or identifier indicating the transmission mode, etc.) that support, broadcast, or transmit each MBS service.

[0339] -In order to Figure 7 The bearer structure proposed in the document for receiving MBS services may include bearer configuration. Furthermore, it may include indicator configuration information indicating whether HARQ reordering, HARQ retransmission, HARQ ACK, or NACK is used; indicator configuration information indicating whether RLC reordering is used; transmission resource information for sending HARQ ACK or NACK; indicator configuration information indicating whether RLC sequential delivery is used; configuration information for RLC reordering timer values; or indicator configuration information regarding whether PDCP out-of-order delivery is used. For each MBS service or each bearer configuration, it may include indicator configuration information indicating whether to use the aforementioned HARQ reordering, HARQ retransmission, HARQ ACK, or NACK; indicator configuration information indicating whether to use RLC reordering; indicator configuration information indicating whether to use RLC sequential delivery; configuration information for RLC reordering timer values; configuration information for RLC mode (TM, UM, or AM); configuration information regarding whether to use data segmentation in the RLC layer device; or indicator configuration information regarding whether to use PDCP out-of-order delivery. As an alternative approach, configuration information can be defined as default configuration information, allowing the terminal to configure some functions as an MBS bearer with default functions even without configuration information.

[0340] - Indicator configuration information that indicates whether the bearer or bearer identifier that supports (sending or receiving) MBS services is a unicast bearer or a multicast bearer.

[0341] - Indicator configuration information that indicates whether the bearer or bearer identifier that supports (sending or receiving) MBS services is a unicast bearer or a multicast bearer.

[0342] - Indicators or configuration information for switching to RRC idle mode, RRC disabled mode, or RRC connected mode.

[0343] -The MBS service configuration information or bearer configuration information proposed above for receiving MBS services in RRC idle mode

[0344] -The MBS service configuration information or bearer configuration information proposed above for receiving MBS services in RRC deactivation mode

[0345] - Information related to the MBS dedicated carrier or the cell (Cell, SCell, or PCell) used for MBS service (e.g., frequency or time resources or cell identifier).

[0346] -MBS-specific bandwidth information (e.g., downlink or uplink bandwidth information) or MBS service bandwidth identifier information

[0347] - In the configuration information, you can also configure the length of the PDCP serial number or RLC serial number, and as another method, you can determine the default length of the RLC serial number or PDCP serial number.

[0348] Upon receiving the aforementioned configuration information related to the MBS service, in RRC idle mode or RRC deactivation mode, in order to receive the MBS service that the terminal is interested in or intends to receive, the terminal can check the first identifier or second identifier or RNTI identifier or logical channel identifier configured or assigned for the MBS service it is interested in or wants to receive, and use the first identifier or second identifier or RNTI identifier or logical channel identifier to receive the MBS user data service channel, through the application disclosed herein. Figure 7 or Figure 8 The method proposed in [the paper] is to receive MBS data in order to receive MBS services (11-50).

[0349] In the above description, under RRC connection mode, the terminal sends a first RRC message (11-10) for receiving MBS service, can receive a second RRC message (11-15), send a third RRC message (11-20) again, receive a fourth RRC message, send a fifth RRC message, and receive MBS service. Alternatively, subsequently, under RRC idle mode or RRC inactive mode, the terminal can receive a sixth RRC message (11-45) and can receive MBS service.

[0350] In another method, the terminal can send a first RRC message (11-10) for receiving MBS services, receive a second RRC message (11-15) (switch to RRC connection mode) and send a third RRC message (11-20) again, and receive MBS services in RRC idle mode or RRC deactivation mode by receiving a sixth RRC message (11-45) and switching to RRC idle mode or RRC deactivation mode.

[0351] In the above description, the characteristic may be that no encryption or integrity protection process is applied to the first or second RRC message. In another approach, the characteristic may be that, for enhanced security, no encryption or integrity protection process is applied to the first or second RRC message, and an encryption or integrity protection process is applied to both the first and second RRC messages. In yet another method, the characteristic may be that, for enhanced security, no encryption or integrity protection process is applied to the first or second RRC message, and an encryption or integrity protection process is applied to both the first and second RRC messages. In the above description, an encryption or integrity protection process may be applied to the third RRC message. Additionally, an encryption or integrity protection process may be applied to the fourth, fifth, or sixth RRC message.

[0352] Figure 13 This is a diagram illustrating the fourth signaling process for MBS service support as proposed in this disclosure.

[0353] The fourth signaling process for MBS service support proposed in this disclosure may be characterized by, based on system information, the terminal checking whether the MBS service it is interested in or broadcast is being broadcast, or configuring a connection with the network to indicate to the base station (or network) the MBS service it is interested in or wants to receive, sending an instruction to receive the MBS service, receiving configuration information related to the MBS service from the base station (or network), and receiving the MBS service. During the fourth signaling process, the terminal may maintain RRC idle mode, RRC connected mode, or RRC deactivation mode. In another method, the terminal indicates to the base station (or network) the MBS service it is interested in or wants to receive, or sends an instruction to receive the MBS service, and enters RRC connected mode in RRC idle mode or RRC deactivation mode to receive configuration information related to the MBS service from the base station (or network). Alternatively, after receiving the aforementioned configuration information related to the MBS service, the terminal may receive the MBS service in RRC connected mode, or in RRC idle mode or RRC deactivation mode.

[0354] exist Figure 13 In this context, terminal 1m-01 can select a suitable cell and camp on it by performing a cell selection or reselection process in RRC idle mode or RRC deactivation mode. Then, it receives system information (1m-05) in RRC idle mode, RRC deactivation mode, or RRC connection mode, and receives the MBS service configuration information within the system information. The MBS service configuration information may include one or more of the following configuration information. That is, the network may send one or more of the following configuration information supporting the MBS service in the system information.

[0355] - Does it support MBS service?

[0356] Configuration information for the physical channels or downlink or uplink transport channels (e.g., MBCH, MBCCH, MBTCH, or DL-SCH) of the MBS service.

[0357] - Transmission resource information (frequency or time resources, transmission period, partial bandwidth (or partial bandwidth identifier), bandwidth or dedicated frequency (frequency information or SCell identifier), subcarrier spacing, subframe number, or identifier indicating transmission mode, etc.) transmitted through the physical channel or downlink or uplink transmission channel (e.g., MBCH or MBS control data channel (MBCCH) or MBS user data channel (MBTCH)).

[0358] - Configuration information for the MBS services supported by the current cell. For example, a list of MBS services or a first identifier (e.g., temporary mobile group identifier) ​​or a second identifier (e.g., session identifier) ​​for each MBS service can be configured or broadcast, and information for each logical channel identifier, bearer identifier, or RNTI identifier corresponding to the first or second identifier of each MBS service can be configured or broadcast. Alternatively, the first identifier (e.g., temporary mobile group identifier) ​​or second identifier (e.g., session identifier) ​​or RNTI identifier for each bearer (or bearer identifier), each logical channel, each RLC configuration information, or each PDCP configuration information can be configured or broadcast. In the above context, the first identifier may indicate the Public Land Mobile Network (PLMN) serving the MBS or may indicate the MBS service type or session. In the above context, the second identifier may indicate a more specific MBS service session or type. Additionally, the configuration information for the MBS service may include information about the transmission resources (frequency or time resources, transmission period, partial bandwidth (or partial bandwidth identifier), bandwidth, dedicated frequency (frequency information or SCell identifier), subcarrier spacing, subframe number, or identifier indicating the transmission mode, etc.) that support, broadcast, or transmit each MBS service.

[0359] -In order to Figure 7 The bearer structure proposed in the document for receiving MBS services may include bearer configuration. Additionally, it may include indicator configuration information indicating whether HARQ reordering, HARQ retransmission, HARQ ACK, or NACK is used; indicator configuration information indicating whether RLC reordering is used; transmission resource information for sending HARQ ACK or NACK; indicator configuration information indicating whether RLC sequential delivery is used; configuration information for RLC reordering timer values; or indicator configuration information regarding whether PDCP out-of-order delivery is used. In the above, for each MBS service or for each bearer configuration, there may be indicator configuration information indicating whether HARQ reordering, HARQ retransmission, or HARQ ACK or NACK is used; indicator configuration information indicating whether RLC reordering is used; indicator configuration information indicating whether RLC sequential delivery is used; configuration information for RLC reordering timer values; configuration information for RLC mode (TM, UM, or AM); configuration information regarding whether data segmentation is used in the RLC layer device; or indicator configuration information regarding whether PDCP out-of-order delivery is used. As an alternative approach, configuration information can be defined as default configuration information, allowing the terminal to configure some functions as an MBS bearer with default functions even without configuration information.

[0360] - Indicator configuration information that indicates whether the bearer or bearer identifier that supports (sending or receiving) MBS services is a unicast bearer or a multicast bearer.

[0361] - Information related to the MBS dedicated carrier or the cell (Cell, SCell, or PCell) used for MBS service (e.g., frequency or time resources or cell identifier).

[0362] -MBS-specific bandwidth information (e.g., downlink or uplink bandwidth information) or MBS service bandwidth identifier information

[0363] - In the configuration information, you can also configure the length of the PDCP serial number or RLC serial number, and as another method, you can determine the default length of the RLC serial number or PDCP serial number.

[0364] As described above, if the system information does not include the configuration information for the MBS service in the stationed cell, the terminal can send a message or indicator to the base station, cell, or network requesting that the system information for the MBS service be broadcast in the stationed cell. Upon receiving the message or indicator, the base station or network can broadcast or send the MBS service configuration information as system information. In this way, the base station can prevent the waste of transmission resources that might occur from unnecessarily broadcasting system information related to the MBS service in the system information.

[0365] Terminals that have received or acknowledged information related to MBS services as system information as described above, terminals that have acknowledged that an interested MBS service has been broadcast in the current cell via system information, or terminals that intend to request an interested MBS service from the network can perform a random access procedure and send a first RRC message to the network. The first RRC message can be an RRC message for a newly defined MBS service, and can be defined as an RRCSetupRequest message, an RRCResumeRequest message, or another existing RRC message. Terminals can indicate in the first RRC message that they intend to receive MBS services, including indicators indicating that they intend to receive MBS services due to their intention to configure an RRC connection with the network, or including indicators of a first or second identifier, logical channel identifier, RNTI identifier, or bearer identifier of the MBS service that the terminal is interested in or intends to receive. In the first RRC message described above, the terminal may include an indicator indicating the type (e.g., unicast or multicast bearer) or structure of the bearer to which the MBS service should be applied or configured or used, or the preferred type (e.g., unicast or multicast bearer) or structure of the bearer, or an indicator indicating in which RRC mode (RRC connected mode, RRC idle mode, or RRC deactivated mode) the terminal wants to receive the MBS service. Alternatively, the terminal may send a first RRC message including an indicator of an MBS service it is no longer interested in, an MBS service it is about to stop receiving, or an MBS service it has already stopped receiving, or an indicator to change the MBS service to another MBS service. The indicators included by the terminal in the first RRC message described above may be determined or indicated based on system information received in 1m-05. Additionally, the terminal may report terminal capability information related to the MBS service to the base station or network via a separate RRC message. For example, when a base station sends an RRC message requesting terminal capability information to a terminal, or when a terminal attempts to receive MBS service in response to an RRC message requesting terminal capability information, the functions supported by the terminal capabilities, configurable configuration information, or functions or configuration information implemented in the terminal can be included in the terminal capability response RRC message and sent to the base station or network. As mentioned above, when the terminal has already previously configured a connection or is storing a terminal identifier assigned from the network (e.g., a terminal identifier assigned to the core network (5G-S-TMSI) or a terminal identifier assigned from the base station for RRC connection recovery (short I-RNTI or I-RNTI)), or when the terminal identifier is indicated by an upper-layer device (e.g., a NAS layer device or an RRC layer device), the terminal can send a first RRC message including the terminal identifier to allow the network to recognize or identify the terminal.For example, a base station or network can distinguish or check a terminal based on the terminal identifiers included above, retrieve and confirm the terminal's capability information from the core network, or retrieve and confirm the terminal's configuration information or terminal capability information from a base station previously configured to connect with it. As described above, when a terminal receives the aforementioned system information, attempts to receive a service of interest, when a service of interest is generated or determined, when the terminal is located in or enters a cell or area supporting the MBS service in the system information, or when the terminal establishes or connects to an MBS service (or session), the terminal can configure its connection with the network and send a first RRC message.

[0366] When the base station receives the first RRC message during the 1m-10 process described above, the base station can identify the MBS service or terminal capability information that the terminal is interested in or intends to receive.

[0367] The base station or network can send a second RRC message (1m-15) to the terminal to support or configure MBS services (1m-15) for the terminal. The second RRC message can be an RRC message for a newly defined MBS service, and can be defined as an RRCSetup message, an RRCResume message, or another existing RRC message.

[0368] The second RRC message may include configuration information for the MBS service, configuration information for the MBS service indicated by the terminal in the first RRC message, and bearer configuration information or unicast bearer or multicast bearer or MBS bearer configuration information for receiving MBS services.

[0369] The second RRC message may include one or more of the following configuration information for MBS service support and may be sent.

[0370] - Does it support MBS service?

[0371] Configuration information for physical channels or downlink or uplink transport channels (e.g., MBCH, MBCCH, MBTCH, or DL-SCH) used for MBS services.

[0372] - Transmission resources (frequency or time resources, transmission period, partial bandwidth (or partial bandwidth identifier), bandwidth, dedicated frequency (frequency information or SCell identifier), subcarrier spacing, subframe number, or identifier indicating transmission mode, etc.) of the physical channel or downlink or uplink transmission channel (e.g., MBCH or MBS control data channel (MBCCH) or MBS user data channel (MBTCH)).

[0373] - Configuration information for the MBS services supported by the current cell. For example, configuring or broadcasting a list of MBS services or a first identifier (e.g., Temporary Mobile Group Identifier (TMGI)) or a second identifier (e.g., session identifier) ​​for each MBS service, and configuring or broadcasting each logical channel identifier, each bearer identifier, or each RNTI identifier information corresponding to the first or second identifier for each MBS service. In another approach, the first identifier (e.g., Temporary Mobile Group Identifier (TMGI)) or the second identifier (e.g., session identifier) ​​or RNTI identifier for the MBS service can be configured or broadcast for each bearer (or bearer identifier) ​​or each logical channel or each RLC configuration information or each PDCP configuration information. As mentioned above, the first identifier may indicate the Public Land Mobile Network (PLMN) serving the MBS or may indicate the MBS service type or session. As mentioned above, the second identifier may indicate a more specific MBS service session or type. Additionally, the configuration information for the MBS service may include information such as the transmission resources (frequency or time resources, transmission period, partial bandwidth (or partial bandwidth identifier), bandwidth, dedicated frequency (frequency information or SCell identifier), subcarrier spacing, subframe number, or identifier indicating the transmission mode, etc.) for supporting, broadcasting, or transmitting each MBS service.

[0374] -In order to Figure 7 The bearer structure proposed in the document for receiving MBS services may include bearer configuration. Additionally, it may include indicator configuration information indicating whether HARQ reordering, HARQ retransmission, HARQ ACK, or NACK is used; indicator configuration information indicating whether RLC reordering functionality is used; transmission resource information for sending HARQ ACK or NACK; indicator configuration information indicating whether RLC sequential delivery functionality is used; configuration information for RLC reordering timer values; or indicator configuration information regarding whether PDCP out-of-order delivery functionality is used. In the above, for each MBS service or for each bearer configuration, there may be indicator configuration information indicating whether HARQ reordering, HARQ retransmission, or HARQ ACK or NACK is used; indicator configuration information indicating whether RLC reordering functionality is used; indicator configuration information indicating whether RLC sequential delivery functionality is used; configuration information for RLC reordering timer values; configuration information for RLC mode (TM, UM, or AM); configuration information regarding whether data segmentation functionality is used in the RLC layer device; or indicator configuration information regarding whether PDCP out-of-order delivery functionality is used. As an alternative approach, configuration information can be defined as default configuration information, allowing the terminal to configure some functions as an MBS bearer with default functions even without configuration information.

[0375] - Indicator configuration information that indicates whether the bearer or bearer identifier that supports (sending or receiving) MBS services is a unicast bearer or a multicast bearer.

[0376] - Information related to the MBS dedicated carrier or the cell (Cell, SCell, or PCell) used for MBS service (e.g., frequency or time resources or cell identifier).

[0377] -MBS-specific bandwidth information (e.g., downlink or uplink bandwidth information) or MBS service bandwidth identifier information

[0378] - In the configuration information, you can also configure the length of the PDCP serial number or RLC serial number, and as another method, you can determine the default length of the RLC serial number or PDCP serial number.

[0379] As described above, a terminal that has received the second RRC message can store or apply configuration information related to the MBS service to search for or determine the MBS service it is interested in or wants to receive, and can receive MBS data (MBS control data or MBS user data) in the transmission resources of the MBS control data channel or MBS user data channel through which it sends data for the MBS service of interest. When the terminal receives the above system information, or when it attempts to receive the service of interest, or when the service of interest is generated or determined, or when the terminal is located in or enters a cell or area supporting the MBS service in the system information, or when the terminal configures or connects to the MBS service (or session), or when the terminal receives or broadcasts the configuration information or bearer configuration information of the MBS service in the system information or RRC message (e.g., RRCSetup, RRCResume, RRCReconfiguration, RRCRelease or a newly defined new RRC message) or the control message of the MBS channel (e.g., sent in the MBS control data channel), the terminal can configure a unicast bearer, multicast bearer or MBS bearer with the bearer structure proposed above for receiving the MBS service.

[0380] When the terminal receives the second RRC message, the terminal can apply the configuration information included in the second RRC message and respond by sending a third RRC message (e.g., RRCSetupComplete or RRCResumeComplete) to the base station or network (1m-20).

[0381] As described above, a terminal can receive MBS data (e.g., MBS control data) through the MBS control data channel or transmission resources used for the MBS service of interest to receive configuration information related to the MBS service.

[0382] When receiving the aforementioned configuration information related to the MBS service, in order to receive the MBS service that the terminal is interested in or intends to receive, the terminal can identify the first identifier or second identifier or RNTI identifier or logical channel identifier configured or assigned for the MBS service it is interested in or wants to receive, and use them, the terminal can access the MBS user data service channel through the application disclosed herein. Figure 7 or Figure 8 The method proposed in the paper is used to receive MBS data (1m-25).

[0383] The base station may send a fourth RRC message (e.g., RRCReconfiguration, 1m-30) to the terminal based on preferences reported by the terminal or indicated indicators or base station implementation, in order to reconfigure configuration information related to the MBS service or reconfigure the bearer through which the terminal receives the MBS service. For example, the fourth RRC message may include configuration information for changing the bearer type (e.g., an indicator for switching from a unicast bearer to a multicast bearer, or an indicator for switching from a multicast bearer to a unicast bearer, or corresponding bearer configuration information), logical channel identifier information changed or updated for each MBS service, RNTI identifier information for the MBS service, or first identifier or second identifier information, etc.

[0384] After receiving the fourth RRC message and storing or applying configuration information related to MBS services, the terminal can configure a fifth RRC message (e.g., RRCReconfigurationComplete, 1m-35) to indicate successful reconfiguration and send it to the base station.

[0385] As described above, a terminal can receive MBS data (e.g., MBS control data) through the MBS control data channel or transmission resources used for the MBS service of interest to receive configuration information related to the MBS service.

[0386] When receiving the aforementioned configuration information related to the MBS service, in order to receive the MBS service that the terminal is interested in or wants to receive, the terminal can identify the first identifier or second identifier or RNTI identifier or logical channel identifier configured or assigned for the MBS service it is interested in or wants to receive, and use them to access the MBS user data service channel through the application disclosed herein. Figure 7 or Figure 8 The method proposed in the paper is for receiving MBS services (1m-40).

[0387] As described above, when a base station (e.g., according to its implementation or at the request of the terminal or instruction from the terminal) attempts to switch the terminal to RRC deactivation mode or RRC idle mode, the base station may configure a sixth RRC message (e.g., an RRC Release message, IM-45) and send it to the terminal to switch to RRC idle mode or RRC inactive mode. The sixth RRC message (IM-45) may include one or more of the following information, enabling the terminal to continue receiving MBS services even in RRC idle mode or RRC deactivation mode.

[0388] - Does it support MBS service?

[0389] Configuration information for physical channels or downlink or uplink transport channels (e.g., MBCH, MBCCH, MBTCH, or DL-SCH) used for MBS services.

[0390] - Transmission resource information (frequency or time resources, transmission period, partial bandwidth (or partial bandwidth identifier), bandwidth, dedicated frequency (frequency information or SCell identifier), subcarrier spacing, subframe number, or identifier indicating transmission mode, etc.) transmitted through the physical channel or downlink or uplink transmission channel (e.g., MBCH or MBS control data channel (MBCCH) or MBS user data channel (MBTCH)).

[0391] - Configuration information for the MBS services supported by the current cell. For example, a list of MBS services or a first identifier (e.g., Temporary Mobile Group Identifier (TMGI)) or a second identifier (e.g., session identifier) ​​for each MBS service can be configured or broadcast, and information for each logical channel identifier, bearer identifier, or RNTI identifier corresponding to the first or second identifier for each MBS service can be configured or broadcast. Alternatively, the first identifier (e.g., Temporary Mobile Group Identifier (TMGI)) or the second identifier (e.g., session identifier) ​​or RNTI identifier for the MBS service can be configured or broadcast for each bearer (or bearer identifier), each logical channel, each RLC configuration information, or each PDCP configuration information. In the above context, the first identifier may indicate the Public Land Mobile Network (PLMN) serving the MBS or may indicate the MBS service type or session. In the above context, the second identifier may indicate a more specific MBS service session or type. Additionally, the configuration information for the MBS service may include information such as the transmission resources (frequency or time resources, transmission period, partial bandwidth (or partial bandwidth identifier), bandwidth, dedicated frequency (frequency information or SCell identifier), subcarrier spacing, subframe number, or identifier indicating the transmission mode, etc.) for supporting, broadcasting, or transmitting each MBS service.

[0392] -In order to Figure 7 The bearer structure proposed in the document for receiving MBS services may include bearer configuration. Additionally, it may include indicator configuration information indicating whether HARQ reordering, HARQ retransmission, HARQ ACK, or NACK is used; indicator configuration information indicating whether RLC reordering functionality is used; transmission resource information for sending HARQ ACK or NACK; indicator configuration information indicating whether RLC sequential delivery functionality is used; configuration information for RLC reordering timer values; or indicator configuration information regarding whether PDCP out-of-order delivery functionality is used. In the above, for each MBS service or for each bearer configuration, there may be indicator configuration information indicating whether HARQ reordering, HARQ retransmission, HARQ ACK, or NACK is used; indicator configuration information indicating whether RLC reordering functionality is used; indicator configuration information indicating whether RLC sequential delivery functionality is used; configuration information for RLC reordering timer values; configuration information for RLC mode (TM, UM, or AM); configuration information regarding whether data segmentation functionality is used in the RLC layer device; or indicator configuration information regarding whether PDCP out-of-order delivery functionality is used. As an alternative approach, configuration information can be defined as default configuration information, allowing the terminal to configure some functions as an MBS bearer with default functions even without configuration information.

[0393] - Indicator configuration information that indicates whether the bearer or bearer identifier that supports (sending or receiving) MBS services is a unicast bearer or a multicast bearer.

[0394] - Indicator configuration information that indicates whether the bearer or bearer identifier that supports (sending or receiving) MBS services is a unicast bearer or a multicast bearer.

[0395] - Indicators or configuration information for switching to RRC idle mode, RRC disabled mode, or RRC connected mode.

[0396] -The MBS service configuration information or bearer configuration information proposed above for receiving MBS services in RRC idle mode

[0397] -The MBS service configuration information or bearer configuration information proposed above for receiving MBS services in RRC deactivation mode

[0398] - Information related to the MBS dedicated carrier or the cell (Cell, SCell, or PCell) used for MBS service (e.g., frequency or time resources or cell identifier).

[0399] -MBS-specific bandwidth information (e.g., downlink or uplink bandwidth information) or MBS service bandwidth identifier information

[0400] - In the configuration information, you can also configure the length of the PDCP serial number or RLC serial number, and as another method, you can determine the default length of the RLC serial number or PDCP serial number.

[0401] Upon receiving the aforementioned configuration information related to the MBS service, in order to receive the MBS service that the terminal is interested in or wants to receive, the terminal can identify the first identifier or second identifier or RNTI identifier or logical channel identifier configured or assigned for the MBS service it is interested in or wants to receive, and use them to access the MBS user data service channel through the application disclosed herein. Figure 7 or Figure 8 The method proposed in the paper is for receiving MBS services (1m-50).

[0402] As described above, in RRC connection mode, the terminal can send a first RRC message (1m-10) for MBS service reception, receive a second RRC message (1m-15), send a third RRC message (1m-20) again, receive a fourth RRC message, send a fifth RRC message, and receive MBS service. Alternatively, subsequently, in RRC idle mode or RRC inactive mode, it can receive a sixth RRC message (1m-45) and can receive MBS service.

[0403] In another method, as described above, the terminal can send a first RRC message (1m-10) for receiving MBS services, receive a second RRC message (1m-15) (switching to RRC connection mode), send a third RRC message (1m-20) again, and receive MBS services in RRC idle mode or RRC deactivation mode by receiving a sixth RRC message (1m-45) and switching to RRC idle mode or RRC deactivation mode.

[0404] In the above method, the characteristic may be that no encryption or integrity protection process is applied to the first or second RRC message. In another method, the characteristic may be that, to enhance security, no encryption or integrity protection process is applied to the first or second RRC message, and an encryption or integrity protection process is applied to the first or second RRC message. In yet another method, the characteristic may be that, to further enhance security, an encryption or integrity protection process is applied to the first or second RRC message, and an encryption or integrity protection process is applied to the first or second RRC message. In the above method, an encryption or integrity protection process may be applied to the third RRC message. Additionally, an encryption or integrity protection process may be applied to the fourth, fifth, or sixth RRC message.

[0405] In the next-generation mobile communication system disclosed herein, the first, second, third, or fourth signaling procedures proposed herein for supporting MBS services are supported.

[0406] The feature of this disclosure is that the base station can configure the sequential delivery function for receiving RLC layer devices as an indicator or default function for AM or UM bearers (e.g., MBS bearers, unicast bearers, or multicast bearers) configured for the terminal, such as RRC messages, MBS control messages, RLC control PDUs, or MAC control information. When long retransmissions of RLC layer devices are required, or when data loss is fatal to service, the base station can configure or activate the sequential delivery function for receiving RLC layer devices as described above. In the above context, when the sequential delivery function indicator is absent or when the sequential delivery function is not configured, the terminal can essentially apply the out-of-order delivery function to the receiving RLC layer devices.

[0407] As mentioned above, when a timer value is configured via an indicator in an RRC message, MBS control message, RLC control PDU, or MAC control information, the terminal can fall back from sequential delivery to out-of-order delivery when the timer expires. The base station can indicate the timer value via an RRC message or MBS control message.

[0408] When an RLC UM layer device is connected to or configured with an RLC UM layer device on a UM bearer (e.g., an MBS bearer, a unicast bearer, or a multicast bearer), overhead can be reduced by having different RLC header structures according to configuration information configured as follows, and the RLC layer device can process data efficiently.

[0409] The RLC header is characterized in that, when sequential delivery is not configured, or when out-of-order delivery is used, or when it is not a bearer supporting MBS service, or in the case of an RLC layer device in which MBS service is not configured, the RLC header does not include the RLC sequence number of the unsegmented complete data (RLC SDU or RLC PDU), and is also characterized in that the RLC header includes the RLC sequence number of the segmented data (RLC SDU or RLC PDU). Additionally, the fragment offset (SO) field (the byte indicating the segment position) is not included in the RLC header for either the unsegmented complete data (RLC SDU or RLC PDU) or the first segmented data (including the first fragment of the RLC SDU or RLC PDU). Additionally, it may be characterized in that the fragment offset (SO) field (a byte indicating the fragment position) is included in the RLC header for segmented data other than unsegmented complete data (RLC SDU or RLC PDU) (e.g., intermediate or final fragment) or the first fragment of segmented data (including the first fragment of the RLC SDU or RLC PDU).

[0410] Its characteristic may be that, when sequential delivery is configured, when sequential delivery is used, or when out-of-order delivery is not used, in the case of a bearer supporting MBS service, or in the case of an RLC layer device in which an MBS service bearer is configured, the RLC sequence number is included in the RLC header even for undivided complete data (RLC SDU or RLC PDU), or it may be characterized in that the RLC sequence number is included in the RLC header even for divided data (RLC SDU or RLC PDU). Additionally, its characteristic may be that the fragment offset (SO) field (the byte indicating the fragment position) is not included in the RLC header for undivided complete data (RLC SDU or RLC PDU) or for the first fragmented data (including the first fragment of the RLC SDU or RLC PDU). Furthermore, its feature may be that the fragment offset (SO) field (a byte indicating the fragment position) is included in the RLC header for fragmented data other than unsegmented complete data (RLC SDU or RLC PDU) (e.g., intermediate fragments or the last fragment) or the first fragment of a segment (including the first fragment of the RLC SDU or RLC PDU).

[0411] In the case where the aforementioned RLC AM layer device is connected to or configured with an AM bearer (e.g., MBS bearer, unicast bearer, or multicast bearer), overhead can be reduced by having different RLC header structures according to the configuration information configured below, and the RLC layer device can process data efficiently.

[0412] Its characteristic is that, when sequential delivery is not configured, or when out-of-order delivery is used, or when sequential delivery is configured, or when sequential delivery is used, or when out-of-order delivery is not used, or in the case of a bearer supporting MBS service, or in the case of an RLC layer device in which MBS service is configured, even for segmented complete data (RLC SDU or RLC PDU), the RLC sequence number is included in the RLC header, and it is also characterized in that the RLC sequence number is included in the RLC header even for segmented data (RLC SDU or RLC PDU). Additionally, it is characterized in that the fragment offset (SO) field (the byte indicating the segment position) is not included in the RLC header for unsegmented complete data (RLC SDU or RLC PDU) or for the first segmented data (including the first fragment of the RLC SDU or RLC PDU containing the first fragment). Additionally, it may be characterized in that the fragment offset (SO) field (a byte indicating the fragment position) is included in the RLC header for segmented data other than unsegmented complete data (RLC SDU or RLC PDU) (e.g., intermediate or final fragment) or the first fragment of segmented data (including the first fragment of the RLC SDU or RLC PDU).

[0413] In the following part of this disclosure, RLC UM mode and RLC AM mode are specifically described and presented in a first embodiment of the operation of the receiving RLC layer device proposed by this disclosure.

[0414] The first embodiment of the operation of the receiving RLC layer device proposed in this disclosure is characterized in that the out-of-order forwarding function is performed as the default operation.

[0415] First, the variables for window operations of the receiving RLC layer device in RLC UM mode can be defined as follows.

[0416] -RX_Next_Reassembly: A status variable indicating the lowest or earliest RLC sequence number among the data (RLC PDU or RLC SDU) that is considered for reassembly in the receiving RLC layer device.

[0417] -RX_Timer_Trigger: A status variable indicating the RLC sequence number following the RLC sequence number that triggered the RLC reconfiguration timer.

[0418] -RX_Next_Highest: A status variable indicating the RLC sequence number immediately adjacent to the highest RLC sequence number in the received data.

[0419] The detailed operation of the (1-1)th embodiment of the receiving RLC layer device of this disclosure when operating in RLC UM mode is as follows.

[0420] When a UMD PDU is received from a lower-level device, the receiving RLC layer device can operate as follows.

[0421] -If the header of the received UMD PDU does not include an RLC sequence number,

[0422] ■ Remove the RLC header and pass the RLC SDU to the upper-layer device.

[0423] - Otherwise (if the RLC sequence number is included in the header of the received UMD PDU above), if the RLC sequence number is greater than or equal to (RX_Next_Highest - UM_Window_Size) and less than RX_Next_Reassembly,

[0424] ■ Discard the received UMD PDU.

[0425] - Otherwise, if the above conditions are not met (if the RLC sequence number is included in the header of the received UMD PDU and the RLC sequence number is less than (RX_Next_Highest - UM_Window_Size) or equal to or greater than RX_Next_Reassembly)

[0426] ■ Store the received UMD PDU in the receive buffer.

[0427] For the UMD PDU stored in the buffer during the above process, the receiving RLC layer device operates as follows. That is, when a UMD PDU with RLC sequence number x is stored in the buffer, the receiving RLC layer device operates as follows.

[0428] -If all fragments with the value of RLC sequence number x have already been received

[0429] ■ It can reassemble all segments with RLC serial number x to form an RLC SDU, remove the RLC header, and pass the RLC SDU to an upper-layer device.

[0430] ■ If the value of x above is the same as the value of RX_Next_Reassembly

[0431] ◆ In the data where the RX_Next_Reassembly variable has not yet been reorganized and has not yet been passed to the upper layer, update the RLC sequence number of the first (or the lowest RLC sequence number in the data with a larger RLC sequence number value) that has a larger RLC sequence number value than the current RX_Next_Reassembly value.

[0432] -If the value of RLC sequence number x is outside the RLC recombination window

[0433] ■ Update the RX_Next_Highest variable to x+1.

[0434] ■ Furthermore, discard all data corresponding to the RLC sequence number outside the RLC recombination window.

[0435] ■ If the RX_Next_Reassembly value is outside the RLC reassembly window

[0436] ◆It is configured as the RLC sequence number of the first (or the lowest RLC sequence number among the data with a larger RLC sequence number value) of the data that has not yet been reassembled by the RX_Next_Reassembly variable and has not yet been passed to the upper layer.

[0437] -If the RLC recombination timer is running

[0438] ■ If the RX_Timer_Trigger value is less than or equal to the RX_Next_Reassembly value

[0439] ■ Alternatively, if the RX_Timer_Trigger value is outside the RLC recombination window, and the RX_Timer_Trigger value is not equal to the RX_Next_Highest value,

[0440] ■ Alternatively, if the RX_Next_Highest value equals RX_Next_Reassembly + 1, and there is no fragment loss before the last byte of all currently received fragments in the RLC SDU with the value of RX_Next_Reassembly as the RLC sequence number,

[0441] ◆Stop and initialize the RLC recombinant timer.

[0442] - If the RLC recombination timer is not running (including cases where the RLC recombination timer has been stopped using the above procedure),

[0443] ■ If the value of RX_Next_Highest is greater than RX_Next_Reassembly+1

[0444] ■ Alternatively, if the RX_Next_Highest value is equal to RX_Next_Reassembly+1, and at least one segment is lost before the last byte of all currently received segments in the RLC SDU with the RX_Next_Reassembly value as the RLC sequence number,

[0445] ◆Start the RLC recombination timer.

[0446] ◆And the RX_Timer_Trigger variable is configured with the value RX_Next_Highest.

[0447] If the RLC reassembly timer expires during the above process, the receiving RLC layer device will operate as follows.

[0448] - Update the RX_Next_Reassembly variable with the RLC sequence number value of the first (or lowest) RLC sequence number that has not yet been reassembled with an RLC sequence number greater than or equal to the RX_Timer_Trigger value.

[0449] - Discard all fragments with RLC sequence numbers that are less than the updated RX_Next_Reassembly value.

[0450] - If the value of RX_Next_Highest is greater than RX_Next_Reassembly+1

[0451] - Alternatively, if the RX_Next_Highest value is equal to RX_Next_Reassembly+1, and at least one segment is lost before the last byte of all currently received segments in the RLC SDU with the RX_Next_Reassembly value as the RLC sequence number.

[0452] ■Start the RLC reassembly timer.

[0453] ■And the RX_Timer_Trigger variable is configured with the value RX_Next_Highest.

[0454] In the (1-1) operation of a receiving RLC layer device having the RLC UM mode configured in this disclosure, if the RLCSDU is transmitted completely without segmenting the RLC SDU when the transmitting RLC layer device transmits data (RLC SDU or RLC PDU), and if a 6-bit RLC sequence number is configured in the RLC layer device, data can be transmitted by including only the SI field (indicating complete data, or the first segment, or the last segment, or an intermediate segment that is neither the first nor the last) in the RLC header without including the RLC sequence number. However, if the RLC SDU is segmented and the segments are transmitted, the first segment can be transmitted by including the RLC sequence number and the SI field in the RLC header, and in the case of another intermediate or last segment, the RLC sequence number, the SI field, and the SO field (indicating the first byte segmented from the RLC SDU) can be included in the RLC header and transmitted.

[0455] Additionally, when transmitting data (RLC SDU or RLC PDU), if the RLC SDU is transmitted completely without segmentation, and if a 12-bit RLC sequence number is configured in the RLC layer device, the transmitting RLC layer device can transmit data by including only the SI field in the RLC header without the RLC sequence number. However, if the RLC SDU is segmented and fragments are transmitted, the first fragment can be transmitted by including the RLC sequence number and SI field in the RLC header. In the case of another intermediate or final fragment, the RLC header can include the RLC sequence number, SI field, and SO field (indicating the first byte segmented from the RLC SDU) and can be transmitted.

[0456] When the receiving RLC layer device of this disclosure operates in RLC AM mode, the detailed operation of embodiments (1-2) is as follows. In RLC AM mode, the RLC layer device implements the ARQ function, receives an RLC status report (indicating whether data was successfully transmitted via the RLC sequence number) from the receiving end, and retransmits data that was not successfully transmitted to prevent data loss.

[0457] First, the variables for window operations of the receiving RLC layer device in RLC AM mode can be defined as follows.

[0458] -RX_Next: A status variable indicating the RLC sequence number immediately following the highest or last RLC sequence number in the fully received data used for reassembly.

[0459] -RX_Next_Status_Trigger: A status variable indicating the next RLC sequence number that triggered the RLC reassembly timer.

[0460] -RX_Next_Highest: A status variable indicating the RLC sequence number immediately adjacent to the highest RLC sequence number in the received data.

[0461] -RX_Next_Highest_Status: A status variable indicating the highest RLC sequence number. When an RLC status report is configured, this highest RLC sequence number can be indicated by the ACK_SN in the RLC status report (e.g., the RLC sequence number following the highest successfully received RLC sequence number).

[0462] When receiving an AMD PDU that includes bytes y to z of an RLC SDU with an RLC sequence number value of x from a lower-level device, the receiving RLC layer device may operate as follows.

[0463] -If the RLC sequence number x of the received AMD PDU is outside the RLC receive window.

[0464] -Or, an AMD PDU that has previously been received containing bytes y to z of an RLC SDU with RLC sequence number x.

[0465] ■ Discard the received AMD PDU.

[0466] Otherwise, in addition to the above,

[0467] ■ Store the received AMD PDU in the receive buffer.

[0468] ■If you have already received a portion or fragment of the AMD PDU

[0469] ◆A portion or fragment included in the AMD PDU is considered to have been received and discarded.

[0470] In the above process, the receiving RLC layer device operates on the AMD PDU stored in the buffer as follows. That is, when an AMD PDU with RLC serial number x is stored in the buffer, the receiving RLC layer device operates as follows.

[0471] - If the value of RLC sequence number x is equal to or greater than the value of RX_Next_Highest

[0472] ■ Update the RX_Next_Highest value to x+1.

[0473] -If all bytes of the RLC SDU corresponding to the value of RLC sequence number x are received.

[0474] ■ Reassemble the data or fragments corresponding to the value of RLC sequence number x to form an RLC SDU, remove the RLC header, and pass the reassembled RLC SDU to the upper-layer device.

[0475] ■If the value of x equals RX_Highest_Status

[0476] ◆ Update the RX_Highest_Status variable using the RLC sequence number value of the first (lowest RLC sequence number) data that is greater than the current RX_Highest_Status value and has not yet received all bytes completely.

[0477] ■If the value of x is equal to RX_Next,

[0478] ◆ Update the RX_Next variable using the RLC sequence number of the first (lowest RLC sequence number) data that is greater than the current RX_Next value and has not yet received all bytes.

[0479] -If the RLC refactoring timer is running

[0480] ■ If the RX_Next_Status_Trigger value is the same as the RX_Next value

[0481] ■ Alternatively, if the RX_Next_Status_Trigger value is equal to RX_Next+1, and there is no fragment loss before the last byte of all currently received fragments in the RLC SDU with the RX_Next value as the RLC sequence number,

[0482] ■ Alternatively, if the RX_Next_Status_Trigger value is outside the RLC receive window, and the RX_Next_Status_Trigger value is not equal to the RX_Next + AM_Window_Size value,

[0483] ◆Stop and initialize the RLC recombinant timer.

[0484] - If the RLC reconfiguration timer is not running (including cases where the RLC reconfiguration timer has been stopped using the above procedure).

[0485] ■ If the value of RX_Next_Highest is greater than RX_Next+1

[0486] ■ Alternatively, if the RX_Next_Highest value is equal to RX_Next+1, and at least one segment is lost before the last byte of all currently received segments in the RLC SDU with the RX_Next value as the RLC sequence number.

[0487] ◆Start the RLC refactoring timer.

[0488] ◆And the RX_Next_Status_Trigger variable is configured to the RX_Next_Highest value.

[0489] If the RLC reassembly timer expires during the above process, the receiving RLC layer device will operate as follows.

[0490] - Update the RX_Highest_Status variable to the RLC sequence number value of the first (or lowest RLC sequence number) data that has not yet been fully received along with an RLC sequence number equal to or greater than the RX_Next_Status_Trigger value.

[0491] -If the value of RX_Next_Highest is greater than RX_Next+1

[0492] - Alternatively, if at least one segment is lost before the last byte of all currently received segments in an RLC SDU that has an RX_Next_Highest value equal to RX_Next+1 and an RX_Next value as the RLC sequence number.

[0493] ◆Start the RLC refactoring timer.

[0494] ◆And the RX_Next_Status_Trigger variable is configured to the RX_Next_Highest value.

[0495] In embodiments (1-2) in which the operation of the receiving RLC layer device configured in the RLC AM mode proposed in this disclosure is performed, when transmitting data (RLC SDU or RLC PDU), if the RLC SDU is transmitted completely without segmentation, or if a first segment segmented from the RLC SDU is transmitted, or if a 12-bit RLC sequence number is configured in the RLC layer device, the transmitting RLC layer device may transmit data by including only the RLC sequence number and the SI field (indicating complete data, first segment, last segment, or intermediate segment that is neither first nor last) in the RLC header. However, if the RLC SDU is segmented and the segments are transmitted, or if an intermediate or last segment is transmitted, the RLC header includes the RLC sequence number, the SI field, and the SO field (indicating the first byte segmented from the RLC SDU) for transmission.

[0496] Furthermore, when the transmitting RLC layer device transmits data (RLC SDU or RLC PDU) in operation (1-2), which is the operation of the receiving RLC layer device configured with the RLC AM mode proposed in this disclosure, if the RLC SDU is transmitted completely without partitioning, or if the first segment partitioned in the RLC SDU is transmitted when the transmitting RLC layer device transmits data (RLC SDU or RLC PDU), and if an 18-bit RLC sequence number is configured in the RLC layer device, the transmitting RLC layer device may transmit data by including only the RLC sequence number and the SI field (indicating complete data, first segment, last segment, or intermediate segment that is neither the first nor the last) in the RLC header. However, when the RLC SDU is segmented and the segments are transmitted, if intermediate or last segments are used, the RLC header may include the RLC sequence number, the SI field (indicating the first byte partitioned from the RLC SDU), and the SO field.

[0497] In the following sections of this disclosure, RLC UM mode and RLC AM mode are specifically described and presented in a second embodiment of the operation of the receiving RLC layer device proposed by this disclosure.

[0498] In the second embodiment, when sequential delivery is configured, when sequential delivery is used, when out-of-order delivery is not used, or in the case of a bearer supporting MBS services, or in the case of an RLC layer device in which an MBS service bearer is configured, an operation to receive an RLC layer device is proposed.

[0499] The second embodiment of the receiving RLC layer device operation disclosed herein is characterized in that, if out-of-order delivery is performed as the default operation, but out-of-order delivery is configured or activated for RRC messages, MBS control messages, MAC control information, or RLC control PDUs, data is aligned based on the RLC sequence number and delivered to the upper layer. Furthermore, the second embodiment is characterized in that, when out-of-order delivery is applied, segments outside the RLC reassembly window are immediately discarded; however, when sequential delivery is configured or activated, segments outside the window are not immediately discarded, and reassembly is performed on the segments outside the window. When a complete RLC SDU is reassembled, the RLC SDU is delivered to the upper layer device in ascending order of the RLC sequence number, and segments that have not yet been reassembled into a complete RLC SDU are discarded. Furthermore, when the sequential forwarding function is configured or activated, even if all bytes are received for an RLC SDU corresponding to an RLC sequence number, it is not immediately reassembled and passed to the upper layer. Instead, it is reassembled after being sorted according to the RLC sequence number and passed to the upper layer in ascending order of the RLC sequence number. And when the out-of-order forwarding function is applied, when all bytes are received for an RLC SDU corresponding to an RLC sequence number, the bytes are reassembled and passed to the upper layer.

[0500] First, the variables for window operations of the receiving RLC layer device in RLC UM mode can be defined as follows.

[0501] -RX_Next_Reassembly: A status variable indicating the lowest or earliest RLC sequence number among the data (RLC PDU or RLC SDU) that is considered for reassembly in the receiving RLC layer device.

[0502] -RX_Timer_Trigger: A status variable indicating the RLC sequence number following the RLC sequence number that triggered the RLC reconfiguration timer.

[0503] -RX_Next_Highest: A status variable indicating the RLC sequence number immediately adjacent to the highest RLC sequence number in the received data.

[0504] The detailed operation of the (2-1)th embodiment of the receiving RLC layer device of this disclosure when operating in RLC UM mode is as follows.

[0505] When a UMD PDU is received from a lower-level device, the receiving RLC layer device can operate as follows.

[0506] -If the header of the received UMD PDU does not include an RLC sequence number,

[0507] ■ Remove the RLC header and pass the RLC SDU to the upper-level device.

[0508] - Additionally (if the RLC sequence number is included in the header of the received UMD PDU above), if the RLC sequence number is greater than or equal to (RX_Next_Highest - UM_Window_Size) and less than RX_Next_Reassembly

[0509] ■ Discard the received UMD PDU.

[0510] - Otherwise (if the RLC sequence number is included in the header of the received UMD PDU above, and the RLC sequence number is less than (RX_Next_Highest - UM_Window_Size) or equal to or greater than RX_Next_Reassembly)

[0511] ■ Store the received UMD PDU in the receive buffer.

[0512] During the above process, the receiving RLC layer device operates on the UMD PDU stored in the buffer as follows. That is, when a UMD PDU with RLC sequence number x is stored in the buffer, the receiving RLC layer device operates as follows.

[0513] -If all fragments with the value of RLC sequence number x have already been received

[0514] ■ If sequential forwarding is not configured or if the MBS service is not configured as a bearer,

[0515] ◆ It can reassemble all fragments with the value of RLC sequence number x to form an RLC SDU, remove the RLC header, and pass the RLC SDU to the upper layer device.

[0516] ■ If the value of x above is the same as the value of RX_Next_Reassembly

[0517] ◆ Update the RX_Next_Reassembly variable using the RLC sequence number of the first data among the data that has not yet been reassembled and passed to the upper layer and has a greater RLC sequence number than the current RX_Next_Reassembly value (or the data with the lowest RLC sequence number among the data with a larger RLC sequence number value).

[0518] ◆If a UMD PDU with an RLC sequence number less than the updated RX_Next_Reassembly value is reassembled into an RLC SDU, the RLC header is removed, and the reassembled RLC SDUs that have not been previously passed to the upper layer are passed to the upper layer device in ascending order of RLC sequence number.

[0519] -If the value of RLC sequence number x is outside the RLC recombination window

[0520] ■ Update the RX_Next_Highest variable to x+1.

[0521] ■ If sorting functionality is not configured or if the MBS service is not configured to be hosted,

[0522] ◆In addition, discard all data corresponding to the RLC serial number outside the RLC reassembly window.

[0523] ■ As stated above, if a UMD PDU with an RLC sequence number outside the RLC reassembly window is reassembled into an RLCSDU, the RLC header is removed, and the reassembled RLC SDUs, which have not been previously passed to the upper layer, are passed to the upper layer device in ascending order of their RLC sequence numbers.

[0524] ■ If the RX_Next_Reassembly value is outside the RLC reassembly window

[0525] ◆The RX_Next_Reassembly variable is configured as the first (or the lowest RLC sequence number among the data that has not yet been reassembled and passed to the upper layer) RLC sequence number value that is equal to or greater than the current (RX_Next_Highest-UM_Window_Size) value.

[0526] -If the RLC recombination timer is running

[0527] ■ If the RX_Timer_Trigger value is less than or equal to the RX_Next_Reassembly value

[0528] ■ Alternatively, if the RX_Timer_Trigger value is outside the RLC recombination window, and the RX_Timer_Trigger value is not equal to the RX_Next_Highest value,

[0529] ■ Alternatively, if the RX_Next_Highest value is equal to RX_Next_Reassembly + 1, and there are no lost segments before the last byte of all currently received segments in the RLC SDU with the RX_Next_Reassembly value as the RLC sequence number,

[0530] ◆Stop and initialize the RLC recombinant timer.

[0531] - If the RLC reconfiguration timer is not running (including cases where the RLC reconfiguration timer has been stopped using the above procedure).

[0532] ■ If the value of RX_Next_Highest is greater than RX_Next_Reassembly+1

[0533] ■ Alternatively, if the RX_Next_Highest value is equal to RX_Next_Reassembly + 1, and at least one segment is lost before the last byte of all currently received segments in the RLC SDU with the RX_Next_Reassembly value as the RLC sequence number.

[0534] ◆Start the RLC recombination timer.

[0535] ◆In addition, the RX_Timer_Trigger variable is configured with the value RX_Next_Highest.

[0536] If the RLC reassembly timer expires during the above process, the receiving RLC layer device will operate as follows.

[0537] - Update the RX_Next_Reassembly variable with the RLC sequence number value of the first (or lowest RLC sequence number) data that has not yet been reassembled with an RLC sequence number equal to or greater than the RX_Timer_Trigger value.

[0538] - If sorting functionality is not configured or if the MBS service is not configured to be hosted,

[0539] - Discard all fragments with RLC sequence numbers that are less than the updated RX_Next_Reassembly value.

[0540] - UMD PDUs with RLC sequence numbers less than the updated RX_Next_Reassembly value are reassembled into RLCSDUs, the RLC header is removed, and if the reassembled RLC SDUs have not yet been passed to the upper layer, they are passed to the upper layer device in ascending order of RLC sequence numbers.

[0541] - If the value of RX_Next_Highest is greater than RX_Next_Reassembly+1

[0542] - Alternatively, if the RX_Next_Highest value is equal to RX_Next_Reassembly+1, and at least one segment is lost before the last byte of all currently received segments in the RLC SDU with the RX_Next_Reassembly value as the RLC sequence number.

[0543] ◆Start the RLC recombination timer.

[0544] ◆In addition, the RX_Timer_Trigger variable is configured with the value RX_Next_Highest.

[0545] In operation (2-1) of the receiving RLC layer apparatus configured with the RLC UM mode proposed in this disclosure, if the sequential forwarding function is not configured or the MBS service is not configured as a bearer, when the transmitting RLC layer apparatus transmits the RLC SDU completely without segmenting it when transmitting data (RLC SDU or RLCPDU), if a 6-bit RLC sequence number is configured in the RLC layer apparatus, the transmitting RLC layer apparatus can transmit data by including only the SI field (indicating complete data, or the first segment, or the last segment, or an intermediate segment that is neither the first nor the last) in the RLC header without including the RLC sequence number. However, if the RLC SDU is segmented and the segments are transmitted, the first segment can be transmitted by including the RLC sequence number and the SI field in the RLC header, and in the case of another intermediate or last segment, the RLC header can include the RLC sequence number, the SI field, and the SO field (indicating the first byte segmented from the RLC SDU) and can be transmitted.

[0546] Furthermore, if sequential delivery is not configured, or if it is not a bearer configured with MBS service, when the transmitting RLC layer device transmits data (RLC SDU or RLC PDU), if the RLC SDU is transmitted completely without segmentation, and if a 12-bit RLC sequence number is configured in the RLC layer device, the transmitting RLC layer device can transmit data by including only the SI field in the RLC header without including the RLC sequence number. However, if the RLC SDU is segmented and fragments are transmitted, the first fragment can be transmitted by including the RLC sequence number and SI field in the RLC header, and in the case of another intermediate or final fragment, the RLC header can include the RLC sequence number, SI field, and SO field (indicating the first byte segmented from the RLC SDU) and can be transmitted.

[0547] In operation (2-1) of the receiving RLC layer apparatus configured with the RLC UM mode proposed in this disclosure, if sequential delivery is configured or if it is a bearer configured with MBS service, when the transmitting RLC layer apparatus transmits data (RLC SDU or RLC PDU), even if the RLC SDU is transmitted completely without segmentation, if a 6-bit RLC sequence number is configured in the RLC layer apparatus, the transmitting RLC layer apparatus can transmit data by including the RLC sequence number and the SI field (indicating complete data, or the first segment, or the last segment, or an intermediate segment that is neither the first nor the last) in the RLC header, so that the receiving RLC layer apparatus can order them sequentially. However, if the RLC SDU is segmented and the segments are transmitted, the first segment can be transmitted by including the RLC sequence number and the SI field in the RLC header, and in the case of another intermediate or last segment, the RLC header can include the RLC sequence number, the SI field, and the SO field (indicating the first byte segmented from the RLC SDU) and can be transmitted.

[0548] In another approach, in operation (2-1) of the receiving RLC layer device configured with the RLC UM mode proposed in this disclosure, if sequential delivery is configured or if it is a bearer configured with MBS service, when the transmitting RLC layer device transmits data (RLC SDU or RLC PDU), even if the RLC SDU is transmitted completely without partitioning, if a 6-bit RLC sequence number is configured in the RLC layer device, the transmitting RLC layer device can include a 12-bit RLC sequence number and an SI field (complete data, or first fragment, or last fragment, or intermediate fragment that is neither first nor last), and data including an indication that can be configured or applied for sequential delivery can be transmitted by defining and including a 1-bit I field. That is, the length of the RLC sequence number can be changed from 6 bits to 12 bits, and the ordering function can be indicated using a 1-bit indicator. However, if the RLC SDU is divided and fragments are sent, in the case of the first fragment, the RLC sequence number and SI field, as well as a 1-bit I field, can be defined and included in the RLC header, and an indication that can be configured or applied for ordering can be sent. In the case of the middle or last fragment, the RLC sequence number, SI field, SO field (indicating the first byte divided from the RLCSDU), and 1-bit I field can be defined and included in the RLC header, so that an indication that can be configured or applied for ordering can be sent.

[0549] Additionally, if sequential delivery is configured, or if it is a bearer in which MBS service is configured, when the sending RLC layer device transmits data (RLC SDU or RLC PDU), if the RLC SDU is transmitted completely without segmentation, or if a 12-bit RLC sequence number is configured in the RLC layer device, the data can be transmitted by including the RLC sequence number and SI field in the RLC header. However, if the RLC SDU is segmented and fragments are transmitted, the first fragment can be transmitted by including the RLC sequence number and SI field in the RLC header. In the case of intermediate or final fragments, they can be transmitted by applying the RLC header and including the RLC sequence number, SI field, and SO field (indicating the first byte segmented from the RLC SDU).

[0550] In another approach, if sequential delivery is configured, or if it is a bearer in which MBS service is configured, when sending data (RLC SDU or RLC PDU), if the RLC SDU is sent completely without fragmentation, and if a 12-bit RLC sequence number is configured in the RLC layer device, the sending RLC layer device can send data including an indication that sequential classification functionality can be configured or applied by defining and including the RLC sequence number, SI field, and 1-bit I field in the RLC header. However, if the RLC SDU is segmented and fragments are sent, in the case of the first fragment, the RLC sequence number, SI field, and 1-bit I field can be defined and included in the RLC header, indicating that sequencing functionality can be configured or applied and that it can be sent; and in the case of the middle or final fragment, the RLC sequence number, SI field, SO field (indicating the first byte fragmented from the RLC SDU), and 1-bit I field can be defined and included in the RLC header, making it possible to send an indication that sequencing functionality can be configured or applied.

[0551] As described above, when the I field in the RLC header is always configured to 0 and sorting is not configured, the header structure described above can be applied to an undivided RLC SDU.

[0552] Furthermore, the transmitting RLC layer device is characterized in that it can transmit data by configuring and including an RLC header structure comprising the I field proposed in this disclosure when the sorting function is configured or activated; when the order delivery is configured or activated, the receiving RLC layer device can check the I field to check t...

Claims

1. A method performed by a terminal in a wireless communication system, the method comprising: Receive a Radio Resource Control (RRC) message from the base station, wherein the RRC message includes: i) Identifiers used for bearers of multicast and broadcast services MBS; ii) The RLC mode of the Radio Link Control (RLC) layer associated with the bearer. iii) Indicate whether the Hybrid Automatic Repeat Request (HARQ) feedback is enabled for the MBS, and iv) An indication configured for the identifier of the bearer, the indication indicating that the bearer associated with the RLC layer is a multicast bearer for the MBS; Receive MBS data from the base station via a multicast bearer used for the MBS; Based on information indicating whether the HARQ feedback is enabled for the MBS, HARQ feedback information is generated for the decoding result of the MBS data; and Using the uplink resources configured by the RRC message, the HARQ feedback information is sent to the base station, and The RLC mode of the RLC layer is configured as negative acknowledgment mode UM.

2. The method according to claim 1, in, The MBS data is identified based on the wireless network temporary identifier RNTI.

3. The method according to claim 1, in, The RRC message also includes information about frequency resources for the bandwidth portion used for MBS data reception, and The MBS data is received from the base station based on the frequency resources of the bandwidth portion.

4. The method according to claim 1, in, When configuring the Service Data Adaptation Protocol (SDAP) layer for the bearer based on the RRC message, at least one Quality of Service (QoS) flow is supported for mapping between the bearer and the bearer.

5. A method performed by a base station in a wireless communication system, the method comprising: Send a Radio Resource Control (RRC) message to the terminal, wherein the RRC message includes: i) Identifiers used for bearers of multicast and broadcast services MBS; ii) The RLC mode of the Radio Link Control (RLC) layer associated with the bearer. iii) Indicate whether the Hybrid Automatic Repeat Request (HARQ) feedback is enabled for the MBS, and iv) An indication configured for the identifier of the bearer, the indication indicating that the bearer associated with the RLC layer is a multicast bearer for the MBS; Send MBS data to the terminal via a multicast bearer used for the MBS, and Based on information indicating whether the HARQ feedback is enabled for the MBS, the uplink resources configured by the RRC message are used to receive HARQ feedback information from the terminal. The RLC mode of the RLC layer is configured as negative acknowledgment mode UM.

6. The method according to claim 5, in, The MBS data is sent based on the Wireless Network Temporary Identifier (RNTI).

7. The method according to claim 5, in, The RRC message also includes information about frequency resources for the bandwidth portion used for MBS data transmission, and The MBS data is sent to the terminal based on the frequency resources of the bandwidth portion.

8. The method according to claim 5, in, When configuring the Service Data Adaptation Protocol (SDAP) layer for the bearer based on the RRC message, at least one Quality of Service (QoS) flow is supported for mapping between the bearer and the bearer.

9. A terminal in a wireless communication system, the terminal comprising: transceiver; as well as The controller is configured to: The transceiver is controlled to receive Radio Resource Control (RRC) messages from the base station, wherein the RRC messages include: i) an identifier for a bearer of Multicast and Broadcast Services (MBS); ii) the RLC mode of the Radio Link Control (RLC) layer associated with the bearer; iii) information indicating whether Hybrid Automatic Repeat Request (HARQ) feedback is enabled for the MBS; and iv) an indication configured for the identifier of the bearer, the indication indicating that the bearer associated with the RLC layer is a multicast bearer for the MBS. Control the transceiver to receive MBS data from the base station via a multicast bearer used for the MBS; Based on information indicating whether the HARQ feedback is enabled for the MBS, HARQ feedback information is generated for the decoding result of the MBS data; and The transceiver is controlled to use the uplink resources configured by the RRC message to send the HARQ feedback information to the base station, and The RLC mode of the RLC layer is configured as negative acknowledgment mode UM.

10. The terminal according to claim 9, in, The MBS data is identified based on the Wireless Network Temporary Identifier (RNTI).

11. The terminal according to claim 9, in, The RRC message also includes information about frequency resources for the bandwidth portion used for MBS data reception, and The MBS data is received from the base station based on the frequency resources of the bandwidth portion.

12. The terminal according to claim 9, in, When configuring the Service Data Adaptation Protocol (SDAP) layer for the bearer based on the RRC message, at least one Quality of Service (QoS) flow is supported for mapping between the bearer and the bearer.

13. A base station in a wireless communication system, the base station comprising: transceiver; as well as The controller is configured to: The transceiver is controlled to send a Radio Resource Control (RRC) message to the terminal, wherein the RRC message includes: i) an identifier for a bearer used for Multicast and Broadcast Services (MBS); ii) the RLC mode of the Radio Link Control (RLC) layer associated with the bearer; iii) information indicating whether Hybrid Automatic Repeat Request (HARQ) feedback is enabled for the MBS; and iv) an indication configured for the identifier of the bearer, the indication indicating that the bearer associated with the RLC layer is a multicast bearer for the MBS. Control the transceiver to send MBS data to the terminal via the multicast bearer used for the MBS, and Based on information indicating whether the HARQ feedback is enabled for the MBS, the transceiver is controlled to use the uplink resources configured by the RRC message to receive HARQ feedback information from the terminal. The RLC mode of the RLC layer is configured as negative acknowledgment mode UM.

14. The base station according to claim 13, in, The MBS data is sent based on the Wireless Network Temporary Identifier (RNTI).

15. The base station according to claim 13, in, The RRC message also includes information about frequency resources for the bandwidth portion used for MBS data transmission. The MBS data is transmitted to the terminal based on the frequency resources of the bandwidth portion, and In the case where the Service Data Adaptation Protocol (SDAP) layer is configured for the bearer based on the RRC message, at least one Quality of Service (QoS) flow is supported in the mapping between the bearer and the bearer.

Images