Method and appratus for bwp configuration for mbs service continuity in wireless communication system

Abstract

A method and apparatus for transmitting and receiving Multicast and Broadcast Service (MBS) services in a wireless communication system are disclosed. A method of operation of a base station for transmitting Multicast and Broadcast Service (MBS) services according to one embodiment of the present disclosure may include: a step of determining a Bandwidth Part (BWP) for which a terminal will receive the MBS service; a step of transmitting to the terminal a configuration information for the determined BWP, including the configuration information in at least one of a System Information Block, an RRC release message, and an RRC reset message; and a step of transmitting the MBS service to the terminal using the determined BWP.

Description

Technology Field

[0001] The present disclosure relates to a wireless communication system, and more specifically, to a method and apparatus for setting a Bandwidth Part (BWP) for Multicast and Broadcast Service (MBS) service continuity in a wireless communication system. Background Technology

[0002] Efforts are being made to develop improved 5G or pre-5G communication systems to meet the increasing demand for wireless data traffic since the commercialization of 4G communication systems. For this reason, 5G or pre-5G communication systems are referred to as systems beyond the 4G network or systems following the LTE system. To achieve high data transmission rates, the implementation of 5G communication systems in the mmWave band (e.g., the 60 GHz band) is being considered. To mitigate path loss and increase transmission distance in the mmWave band, technologies such as beamforming, massive MIMO, full Dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and large-scale antennas are being discussed for 5G communication systems. In addition, to improve the network of the system, the development of technologies such as advanced small cell, advanced small cell, cloud radio access network (cloud RAN), ultra-dense network, Device to Device communication (D2D), wireless backhaul, moving network, cooperative communication, CoMP (Coordinated Multi-Points), and interference cancellation is taking place in 5G communication systems.In addition, advanced coding modulation (ACM) methods such as FQAM (Hybrid FSK and QAM Modulation) and SWSC (Sliding Window Superposition Coding), as well as advanced access technologies such as FBMC (Filter Bank Multi Carrier), NOMA (non-orthogonal multiple access), and SCMA (sparse code multiple access) are being developed in 5G systems.

[0003] Meanwhile, the Internet is evolving from a human-centered network where humans generate and consume information into an IoT (Internet of Things) network where distributed components, such as objects, exchange and process information. IoE (Internet of Everything) technology, which combines IoT with Big Data processing technologies through connections with cloud servers, is also emerging. To implement IoT, technological elements such as sensing technology, wired and wireless communication and network infrastructure, service interface technology, and security technology are required; consequently, technologies such as sensor networks, Machine-to-Machine (M2M) communication, and Machine-Type Communication (MTC) are currently being researched to facilitate the connection of objects. In an IoT environment, intelligent IT services that create new value for human life by collecting and analyzing data generated from connected objects can be provided. Through the convergence and integration of existing IT technologies with various industries, IoT can be applied to fields such as smart homes, smart buildings, smart cities, smart or connected cars, smart grids, healthcare, smart home appliances, and advanced medical services.

[0004] Accordingly, various attempts are being made to apply 5G communication systems to IoT networks. For example, technologies such as sensor networks, Machine to Machine (M2M), and Machine Type Communication (MTC) are being implemented using 5G communication techniques such as beamforming, MIMO, and array antennas. The application of cloud RAN as a big data processing technology, as previously explained, can also be considered an example of the convergence of 5G and IoT technologies.

[0005] As a result of the aforementioned developments and advancements in wireless communication systems, it has become possible to provide various services; consequently, measures are required to facilitate the smooth provision of services, particularly those related to multicast and broadcast. The problem to be solved

[0006] The disclosed embodiments aim to provide an apparatus and method capable of effectively supporting Multicast and Broadcast Service (MBS) in a mobile communication system. means of solving the problem

[0007] A method of operation of a base station for transmitting a Multicast and Broadcast Service (MBS) service in a wireless communication system according to one embodiment of the present disclosure may include: determining a Bandwidth Part (BWP) for which a terminal will receive the MBS service; transmitting to the terminal a configuration information for the determined BWP, including the configuration information in at least one of a System Information Block, an RRC release message, and an RRC reset message; and transmitting the MBS service to the terminal using the determined BWP.

[0008] A method of operation of a terminal for receiving a Multicast and Broadcast Service (MBS) service in a wireless communication system according to one embodiment of the present disclosure comprises: a step in which a terminal in idle mode or inactive mode receives configuration information for a Broadcasting Workpiece (BWP) to receive the MBS service from a base station; and a step of receiving the MBS service from the base station based on the configuration information for the BWP, wherein the configuration information for the BWP to receive the MBS service may be received by including in at least one of a System Information Block, an RRC release message, and an RRC reset message. Brief explanation of the drawing

[0009] FIG. 1 is a diagram showing the operation method of MBS communication according to one embodiment of the present disclosure. FIG. 2 is a diagram showing a setting procedure for performing MBS communication according to one embodiment of the present disclosure. FIG. 3 is a diagram illustrating a method for setting an Initial BWP for receiving an MBS service according to one embodiment of the present disclosure. FIG. 4 is a diagram illustrating a method for setting a downlink BWP for receiving an MBS service according to one embodiment of the present disclosure. FIG. 5 is a diagram illustrating an operation for receiving an MBS service during a connection mode transition according to one embodiment of the present disclosure. FIG. 6 is a diagram illustrating a method for setting a dedicated carrier for an MBS service according to one embodiment of the present disclosure. FIG. 7 is a diagram illustrating an operation for receiving MBS services during an idle mode or inactive mode transition according to one embodiment of the present disclosure. FIG. 8 is a diagram showing a BWP setting method for an MBS service according to one embodiment of the present disclosure. FIG. 9 is a diagram showing a BWP setting method for an MBS service according to one embodiment of the present disclosure. FIG. 10 is a drawing illustrating the structure of a base station according to one embodiment of the present disclosure. FIG. 11 is a drawing illustrating the structure of a terminal according to one embodiment of the present disclosure. FIG. 12 is a drawing illustrating an MBS split bearer and path switching according to one embodiment of the present disclosure. FIG. 13 is a diagram illustrating an MBS split bearer and a path switching process according to one embodiment of the present disclosure. FIG. 14 is a diagram illustrating an MBS split bearer and a path switching process according to one embodiment of the present disclosure. FIG. 15 is a diagram illustrating the first packet reception operation after path switching of an MBS split bearer according to one embodiment of the present disclosure. FIG. 16 is a diagram illustrating the first packet reception operation after path switching of an MBS split bearer according to one embodiment of the present disclosure. FIG. 17 is a diagram illustrating the first packet reception operation after path switching of an MBS split bearer according to one embodiment of the present disclosure. FIG. 18 is a diagram illustrating the path switching operation of an MBS split bearer according to one embodiment of the present disclosure. FIG. 19 is a diagram illustrating the operation of an MBS wireless bearer during handover according to one embodiment of the present disclosure. FIG. 20 is a drawing illustrating a bearer type conversion including an MBS split bearer according to one embodiment of the present disclosure. Specific details for implementing the invention

[0010] The operating principles of the present disclosure will be described in detail below with reference to the attached drawings. In describing the present disclosure below, specific descriptions of related known functions or configurations will be omitted if it is determined that such detailed descriptions would unnecessarily obscure the essence of the present disclosure. Furthermore, the terms described below are defined in consideration of their functions in the present disclosure, and these may vary depending on the intentions or practices of the user or operator. Therefore, their definitions should be based on the content throughout this specification.

[0011] For the same reason, some components in the attached drawings have been exaggerated, omitted, or schematically depicted. Additionally, the dimensions of each component do not entirely reflect their actual dimensions. Identical or corresponding components in each drawing have been assigned the same reference numbers.

[0012] The advantages and features of the present disclosure and the methods for achieving them will become clear by referring to the embodiments described below in detail together with the accompanying drawings. However, the present disclosure is not limited to the embodiments disclosed below but may be implemented in various different forms; the embodiments are provided merely to make the present disclosure complete and to fully inform those skilled in the art of the scope of the disclosure, and the present disclosure is defined only by the scope of the claims. Throughout the specification, like reference numerals refer to like components.

