CN116982398A

CN116982398A - MBS data control method and device

Info

Publication number: CN116982398A
Application number: CN202280021153.7A
Authority: CN
Inventors: 洪成杓
Original assignee: KT Corp
Current assignee: KT Corp
Priority date: 2021-03-16
Filing date: 2022-03-16
Publication date: 2023-10-31

Abstract

The present disclosure relates to a technology for a terminal to process multicast/broadcast service (MBS) data in an NR-based mobile communication network. In one aspect, the present embodiment may provide a method and apparatus by which a terminal receives MBS data, the method comprising the steps of: receiving an RRC message from a base station; configuring a data inactivity timer on the basis of the RRC message; and starting or restarting the data inactivity timer when the MAC entity receives an MBS service channel (MTCH) MAC SDU of the MBS.

Description

MBS data control method and device

Technical Field

The present disclosure relates to a method and apparatus for a terminal to process multicast/broadcast service (MBS) data in an NR based mobile communication network.

Background

In a broadcast communication service, the same service along with the same specific content data may be provided to all terminals within one geographical area (such as a broadcast coverage area) at the same time. All terminals within the broadcast coverage range are likely to receive broadcast communication services. The broadcast communication service may be delivered to the terminal through a broadcast session. During the broadcast session, the terminal may receive MBS data while in RRC idle, RRC inactive and RRC connected states.

In a multicast communication service, the same service along with the same specific content data may be provided to a specified group of terminals at the same time. Multicast communication services may be delivered to terminals through multicast sessions. During the multicast session, the terminal may receive MBS data in an RRC connected state.

Therefore, a multicast/broadcast service requires a technique of efficiently utilizing network resources while transmitting data to a plurality of terminals. In particular, there is a need for a technique for efficiently utilizing network resources by activating/deactivating multicast sessions. However, no specific procedures or techniques are proposed.

Disclosure of Invention

Technical problem

The present disclosure provides a method and apparatus for a terminal to efficiently process MBS data.

Technical proposal

In one aspect, a method for receiving multicast/broadcast service (MBS) data by a terminal may be provided. The method may include receiving an RRC message from a base station, configuring a data inactivity timer based on the RRC message, and starting or restarting the data inactivity timer if a MAC entity receives an MBS Traffic Channel (MTCH) MAC SDU of the MBS.

In another aspect, a method for controlling multicast/broadcast service (MBS) data by a base station may be provided. The method may include receiving at least one of MBS session status information, a message for activating an MBS session and a message for deactivating the MBS session from a core network entity, and controlling a radio resource configuration associated with the MBS session based on at least one of the MBS session status information, the message for activating the MBS session and the message for deactivating the MBS session.

In yet another aspect, a terminal for receiving multicast/broadcast service (MBS) data may be provided. The terminal may include: a receiver configured to receive an RRC message from a base station; and a controller configured to set a data inactivity timer based on the RRC message, and to start or restart the data inactivity timer in case that the MAC entity receives an MBS service channel (MTCH) MAC SDU of the MBS.

In yet another aspect, a base station for controlling multicast/broadcast service (MBS) data may be provided. The base station may include: a receiver configured to receive at least one of MBS session status information, a message for activating an MBS session and a message for deactivating an MBS session from a core network entity; and a controller configured to control a radio resource configuration associated with the MBS session based on at least one of the MBS session status information, the message for activating the MBS session, and the message for deactivating the MBS session.

Advantageous effects

According to the embodiment of the disclosure, the terminal can effectively process MBS data.

Drawings

Fig. 1 is a view schematically showing an NR wireless communication system;

fig. 2 is a view for explaining a frame structure in an NR system;

Fig. 3 is a view for explaining a resource grid supported by a radio access technology;

fig. 4 is a view for explaining a bandwidth part supported by a radio access technology;

fig. 5 is a view showing an example of a synchronization signal block in a radio access technology;

fig. 6 is a view for explaining a random access procedure in a radio access technology;

fig. 7 is a view for explaining CORESET;

fig. 8 is a flowchart for describing the operation of a terminal according to an embodiment;

fig. 9 is a flowchart for describing an operation of a base station according to an embodiment;

fig. 10 is a view showing an example of a layer 2 structure for receiving MBS data according to an embodiment;

fig. 11 is a block diagram illustrating a terminal according to an embodiment; and

fig. 12 is a block diagram illustrating a base station according to an embodiment.

Detailed Description

Hereinafter, some embodiments of the present disclosure will be described in detail with reference to the accompanying illustrative drawings. In the drawings, like reference numerals are used to refer to like elements throughout the drawings even though they are shown in different drawings. Furthermore, in the following description of the present disclosure, a detailed description of configurations and known functions incorporated herein will be omitted when it may make the subject matter of the present disclosure rather unclear. When the expressions "comprising," "having," "including," and the like are used as referred to herein, any other component may be added unless the expression "only" is used. When an element is referred to in the singular, the plural is contemplated unless limitation to the singular is explicitly stated.

Further, when describing the components of the present disclosure, terms such as first, second, A, B, (a), (b), and the like may be used herein. Each of these terms is not intended to limit the nature, order, or sequence of corresponding components, but is merely intended to distinguish the corresponding components from one or more other components.

In describing the positional relationship between the components, if two or more components are described as being "connected", "combined", or "coupled" to each other, it should be understood that two or more components may be directly "connected", "combined", or "coupled" to each other, and two or more components may be "connected", "combined", or "coupled" to each other with another component "interposed" therebetween. In this case, another component may be included in at least one of two or more components that are "connected", "combined", or "coupled" with each other.

In describing a series of operation methods or manufacturing methods, for example, the expressions of "after … …", "after … …", "next", "before … …", and the like may also include a case where the operations or processes are discontinuously performed, unless "immediate" or "direct" is used in the expressions.

The numerical values of the components referred to herein or the information (e.g., levels, etc.) corresponding thereto may be construed as including ranges of error caused by various factors (e.g., process factors, internal or external influences, noise, etc.), even if no explicit description thereof is provided.

The wireless communication system in this specification refers to a system that provides various communication services such as a voice service and a data service using radio resources. The wireless communication system may include user equipment (terminals), base stations, core networks, and the like.

The embodiments disclosed below may be applied to wireless communication systems using various radio access technologies. For example, embodiments may be applied to various radio access technologies such as Code Division Multiple Access (CDMA), frequency Division Multiple Access (FDMA), time Division Multiple Access (TDMA), orthogonal Frequency Division Multiple Access (OFDMA), single carrier frequency division multiple access (SC-FDMA), non-orthogonal multiple access (NOMA), and so forth. In addition, radio access technologies may refer to generation communication technologies and specific access technologies established by various communication organizations (such as 3GPP, 3GPP2, wiFi, bluetooth, IEEE, ITU, etc.). For example, CDMA may be implemented as a wireless technology such as Universal Terrestrial Radio Access (UTRA) or CDMA 2000. TDMA may be implemented as a wireless technology such as global system for mobile communications (GSM)/General Packet Radio Service (GPRS)/enhanced data rates for GSM evolution (EDGE). OFDMA may be implemented as a wireless technology such as IEEE (institute of electrical and electronics engineers) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802-20, evolved UTRA (E-UTRA), and so forth. IEEE 802.16m is an evolution of IEEE 802.16e, IEEE 802.16m providing backward compatibility with IEEE 802.16 e-based systems. UTRA is part of Universal Mobile Telecommunications System (UMTS). 3GPP (third Generation partnership project) LTE (Long term evolution) is a part of E-UMTS (evolved UMTS) that uses evolved UMTS terrestrial radio Access (E-UTRA), which employs OFDMA in the downlink and SC-FDMA in the uplink. As described above, the embodiments can be applied to radio access technologies that have been initiated or commercialized, and can be applied to radio access technologies that are being developed or are to be developed in the future.

A terminal used in the specification must be interpreted in a broad sense, which means a device including a wireless communication module that communicates with a base station in a wireless communication system. For example, the terminals include User Equipment (UE) in WCDMA, LTE, NR, HSPA, IMT-2020 (5G or new radio) or the like, mobile stations in GSM, user Terminals (UTs), subscriber Stations (SS), wireless devices, and the like. In addition, the terminal may be a portable user device such as a smart phone, or may be a vehicle, a device including a wireless communication module in the vehicle, a device in a V2X communication system according to the type of use thereof, or the like. In the case of a Machine Type Communication (MTC) system, a terminal may refer to an MTC terminal, an M2M terminal, or a URLLC terminal, which employs a communication module capable of performing machine type communication.

A base station or cell in this specification refers to an endpoint that communicates with terminals over a network and encompasses various coverage areas, such as Node-bs (Node-bs), evolved Node-bs (enbs), g-Node-bs (gNode-bs), low Power Nodes (LPNs), sectors, sites, various types of antennas, base Transceiver Systems (BTSs), access points, points (e.g., transmission points, reception points, or transmission/reception points), relay nodes, megacells, macrocells, microcells, picocells, femtocells, remote Radio Heads (RRHs), radio Units (RUs), small cells, and the like. In addition, a cell may be used as a meaning including a bandwidth part (BWP) in a frequency domain. For example, the serving cell may refer to an active BWP of the terminal.

The various cells listed above are provided with a base station controlling one or more cells and the base station may be interpreted as two meanings. The base station may be 1) a device for providing megacells, macro cells, micro cells, pico cells, femto cells, or small cells associated with a wireless area, or the base station may be 2) the wireless area itself. In the above description 1), the base station may be a device controlled by the same entity and providing a predetermined wireless area, or all devices that interact and cooperatively configure the wireless area with each other. For example, the base station may be a point, a transmission/reception point, a transmission point, a reception point, or the like according to a configuration method of the wireless area. In the above description 2), the base station may be a wireless area in which a user equipment (terminal) may be caused to transmit and receive data to and from other terminals or neighboring base stations.