[0013] At this point, it will be understood that each block of the process flow diagrams and combinations of the flow diagrams can be executed by computer program instructions. Since these computer program instructions can be loaded into the processor of a general-purpose computer, a special-purpose computer, or other programmable data processing equipment, the instructions executed through the processor of the computer or other programmable data processing equipment create means to perform the functions described in the flow diagram block(s). Since these computer program instructions can also be stored in computer-available or computer-readable memory that can be directed toward the computer or other programmable data processing equipment to implement the function in a specific way, the instructions stored in computer-available or computer-readable memory can also produce a manufactured item containing instruction means to perform the function described in the flow diagram block(s). Since computer program instructions can be loaded onto a computer or other programmable data processing equipment, instructions that perform a series of operation steps on the computer or other programmable data processing equipment to create a process executed by the computer can also provide steps for executing the functions described in the flowchart block(s).

[0014] Additionally, each block may represent a module, segment, or part of code containing one or more executable instructions for executing a specific logical function(s). It should also be noted that in some alternative execution examples, the functions mentioned in the blocks may occur out of order. For example, two blocks described in succession may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order according to their corresponding functions.

[0015] In this embodiment, the term "part" refers to a software or hardware component such as an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit), and the "part" performs certain roles. However, the meaning of "part" is not limited to software or hardware. The "part" may be configured to reside in an addressable storage medium or configured to run one or more processors. Thus, as an example, the "part" includes components such as software components, object-oriented software components, class components, and task components, as well as processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functions provided within the components and "parts" may be combined into a smaller number of components and "parts" or further separated into additional components and "parts." In addition, the components and 'parts' may be implemented to utilize one or more CPUs within the device or secure multimedia card. Also, in the embodiments, 'parts' may include one or more processors.

[0016] In describing the present disclosure below, specific descriptions of related known functions or configurations will be omitted if it is determined that such detailed descriptions would unnecessarily obscure the essence of the present disclosure. Embodiments of the present disclosure will be described below with reference to the attached drawings.

[0017] Terms used in the following description to identify connection nodes, terms referring to network entities, terms referring to messages, terms referring to interfaces between network entities, terms referring to various identification information, etc., are examples provided for the convenience of explanation. Accordingly, the present disclosure is not limited to the terms described below, and other terms referring to objects having equivalent technical meanings may be used.

[0018] Hereinafter, the base station is an entity that performs resource allocation for terminals and may be at least one of a gNode B, eNode B, Node B, BS (Base Station), wireless access unit, base station controller, or a node on a network. The terminal may include a UE (User Equipment), MS (Mobile Station), cellular phone, smartphone, computer, or a multimedia system capable of performing communication functions. Furthermore, the term terminal may refer to mobile phones, NB-IoT devices, sensors, as well as other wireless communication devices. Of course, base stations and terminals are not limited to the above examples.

[0019] For convenience of explanation, the present disclosure uses terms and names defined in the 3GPP LTE (3rd Generation Partnership Project Long Term Evolution) and / or 3GPP NR (3rd Generation Partnership Project New Radio) standards. However, the present disclosure is not limited by the above terms and names and may be equally applied to systems conforming to other standards. In the present disclosure, eNB may be used interchangeably with gNB for convenience of explanation. That is, a base station described as an eNB may represent a gNB.

[0020] In particular, the present disclosure is applicable to 3GPP NR (5th generation mobile communication standard). Furthermore, the present disclosure is applicable to intelligent services based on 5G communication technology and IoT-related technology (e.g., smart home, smart building, smart city, smart car or connected car, healthcare, digital education, retail, security and safety-related services, etc.). In the present disclosure, eNB may be used interchangeably with gNB for convenience of explanation. That is, a base station described as eNB may represent a gNB. Additionally, the term terminal may refer to mobile phones, NB-IoT devices, sensors, as well as other wireless communication devices.

[0021] Wireless communication systems are evolving from providing early voice-oriented services to broadband wireless communication systems that provide high-speed, high-quality packet data services, such as communication standards like 3GPP’s HSPA (High Speed ​​Packet Access), LTE (Long Term Evolution or E-UTRA (Evolved Universal Terrestrial Radio Access)), LTE-Advanced (LTE-A), LTE-Pro, 3GPP2’s HRPD (High Rate Packet Data), UMB (Ultra Mobile Broadband), and IEEE’s 802.16e.

[0022] As a representative example of a broadband wireless communication system, the LTE system employs the Orthogonal Frequency Division Multiplexing (OFDM) method for the downlink (DL) and the Single Carrier Frequency Division Multiple Access (SC-FDMA) method for the uplink (UL). The uplink refers to a wireless link through which a terminal (User Equipment; UE or Mobile Station; MS) transmits data or control signals to a base station (eNode B or BS; Base Station), and the downlink refers to a wireless link through which a base station transmits data or control signals to a terminal. The above multiple access method distinguishes the data or control information of each user by allocating and operating time-frequency resources to be transmitted for each user so that they do not overlap, that is, so that orthogonality is established.

[0023] As a future communication system following LTE, that is, a 5G communication system, it must be able to freely reflect the diverse requirements of users and service providers, and therefore, services that satisfy various requirements simultaneously must be supported. Services being considered for the 5G communication system include Enhanced Mobile BroadBand (eMBB), massive Machine Type Communication (mMTC), and Ultra Reliability Low Latency Communication (URLLC).

[0024] According to one embodiment, eMBB may aim to provide a data transmission speed that is higher than the data transmission speed supported by existing LTE, LTE-A, or LTE-Pro. For example, in a 5G communication system, eMBB must be able to provide a peak data rate of 20 Gbps in the downlink and a peak data rate of 10 Gbps in the uplink from the perspective of a single base station. In addition, the 5G communication system may need to provide a user-perceived data rate while simultaneously providing the peak data rate. To satisfy these requirements, the 5G communication system may require improvements in various transmission and reception technologies, including enhanced Multi-Input Multi-Output (MIMO) transmission technology. Furthermore, while current LTE transmits signals using a maximum transmission bandwidth of 20 MHz in the 2 GHz band, the 5G communication system can satisfy the data transmission speed required by the 5G communication system by using a frequency bandwidth wider than 20 MHz in frequency bands of 3 to 6 GHz or above 6 GHz.

[0025] Simultaneously, mMTC is being considered to support application services such as the Internet of Things (IoT) in 5G communication systems. To efficiently provide IoT services, mMTC may require support for a large number of terminal connections within a cell, improved terminal coverage, enhanced battery life, and reduced terminal costs. Since IoT devices are attached to various sensors and equipment to provide communication functions, the system must be able to support a large number of terminals within a cell (e.g., 1,000,000 terminals / km²). Furthermore, due to the nature of the service, terminals supporting mMTC are likely to be located in dead zones not covered by cells, such as building basements; therefore, wider coverage may be required compared to other services provided by 5G communication systems. Terminals supporting mMTC must consist of low-cost devices, and since it is difficult to frequently replace terminal batteries, a very long battery life of 10 to 15 years may be required.

[0026] Finally, URLLC is a mission-critical cellular-based wireless communication service that can be used for services such as remote control of robots or machinery, industrial automation, unmanned aerial vehicles, remote health care, and emergency alerts. Therefore, the communication provided by URLLC may need to offer very low latency and very high reliability. For example, services supporting URLLC must satisfy an air interface latency of less than 0.5 milliseconds and may simultaneously require a packet error rate of 10⁻⁵ or less. Consequently, for services supporting URLLC, 5G systems must provide a Transmit Time Interval (TTI) smaller than other services, and design considerations may be required to allocate wide resources in the frequency band to ensure the reliability of the communication link.

[0027] The three services considered in the aforementioned 5G communication system, namely eMBB, URLLC, and mMTC, can be multiplexed and transmitted within a single system. In this case, different transmission and reception techniques and parameters may be used between the services to satisfy the different requirements of each service. However, the aforementioned mMTC, URLLC, and eMBB are merely examples of different service types, and the service types to which the present disclosure applies are not limited to the examples mentioned above.

[0028] In addition, although embodiments of the present disclosure are described below using LTE, LTE-A, LTE Pro, or 5G (or NR, next-generation mobile communication) systems as examples, embodiments of the present disclosure may be applied to other communication systems having similar technical backgrounds or channel types. Furthermore, embodiments of the present disclosure may be applied to other communication systems with some modifications made at the discretion of a person with skilled technical knowledge, without significantly departing from the scope of the present disclosure.

[0029] Embodiments of the present disclosure will be described below with reference to the attached drawings.

[0030] FIG. 1 is a diagram illustrating the operation method of MBS communication according to one embodiment of the present disclosure. MBS (Multicast and Broadcast Service) communication refers to a method in which a single transmitting device communicates with multiple receiving devices in a wireless communication system. Here, the transmitting device may be a base station, and each receiving device may be a terminal. However, it is not limited thereto, and the transmitting device may also be a terminal.

[0031] Referring to FIG. 1, the process of performing MBS communication is illustrated when a base station (110) is a transmitting device and a terminal (120, 130, 140, 150) is a receiving device. This MBS communication may be a broadcast for an unspecified number of people, or a multicast for a specific number of receiving devices. If communication is performed using a multicast method, the base station may be configured so that only specific terminals can receive the corresponding multicast packet. To this end, a set of terminals to perform specific multicast communication may be configured, and in FIG. 1, this is referred to as a multicast group (160).

[0032] Terminals (120, 130, 140) within a multicast group (160) can receive data assigned to the corresponding G-RNTI by being assigned the same G-RNTI (Group - Radio Network Temporary Identity) from the base station (110). In the embodiment of FIG. 1, it is assumed that terminal 1 (120), terminal 2 (130), and terminal 3 (140) are set up as a single multicast group (160) and receive data from the base station (110) via multicast by being assigned a G-RNTI. Since terminal 4 (150) is not included in the multicast group, it is not assigned a G-RNTI, and consequently, terminal 4 (150) cannot receive the data that terminal 1 (120), terminal 2 (130), and terminal 3 (140) receive from the base station (110).

[0033] One or more multicast groups may be configured within the coverage of a base station (110), and each multicast group may be distinguished by a G-RNTI. A terminal may be assigned one or more G-RNTIs from the base station (110). The terminal may receive multicast data using the G-RNTI value assigned in connection mode, not only in connection mode (RRC CONNECTED MODE) but also in idle mode (RRC IDLE MODE) or inactive mode (RRC INACTIVE MODE). The G-RNTI may be configured for the terminal by being included in at least one message among the RRC Reconfiguration, RRC Setup, and RRC Reestablishment messages that the terminal can receive in connection mode. However, it is not limited thereto, and the base station may transmit to the terminal a G-RNTI value that the terminal can receive in a System Information Block (SIB). A terminal that has received a G-RNTI value according to one or more of the various methods described above can apply the G-RNTI value from the time it receives the G-RNTI value.

[0034] FIG. 2 is a diagram showing a setting procedure for performing MBS communication according to one embodiment of the present disclosure.

[0035] Referring to FIG. 2, in the case of a terminal (220) that is not connected to a base station (210) and an RRC (Radio Resource Control) setting, the terminal may select a base station to request MBS service in order to perform MBS communication. At this time, in step 230, the terminal (220) may receive a synchronization signal transmitted from the base station and perform a cell selection or cell reselection procedure to select a base station with a strong received signal. In the embodiment of FIG. 2, it is assumed that the terminal, having transitioned to an idle mode or inactive mode after the initial connection state, performs a cell reselection operation to select a cell.

[0036] In step 235, the terminal (220) may receive a System Information Block (SIB) from a selected cell. At this time, if the terminal (220) wishes to receive MBS services, it may receive a System Information Block containing MBS information among the System Information Blocks. The System Information Block containing MBS information may include a list of MBS services that are already provided or may be provided in each serving cell. This list of MBS services that are already provided or may be provided in each serving cell may be referred to as AvailableMBSList. AvailableMBSList may include MBS session information. MBS session information may include a tmgi (Temporary Mobile Group Identity) value that can identify a group and an MBS session ID (sessionID). The tmgi value may include a PLMN (Public Land Mobile Network) ID (plmn-id) that identifies whether the service is provided by a telecommunications carrier and a service ID (serviceID) that identifies the service provided by that telecommunications carrier. When this information is combined, AvailableMBSList can have a structure like the following example.

[0037] - AvailableMBSList = MBSSessionInfoList

[0038] ■ MBSSessionInfoList = Sequence of (tmgi, sessionID)

[0039] ◆ tmgi = (plmn-id, serviceID)

[0040] If all terminals request RRC settings to receive all MBS services, the base station may become overloaded due to a sudden influx of many terminals. Therefore, an access control method for MBS services may be required. To this end, an access category value and uac-BarringForAccessIdentity for access control can be set for each tmgi. Using the access category and uac-BarringForAccessIdentity set in this way, the frequency of connection requests to the base station for each tmgi can be controlled. In the embodiment of FIG. 2, it was assumed that the terminal receives a system information block containing MBS information, but this is not limited thereto, and the MBS information can be transmitted via a Downlink Information Transfer (DL) message.

[0041] A terminal (220) that has received a system information block containing MBS information can, at step 240, identify an MBS service of interest among the list of MBS services that are already provided or may be provided in each serving cell. The terminal (220) may determine whether the terminal (220) is interested in a particular MBS service based on whether it is an MBS service required by the application of the terminal (220) or other conditions. The criterion for the terminal (220) to identify an MBS service may be in the tmgi unit. That is, the terminal (220) can check whether the tmgi of the MBS service that the terminal (220) intends to receive (or that the terminal (220) is interested in) is included in the system information block containing MBS information. Specifically, the terminal (220) can check whether the tmgi of the MBS service that the terminal (220) intends to receive is included in the AvailableMBSList of the system information block containing MBS information. If the tmgi of the MBS service that the terminal (220) intends to receive is included in a system information block containing MBS information, the terminal (220) may perform the step of establishing an RRC connection to receive the MBS service. In step 245, the terminal (220) may perform an access control operation to determine whether to initiate the establishment of an RRC connection. The terminal (220) may perform access control based on the PLMN ID (plmn-ID) included in the tmgi of the MBS service to be received, using UAC-Barring information for the corresponding PLMN ID. It may be determined whether access is allowed for the uac-BarringForAccessIdentity and access category of the MBS service that the terminal (220) intends to receive. If access to this MBS service is allowed, the terminal (220) may start the procedure to request an RRC connection.

[0042] In step 250, if the terminal (220) is granted access to receive MBS services, the terminal (220) may send an RRC Setup Request message to the base station (210). However, not limited thereto, an RRC Reestablishment Request message may also be used for the same purpose as the RRC Setup Request message. Since these RRC Setup Request messages or RRC Reestablishment Request messages are general messages that can be used for the terminal to transition to RRC CONNECTED MODE, they may include a Cause value indicating the purpose for which the terminal wishes to transition to CONNECTED MODE. At this time, if the terminal (220) wishes to receive MBS services, it may send an RRC Setup Request or RRC Reestablishment Request message to the base station (210), including a Cause value indicating that it wishes to set up MBS. However, if the RRC establishment request or RRC re-establishment request is not for the terminal (220) to receive MBS services, the terminal (220) can send an RRC establishment request or RRC re-establishment request message using the Cause value transmitted from the upper layer.

[0043] In step 260, the base station (210) may transmit an RRC Setup message to the terminal (220) to transition the terminal (220) to a connection mode. However, not limited thereto, an RRC Reestablishment message may also be used for the same purpose as the RRC Setup message. When the terminal (220) receives an RRC Setup message or an RRC Reestablishment message, the SRB1 may be configured by the configuration information of the SRB1 (Signaling Radio Bearer 1) included in the received message. The SRB1 may be a radio bearer for exchanging RRC (Radio Resource Control) messages between the base station (210) and the terminal (220).

[0044] In step 265, the terminal (220) applies the configuration information included in the RRC establishment message or RRC re-establishment message and transmits an RRC establishment completion or RRC re-establishment completion message to the base station (210) to indicate that the configuration received from the base station (210) has been successfully applied. In addition, the RRC establishment completion or RRC re-establishment completion message transmitted in step 265 may include a list of MBS services that the terminal (220) wishes to receive. This MBS service list may be a list containing tmgi values ​​corresponding to the MBS services that the terminal wishes to receive. In this case, the tmgi containing the MBS service list may be all or part of the tmgi included in the list of MBS services that are already provided or may be provided in each serving cell, which is included in the system information block or downlink information transmission message transmitted by the base station (210) in step 235.