In this specification, a cell may refer to a coverage of a signal transmitted from a transmission/reception point, a component carrier having a coverage of a signal transmitted from a transmission/reception point (or a transmission point), or a transmission/reception point itself.

The Uplink (UL) refers to a scheme of transmitting data from a terminal to a base station, and the Downlink (DL) refers to a scheme of transmitting data from a base station to a terminal. The downlink may mean a communication or a communication path from a plurality of transmission/reception points to a terminal, and the uplink may mean a communication or a communication path from a terminal to a plurality of transmission/reception points. In the downlink, a transmitter may be part of a plurality of transmission/reception points and a receiver may be part of a terminal. In addition, in the uplink, the transmitter may be part of a terminal and the receiver may be part of a plurality of transmission/reception points.

Uplink and downlink transmit and receive control information through control channels such as a Physical Downlink Control Channel (PDCCH) and a Physical Uplink Control Channel (PUCCH). Uplink and downlink transmit and receive data through data channels such as a Physical Downlink Shared Channel (PDSCH) and a Physical Uplink Shared Channel (PUSCH). Hereinafter, transmitting and receiving signals through a channel such as PUCCH, PUSCH, PDCCH, PDSCH may be denoted as "transmitting and receiving PUCCH, PUSCH, PDCCH, PDSCH", etc.

For clarity, the following description will focus on a 3GPP LTE/LTE-A/NR (New radio) communication system, but technical features of the present disclosure are not limited to the corresponding communication system.

After researching 4G (4 th generation) communication technology, 3GPP has been developing 5G (5 th generation) communication technology to meet the requirements of the next generation radio access technology of ITU-R. In particular, by improving the LTE-advanced technology, 3GPP is developing LTE-a pro as a 5G communication technology so as to meet the requirements of ITU-R and a new NR communication technology completely different from the 4G communication technology. LTE-Apro and NR refer to both 5G communication technologies. Hereinafter, unless a specific communication technology is specified, a 5G communication technology will be described based on NR.

Various operation scenarios have been defined in NR in view of satellites, automobiles, new vertical industries (vertical), etc. in a typical 4G LTE scenario, to support an enhanced mobile broadband (eMBB) scenario in terms of services, a large machine type communication (mctc) scenario in which terminals are distributed over a wide area with a high terminal density, thus requiring low data rates and asynchronous connections, and an ultra-reliability and low latency (URLLC) scenario requiring high responsiveness and reliability and supporting high-speed mobility.

To meet this scenario, NR discloses a wireless communication system employing a new waveform and frame structure technique, a low latency technique, an ultra high band (mmWave) support technique, and a forward compatibility providing technique. In particular, NR systems have various technical variations in terms of flexibility in order to provide forward compatibility. The main technical features of NR will be described below with reference to the drawings.

< overview of NR System >

Fig. 1 is a view schematically showing an NR system.

Referring to fig. 1, the nr system is divided into a 5G core network (5 GC) and NG-RAN part. The NG-RAN includes a ngnb and a NG-eNB that provide user plane (SDAP/PDCP/RLC/MAC/PHY) and User Equipment (UE) control plane (RRC) protocol ends. The gNB or gNB and the ng-eNB are connected to each other via an Xn interface. The gNB and NG-eNB are connected to the 5GC via NG interfaces, respectively. The 5GC may be configured to include an access and mobility management function (AMF) for managing a control plane, such as a terminal connection and mobility control function, and a User Plane Function (UPF) for controlling user data. NR supports a frequency band below 6GHz (frequency range 1: FR 1) and a frequency band equal to or greater than 6GHz (frequency range 2: FR 2).

gNB denotes a base station providing NR user plane and control plane protocol ends to a terminal, and ng-eNB denotes a base station providing E-UTRA user plane and control plane protocol ends to a terminal. The base station described in this specification should be understood to include gNB and ng-eNB. However, base stations may also be used to refer to gNB or ng-eNB that are separate from each other, as desired.

< NR waveform, parameter set, and frame Structure >

NR uses a CP-OFDM waveform that uses a Cyclic Prefix (CP) for downlink transmission and CP-OFDM or DFT-s-OFDM for uplink transmission. OFDM technology is easily combined with multiple-input multiple-output (MIMO) schemes and allows the use of low complexity receivers at high frequency efficiency.

Since the above three scenarios have mutually different requirements for data rate, delay (delay) rate, coverage, etc. in NR, it is necessary to efficiently satisfy the requirements of each scenario by the frequency bands constituting the NR system. For this reason, a technique for efficiently multiplexing radio resources based on a plurality of different parameter sets has been proposed.

Specifically, the NR transmission parameter set is determined based on the subcarrier spacing and the Cyclic Prefix (CP), and as shown in table 1 below, "μ" is used as an index value of 2, thereby exponentially varying on the basis of 15kHz

TABLE 1

μ	Subcarrier spacing	Cyclic prefix	Supporting data	Supporting synchronization
					0	15	Normal state	Is that	Is that
1	30	Normal state	Is that	Is that
					2	60	Normal, extended	Is that	Whether or not
3	120	Normal state	Is that	Is that
					4	240	Normal state	Whether or not	Is that

As shown in table 1 above, NR may have five types of parameter sets according to subcarrier spacing. This is different from LTE, which is one of 4G communication technologies, in which the subcarrier spacing is fixed to 15kHz. Specifically, in NR, the subcarrier spacing for data transmission is 15, 30, 60, or 120kHz, and the subcarrier spacing for synchronization signal transmission is 15, 30, 120, or 240kHz. In addition, the extended CP is applied only to a subcarrier spacing of 60 kHz. Frames comprising 10 subframes (each subframe having the same length of 1 ms) and having a length of 10ms are defined in a frame structure in NR. A frame may be divided into 5ms half frames, and each half frame includes 5 subframes. In case that the subcarrier spacing is 15kHz, one subframe includes one slot, and each slot includes 14 OFDM symbols. Fig. 2 is a view for explaining a frame structure in the NR system.

Referring to fig. 2, in the case of a typical CP, a slot fixedly includes 14 OFDM symbols. However, the length of the slots in the time domain may vary according to the subcarrier spacing. For example, in the case where the parameter set has a subcarrier spacing of 15kHz, the slot is configured to have a length of 1ms that is the same as the length of the subframe. On the other hand, in case that the parameter set has a subcarrier spacing of 30kHz, a slot includes 14 OFDM symbols, but one subframe may include two slots each having a length of 0.5 ms. That is, subframes and frames may be defined using a fixed time length, and a slot may be defined as the number of symbols such that the time length of the slot varies according to the subcarrier spacing.

NR defines the basic unit of scheduling as a slot and also introduces micro-slots (or sub-slots or non-slot based scheduling) to reduce the transmission delay of the radio segment. If a wide subcarrier spacing is used, the length of one slot is shortened inversely proportional thereto, thereby reducing transmission delay in a radio section. The minislots (or subslots) are intended to efficiently support the URLLC scenario, and the minislots may be scheduled in 2, 4, or 7 symbol units.

In addition, unlike LTE, NR defines uplink and downlink resource allocation as symbol level in one slot. In order to reduce the HARQ delay, a slot structure capable of directly transmitting HARQ ACK/NACK in a transmission slot has been defined. This slot structure is referred to as a "self-contained structure," which will be described.

NR is designed to support a total of 256 slot formats and its 62 slot formats are used in 3GPP Rel-15. In addition, NR supports a common frame structure constituting an FDD or TDD frame through a combination of various slots. For example, NR supports i) a slot structure in which all symbols of a slot are configured for downlink, ii) a slot structure in which all symbols are configured for uplink, and iii) a slot structure in which downlink symbols and uplink symbols are mixed. Further, NR supports data transmission scheduled to be distributed to one or more slots. Thus, the base station may inform the terminal of whether a slot is a downlink slot, an uplink slot, or a flexible slot using a Slot Format Indicator (SFI). The base station may inform the slot format by using the SFI to indicate an index of a table configured through UE-specific RRC signaling. In addition, the base station may dynamically indicate the slot format through Downlink Control Information (DCI), or may statically or quasi-statically indicate the slot format through RRC signaling.

< physical resources of NR >

Regarding physical resources in NR, antenna ports, resource grids, resource elements, resource blocks, bandwidth parts, etc. are considered.

An antenna port is defined as a channel that carries a symbol on an antenna port inferred from another channel that carries another symbol on the same antenna port. If a wide range of properties of the channel carrying the symbol on the antenna port can be inferred from another channel carrying the symbol on another antenna port, the two antenna ports may have a quasi co-located (QC/QCL) or quasi co-located (quasi-co-located) relationship. The wide range of properties includes at least one of delay spread, doppler spread, frequency shift, average received power, and received timing.

Fig. 3 is a view for explaining a resource grid supported by a radio access technology.

Referring to fig. 3, a resource grid may exist according to respective parameter sets because NRs support multiple parameter sets in the same carrier. In addition, a resource grid may exist according to antenna ports, subcarrier spacing, and transmission directions.

The resource block includes 12 subcarriers and is defined only in the frequency domain. In addition, the resource elements include one OFDM symbol and one subcarrier. Thus, as shown in fig. 3, the size of one resource block may be changed according to the subcarrier spacing. Further, "point a" serving as a common reference point for the resource block grid, the common resource block, and the virtual resource block is defined in NR.

Fig. 4 is a view for explaining a bandwidth part supported by a radio access technology.

Unlike LTE, which fixes the carrier bandwidth to 20MHz, the maximum carrier bandwidth is configured to be 50MHz to 400MHz according to the subcarrier spacing in NR. Therefore, it is not assumed that all terminals use the entire carrier bandwidth. Accordingly, as shown in fig. 4, a bandwidth part (BWP) may be specified within a carrier bandwidth in NR so that the terminal may use the bandwidth part (BWP). In addition, the bandwidth portion may be associated with one parameter set, may include a subset of contiguous common resource blocks, and may be dynamically activated over time. The terminal has up to four bandwidth parts in each of the uplink and downlink, and the terminal transmits and receives data using the active bandwidth parts during a given time.