[0045] In step 265, since SRB1 is configured and a list of MBS services that the terminal (220) wishes to receive is transmitted to the base station (210), the base station (210) can configure the reception of MBS services based on this in step 270. These MBS services can be configured using an RRC reconfiguration message transmitted by the base station (210) to the terminal (220). This RRC reconfiguration message may include SRB2 (Signaling Radio Bearer 2) used for transmitting and receiving NAS (Non-Access Stratum) messages, DRB (Data Radio Bearer) used for transmitting and receiving data, and PTM (Point To Multipoint) DRB configuration information used for multicast transmission. Here, the PTM DRB may be configured without distinction from the general DRB, or it may be configured by the received G-RNTI. In addition, the Radio Link Control (RLC) bearer to which the configured Radio Bearer will transmit can be configured, and which Radio Bearer this RLC bearer will be connected to can also be configured. Furthermore, a G-RNTI can be configured to enable terminals belonging to a multicast group to receive multicast data. This G-RNTI is an RNTI configured for the reception of Transport Blocks (TB) and can be used to indicate scheduling information for PDSCH. This G-RNTI can be configured at the MAC device level, but it can also be configured at the Bandwidth Part (BWP) level. If the G-RNTI is configured at the BWP level, the configured G-RNTI can only be used when receiving PDSCH resources of that BWP. In other words, the corresponding G-RNTI may not be used by other BWPs. To this end, the G-RNTI can be configured by including it in the Downlink BWP configuration field of the RRC message.A BWP ID to be used when the G-RNTI is configured may also be configured. In another embodiment, the G-RNTI may be configured on a cell-by-cell basis. If the G-RNTI is configured on a cell-by-cell basis, the configured G-RNTI may be used only when receiving the PDSCH resources of that cell. That is, the G-RNTI may not be used in other cells. To this end, the G-RNTI may be configured by including it in the cell configuration field of an RRC message. A cell ID to be used when the G-RNTI is configured may also be configured.

[0046] For the reception of MBS services, a BWP and a Search Space may be separately configured. Information regarding a BWP and a Search Space for receiving a specific MBS service may be configured from a base station to a terminal, and the configuration information regarding the BWP and Search Space for receiving a specific MBS service may include an MBS BWP and an MBS Search Space. Here, an MBS BWP may refer to a BWP to which an assigned G-RNTI is applied. According to one embodiment, a BWP containing a G-RNTI in the BWP-Downlink configuration field may be an MBS BWP. An MBS Search Space may be a Search Space in which a DCI (Downlink Control Information) format for MBS reception is configured in the Search Space configuration information, or a Search Space in which an indicator indicating that it is a Search Space for MBS reception is included in the Search Space configuration information. For example, a 1-bit indicator indicating whether the corresponding Search Space is an MBS Search Space may be included in the Search Space configuration information. If this indicator shows whether it is an MBS search space, then that search space can be an MBS search space and can be used as a search space monitoring G-RNTI for MBS reception.

[0047] If the terminal has applied the contents included in the RRC configuration message of step 270, in step 275, the terminal (220) can notify the base station (210) that it has applied the information of the RRC configuration message by sending an RRC Reconfiguration Complete message. Accordingly, in step 280, the terminal (220) can perform MBS communication to receive broadcast or multicast packets. That is, it can receive MBS services from the base station.

[0048] FIG. 3 is a diagram illustrating a method for setting an Initial BWP for receiving an MBS service according to one embodiment of the present disclosure.

[0049] If a terminal in idle mode or inactive mode is to receive MBS services, a BWP capable of receiving MBS services must be configured. Since multiple BWPs can be configured in a single cell and a terminal can only have one BWP active, the terminal needs to receive MBS services from the terminal's Active BWP. To this end, the base station can configure the BWP for the terminal to receive MBS services in the terminal's idle mode or inactive mode. Referring to FIG. 3, a terminal (320) in idle mode or inactive mode can receive MBS services from an Initial BWP configured by the base station (310). The Initial BWP represents the BWP to be used when the terminal makes an initial connection, but in the embodiment of FIG. 3, the Initial BWP can be used for receiving MBS services. This configuration of the Initial BWP can be achieved by the base station (310) transmitting a message (330) to the terminal (320) to configure the Initial BWP. A message for setting the Initial BWP may be transmitted periodically via a System Information Block or transmitted when the terminal transitions to idle mode or inactive mode via an RRC Release message, etc. In another embodiment, Initial BWP information may be transmitted and set via an RRC Reconfiguration message. The message for setting the Initial BWP may include at least one of the BWP ID of the Initial BWP, the tmgi of the MBS service that can be serviced by the BWP, and a G-RNTI value that can receive data from the MBS service. By applying the information included in the message for setting the Initial BWP, the terminal can receive the MBS service when in idle mode or inactive mode.According to one embodiment, the terminal can detect whether there is data for receiving MBS services using G-RNTI in the Initial BWP set when in idle mode or inactive mode, and if a downlink radio resource using G-RNTI is detected, the terminal can receive MBS services from the downlink radio resource using G-RNTI.

[0050] A search space and a CORESET (Control Resource Set) for the PDCCH (Physical Downlink Control Channel) that the terminal must monitor to receive MBS services from the Initial BWP can be included and configured in the message (330) that sets the Initial BWP. Although the embodiment of FIG. 3 focuses on cases where the terminal is in idle mode or inactive mode, it is not limited thereto, and the terminal may also receive MBS services from the Initial BWP when it is in connection mode.

[0051] FIG. 4 is a diagram illustrating a method for setting a downlink BWP for receiving an MBS service according to one embodiment of the present disclosure.

[0052] If a terminal in idle mode or inactive mode is to receive MBS services, a BWP capable of receiving MBS services must be configured. Since multiple BWPs can be configured in a single cell and a terminal can only have one BWP active, the terminal needs to receive MBS services from its Active BWP. To this end, the base station can configure a Downlink BWP to receive MBS services when the terminal is in idle mode or inactive mode. Referring to FIG. 4, a terminal (420) in idle mode or inactive mode can receive MBS services from a Downlink BWP configured by the base station (410). The Downlink BWP configured by the base station (410) is a BWP configured by the base station (410) for the terminal (420) to receive MBS services, and can be configured for a terminal in idle mode or inactive mode to receive specific MBS services. The setting of a downlink BWP for MBS purposes can be accomplished by a message (430) for setting a downlink BWP for MBS purposes that the base station (410) transmits to the terminal (420). The message for setting a downlink BWP for MBS purposes may be transmitted periodically via a System Information Block or transmitted when the terminal transitions to an idle mode or inactive mode via an RRC Release message, etc. In another embodiment, the downlink BWP setting may be configured by transmitting downlink BWP information for MBS purposes via an RRC Reconfiguration message. The message for setting a downlink BWP for MBS purposes may include at least one of the BWP ID of the BWP, the tmgi of the MBS service that can be serviced by the BWP, and a G-RNTI value that can receive data of the MBS service. By applying this information, the terminal can receive the MBS service when in an idle mode or inactive mode.The downlink BWP for MBS purposes set in the embodiment of FIG. 4 may be a different BWP from the Initial BWP. According to one embodiment, when the terminal is in idle mode or inactive mode, it may use G-RNTI in the downlink BWP for MBS purposes set to detect whether there is data for receiving MBS services, and if a downlink radio resource is detected using G-RNTI, it may receive MBS services from that downlink radio resource. However, in another embodiment, the terminal may detect downlink radio resources using G-RNTI in the Initial BWP, and receive the actual corresponding downlink radio resource in the downlink BWP for MBS purposes. The Search Space and CORESET (Control Resource Set) for the PDCCH (Physical Downlink Control Channel) that the terminal must monitor to receive MBS services in the Active BWP may be included and set in the message (430) for setting the downlink BWP for MBS purposes.

[0053] FIG. 5 is a diagram illustrating an operation for receiving an MBS service during a connection mode transition according to one embodiment of the present disclosure.

[0054] By means of the method described in FIG. 3 or FIG. 4, the terminal may receive MBS services in idle mode or inactive mode. While the terminal is receiving MBS services, a transition to connection mode may be required by a pre-set condition. Referring to FIG. 5, in step 530, the terminal (520) that was in idle mode or inactive mode may perform a procedure to transition to connection mode. To transition to connection mode, the terminal (520) may transmit a message such as an RRC Connection Request or an RRC Resume Request to the base station (510). Accordingly, the terminal (520) may request to transition to connection mode by transmitting a message such as an RRC Connection Request or an RRC Resume Request to the base station (510). If a terminal has been receiving MBS services in idle mode or inactive mode and wishes to receive the MBS services in connection mode as well, in step 540, the terminal (510) may transmit to the base station (520) a list of MBS services that the terminal (510) was receiving in idle mode or inactive mode. The list of MBS services that the terminal (510) was receiving may be the MBS services that the terminal (510) was receiving. In addition, the terminal (510) may transmit to the base station (520) a list of MBS services that it is receiving, including an indicator that it wishes to receive the services continuously in connection mode as well. In another embodiment, the terminal (510) may separately transmit to the base station (520) a list of MBS services that it wishes to receive continuously in connection mode and a list of MBS services that it no longer needs to receive.In another embodiment, the terminal (510) may transmit to the base station (520) only the list of MBS services that it wishes to continuously receive in connection mode from the list of MBS services that were being received. In step 550, the base station (520) may set the MBS services that the terminal (510) can receive in connection mode based on the information received from the terminal (510). The MBS service setting information that can be received in connection mode may include a list of tmgi that the terminal can receive, settings of a wireless bearer for MBS, G-RNTI information, etc. Additionally, the base station (520) may set an Active BWP for receiving the terminal MBS services. Based on this setting information, the terminal can continuously receive MBS services in connection mode.

[0055] FIG. 6 is a diagram illustrating a method for setting a dedicated carrier for an MBS service according to one embodiment of the present disclosure.

[0056] A base station providing MBS services may provide MBS services on a specific carrier or a specific cell. In a mobile communication network, terminals receiving unicast communication services other than MBS services and terminals receiving MBS services may exist simultaneously. Furthermore, some terminals (610) may receive both unicast communication and MBS services. A mobile communication operator or a mobile communication base station may distinguish between unicast data and data for MBS services and provide each service on a different carrier or a different cell. Referring to FIG. 6, ordinary unicast data may be transmitted from a downlink carrier (620), and data for MBS services may be transmitted from a separate dedicated carrier, a Supplementary Downlink (SDL) carrier. However, this is merely one embodiment and is not limited thereto, and unicast data may be transmitted from one cell and data for MBS services may be transmitted from another cell. To distinguish traffic, the base station may set an SDL carrier for MBS services or an MBS-dedicated cell for the terminal. Configuration information for distinguishing traffic may be transmitted using a system information block as shown in FIG. 3 or FIG. 4, or by using at least one of an RRC release message or an RRC reset message. Additionally, the configuration information may include a PCI (Physical-layer Cell ID) or an SDL configuration indicator for an SDL carrier or cell for MBS services. Furthermore, the configuration information may include a list of MBS services provided by the SDL carrier or cell for MBS services. tmgi may be used as such a list of MBS services.

[0057] FIG. 7 is a diagram illustrating an operation for receiving MBS services during an idle mode or inactive mode transition according to one embodiment of the present disclosure.

[0058] Referring to FIG. 7, in step 730, the terminal (720) can receive MBS services from the connection board by receiving MBS settings from the base station (710). However, if the base station (710) determines that connection mode communication is no longer necessary for the terminal (720), in step 740, the base station (710) may send an RRC Release message to the terminal (720) to instruct the terminal (720) to transition to idle mode or inactive mode. However, if the terminal (720) was receiving MBS services in the existing connection mode and needs to continue receiving the MBS services that were previously provided, the terminal (720) needs to be configured with MBS services to continue receiving these MBS services in idle mode or inactive mode. The configuration of MBS services to continue receiving MBS services may include a configuration for the BWP that the terminal (720) will receive MBS services from in idle mode or inactive mode. To configure the BWP for which the terminal (720) will receive MBS services, the base station (710) may include a BWP ID for the BWP that the terminal (720) will receive in idle mode or inactive mode in the RRC release message, thereby including information on which BWP the terminal will receive MBS services from. However, this is not limited thereto, and in one embodiment, the BWP ID is not included in the RRC release message, and the base station (710) may instruct the terminal (720) to continue using the currently used Active BWP. In another embodiment, the BWP ID is not included in the RRC release message, and the base station (710) may instruct the terminal (720) to switch to the Initial BWP to receive MBS services. In yet another embodiment, the BWP ID is not included in the RRC release message, and the base station (710) may instruct the terminal (720) to switch to the Default BWP to receive MBS services.In another embodiment, if the RRC release message includes a BWP ID indicating which BWP will receive the MBS service, the terminal can receive the MBS service using the corresponding BWP in idle mode or inactive mode; however, if the RRC release message does not include a BWP ID, the terminal can receive the MBS service from the Initial BWP. In another embodiment, if the RRC release message includes a BWP ID indicating which BWP will receive the MBS service, the terminal can receive the MBS service using the corresponding BWP in idle mode or inactive mode; however, if the RRC release message does not include a BWP ID, the terminal can receive the MBS service from the last Active BWP used in connection mode. In another embodiment, if the RRC release message includes a BWP ID indicating which BWP will receive the MBS service, the terminal can receive the MBS service using the corresponding BWP in idle mode or inactive mode; however, if the RRC release message does not include a BWP ID, the terminal can receive the MBS service from the Default BWP. And the MBS configuration information that can be included and transmitted in the RRC disconnection message may include a list of MBS services that the terminal can use in the BWP. This list of MBS services may include a list of tmgi. In step 750, the terminal (720) may continue to receive MBS services in idle mode or inactive mode. If the MBS service that the terminal is currently receiving and wishes to continue receiving is not included in the list of MBS services included in the RRC disconnection message, after RRC disconnection, the terminal (720) may transmit an RRC configuration request message or an RRC connection resumption request message to the base station (710) to transition back to connection mode.

[0059] In one embodiment, if the RRC disconnection message includes an indicator indicating that the base station does not discontinue the MBS service being received by the terminal upon RRC disconnection (where no indicator indicating that the MBS service is discontinued is included), and the RRC disconnection message does not include a list of MBS services that the terminal is currently receiving and wishes to continue receiving, then after RRC disconnection, the terminal may send an RRC setup request message or an RRC connection resumption request message to the base station to transition back to connection mode. Alternatively, if the RRC disconnection message does not include an indicator indicating that the base station does not discontinue the MBS service being received by the terminal upon RRC disconnection (where no indicator indicating that the MBS service is discontinued is included), and the RRC disconnection message does not include a list of MBS services that the terminal is currently receiving and wishes to continue receiving, then the terminal may transition to idle mode or inactive mode and no longer receive the MBS service it was receiving.

[0060] FIG. 8 is a diagram illustrating a BWP configuration method for an MBS service according to an embodiment of the present disclosure. A base station may operate multiple BWPs in a single cell and may configure one Active BWP at a single time for a single terminal. An MBS service may be provided in all or some of these multiple BWPs.

[0061] Referring to FIG. 8, it is assumed that a total of four BWPs (800, 810, 820, 830) are set in one cell. Among the four BWPs (800, 810, 820, 830), data for the MBS service may be transmitted only from BWP0 (800) and BWP1 (810), and data for the MBS service may not be transmitted from the other BWPs, BWP2 (820) and BWP3 (830).

[0062] In the embodiment of FIG. 8, it is assumed that the same MBS service is provided by two BWPs (800, 810) that transmit data for the MBS service. Therefore, if a terminal can receive data from at least one of BWPs, either BWP0 (800) or BWP1 (810), the terminal can receive the same MBS service. In this case, the terminal needs to know which BWP transmits data for the MBS service. To this end, the base station may inform the terminal which BWP transmits data for the MBS service by using at least one of an RRC Reconifguration, RRC Setup, RRC Re-establishment, RRC Release, or System Information Block message. In one embodiment, the base station may inform the terminal of a list of BWPs that transmit data for the MBS service in each Cell. In another embodiment, the base station may transmit to the terminal each BWP setup information including an indicator indicating whether it is a BWP transmitting data for the MBS service.

[0063] FIG. 9 is a diagram illustrating a BWP configuration method for an MBS service according to an embodiment of the present disclosure. A base station may operate multiple BWPs in a single cell and may configure one Active BWP at a single time for a single terminal. The MBS service may be provided in all or some of these multiple BWPs.

[0064] Referring to FIG. 9, it is assumed that a total of four BWPs (900, 910, 920, 930) are set in one cell. Among the four BWPs (900, 910, 920, 930), data for the MBS service may be transmitted only from BWP0 (900) and BWP1 (910), and data for the MBS service may not be transmitted from the other BWPs, BWP2 (920) and BWP3 (930).

[0065] In the embodiment of FIG. 9, it is assumed that different MBS services are provided at the two BWPs transmitting data for MBS services. Therefore, in order for a terminal to receive a specific MBS service, it must receive data from the BWP that provides that MBS service. In this case, the terminal needs to know which BWP transmits data for which MBS service. Accordingly, the base station may notify the terminal of the list of MBS services provided by each BWP using at least one of RRC Reconifguration, RRC Setup, RRC Re-establishment, RRC Release, or System Information Block Message. In one embodiment, a list of tmgi may be used and transmitted as the list of MBS services provided by the BWP.