In the case of paired spectrum, the uplink and downlink bandwidth portions are configured independently. In the case of unpaired spectrum, in order to prevent unnecessary frequency retuning between downlink and uplink operations, the downlink bandwidth portion and the uplink bandwidth portion are paired to share the center frequency.

< initial Access in NR >

In NR, a terminal performs a cell search and random access procedure in order to access and communicate with a base station.

Cell search is a process in which a terminal synchronizes with a cell of a corresponding base station using a Synchronization Signal Block (SSB) transmitted from the base station and acquires a physical layer cell ID and system information.

Fig. 5 is a view showing an example of a synchronization signal block in a radio access technology.

Referring to fig. 5, the ssb includes a Primary Synchronization Signal (PSS) and a Secondary Synchronization Signal (SSS), which occupy one symbol and 127 subcarriers, and a PBCH spanning three OFDM symbols and 240 subcarriers.

The terminal monitors the SSB in the time domain and the frequency domain, thereby receiving the SSB.

Up to 64 SSBs can be transmitted within 5 ms. Multiple SSBs are transmitted over different transmission beams in a time of 5ms, and it is assumed that the terminal performs detection based on the SSB transmitted every 20ms for a specific beam used for transmission. As the frequency band increases, the number of beams that can be used for SSB transmission within 5ms can increase. For example, up to 4 SSB beams may be transmitted at a frequency band of 3GHz or lower, and up to 8 SSB beams may be transmitted at a frequency band of 3 to 6 GHz. In addition, up to 64 different beams may be used to transmit SSBs at a frequency band of 6GHz or higher.

One slot includes two SSBs, and the start symbol and the number of repetitions in the slot are determined according to the subcarrier spacing, as described below.

Unlike an SS in a typical LTE system, SSB is not transmitted at the center frequency of the carrier bandwidth. That is, SSBs may also be transmitted at frequencies other than the center of the system band, and a plurality of SSBs may be transmitted in the frequency domain with wideband operation supported. Thus, the terminal monitors the SSB using a synchronization grid, which is a candidate frequency location for monitoring the SSB. A carrier grid and a synchronization grid, which are center frequency position information of the initially connected channel, are newly defined in NR, and the synchronization grid can support a fast SSB search of the terminal because its frequency interval is configured to be wider than that of the carrier grid.

The terminal may acquire the MIB through the PBCH of the SSB. The MIB (master information block) includes minimum information of Remaining Minimum System Information (RMSI) that the terminal receives network broadcasts. In addition, the PBCH may include information about the location of the first DM-RS symbol in the time domain, information of the terminal monitoring SIB1 (e.g., SIB1 parameter set information, SIB1 CORESET related information, search space information, PDCCH related parameter information, etc.), offset information between the common resource block and the SSB (location of absolute SSB in the carrier is transmitted via SIB 1), and the like. The SIB1 parameter set information is also applied to some messages for the terminal to access the base station after completing the cell search procedure in the random access procedure. For example, the parameter set information of SIB1 may be applied to at least one of messages 1 to 4 for the random access procedure.

The RMSI described above may mean SIB1 (system information block 1) and the SIB1 is periodically (e.g., 160 ms) broadcast in a cell. SIB1 includes information required for a terminal to perform an initial random access procedure, and SIB1 is periodically transmitted through a PDSCH. In order to receive SIB1, the terminal must receive parameter set information for SIB1 transmission and CORESET information for scheduling SIB1 through the PBCH. The terminal recognizes scheduling information of SIB1 using SI-RNTI in CORESET, and acquires SIB1 on PDSCH according to the scheduling information. The remaining SIBs other than SIB1 may be periodically transmitted, or may be transmitted according to a request of the terminal.

Fig. 6 is a view for explaining a random access procedure in a radio access technology.

Referring to fig. 6, if cell search is completed, the terminal transmits a random access preamble for random access to the base station. The random access preamble is transmitted through the PRACH. In particular, the random access preamble is periodically transmitted to the base station through a PRACH, which includes consecutive radio resources in repeated specific time slots. In general, a contention-based random access procedure is performed when a terminal performs an initial access to a cell, and a non-contention-based random access procedure is performed when the terminal performs a random access for Beam Fault Recovery (BFR).

The terminal receives a random access response to the transmitted random access preamble. The random access response may include a random access preamble Identifier (ID), UL grant (uplink radio resource), temporary C-RNTI (temporary cell-radio network temporary identifier), and TAC (time alignment command). Since one random access response may include random access response information of one or more terminals, a random access preamble identifier may be included, thereby indicating terminals for which the included UL grant, temporary C-RNTI, and TAC are valid. The random access preamble identifier may be an identifier of a random access preamble received by the base station. The TAC may be included as information for the terminal to adjust uplink synchronization. The random access response may be indicated by a random access identifier on the PDCCH, i.e. a random access radio network temporary identifier (RA-RNTI).

Upon receiving the valid random access response, the terminal processes information included in the random access response and performs scheduled transmission to the base station. For example, the terminal applies TAC and stores temporary C-RNTI. In addition, the terminal transmits data stored in a buffer of the terminal or newly generated data to the base station using UL grant. In this case, information for identifying the terminal must be included in the data.

Finally, the terminal receives the downlink message for contention resolution.

The downlink control channel in NR is transmitted in CORESET (control resource set) of 1 to 3 symbols in length, and the downlink control channel transmits uplink/downlink scheduling information, SFI (slot format index), TPC (transmit power control) information, and the like.

As mentioned above, NR has introduced the concept of CORESET to ensure flexibility of the system. CORESET refers to the time-frequency resources of the downlink control signal. The terminal may decode the control channel candidates using one or more search spaces in the CORESET time-frequency resources. CORESET-specific QCL (quasi co-location) is assumed to be configured and used for the following purposes: information about the characteristics of the analog beam direction is provided, as well as information about delay spread, doppler shift and average delay, which are characteristics exhibited by existing QCLs.

Fig. 7 is a view for explaining CORESET.

Referring to fig. 7, CORESET may exist in various forms within a carrier bandwidth in a single slot, and CORESET may include up to 3 OFDM symbols in the time domain. In addition, CORESET is defined as a multiple of up to six resource blocks of the carrier bandwidth in the frequency domain.

Additional configuration information and system information is received from the network by specifying (e.g., indicating, allocating) a first CORESET as part of the initial bandwidth portion via the MIB. After establishing a connection with the base station, the terminal may receive and configure one or more pieces of CORESET information through RRC signaling.

In the present disclosure, frequencies, frames, subframes, resources, resource blocks, regions, frequency bands, subbands, control channels, data channels, synchronization signals, various reference signals, various signals, or various messages related to a New Radio (NR) may be interpreted in various meanings used in the past, present, or future.

NR (New radio)

In contrast to LTE/LTE-advanced, NR is designed as: not only provides improved data transmission rates, but also meets various QoS requirements for each specific and particular usage scenario. In particular, enhanced mobile broadband (EmB), large-scale machine type communication (mMTC), and Ultra Reliable Low Latency Communication (URLLC) are defined as representative usage scenarios for NR. To meet the requirements of each usage scenario, NR is designed to have a flexible frame structure compared to LTE/LTE-advanced. Since each usage scenario has different requirements for data rate, delay, coverage, etc., there is a need for a method of efficiently multiplexing radio resource units different from each other based on parameter sets (e.g., subcarrier spacing (SCS), subframe, transmission Time Interval (TTI), etc.), as a solution for efficiently satisfying the requirements according to the usage scenario through a frequency band provided to an NR system.

To this end, there have been discussed i) a method of multiplexing parameter sets having subcarrier spacing (SCS) values different from each other based on Time Division Multiplexing (TDM), frequency Division Multiplexing (FDM), or TDM/FDM through one NR carrier, and ii) a method of supporting one or more time units when a scheduling unit is configured in a time domain. In this regard, in NR, the definition of a subframe is given as one type of time domain structure. In addition, as a reference parameter set for defining the corresponding subframe duration, a single subframe duration is defined as 14 OFDM symbols having normal CP overhead based on 15kHz subcarrier spacing (SCS), like LTE. Thus, the subframe of NR has a duration of 1 ms. Unlike LTE, since the subframe of NR is an absolute reference duration, slots and minislots can be defined as time units for actual UL/DL data scheduling. In this case, the number of OFDM symbols (value of y) constituting a slot is defined as y=14, regardless of the parameter set.

Thus, a slot may consist of 14 symbols. Depending on the transmission direction of the corresponding slot, all symbols may be used for DL transmission or UL transmission, or the symbols may be used in the configuration of DL part + gap + UL part.

Furthermore, minislots have been defined to consist of fewer symbols than slots in the parameter set (or SCS). Thus, a short time domain scheduling interval may be configured for UL/DL data transmission or reception based on the micro-slot. Also, a long time domain scheduling interval may be configured for UL/DL data transmission or reception through slot aggregation. In particular, in the case of transmitting or receiving delay critical data such as URLLC, when scheduling is performed on a slot basis based on a parameter set having a small SCS value (e.g., 15 kHz) based on 1ms (14 symbols) defined in a frame structure, it may be difficult to satisfy a delay requirement. For this purpose, a micro slot may be defined to be made up of fewer OFDM symbols than a slot. Scheduling of delay critical data such as URLLC may be performed on a minislot basis.

Meanwhile, in NR, the default scheduling unit has been changed to a slot. Furthermore, a slot consists of 14 OFDM symbols regardless of the subcarrier spacing. In contrast, NR supports a non-slot structure configured by 2, 4, or 7 OFDM symbols, which is a smaller scheduling unit. The non-slot structure may be used as a scheduling unit for the URLLC service.

NR MBS (multicast and broadcast service)

The 3GPP approves the 5G/NR based MBS task in Rel-17. MBS means multicast communication service and broadcast communication service.