[0066] FIG. 10 is a drawing illustrating the structure of a base station according to one embodiment of the present disclosure.

[0067] Referring to FIG. 10, a base station may include a transceiver (1010), a control unit (1020), and a storage unit (1030). In the present disclosure, the control unit (1020) may be defined as a circuit or an application-specific integrated circuit or at least one processor. The transceiver (1010), control unit (1020), and storage unit (1030) of the base station may operate according to the communication method of the base station described above. However, the components of the base station are not limited to the examples described above. For example, the base station may include more components or fewer components than the components described above. In addition, the transceiver (1010), control unit (1020), and storage unit (1030) may be implemented in the form of a single chip.

[0068] The transceiver (1010) can transmit and receive signals with other network entities. The transceiver (1010) can, for example, transmit system information to a terminal and transmit a synchronization signal or a reference signal. The transceiver (1010) is a collective term for the receiver and the transmitter of a base station and can transmit and receive signals with a terminal or a network entity. The signals transmitted and received with the terminal or network entity may include control information and data. To this end, the transceiver (1010) may be composed of an RF transmitter that up-converts and amplifies the frequency of a transmitted signal, and an RF receiver that low-noise amplifies a received signal and down-converts the frequency. However, this is merely one embodiment of the transceiver (1010), and the components of the transceiver (1010) are not limited to an RF transmitter and an RF receiver. Additionally, the transmitting and receiving unit (1010) can receive a signal through a wireless channel and output it to the control unit (1020), and transmit the signal output from the control unit (1020) through the wireless channel.

[0069] The control unit (1020) can control the overall operation of the base station according to the embodiment proposed in the present disclosure. For example, the control unit (1020) can control the signal flow between each block to perform operations according to the flowchart described above. The control unit (1020) can receive control signals and data signals through the transceiver (1010) and process the received control signals and data signals. In addition, the control unit (1020) can transmit the processed control signals and data signals through the transceiver (010). In addition, the control unit (1020) can control each component of the base station to configure downlink control information (DCI) including allocation information for the physical downlink shared channel (PDSCH) and to transmit it. The control unit (1020) may be one but may be multiple, and may be composed of one or multiple processors. The control unit (1020) can perform control operations of the base station components by executing a program stored in the storage unit (1030).

[0070] The storage unit (1030) can store at least one of the information transmitted and received through the transmission and reception unit (1010) and the information generated through the control unit (1020). The storage unit (1030) may be defined as 'memory'. The storage unit (1030) can store programs and data required for the operation of the base station. Additionally, the storage unit (1030) can store control information or data included in signals obtained from the base station. The storage unit (1030) may be composed of a storage medium or a combination of storage media such as ROM, RAM, hard disk, CD-ROM, and DVD. Additionally, the storage unit (1030) may not exist separately but may be configured to be included in the control unit (1020).

[0071] FIG. 11 is a drawing illustrating the structure of a terminal according to one embodiment of the present disclosure.

[0072] Referring to FIG. 11, the terminal may include a transceiver (1110), a control unit (1120), and a storage unit (1130). In the present disclosure, the control unit may be defined as a circuit or an application-specific integrated circuit or at least one processor. Depending on the communication method of the terminal described above, the transceiver (1110), the control unit (1120), and the storage unit (1130) of the terminal may operate. However, the components of the terminal are not limited to the examples described above. For example, the terminal may include more components or fewer components than the components described above. In addition, the transceiver (1110), the control unit (1120), and the storage unit (1130) may be implemented in the form of a single chip.

[0073] The transceiver (1110) can transmit and receive signals with other network entities. The transceiver (1110) can, for example, receive system information from a base station and receive synchronization signals or reference signals. The transceiver (1110) is a collective term for the receiving unit and the transmitting unit of a terminal, and can transmit and receive signals with a network entity, a base station, or another terminal. The signals transmitted and received with the network entity, the base station, or another terminal may include control information and data. To this end, the transceiver (1110) may be composed of an RF transmitter that up-converts and amplifies the frequency of a transmitted signal, and an RF receiver that low-noise amplifies a received signal and down-converts the frequency. However, this is merely one embodiment of the transceiver (1110), and the components of the transceiver (1110) are not limited to an RF transmitter and an RF receiver. Additionally, the transmitting and receiving unit (1110) can receive a signal through a wireless channel and output it to the control unit (1120), and transmit the signal output from the control unit (1120) through the wireless channel.

[0074] The control unit (1120) can control the overall operation of the terminal according to the embodiment proposed in the present disclosure. For example, the control unit (1120) can control the signal flow between each block to perform operations according to the flowchart described above. The control unit (1120) can receive control signals and data signals through the transceiver (1110) and process the received control signals and data signals. In addition, the control unit (1120) can transmit the processed control signals and data signals through the transceiver (1110). In addition, the control unit (1120) can receive DCI composed of two layers and control the components of the terminal to receive multiple PDSCHs simultaneously. The control unit (1120) may be one or multiple and may be composed of one or multiple processors. The control unit (1120) can perform the operation of controlling the components of the terminal by executing a program stored in the storage unit (1130).

[0075] The storage unit (1130) can store at least one of the information transmitted and received through the transmission and reception unit (1110) and the information generated through the control unit (1120). The storage unit (1130) may be defined as 'memory'. The storage unit (1130) can store programs and data necessary for the operation of the terminal. Additionally, the storage unit (1130) can store control information or data included in signals obtained from the terminal. The storage unit (1130) may be composed of a storage medium such as ROM, RAM, hard disk, CD-ROM, and DVD, or a combination of storage media. Additionally, the storage unit (1130) may not exist separately but may be configured to be included in the control unit (1120).

[0076] FIG. 12 is a drawing illustrating an MBS split bearer and path switching according to one embodiment of the present disclosure.

[0077] In MBS, since multiple terminals receive data, transmission to a single specific terminal cannot be guaranteed. If the provided MBS service involves data requiring high reliability, it is difficult to satisfy these requirements using broadcast or multicast transmission methods. For this reason, although the data is intended for MBS services, some packets need to be transmitted via unicast. To this end, an MBS Radio Bearer (MRB) may be defined that combines PTM and PTP transmission methods, rather than using a specific PTM or PTP method. Since this MBS Radio Bearer handles the same MBS service, there is only one SDAP (Service Data Adaptation Protocol) or PDCP (Packet Data Convergence Protocol) layer connecting to the upper layer, while there are two or more RLC devices for the RLC (Radio Link Control) layer. This allows some RLCs to be used in the PTM mode (RLC-PTM, PTM RLC) and others in the PTP mode (RLC-PTP, PTP RLC). Each RLC device can correspond to a logical channel, and PTM RLC can be transmitted to a radio resource allocated to G-RNTI, and PTP RLC can be transmitted to a radio resource allocated to C-RNTI. A radio bearer having both PTP RLC and PTM RLC in a single radio bearer can be called an MBS split radio bearer.

[0078] The embodiment of FIG. 12 illustrates an operation method for determining whether data for an MBS service will be transmitted via PTM or PTP depending on the selection of the base station. The base station can decide whether to transmit using PTM RLC or PTP RLC by considering various factors such as the location of the terminal, signal strength, and the number of terminals receiving the MBS service. If the base station transmits data using PTM RLC, it can activate PTM RLC and deactivate PTP RLC. (1210) At this time, the terminal can receive data using the activated PTM RLC. Conversely, if the base station transmits data using PTP RLC, it can activate PTP RLC and deactivate PTM RLC. (1220) At this time, the terminal can receive data using the activated PTP RLC. PTM RLC uses unidirectional RLC UM (Unacknowledged Mode), and PTP RLC can use unidirectional or bidirectional RLC UM or RLC AM (Acknowledged Mode).

[0079] The base station may instruct the terminal whether to activate and use PTM RLC or PTP RLC. The terminal may then receive data using the RLC that the base station instructed to activate. In another embodiment, the terminal may detect data received from the base station and determine the activated RLC device itself. Detailed operations regarding whether to activate and use PTM RLC or PTP RLC are described later in FIGS. 12 and FIGS. 13. Based on this method, the base station and the terminal may perform an operation to switch the activated RLC. (1230) After the operation to switch the activated RLC, the terminal may transmit a PDCP Status Report message to inform the base station of information regarding the packets successfully received by the terminal and enable the base station to perform retransmission.