In a broadcast communication service, the same service along with the same specific content data may be provided to all terminals within one geographical area (such as a broadcast coverage) at the same time. In the broadcast communication service, it is possible for all terminals within the broadcast coverage to receive the broadcast communication service. The broadcast communication service may be delivered to the terminal through a broadcast session. During the broadcast session, the terminal may receive MBS data in RRC idle, RRC inactive and RRC connected states.

In a multicast communication service, the same service along with the same specific content data may be provided to a specified group of terminals at the same time. Not all terminals within the multicast coverage area are authorized to receive the multicast communication service. Multicast communication services may be delivered to terminals through multicast sessions. During the multicast session, the terminal may receive MBS data in an RRC connected state.

For multicast services, the base station may use the following method to deliver MBS data packets.

PTP (point-to-point) transmission: the base station separately communicates separate copies of the MBS data packets. The base station may schedule the terminal-specific PDSCH using a terminal-specific PDCCH CRC-scrambled by a terminal-specific RNTI (e.g., C-RNTI). The terminal-specific PDSCH is scrambled using the same terminal-specific RNTI (e.g., C-RNTI).

PTM (point-to-multipoint) transmission: the base station delivers a single copy of the MBS data packet to a group of terminals. The base station may schedule the group common PDSCH using a group common PDCCH CRC-scrambled by a group common RNTI (e.g., G-RNTI of LTE SC-PTM). The group common PDSCH is scrambled using the same group common RNTI.

The base station may dynamically determine whether to transmit multicast data to the terminals via PTM or PTP. The base station may dynamically schedule multicast data to be transmitted and transmit the data to the terminals. Meanwhile, it is preferable that the specific multicast session is deactivated when multicast data transmission to the terminal for the specific session does not occur. This approach increases the effective utilization of network resources. However, the current frame work lacks a designated control method for activating or deactivating multicast sessions. In particular, in a radio network, a terminal may perform data inactivity monitoring through an RRC procedure, possibly transitioning to an RRC idle state during the monitoring procedure. In such an instance, the terminal may experience difficulty in receiving MBS data. Despite this situation, no specific method of operation has been proposed to address this problem.

It may therefore be more advantageous to deactivate a particular multicast session when multicast data transmission is not intended for a corresponding terminal within the particular multicast session in order to save radio resources. However, there is a lack of dedicated control methods for managing terminal operation based on activation or deactivation of multicast sessions within a radio network.

To address this problem, the present disclosure introduces a method and apparatus for a terminal to efficiently receive MBS data during an activation/deactivation procedure during a multicast session.

Hereinafter, a method and apparatus for providing a multicast/broadcast service (MBS) based on an NR radio access technology according to an embodiment will be described. However, embodiments are not limited to NR radio access technologies. For example, embodiments of the present disclosure may be applied to any radio access technology (e.g., LTE or 6G). Embodiments described in this disclosure may include the content of information elements and operations set forth in 3GPP NR MAC standard TS 38.321 and NR RRC standard TS 38.331. Although the present disclosure does not include content of terminal operations related to detailed definitions of corresponding information elements, content set forth in the standards may be incorporated into the present disclosure.

For convenience of description, the following description focuses mainly on a method for receiving multicast communication service data by an RRC-connected terminal. However, this is for convenience of description. Embodiments may also be applied to broadcast communication services. In addition, the embodiments may also be applied to RRC idle or RRC inactive terminals.

The embodiments described below may be applied alone or in any combination thereof.

Fig. 8 is a flowchart for describing the operation of a terminal according to an embodiment.

Referring to fig. 8, a terminal receiving multicast/broadcast service (MBS) data may perform a step of receiving an RRC message from a base station (S810).

According to an embodiment, the terminal may receive higher layer messages from the base station. For example, the higher layer message may be a Radio Resource Control (RRC) message. The RRC message may be an RRC connection reconfiguration message or an RRC connection configuration message.

The RRC message may include at least one of MBS radio bearer configuration information mapped to the MBS session and a data inactivity timer. For example, the MBS radio bearer configuration information may include information necessary to configure a radio bearer mapped to the MBS session in the terminal to receive multicast data or broadcast data. The data inactivity timer may be included in the MBS radio bearer configuration information. Alternatively, the data inactivity timer may be included in a separate field from the MBS radio bearer configuration information.

The terminal may perform a step of configuring a data inactivity timer based on the RRC message (S820).

According to an embodiment, the terminal may configure a data inactivity timer in the terminal based on the data inactivity timer information included in the RRC message. In addition, the terminal may configure MBS radio bearers mapped to the MBS session in the terminal based on the RRC message. One or more MBS radio bearers may be configured. For example, a data inactivity timer is configured in the MAC entity of the terminal.

If the terminal receives an MBS service channel (MTCH) MAC SDU for an MBS from the MAC entity, the terminal may perform a step of starting or restarting a data inactivity timer (S830).

According to an embodiment, the terminal may control data reception in the MBS session based on the operation of the data inactivity timer. As an example, the data inactivity timer is configured to be started or restarted if a logical channel associated with the MBS session is received. In other words, when the MAC entity of the terminal receives the MAC SDU of the MBCH, the terminal may start or restart the data inactivity timer. As another example, the data inactivity timer of the terminal in the RRC connected state may be configured to be started or restarted if multicast data is received during the active multicast session.

If the data inactivity timer expires, the MAC entity of the terminal indicates (e.g., informs or informs) the higher layer (RRC layer) that the data inactivity timer expires.

Meanwhile, the base station may configure radio resources associated with the MBS session based on at least one of MBS session state information received from the core network entity, a message for activating the MBS session, and a message for deactivating the MBS session. According to an embodiment, the base station may receive MBs session state information from a core network entity (e.g., AMF or SMF or MB-SMF). According to another embodiment, the base station may receive a message from the core network entity for activating or deactivating the MBS session. Further, the base station may receive indication information for enabling MBS session state change (function), a timer (value) for checking MBS session state change, etc. from the core network entity. The above information may be received through an N2 message.

As described above, the terminal may receive the RRC message from the base station. For example, when the MBS session state information received by the base station from the core network entity indicates that it is active, the RRC message may include MBS radio bearer configuration information for the MBS session and be transmitted to the terminal. In other words, if the base station receives MBS session state information from the core network entity and the MBS session state information includes a value indicating that it is active, the base station may transmit an RRC message including MBS radio bearer configuration information of the MBS session to the terminal.

Alternatively, the base station may transmit a paging message including an MBS session ID for the RRC idle terminal or the RRC non-active terminal when receiving a message for activating the MBS session or receiving MBS data from the core network entity. For example, the base station may receive a message from the core network entity for activating the MBS session. Alternatively, the base station may receive MBS data from the core network entity. In this case, the base station may transmit a paging message including an MBS session ID for the RRC idle terminal or the RRC non-active terminal. The terminal may receive the paging message, change the RRC state, and continue MBS data reception.

Alternatively, when the MBS session status information indicates that it is inactive, or when a message for deactivating the MBS session is received, the base station may release the radio resource configuration for the inactive MBS session for not allocating radio resources for the inactive MBS session. For example, when the MBS session status information indicates that it is inactive or the base station receives a message for deactivating an MBS session, the base station may release the radio resource configuration for the corresponding inactive MBS session. Thus, the base station may not allocate radio resources for MBS sessions indicated as inactive or inactive.

According to the embodiments shown above, unnecessary waste of network resources for transmitting and receiving MBS data can be prevented.

Fig. 9 is a flowchart for describing an operation of a base station according to an embodiment.

Referring to fig. 9, a base station (controlling multicast/broadcast service (MBS) data) may perform at least one of receiving MBS session state information, a message for activating an MBS session, and a message for deactivating an MBS session from a core network entity (S910).

According to an embodiment, the base station may receive MBs session state information from a core network entity (e.g., AMF or SMF or MB-SMF). According to another embodiment, the base station may receive a message from the core network entity for activating or deactivating the MBS session. Further, the base station may receive indication information for enabling MBS session state change (function), a timer (value) for checking MBS session state change, etc. from the core network entity. The above information may be received through an N2 message.

The base station may perform control of a radio resource configuration associated with the MBS session based on at least one of the MBS session status information, a message for activating the MBS session, and a message for deactivating the MBS session (S920).

According to an embodiment, the base station controls the radio resource configuration associated with the MBS session based on messages and information received from the core network entity. Furthermore, the base station may transmit an RRC message or a paging message to the terminal based on the message and information received from the core network entity. To this end, the base station may perform operations such as configuring MBS radio bearers and configuring radio resources.

For example, when MBS session status information received by the base station from the core network entity indicates that it is active, the base station may perform transmission of an RRC message including MBS radio bearer configuration information for the MBS session to the terminal (S930). The RRC message may be an RRC connection reconfiguration message or an RRC connection configuration message. Such operation S930 may be omitted and may be optionally performed as needed.

As another example, when the base station receives a message for activating an MBS session or receives MBS data from the core network entity, the base station may perform transmission of a paging message including an MBS session ID for an RRC idle terminal or an RRC non-activated terminal (S930). For example, the base station may receive a message from the core network entity for activating the MBS session. Alternatively, the base station may receive MBS data from the core network entity. In this case, the base station may transmit a paging message including an MBS session ID for the RRC idle terminal or the RRC non-active terminal. The terminal may receive the paging message, change the RRC state, and continue MBS data reception.

As another example, when the MBS session status information indicates inactivity, or when the base station receives a message for deactivating the MBS session, the base station may control release of the radio resource configuration for the inactive MBS session to prevent radio resources from being allocated for the inactive MBS session. For example, when the MBS session status information indicates that the message for deactivating the MBS session is received by the base station or the non-active MBS session, the base station may release the radio resource configuration for the corresponding non-active MBS session. Thus, the base station may not allocate radio resources for MBS sessions indicated as inactive or inactive.

As described above, the core network entity may be an AMF or an SMF or an MB-SMF.

The terminal (receiving the RRC message or paging message from the base station) may perform the operations described with reference to fig. 8 to control the MBS data reception operation.