[0080] FIG. 13 is a diagram illustrating an MBS split bearer and a path switching process according to one embodiment of the present disclosure.

[0081] A base station (1310) can provide MBS services to multiple terminals via an MBS wireless bearer. At this time, the base station can perform data transmission by selecting either PTM RLC or PTP RLC for each terminal (1320). To do this, the base station can transmit a message (or may be referred to as a route switching instruction message, a route change instruction message, etc.) to the terminal instructing it to transmit data via either the PTM RLC or PTP RLC path. (1330) The terminal can receive this route switching instruction message and, based on this information, activate and apply an RLC device (path of data) used for data transmission. In the embodiment of FIG. 13, it is assumed that the terminal receives data via the first path (PTM or PTP), but after receiving the route switching instruction message (1330), receives data via the second path (the instructed PTM or PTP).

[0082] A route switching instruction message may be indicated by DCI (Downlink Control Information), etc., transmitted via MAC CE (Medium Access Control - Control Element) or PDCCH (Physical Downlink Control Channel). The information included therein may indicate which MBS radio bearer the route switching is for and which RLC device the changed route is for. As an identifier for the RLC device, at least one of whether it is PTM RLC or PTP RLC and a logical channel ID may be used. In another embodiment, the route switching instruction message may be indicated by a PDCP Control PDU (Protocol Data Unit), and the PDCP Control PDU may signify a route switching for the MBS radio bearer to which it is transmitted. The information included therein may indicate which RLC device the switched route is for. As an identifier for the RLC device, at least one of whether it is PTM RLC or PTP RLC and a logical channel ID may be used.

[0083] FIG. 14 is a diagram illustrating an MBS split bearer and a path switching process according to one embodiment of the present disclosure.

[0084] In the embodiment of FIG. 14, it is assumed that the terminal monitors both the PTM RLC and PTP RLC configured in the MBS wireless bearer, but activates only one RLC. To this end, a method is shown in which the activated RLC device (activated data path) is switched and applied when the reception of a packet is detected in the PTP RLC device or the PTM RLC device. In the embodiment of FIG. 14, it is assumed that the base station (1410) is transmitting data to the terminal (1420) using PTM RLC. (1430, 1440, 1450) At this time, the terminal's activated path in the MBS wireless bearer becomes PTM RLC. Subsequently, when data to PTP RLC is detected (1460), the terminal switches the RLC device activated to PTP RLC. Subsequently, data transmission continues via PTP RLC (1470), and when data arrives again via PTM RLC (1480), the RLC device activated to PTM RLC is switched and applied. Afterwards, when additional data arrives at the PTM RLC, the data reception can continue with the activated PTM RLC device (1490).

[0085] In one embodiment, the RLC device may be initialized when it is deactivated or newly activated. That is, the operation of initializing the state variables of the RLC and emptying the receive RLC buffer may be performed. In another embodiment, the re-establishment operation of the RLC device may be performed. In addition, the activated path information may be known to the upper layer PDCP device.

[0086] FIG. 15 is a diagram illustrating the first packet reception operation after path switching of an MBS split bearer according to one embodiment of the present disclosure.

[0087] After the terminal is instructed to switch paths from the PTM RLC or PTM RLC of the MBS split bearer to another RLC by the method of FIG. 13 or FIG. 14 or by any other method, the terminal can receive the first packet after switching to the PTM RLC or PTP RLC (in the case of initial setup, after the RLC device is set up). (1510) In order for the terminal to receive data from the MBS wireless bearer including this first received packet, it can perform a re-establishment of the corresponding RLC device. (1520) The re-establishment operation of the RLC device may include initializing the state variables of the RLC and emptying the receiving RLC buffer.

[0088] FIG. 16 is a diagram illustrating the first packet reception operation after path switching of an MBS split bearer according to one embodiment of the present disclosure.

[0089] After the terminal is instructed to switch paths from the PTM RLC or PTM RLC of the MBS split bearer to another RLC using the method of FIG. 13 or FIG. 14 or other methods, the terminal can receive the first packet after switching to the PTM RLC or PTP RLC (in the case of initial setup, after the RLC device is set). (1610) In order for the terminal to receive data from the MBS wireless bearer including this first received packet, it can perform the operation of initializing the state variables of the corresponding RLC device and emptying the receiving RLC buffer. The terminal can check whether this switched RLC device (in the case of initial setup, after the RLC device is set) is an RLC UM device or an RLC AM device. (1620) If it is an RLC UM device, the terminal can set RX_Next_Reassembly and RX_Next_Highest among the state variables of the RLC of the corresponding RLC device to the SN value of the packet having the first received SN. (1630) Otherwise, if it is an RLC AM device, the terminal can set RX_Next and RX_Next_Highest among the RLC state variables of the corresponding RLC device to the SN value of the packet that has the first received SN. (1640) Subsequent operations may follow the previously defined RLC reception operations.

[0090] FIG. 17 is a diagram illustrating the first packet reception operation after path switching of an MBS split bearer according to one embodiment of the present disclosure.

[0091] After the terminal is instructed to switch the path from the PTM RLC or PTM RLC of the MBS split bearer to another RLC by the method of FIG. 13 or FIG. 14 or by any other method, the terminal can receive the first packet after switching to the PTM RLC or PTP RLC (in the case of initial setup, after the RLC device is set). (1710) In order for the terminal to receive data from the MBS wireless bearer including this first received packet, the terminal can perform the operation of initializing the state variables of the corresponding RLC device and emptying the receiving RLC buffer. The terminal can check whether this switched RLC device (in the case of initial setup, after the RLC device is set) is an RLC UM device or an RLC AM device. (1720) If it is an RLC UM device, the terminal can set RX_Next_Reassembly and RX_Next_Highest among the state variables of the RLC of the corresponding RLC device to the SN value of the packet that has SI=01 and has the first received SN. (1730) The SI (Segment Info) field is a field that indicates the segmentation type of the packet. The first bit of the SI field indicates whether the front part of the received SDU has been segmented, and has a value of 1 if it has been segmented. The second bit of the SI field indicates whether the back part of the received SDU has been segmented, and has a value of 1 if it has been segmented. If the value of the SI field is 01, it indicates that it is the first segment of the RLC SDU (Service Data Unit), and receiving such a first segmented packet may mean that there is a high probability of receiving the entire packet. In step 1720, if it is an RLC AM device, the terminal can set RX_Next and RX_Next_Highest among the RLC state variables of the corresponding RLC device to the SN value of the packet that has SI=00 or 01 and has the first received SN.(1740) If the value of the SI field is 00, it indicates that it is an undivided, complete RLC SDU. Subsequent operations may follow the existing defined RLC receiving operations.

[0092] FIG. 18 is a diagram illustrating the path switching operation of an MBS split bearer according to one embodiment of the present disclosure.

[0093] When a terminal is instructed to switch paths from the PTM RLC of an MBS split bearer to another RLC, or from the PTM RLC to another RLC, by the method of FIG. 13 or FIG. 14 or by any other method (1810), there may be data available to be received from the existing RLC bearer through HARQ (Hybrid Automatic Repeat reQuest) retransmission, etc. To complete the reception of this remaining data and to complete the switch to the instructed RLC, the switching of the RLC path may be delayed for a predetermined time (1820). The length of the delay time may be set by an RRC reset message transmitted from the base station. Furthermore, by not performing additional path switching during this predetermined time, unnecessary path switching caused by retransmission packets can be prevented. In the embodiment of FIG. 18, it is shown that the PTM RLC is activated and used, and then a path switch to the PTP RLC is instructed, but it is applicable in the opposite case. After a predetermined delay time, the path can be switched to the PTP RLC to activate and use the PTP RLC. And it demonstrates a method that does not switch to PTM RLC even if data is received in PTM RLC during this delay time, but switches to PTP RLC after the delay time.

[0094] FIG. 19 is a diagram illustrating the operation of an MBS wireless bearer during handover according to one embodiment of the present disclosure.