According to the above-described embodiments, unnecessary waste of network resources for transmitting and receiving MBS data can be prevented.

Hereinafter, various embodiments that can be performed by the above-described terminal and base station, respectively, will be described. The embodiments described below may be performed independently or in any combination with the above-described terminal and base station operations. In the present disclosure, MBS data transmission is used in the same sense as PTM transmission or group common PDSCH transmission, if necessary. Accordingly, these terms may be interchanged.

Method for controlling not to switch receiving terminal into RC idle state before triggering MBS session deactivation

In the RRC connected state, the terminal may be configured with a data inactivity monitoring function through the RRC layer. If the data inactivity timer is configured, the terminal should operate as follows.

-if any MAC entity receives a MAC SDU for a Dedicated Traffic Channel (DTCH) logical channel, a Dedicated Control Channel (DCCH) logical channel, an MBS Traffic Channel (MTCH) or a Common Control Channel (CCCH) logical channel, or

If any MAC entity transmits MAC SDUs for DTCH logical channels or DCCH logical channels,

the terminal (the MAC entity of the terminal) starts or restarts the data inactivity timer.

If the data inactivity timer expires,

the terminal (the MAC entity of the terminal) indicates the expiration of the data inactivity timer to the higher layer (RRC layer).

If the higher layer (RRC layer) receives the expiration of the data inactivity timer from the lower layer (MAC layer), the terminal performs an action of entering RRC IDLE. The terminal resets the MAC layer and releases all radio resources and instructs the release of the RRC connection to the NAS/application layer.

If the terminal receives data associated with the active multicast session through the MBS session activation procedure, it is necessary to maintain the RRC connection state of the terminal in the active multicast session state. Alternatively, it is required to control the receiving terminal not to switch to the RRC idle state before triggering MBS session deactivation. Alternatively, when an MBS radio bearer associated with an active MBS session is configured and the terminal is receiving data, it is required to control the receiving terminal not to switch to the RRC idle state.

Otherwise, the terminal may switch to the RRC idle state and it is difficult to receive MBS session data. For example, the MBS radio bearer configuration may be maintained to receive data even in the RRC idle state. However, in this case, the base station does not maintain the context of the terminal, so that it may be difficult to continuously provide services while the terminal moves.

Not when configuring MBS radio bearer associated with activating MBS session (or indicating activation of MBS session) Method for configuring data to deactivate functions/timers (by releasing the corresponding function or indicating bits if there is a configured terminal) Method for setting value to disable corresponding function

The base station may configure the terminal with MBS radio bearers mapped to active MBS sessions through a multicast session configuration procedure. Alternatively, the base station may set the MBS session to an active state through a multicast session configuration procedure and configure the MBS radio bearer mapped to the MBS session to the terminal. Alternatively, the base station may set/activate the MBS session to an active state through a multicast session activation procedure, configure/modify/change the MBS radio bearer mapped to the MBS session to the terminal, and transmit MBS data.

The base station may receive an N2 message from the AMF (or any 5GC node/entity, e.g., SMF/MB-SMF) through a multicast session configuration procedure or a multicast session activation procedure (or receive a message from the 5GC through the AMF). The message may include information for indicating the multicast session as an active state or information for indicating the activation of the multicast session. The message may include a paging message for paging the CM IDLE terminal joining the multicast session. Information for indicating the multicast session as an active state or information for indicating the activation of the multicast session may be included in a paging message for paging the CM IDLE terminal joining the multicast session. The message may include MBS session context information. The MBS session context information may include one or more of MBS session ID, source specific multicast address, TMGI, multicast QoS flow information, MBS session AMBR, associated PDU session context, PDU session ID, S-nsai, PDU session AMBR, associated unicast QoS flow-multicast QoS flow information mapping/association, and multicast session state (active/inactive), and information on whether multicast session state (active/inactive) is supported.

Upon receiving the above information, the base station may instruct (e.g., instruct, provide, transmit) a paging message to page the CM IDLE terminal joining the multicast session over the radio interface (Uu). Alternatively, upon receiving the above information, the base station may instruct (e.g., instruct, provide, transmit) a paging message to page RRC INACTIVE terminals joining the multicast session over the radio interface (Uu). Alternatively, upon receiving the above information, the base station may set/activate the MBS session to an active state and indicate to the terminal an RRC reconfiguration message for configuring/modifying/changing the MBS radio bearer mapped to the MBS session to the terminal. In this case, the base station may allow the data inactivity function/timer to be not configured in the terminal. Alternatively, upon receiving the above information, the base station may set/activate the MBS session to an active state and indicate to the terminal an RRC reconfiguration message for configuring/modifying/changing the MBS radio bearer mapped to the MBS session to the terminal. In this case, if the data inactivity function/timer is configured/applied to the terminal, the base station may instruct to release the configuration. For example, if the operation has been configured/reconfigured/applied to the terminal because the MAC cell group configuration includes the data inactivity timer in the previous configuration, the base station includes and transmits information on the RRC reconfiguration message for releasing the data inactivity timer in the MAC cell group. Alternatively, the base station may include information on the RRC reconfiguration message indicating to release the data inactivity timer in the MAC cell group configuration, indicating the terminal reconfiguration/modification/release function/timer. Alternatively, the base station may instruct the terminal reconfiguration/modification/release function/timer by excluding the data inactivity timer in the MAC cell group configuration on the RRC reconfiguration message. Alternatively, the base station may indicate a specific value (e.g., infinity) on the RRC reconfiguration message as a data inactivity timer value in the MAC cell group configuration, indicating that the terminal reconfigures/modifies/releases the function/timer so that the function is not operated. For example, the base station may indicate the timer value as unlimited, disabling the timer/function. The data inactivity timer value may be one of { s1, s2, s3, s5, s7, s10, s15, s20, s40, s50, s60, s80, s100, s120, s150, and s180 } where s1 represents 1 second. The base station may specify a value for disabling the function and apply it to the terminal, or may add a new value to disable the function.

A method and apparatus for associating (controlling) data reception associated with MBS sessions based on data inactivity timer operations Is a method of (2)

The MAC entity may additionally perform data reception to the data inactivity timer operation through the MBS radio bearer mapped to the MBS session, thereby preventing the terminal from switching (e.g., toggling) to the RRC idle state when receiving the MBS session data.

As an example, if the terminal receives a logical channel associated with an MBS session when the data inactivity timer is configured in the terminal, the terminal may start or restart the data inactivity timer. The logical channels associated with the MBS session may indicate MBS traffic logical channels and/or MBS control logical channels.

As another example, if the terminal receives multicast data activating the multicast session while configuring a data inactivity timer for the terminal in the RRC connected state, the terminal may start or restart the data inactivity timer. The multicast data may indicate a multicast traffic channel and/or a multicast control channel logical channel.

If any MAC entity receives a MAC SDU for a Dedicated Traffic Channel (DTCH) logical channel, a Dedicated Control Channel (DCCH) logical channel, a Common Control Channel (CCCH) logical channel or an MB Traffic Channel (MTCH) logical channel or an MB control channel logical channel,

If any MAC entity transmits MAC SDUs of DTCH logical channels or DCCH logical channels,

If the data inactivity timer expires,

the terminal (the MAC entity of the terminal) indicates to the higher layer (RRC) the expiration of the data inactivity timer.

One for stopping/suspending data inactivity if MBS session activation indication is receivedRecipe of active timer Method of

The base station may receive information indicating the multicast session as an active state or information indicating the activation of the multicast session from the core network entity. Upon receiving the information (or including any information included in the above embodiments, such as MBS context information), the base station may set/activate the MBS session to an active state and indicate to the terminal an RRC reconfiguration message for configuring/modifying/changing the MBS radio bearer mapped to the MBS session. The terminal may stop/suspend the MBS data inactivity timer upon receiving the message (or upon receiving any relevant indication information such as MBS session activation status indication, data inactivity timer suspend/stop/suspend indication). Therefore, the terminal can be prevented from switching to the RRC idle state due to the function.

A method for ignoring expiration of a data inactivity timer if an MBS session in active is received

Hereinafter, additional embodiments will be described. First, the following definition is made regarding MBS session status of resource efficient multicast data transmission.

Configured multicast session (multicast session configuration state): multicast data is not transmitted. Some information about the multicast session is configured. However, no resources are reserved. For example, the TMGI is allocated, but complete session information is not provided to the terminal. The terminal may be allowed to join. However, the first accepted terminal join request will trigger the multicast session establishment.

Activate multicast session (multicast session active state): the multicast data is transmitted to terminals that have joined the multicast session. Resources of the multicast session 5GC are reserved. Corresponding radio resources are reserved according to the location of the joining terminal. The terminal joining the multicast session is in the CM CONNECTED state. The terminal is allowed to join the multicast session. Which is a multicast session configured in an active state.

Inactive multicast session (multicast session inactive state): multicast data is not transmitted. The terminal joining the multicast session is in the CM CONNECTED or CM IDLE state. The terminal is allowed to join the multicast session. Which is a multicast session configured in an inactive state.

A multicast session configuration procedure may be provided. Including network internal configurations for multicast sessions such as TMGI allocation requests and/or information about multicast sessions provided by application functions. Resources of the multicast session are not reserved, or resources may be reserved only in core network entities (e.g., MB-SMF, MB-UPF, or NEF) associated with the MBS. In contrast, in the inactive multicast session state, multicast data is not transmitted. The configuration may indicate whether or when the multicast session is created and whether the multicast session is in an inactive state. The application function may provide configuration in multiple steps. For example, the TMGI may be allowed to be requested and then the entire information about the multicast session provided and configured.

Meanwhile, a multicast session setup procedure may be provided. When a first terminal's request to join a multicast session is accepted, the multicast session is set to an inactive or active state according to a configuration. The 5G core (5 GC) resources of the multicast session are being reserved.

Alternatively, a multicast session activation procedure may be provided. The CM IDLE terminal joining the multicast session is paged. Activation may be triggered by an application function request. Alternatively, activation may be triggered by receipt of multicast data.

Alternatively, a multicast session deactivation procedure may be provided. Deactivation may be triggered by an application function request. Alternatively, deactivation may be triggered by lack of receipt of multicast data.

Alternatively, a multicast session release procedure may be provided. Releasing all resources of the multicast session for all 5GC nodes and radio network nodes. Informing the terminals joining the multicast session. For active or inactive multicast sessions, release is possible.

Alternatively, a multicast session de-configuration procedure may be provided. All information about the multicast session is removed from the 5 GC. The TMGI is deallocated.

When the multicast session is configured, the multicast session may be set to an active state or an inactive state. During the multicast session configuration procedure (for activating the multicast session), the base station may establish/configure data radio bearers mapped to PDU sessions associated with the multicast session and/or MBS radio bearers mapped to the multicast session and set the multicast session (in an active state). Alternatively, during the multicast session configuration procedure (for inactive multicast sessions), the base station may establish/configure data radio bearers mapped to PDU sessions associated with the multicast session and/or MBS radio bearers mapped to the multicast session and set the multicast session (inactive state). The corresponding MBS radio bearer and/or data radio bearer may be configured to operate according to an MBS session inactive state. Alternatively, during the multicast session configuration procedure (for inactive multicast sessions), the base station may only establish/configure data radio bearers mapped to PDU sessions associated with the multicast session and set the multicast session (inactive state). Alternatively, during the multicast session configuration procedure (for inactive multicast sessions), the base station may set the multicast session (inactive state) without setting/configuring the data radio bearers mapped to the PDU session associated with the multicast session or the MBS radio bearers mapped to the multicast session. Hereinafter, such an operation will be described in more detail.

The terminal may join the multicast session through a PDU session modification procedure in the RRC connected state. First, such a joining process will be described below.

To join the multicast group, the terminal transmits a PDU session modification request message to the AMF. The message includes an MBS session ID indicating a multicast group to which the terminal desires to join.

The AMF receives MBs context of the multicast session from the associated 5GC node/entity (SMF/MB-SMF) through signaling. For example, the SMF performs authorization for the MBS session join request and extracts multicast QoS flow information of the MBS session indicated through signaling with the MB-SMF. The SMF transmits the MBS session context to the AMF. The MBS session context may include one or more of an MBS session ID, a source specific multicast address, a TMGI, multicast QoS flow information, an MBS session AMBR, an associated PDU session context, a PDU session ID, S-nsai, a PDU session AMBR, an associated unicast QoS flow-multicast QoS flow information mapping/association, and multicast session state (active/inactive), and information on whether multicast session state (active/inactive) is supported.

The AMF transmits an N2 message including PDU session modification command information to the base station. The PDU session modification command information or the N2 message may include MBS context information. The PDU session modification command information or the N2 message may include an MBS session state (or a multicast session state or information indicating activation/deactivation of the MBS/multicast session). For example, the MBS session state (or multicast session state or information indicating activation/deactivation of the MBS/multicast session) may be configured by one bit of information to distinguish between activation/deactivation states (activation/deactivation indication).

If the MBS-capable base station receives the MBS session ID but there is no multicast session context for the MBS session ID, the base station allocates resources for servicing the MBS session using the MBS session QoS information. If the base station does not support MBS, 5GC separate MBS service delivery may be performed. For example, the base station may transmit MBS data received from the core network entity to the terminal in PTP manner using PDU session context (unicast QoS flow information) associated with the MBS session, through a separate tunnel between the base station and the UPF/MB-UPF, using conventional data radio bearers. The base station may configure/reserve radio resources to the terminal.

As an example, when the MBS session state is set to an active state and indicated (through an N2 message). The base station may indicate (e.g., provide, transmit) to the terminal an RRC reconfiguration message including radio resource configuration information for receiving MBS session data. The RRC reconfiguration message may include MBS radio bearer configuration information mapped to the MBS session and/or data radio bearer information mapped to a PDU session associated with the MBS session. The data radio bearers may be configured based on PDU session context (e.g., qoS flow information) mapped/associated to the MBS session. The data radio bearer may be used for transmission in PTP scheme using 5GC separate MBS service delivery.

The RRC reconfiguration message may include MBS session state information (active/inactive). The RRC reconfiguration message may include information configured in association with a multicast session state of the MBS radio bearer mapped to the multicast session. As an example, the RRC message may include information configured with MBS radio bearers mapped to multicast sessions differentiated for active/inactive states (or data radio bearers mapped to PDU sessions associated with the MBS session). As another example, the RRC message may include information configured with MBS radio bearers mapped to multicast sessions differentiated for active/inactive states (or data radio bearers mapped to PDU sessions associated with the MBS session).

The terminal may configure the MBS radio bearer and/or the data radio bearer mapped to the PDU session associated with the MBS session (when the multicast session state is set to the active state and indicated). The terminal may receive the MBS session data over the configured MBS radio bearer and/or the data radio bearer mapped to the PDU session associated with the MBS session.

Fig. 10 is a view showing an example of a layer 2 structure for receiving MBS data.

Referring to fig. 10, for an MBS service session belonging to one multicast group, an MBS radio bearer may be defined as a separate bearer structure having two legs/paths. One leg/path of the MBS radio bearer based on the separate bearer structure may comprise the L2 entity configuration of the (regular) unicast DRB for PTP transmission and perform PTP transmission. Other legs/paths may include L2 entity configuration for PTM transmission and performing PTM transmission.

The RLC entity of the unicast leg/path for PTP transmission may be configured in association with a logical channel identifier. The data may be received through a schedule indicated by the C-RNTI in the MAC. RLC entities for the leg/path of PTM transmission may be differentiated per MBS session and may be configured in association with RNTI for identifying data reception or MBS session data transmission. Here, for convenience of description, MBS user data is referred to as NR-MTCH, but this is merely for convenience of description and may be replaced with any other terms (e.g., MB traffic channel, multicast traffic channel). Furthermore, the RNTI for MBS data identity means a multicast session/multicast group specific RNTI or a group common RNTI for multicast traffic/data, similar to SC-RNTI and G-RNTI. Here, for convenience of description, it is referred to as MBS-G-RNTI. However, the embodiment is not limited thereto. It may be replaced with another term.

The RLC entity of the unicast leg/path for PTP transmission and the RLC entity of the leg/path for PTM transmission may be associated with one PDCP entity. The PDCP entity may be associated with an MBS service session (TMGI/MBS session ID/IP multicast address). The terminal may receive MBS service data transmitted according to a transmission scheme selected by the base station. For example, the base station may transmit data through one path (or two paths) of the RLC entity of the unicast leg/path for PTP transmission and the RLC entity of the leg/path for PTM transmission in the PDCP entity, and the terminal may receive the data.

The base station knows that a group of terminals has joined the corresponding multicast group. For example, in the structure as shown in fig. 10, there may be RLC entities for the legs/paths of PTM transmission as many as the number of terminals that have joined the RRC connection of the corresponding multicast group.

Meanwhile, as another example, when the MBS session state is set to an inactive state and indicated (through an N2 message), the base station may indicate (e.g., instruct or notify) to the terminal an RRC reconfiguration/release message including radio resource configuration information for receiving MBS session data. The RRC reconfiguration/release message may include MBS radio bearer configuration information mapped to the MBS session. The RRC reconfiguration/release message may include multicast session state information (inactive). The RRC reconfiguration/release message may include inactive MBS radio bearer configuration information associated with the MBS session. The RRC reconfiguration/release message may include MBS radio bearer configuration information associated with the MBS session to be suspended. The RRC reconfiguration/release message may include any configuration information for indicating that the MBS session is in an inactive state.

As another example, when the multicast session state is set to the inactive state and indicated (through an N2 message) (or when deactivation of the multicast session is indicated), the base station may indicate (e.g., provide, transmit) to the terminal an RRC reconfiguration message including radio resource configuration information for the terminal to receive MBS session data. Alternatively, the base station may indicate (e.g., provide, transmit) an RRC release message to the terminal to release/suspend the radio resource configuration information for the terminal to receive MBS session data. The RRC reconfiguration/release message may include a PDU session modification command message. The PDU session modification command may be included in a dedicated NAS message information element and transmitted. The PDU session modification command message may include multicast session state information (inactive). The RRC reconfiguration/release message may include MBS radio bearer configuration information mapped to the MBS session. The NAS/higher layer of the terminal receiving the PDU session modification command may indicate status information (inactive) about the multicast session to the AS/RRC/lower layer. The RRC of the terminal may suspend/release/switch the MBS radio bearer mapped to the multicast session to an inactive state.

As another example, when the multicast session state is set to the inactive state and indicated (through an N2 message) (or when deactivation of the multicast session is indicated), the base station may indicate an RRC reconfiguration/release message including radio resource configuration information for the terminal to receive MBS session data to the terminal. The RRC reconfiguration/release message may include a PDU session modification command message. The PDU session modification command may be included in a dedicated NAS message information element and transmitted. The PDU session modification command message may include multicast session state information (inactive). The RRC reconfiguration/release message may include information indicating suspension of MBS radio bearer configuration information mapped to the MBS session (if the MBS radio bearer mapped to the MBS session is configured in the terminal). The RRC reconfiguration/release message may include data radio bearer configuration information mapped to a PDU session associated with the MBS session.

As another example, when the multicast session state is set to the inactive state and indicated (through an N2 message) (or when deactivation of the multicast session is indicated), the base station may indicate a MAC CE to the terminal for indicating that the state of the multicast conference is inactive. The MAC CE may include one or more of MBS session ID information, TMGI, source specific IP multicast address, information indicating MBS session status, information indicating MBS session activation/deactivation, MBS radio bearer identifiers mapped to MBS sessions, and data radio bearer identifiers mapped to PDU sessions associated with MBS sessions. The MAC CE may be used to instruct the base station to perform terminal operations related to radio resource configuration (associated with MBS sessions) in association with a multicast session activation/deactivation procedure.