[0095] When a terminal receives MBS service from a serving base station (1910) and moves to the area of ​​a target base station (1920), the terminal can perform a handover procedure to the target base station to receive data from the target base station. However, since each base station operates independently, the same packet (PDCP PDU or PDCP SDU unit) may not have the same PDCP SN (Sequence Number). In the embodiment of FIG. 19, packets assigned sequence numbers 0, 1, 2, 3, and 4, respectively, may be assigned sequence numbers 7, 8, 9, 10, and 11 at the target base station and used. In this case, the terminal may need to modify the sequence number it was using during the handover. In the embodiment of FIG. 19, the serving base station and the target base station have a sequence number difference of 7 for the PDCP packets of a specific MBS wireless bearer. Therefore, during handover, the RRC reset message transmitted by the serving base station indicates that there is a difference of 7 in the PDCP sequence number of the target base station, and using this value, the terminal can change the PDCP sequence number after handover so that it can continue to use the MBS radio bearer for the same service at the target base station. The terminal can perform PDCP reception operations by correcting the difference in the PDCP state variables by the same amount as the difference in the PDCP sequence number. If a PDCP status report message is transmitted to the target base station after handover, the COUNT value used in the PDCP status report message may be a COUNT value derived by converting it into the sequence number used by the target base station.

[0096] FIG. 20 is a drawing illustrating a bearer type conversion including an MBS split bearer according to one embodiment of the present disclosure.

[0097] In MBS, since multiple terminals receive data, transmission to a single specific terminal cannot be guaranteed. If the provided MBS service involves data requiring high reliability, it is difficult to satisfy these requirements using broadcast or multicast transmission methods. For this reason, although the data is intended for MBS services, some packets may need to be transmitted via unicast. To this end, an MBS Radio Bearer (MRB) may be defined that combines PTM and PTP transmission methods rather than using a specific PTM or PTP method. Since this MBS Radio Bearer handles the same MBS service, there is only one SDAP (Service Data Adaptation Protocol) or PDCP (Packet Data Convergence Protocol) layer connecting to the upper layer, while there are two or more RLC (Radio Link Control) devices for the RLC layer. This allows some RLCs to be used in the PTM mode (RLC-PTM, PTM RLC) and others in the PTP mode (RLC-PTP, PTP RLC). Each RLC device can correspond to a logical channel, and PTM RLC can be transmitted to radio resources allocated to G-RNTI, while PTP RLC can be transmitted to radio resources allocated to C-RNTI. A radio bearer that possesses both PTP RLC and PTM RLC in a single radio bearer can be referred to as an MBS split radio bearer. (2010) In such an MBS split radio bearer, the base station can arbitrarily decide which RLC device to use to transmit data without separate instructions. Furthermore, the base station can switch the path for transmitting data. The terminal can receive packets in order without duplication by using reordering and duplicate detection techniques in the PDCP device.In the MBS split wireless bearer shown in step 2010, it is assumed that the terminal always receives data from PTM RLC and PTP RLC.

[0098] However, an MBS radio bearer does not necessarily need to have PTP RLC. That is, if the multicast or broadcast method transmitted by the base station via PTM RLC is sufficient, there is no need to have a separate PTP RLC. A radio bearer having a single PTM RLC can be called a PTM MBS radio bearer (PTM MRB). (2020) Additionally, there may exist radio bearers that have only PTP RLC and whose resources are allocated via C-RNTI without PTM RLC. Since this radio bearer has the same structure as an existing DRB (Data Radio Bearer), it can be referred to as a DRB; however, for a radio bearer through which MBS data is transmitted, it can also be called a PTP MBS radio bearer (PTP MRB). (2030) Bearer format conversion operations can be performed between these MBS split radio bearers, PTM MBS radio bearers, and PTP MBS radio bearers.

[0099] When changing the bearer format, if the PDCP sequence number is maintained as is or if the difference in the status number is corrected as shown in FIG. 19, the terminal may request retransmission by transmitting a PDCP status report message to the base station. To this end, when setting up the MBS wireless bearer (MBS split wireless bearer, PTM MBS wireless bearer, PTP MBS wireless bearer), the terminal may be separately notified of whether to maintain the PDCP sequence number (or, in some embodiments, whether to perform re-establishment of the MBS wireless bearer). In other embodiments, the base station may notify the terminal of the difference in the PDCP sequence number (or COUNT) when setting up the MBS wireless bearer. The PDCP status report message may be transmitted only when the PTP RLC is RLC AM and may not be transmitted when it is RLC UM. In some embodiments, when changing the bearer format, the PDCP status report message may be transmitted to the base station if at least one of the operations of releasing the pre-configured RLC device, resetting the MAC, or re-establishing the pre-configured RLC device is involved.

[0100] Meanwhile, the embodiments disclosed in this specification and drawings are merely specific examples provided to facilitate the explanation of the technical content of this disclosure and to aid in understanding this disclosure, and are not intended to limit the scope of this disclosure. That is, it is obvious to those skilled in the art that other variations based on the technical concept of this disclosure are possible. Furthermore, each of the above embodiments may be combined and operated as needed. For example, parts of one embodiment of this disclosure and another embodiment may be combined to operate a base station and a terminal. Additionally, the embodiments of this disclosure are applicable to other communication systems, and other variations based on the technical concept of the embodiments may also be possible.

Claims

Claim 1 A method for a terminal to perform a multicast and broadcast service (MBS) in a wireless communication system, comprising the steps of: receiving configuration information related to a first MRB (MBS radio bearer) from a base station; wherein the first MRB includes a first RLC (radio link control) entity for point-to-point (PTP) transmission and a second RLC entity for point-to-multipoint (PTM) transmission; and, if the first RLC entity for PTP transmission of the first MRB is an acknowledged mode (AM) RLC entity, transmitting a packet data convergence protocol (PDCP) status report to the base station. Claim 2 A method according to claim 1, further comprising the step of receiving configuration information related to at least one of a second MRB or a third MRB from the base station, wherein the second MRB includes the first RLC entity for the PTP transmission and the third MRB includes the second RLC entity for the PTM transmission. Claim 3 A method according to paragraph 2, further comprising the step of performing a change of the MRB type among the first MRB, the second MRB, and the third MRB. Claim 4 A method for a base station to perform a multicast and broadcast service (MBS) in a wireless communication system, comprising the steps of: transmitting configuration information related to a first MRB (MBS radio bearer) to a terminal; wherein the first MRB includes a first RLC (radio link control) entity for point-to-point (PTP) transmission and a second RLC entity for point-to-multipoint (PTM) transmission; and, if the first RLC entity for PTP transmission of the first MRB is an acknowledged mode (AM) RLC entity, receiving a packet data convergence protocol (PDCP) status report from the terminal. Claim 5 A method according to claim 4, further comprising the step of transmitting configuration information related to at least one of a second MRB or a third MRB to the terminal, wherein the second MRB includes the first RLC entity for the PTP transmission and the third MRB includes the second RLC entity for the PTM transmission. Claim 6 delete Claim 7 A terminal performing a multicast and broadcast service (MBS) in a wireless communication system, wherein the terminal comprises: a transceiver; and at least one processor connected to the transceiver, wherein the at least one processor receives configuration information related to a first MRB (MBS radio bearer) from a base station, and the first MRB comprises a first RLC (radio link control) entity for point-to-point (PTP) transmission and a second RLC entity for point-to-multipoint (PTM) transmission; and wherein, if the first RLC entity for PTP transmission of the first MRB is an acknowledged mode (AM) RLC entity, the terminal is configured to transmit a packet data convergence protocol (PDCP) status report to the base station. Claim 8 A terminal according to claim 7, wherein the at least one processor is configured to receive configuration information related to at least one of a second MRB or a third MRB from the base station, wherein the second MRB includes the first RLC entity for the PTP transmission and the third MRB includes the second RLC entity for the PTM transmission. Claim 9 In claim 8, the terminal, wherein the at least one processor is configured to perform a change of MRB type among the first MRB, the second MRB, and the third MRB. Claim 10 A base station performing a multicast and broadcast service (MBS) in a wireless communication system, wherein the base station comprises: a transceiver; and at least one processor connected to the transceiver, wherein the at least one processor transmits configuration information related to a first MRB (MBS radio bearer) to a terminal, and the first MRB comprises a first RLC (radio link control) entity for point-to-point (PTP) transmission and a second RLC entity for point-to-multipoint (PTM) transmission; and, when the first RLC entity for PTP transmission of the first MRB is an acknowledged mode (AM) RLC entity, the base station receives a packet data convergence protocol (PDCP) status report from the terminal. Claim 11 A base station according to claim 10, wherein the at least one processor is configured to transmit configuration information related to at least one of a second MRB or a third MRB to a terminal, wherein the second MRB includes the first RLC entity for the PTP transmission and the third MRB includes the second RLC entity for the PTM transmission. Claim 12 delete

Images