The above-described operations may be an example of receiving any information indicating that the state of the multicast session is inactive.

Upon receiving any information indicating that the state of the multicast session is inactive, the terminal may perform one or more of the following operations.

The terminal may configure MBS radio bearers. The terminal may store the MBS radio bearer. The terminal may configure/store the MBS radio bearer in an inactive state. The terminal may suspend the MBS radio bearer. The terminal may suspend reception of data for the MBS session. The terminal may consider the MBS radio bearer to be in an inactive multicast session state. The terminal does not perform data reception through the MBS-G-RNTI. The terminal stops/suspends data reception through the MBS-G-RNTI. The terminal does not perform PDCCH monitoring through the MBS-G-RNTI. The terminal does not perform group common PDCCH monitoring through the MBS-G-RNTI. The terminal may release the MBS radio bearer. The terminal may configure data radio bearers mapped to PDU sessions associated with the MBS session. The terminal may terminate the data radio bearer mapped to the PDU session associated with the MBS session. Alternatively, the terminal may receive data over a data radio bearer mapped to a PDU session associated with the MBS session.

Meanwhile, when the MBS session supports the multicast session state (active/inactive change), the state change/handover (active/inactive) of the MBS session may be triggered by an application function request or whether multicast data is received. The activation/deactivation process may be initiated by a trigger.

As an example, when the MBS session supports an inactive state (or an active-inactive state switch) during the MBS session configuration procedure, the AMF/SMF/MB-SMF may include and transmit one or more of an MBS session state (active/inactive), indication information for enabling an MBS session state change (function), and a timer (value) for checking the MBS session state change to the UPF/MB-UPF/base station. If the MBS session state is set to active, the UPF/MB-UPF/base station receiving the information may check for MBS session state changes. For example, if the data/logical channel associated with the MBS session is transmitted/received, the UPF/MB-UPF/base station starts or restarts a timer for checking the MBS session state change. If the timer for checking the MBS session state change expires, the UPF/MB-UPF/base station may transmit information for indicating the MBS session deactivation to the AMF/SMF/MB-SMF. As another example, if the AMF/SMF/MB-SMF receives information indicating MBs session deactivation, the AMF/SMF/MB-SMF may request the base station to deactivate the MBs session. As another example, if a data/logical channel associated with an MBs session is received from the UPF/MB-UPF, the base station starts or restarts a timer for checking for MBs session state changes. If the timer for checking the MBS session state change expires, the base station may transmit information for indicating the MBS session deactivation to the AMF.

As another example, upon receiving data of a multicast session in an inactive state, the MB-UPF/base station may notify the AMF/SMF/MB-SMF of this. The corresponding message may include MBS session identification information. The corresponding message may include indication information/message for informing the MBS session of downlink data (or for indicating that activation of the MBS session has been triggered). Upon receiving the message, the AMF may request/instruct the base station to activate the MBS session. The message for the AMF requesting/indicating the base station to activate the MBS session may include one or more of a paging message/related information, an MBS session ID, information for indicating an MBS session state, and information for indicating MBS session activation/deactivation. When a terminal in an RRC idle state joins a multicast session, the AMF may page the terminal through a CN-initiated paging procedure. The paging message transmitted from the AMF to the base station may include one or more of MBS session ID information, information indicating a status of the MBS session, and information indicating activation/deactivation of the MBS session. The paging message transmitted by the base station to the terminal may include one or more of MBS session ID information, information indicating a status of the MBS session, and information indicating activation/deactivation of the MBS session. The paging message may be included in the paging record or in a terminal identifier information element included in the paging record. As a terminal identifier information element included in the current paging record, a 48-bit NG-5G-S-TMSI or a 40-bit full-RNTI may be selected. If the MBS session ID is a value less than 48 bits, it may be included on the terminal identifier information element and transmitted. When the MBS session ID included in the paging message matches the MBS session ID of the inactive multicast session to which the terminal joins, the terminal may initiate/perform any operation for receiving data through the MBS radio bearer or any procedure (RRC restoration or RRC establishment) for restoring the MBS radio bearer. As an example, the terminal may instruct the base station to resume/activate data reception of the MBS session through the MAC CE and resume/activate data reception through the MBS radio bearer. As another example, any operation included in the present disclosure may be an example of any operation of receiving data over an MBS radio bearer.

As another example, when there is a terminal in an RRC inactive state, joining an inactive multicast session, the base station may page the terminal through a RAN-initiated paging procedure. The paging message transmitted by the base station to the terminal may include one or more of MBS session ID information, information indicating a status of the MBS session, and information indicating activation/deactivation of the MBS session. The paging message may be included in the paging record or in a terminal identifier information element included in the paging record. Alternatively, the paging message may be provided by the base station to a terminal that has switched to an RRC inactive state (RRC release with susposdconfig) among terminals joining the multicast session. The paging message may be included in the paging record or in a terminal identifier information element included in the paging record. As a terminal identifier information element included in the current paging record, a 48-bit NG-5G-S-TMSI or a 40-bit full-RNTI may be selected. If the MBS session ID is a value less than 48 bits, it may be included on the terminal identifier information element and transmitted. When the MBS session ID included in the paging message matches the MBS session ID of the inactive multicast session to which the terminal joins, the terminal may initiate/perform any operation for receiving data through the MBS radio bearer or any procedure (RRC restoration or RRC establishment) for restoring the MBS radio bearer. As an example, the terminal may instruct the base station to resume/activate data reception of the MBS session through the MAC CE or resume/activate data reception through the MBS radio bearer. As another example, any operation included in the present disclosure may be an example of any operation of receiving data over an MBS radio bearer. The MAC CE may include one or more of MBS session ID information, TMGI, source specific IP multicast address, information indicating MBS session status, and information indicating activation/deactivation of MBS session.

If the base station receives information from the AMF (or any 5GC node/entity) indicating to deactivate the multicast session, the base station may store the inactive state of the multicast session on the terminal context of the terminal. The base station may transmit an RRC release message (RRC release or RRC release with supendconfig) according to the data inactivity timer of the terminal, allowing the terminal to enter an RRC idle or RRC inactive state. When the terminal is switched to the RRC inactive state, the AMF does not page the terminal because it considers the terminal to be in the CM CONNECTED state. Thus, if the multicast session state is triggered to change/switch from the inactive state to the active state, e.g., if the base station receives information from the AMF (or any 5GC node/entity) indicating that the multicast session is active, and/or if the base station receives multicast session data, the base station shall perform RAN-initiated paging of the terminal.

As another example, the base station may further receive assistance information for indicating that the terminal does not switch to the RRC inactive state upon receiving the active multicast session state from the AMF or upon receiving information for indicating that the multicast session is active from the AMF. The corresponding information may include one or more of MBS session ID information, information indicating an MBS session state, information indicating activation/deactivation of an MBS session, and information on whether to support the MBS session state. The corresponding information may be included in core network assistance information of the RRC inactivity information element. The corresponding information may be provided in an information element that is distinguished from the RRC-inactive core network assistance information. If the corresponding information is received, the base station may store the received corresponding information. The base station may use the stored corresponding information to determine RRC inactive state or RAN paging. Alternatively, the base station may release/remove/discard/update/ignore/override the stored RRC non-activated core network assistance information.

According to the described embodiments, the terminal can efficiently receive MBS service data. Hereinafter, hardware and software configurations of a terminal and a base station for performing at least one of the operations of the above-described embodiments will be described. The following terminals and base stations are configured to be able to practice the above embodiments according to any combination.

Fig. 11 is a block diagram illustrating a terminal according to an embodiment.

Referring to fig. 11, a terminal 1100 receiving multicast/broadcast service (MBS) data may include: a receiver 1130 that receives an RRC message from the base station; and a controller 1110 for configuring a data inactivity timer based on the RRC message and starting or restarting the data inactivity timer if an MBS service channel (MTCH) MAC SDU of the MBS is received from the MAC entity.

According to an embodiment, the receiver 1130 may receive higher layer messages from a base station. For example, the higher layer message may be an RRC message. The RRC message may be an RRC connection reconfiguration message or an RRC connection configuration message.

Further, the controller 1110 may configure a data inactivity timer in the terminal based on the data inactivity timer information included in the RRC message. In addition, the controller 1110 may configure MBS radio bearers mapped to MBS sessions in a terminal based on RRC messages. One or more MBS radio bearers may be configured. For example, a data inactivity timer is configured in the MAC entity of the terminal.

In addition, the controller 1110 may control data reception in the MBS session based on the operation of the data inactivity timer. As an example, if a logical channel associated with an MBS session is received while configuring a data inactivity timer, the controller 1110 may start or restart the data inactivity timer of the terminal. In other words, when the MAC entity of the terminal receives the MAC SDU of the MBCH, the controller 1110 may start or restart the data inactivity timer configured in the terminal. As another example, if multicast data for activating a multicast session is received while configuring a data inactivity timer for a terminal in an RRC connected state, the controller 1110 may start or restart the data inactivity timer of the terminal.

If the data inactivity timer expires, the MAC entity of the terminal indicates to a higher layer (RRC layer) that the data inactivity timer expires.

Meanwhile, the base station may configure radio resources associated with the MBS session based on at least one of MBS session state information received from the core network entity, a message for activating the MBS session, and a message for deactivating the MBS session. For example, the base station may receive MBs session state information from a core network entity (e.g., AMF or SMF or MB-SMF). As another example, the base station may receive a message from the core network entity to activate or deactivate the MBS session. Further, the base station may receive indication information for enabling MBS session state change (function), a timer (value) for checking MBS session state change, etc. from the core network entity. The above information may be received through an N2 message.

As described above, the receiver 1130 may receive RRC messages from the base station. For example, when the MBS session status information received by the base station from the core network entity indicates that it is active, the RRC message may include MBS radio bearer configuration information for the MBS session and be transmitted to the terminal. In other words, if the base station receives MBS session state information from the core network entity and the MBS session state information includes a value indicating that it is active, the base station may transmit an RRC message including MBS radio bearer configuration information of the MBS session to the terminal.

Alternatively, the base station may transmit a paging message including an MBS session ID of the RRC idle terminal or the RRC non-active terminal when receiving a message for activating the MBS session or receiving MBS data from the core network entity. For example, the base station may receive a message from the core network entity for activating the MBS session. Alternatively, the base station may receive MBS data from the core network entity. In this case, the base station may transmit a paging message including an MBS session ID of the RRC idle terminal or the RRC non-active terminal. The terminal may receive the paging message, change the RRC state, and continue MBS data reception.

Alternatively, when the MBS session status information indicates that it is inactive, or when a message for deactivating the MBS session is received, the base station may release the radio resource configuration of the inactive MBS session without allocating radio resources for the inactive MBS session. For example, when the MBS session status information indicates that it is inactive or the base station receives a message for deactivating the MBS session, the base station may release the radio resource configuration of the corresponding inactive MBS session. Thus, the base station may not allocate radio resources for MBS sessions indicated as inactive or inactive.

Further, the controller 1110 controls the overall operation of the terminal 1100 according to an operation for receiving MBS data required to perform the above-described embodiments.

The transmitter 1120 and the receiver 1130 are used to transmit or receive signals or messages or data required to perform the above-described embodiments with a base station.

Referring to fig. 12, a base station 1200 controlling multicast/broadcast service (MBS) data may include: a receiver 1230 receiving at least one of MBS session status information, a message for activating an MBS session, and a message for deactivating an MBS session from a core network entity; and a controller 1210 controlling a radio resource configuration associated with the MBS session based on at least one of MBS session status information, a message for activating the MBS session, and a message for deactivating the MBS session.

According to an embodiment, the receiver 1230 may receive MBs session state information from a core network entity (e.g., AMF or SMF or MB-SMF). According to another embodiment, the receiver 1230 may receive a message from a core network entity for activating or deactivating an MBS session. Further, the receiver 1230 may receive indication information for enabling MBS session state change (function), a timer (value) for checking MBS session state change, etc. from the core network entity. The above information may be received through an N2 message.

The controller 1210 controls a radio resource configuration associated with the MBS session based on the message and information received from the core network entity. In addition, the transmitter 1220 may transmit an RRC message or a paging message to the terminal based on the message and information received from the core network entity. To this end, the controller 1210 may perform operations such as configuring MBS radio bearers and configuring radio resources.

When the base station receives a message for activating an MBS session or receives MBS data from a core network entity, the transmitter 1220 may transmit a paging message including an MBS session ID of an RRC idle terminal or an RRC non-active terminal. For example, the receiver 1230 may receive a message for activating an MBS session from a core network entity. Alternatively, the receiver 1230 may receive MBS data from a core network entity. In this case, the transmitter 1220 may transmit a paging message including an MBS session ID of the RRC idle terminal or the RRC non-active terminal. The terminal may receive the paging message, change the RRC state, and continue MBS data reception.

Alternatively, when the MBS session status information indicates that it is inactive, or when the base station receives a message for deactivating the MBS session, the controller 1210 may control the radio resource configuration for releasing the inactive MBS session without allocating radio resources for the inactive MBS session. For example, when the MBS session status information indicates inactive or a message for deactivating the MBS session is received, the controller 1210 may release the radio resource configuration of the corresponding inactive MBS session. Accordingly, the controller 1210 may not allocate radio resources for MBS sessions indicated as inactive or inactive. As described above, the core network entity may be an AMF or an SMF or an MB-SMF.

A terminal receiving an RRC message or a paging message from a base station may control MBS data reception operation.

Further, the controller 1210 controls the overall operation of the base station 1200 according to MBS data transmission operations required to perform the above-described embodiments.

The transmitter 1220 and the receiver 1230 are used to transmit or receive signals or messages or data required to perform the above-described embodiments together with a terminal.

The above-described embodiments may be supported by standard documents disclosed in at least one radio access system such as IEEE 802, 3GPP, and 3GPP 2. That is, in order to clarify the technical idea of the present disclosure, steps, configurations, and components not described in the present embodiment can be supported by the above-described standard documents. In addition, all terms disclosed herein can be described by the above standard documents.

The above embodiments may be implemented by any of various means. For example, the present embodiments may be implemented as hardware, firmware, software, or a combination thereof.

In the case of implementation by hardware, the method according to the present embodiment may be implemented as at least one of an Application Specific Integrated Circuit (ASIC), a Digital Signal Processor (DSP), a Digital Signal Processing Device (DSPD), a Programmable Logic Device (PLD), a Field Programmable Gate Array (FPGA), a processor, a controller, a microcontroller, or a microprocessor.

In the case of implementation by firmware or software, the method according to the present embodiment may be implemented in the form of a device, process or function for performing the above-described functions or operations. The software codes may be stored in memory units and may be driven by processors. The memory unit may be provided inside or outside the processor and may exchange data with the processor by any of various well-known means.

Furthermore, the terms "system," "processor," "controller," "component," "module," "interface," "model," "unit," and the like may generally refer to computer-related physical hardware, a combination of hardware and software, or running software. For example, the components described above may be, but are not limited to being, processes driven by a processor, a controller, a control processor, an entity, a thread of execution, a program, and/or a computer. For example, both an application running in a controller or processor and the controller or processor can be a component. One or more components may be provided in a process and/or thread of execution, and a component may be provided in a single device (e.g., a system, computing device, etc.), or a component may be distributed across two or more devices.

The above-described embodiments of the present disclosure have been described for illustrative purposes only, and it will be appreciated by those skilled in the art that various modifications and changes can be made thereto without departing from the scope and spirit of the present disclosure. Furthermore, the embodiments of the present disclosure are not intended to be limiting, but rather are intended to illustrate the technical concept of the present disclosure, and thus the scope of the technical concept of the present disclosure is not limited by these embodiments. The scope of the present disclosure should be construed in the following manner based on the appended claims: all technical ideas included in the scope equivalent to the claims belong to the present disclosure.

Cross Reference to Related Applications

The present patent application claims priority from korean patent application nos. 10-2021-0033994 and 10-2022-0031952 filed in the korean intellectual property office on day 16 of 2021 and day 15 of 2022, respectively, in 35u.s.c.119 (a), the disclosures of which are incorporated herein by reference in their entireties. This patent application claims priority from other applications filed in other countries, the disclosure of which is also incorporated herein by reference in its entirety.

Claims

1. A method for receiving multicast/broadcast service MBS data by a terminal, the method comprising:

receiving a radio resource control, RRC, message from a base station;

Configuring a data inactivity timer based on the RRC message; and

if the media access control MAC entity receives the MBS service channel MTCH MAC service data unit SDU for MBS, a data inactivity timer is started or restarted.

2. The method of claim 1, wherein the RRC message includes at least one of MBS radio bearer configuration information mapped to an MBS session and the data inactivity timer.

3. The method of claim 1, wherein the base station configures radio resources associated with the MBS session based on at least one of MBS session status information received from a core network entity, a message for activating an MBS session, and a message for deactivating the MBS session.

4. The method of claim 3, wherein the RRC message is received when the MBS session state information indicates that it is active, the RRC message including MBS radio bearer configuration information regarding the MBS session.

5. The method of claim 3, wherein if the base station receives a message for activating the MBS session or the base station receives the MBS data, the base station transmits a paging message including an MBS session ID of an RRC idle terminal or an RRC inactive terminal.

6. The method of claim 3, wherein the base station releases a radio resource configuration of an inactive MBS session when the MBS session status information indicates that it is inactive or the base station receives a message for deactivating the MBS session, and does not allocate radio resources for the inactive MBS session.

7. A method for controlling multicast/broadcast service MBS data by a base station, the method comprising:

receiving at least one of MBS session state information, a message for activating an MBS session and a message for deactivating the MBS session from a core network entity; and

controlling a radio resource configuration associated with the MBS session based on at least one of the MBS session status information, a message for activating the MBS session, and a message for deactivating the MBS session.

8. The method of claim 7, further comprising transmitting an RRC message including MBS radio bearer configuration information of the MBS session to a terminal when the MBS session status information indicates activation.

9. The method of claim 7, further comprising transmitting a paging message including an MBS session ID of an RRC idle terminal or an RRC non-active terminal if a message for activating the MBS session or the MBS data is received from the core network entity.

10. The method of claim 7, wherein the radio resource configuration is controlled, and when the MBS session status information indicates that it is inactive or the base station receives a message for deactivating the MBS session, the radio resource configuration for releasing the inactive MBS session is controlled not to allocate radio resources for the inactive MBS session.

11. A terminal for receiving multicast/broadcast service MBS data, comprising:

a receiver configured to receive a radio resource control, RRC, message from a base station; and

a controller configured to set a data inactivity timer based on the RRC message and to start or restart the data inactivity timer if the MAC entity receives an MBS traffic channel MTCH MAC service data unit SDU for an MBS.

12. The terminal of claim 11, wherein the RRC message includes at least one of MBS radio bearer configuration information mapped to an MBS session and the data inactivity timer.

13. The terminal of claim 11, wherein the base station configures radio resources associated with the MBS session based on at least one of MBS session status information received from a core network entity, a message for activating an MBS session, and a message for deactivating the MBS session.

14. The terminal of claim 13, wherein the RRC message is received when the MBS session state information indicates activation, and includes MBS radio bearer configuration information regarding the MBS session.

15. The terminal of claim 13, wherein the base station transmits a paging message including an MBS session ID of an RRC idle terminal or an RRC inactive terminal if the base station receives a message for activating the MBS session or the base station receives the MBS data.

16. The terminal of claim 13, wherein when the MBS session status information indicates inactivity or the base station receives a message for deactivating the MBS session, the base station releases a radio resource configuration of the inactive MBS session without allocating radio resources for the inactive MBS session.