KR20210104539A - Methods for processing multicast/broadcast service data and apparatuses thereof - Google Patents

Abstract

The present disclosure relates to a technology regarding an operation of processing multicast/broadcast service (MBS) data. In one aspect, the present disclosure provides a method and an apparatus, in a method for a terminal to receive MBS data, wherein the method includes the steps of: receiving, when handover is determined, radio bearer configuration information for receiving MBS session data through a target base station, through a source base station; configuring a radio bearer for receiving MBS session data through the target base station, based on the radio bearer configuration information; and receiving the MBS session data through the radio bearer, wherein the radio bearer configuration information is information which is generated by the target base station and transmitted to the source base station.

Description

Method and apparatus for processing MBS data

The present disclosure relates to an operation for processing MBS data.

Cellular mobile communication networks have been developed mainly to provide end-to-end/point-to-point transmission services, but due to the development of broadband wireless transmission technologies and terminals providing various functions, there is a demand for various services. . In particular, Multimedia Broadcast Multicast Services (MBMS) is a technology that can provide mobile broadcasting services using a cellular mobile communication network. Technology to provide services is being developed.

Unlike end-to-end transmission service, MBMS is an end-to-end/point-to-multipoint transmission service. have. In addition, the MBMS service adopts a multi-cell transmission method in which a plurality of base stations transmit the same packet at the same time, and when this multi-cell transmission method is used, a terminal receiving the service has diversity in the physical layer. ) may be beneficial.

However, in the prior art, it was necessary to configure dedicated entities (e.g. BM-SC, MBMS GW, MCE) with specific functions to provide MBMS. Accordingly, it is difficult to dynamically and flexibly provide unicast transmission and multicast transmission for various multicast/broadcast services.

In addition, in order to receive MBMS service while the connected state terminal moves, there is a problem in that the procedure of setting up a multicast radio bearer must be performed again after a cell change in the handover process.

The present disclosure devised in the above background proposes a technique for flexibly providing a multicast/broadcast service (MBS) based on NR. In addition, the present disclosure proposes a technique in which MBS can be effectively provided even when the terminal moves.

In one aspect, the present disclosure provides a method for a terminal to receive MBS (Multicast/Broadcast Service) data. When handover is determined, radio bearer configuration information for MBS session data reception through a target base station is received through a source base station. and configuring a radio bearer for receiving MBS session data through the target base station based on the steps and radio bearer configuration information, and receiving MBS session data through the radio bearer, wherein the radio bearer configuration information is the target base station It provides a method characterized in that the information is generated and transmitted to the source base station.

In another aspect, the present disclosure provides a method for a target base station to control reception of MBS (Multicast/Broadcast Service) data of a terminal, of MBS session context information for a terminal from a source base station and PDU session context information associated with the MBS session A method comprising the steps of receiving a handover request message including at least one piece of information, generating radio bearer configuration information for receiving MBS session data of the terminal, and transmitting the radio bearer configuration information to a source base station to provide.

In another aspect, the present disclosure provides a receiving unit that receives, through a source base station, radio bearer configuration information for receiving MBS session data through a target base station when handover is determined in a terminal for receiving MBS (Multicast/Broadcast Service) data and a control unit configured to configure a radio bearer for receiving MBS session data through a target base station based on the radio bearer configuration information, wherein the receiving unit further receives MBS session data through the radio bearer, and the radio bearer configuration information is the target It provides a terminal device, characterized in that the information is generated by the base station and transmitted to the source base station.

In another aspect, in the target base station for controlling the reception of Multicast / Broadcast Service (MBS) data of the terminal, the present disclosure provides at least one of MBS session context information for the terminal from the source base station and PDU session context information associated with the MBS session. A target base station device comprising a receiver for receiving a handover request message including one piece of information, a controller for generating radio bearer configuration information for receiving MBS session data of the terminal, and a transmitter for transmitting radio bearer configuration information to a source base station provides

The present disclosure has an effect of flexibly providing a multicast/broadcast service (MBS) based on NR. In addition, the present disclosure can effectively provide the MBS even when the terminal moves.

1 is a diagram schematically illustrating a structure of an NR wireless communication system to which this embodiment can be applied.
2 is a diagram for explaining a frame structure in an NR system to which this embodiment can be applied.
3 is a diagram for explaining a resource grid supported by a radio access technology to which this embodiment can be applied.
4 is a diagram for explaining a bandwidth part supported by a radio access technology to which the present embodiment can be applied.
5 is a diagram exemplarily illustrating a synchronization signal block in a radio access technology to which the present embodiment can be applied.
6 is a diagram for explaining a random access procedure in a radio access technology to which the present embodiment can be applied.
7 is a diagram for explaining CORESET.
8 is a diagram exemplarily illustrating a logical structure in MBMS.
9 is a diagram for explaining a procedure for starting an MBMS session.
10 is a diagram for explaining an operation of a terminal according to an embodiment.
11 is a diagram for explaining an operation of a target base station according to an embodiment.
12 is a diagram illustrating a downlink layer 2 structure in an LTE system.
13 is a diagram exemplarily illustrating MBS radio bearer configuration information according to an embodiment.
14 is a diagram exemplarily illustrating MBS radio bearer configuration information according to another embodiment.
15 is a diagram illustrating a layer 2 structure according to an exemplary embodiment.
16 is a diagram illustrating a terminal configuration according to an embodiment.
17 is a diagram illustrating a configuration of a target base station according to an embodiment.

Hereinafter, some embodiments of the present disclosure will be described in detail with reference to exemplary drawings. In adding reference numerals to components of each drawing, the same components may have the same reference numerals as much as possible even though they are indicated in different drawings. In addition, in describing the present embodiments, if it is determined that a detailed description of a related known configuration or function may obscure the gist of the present technical idea, the detailed description thereof may be omitted. When "includes", "having", "consisting of", etc. mentioned in this specification are used, other parts may be added unless "only" is used. When a component is expressed in a singular, it may include a case in which the plural is included unless otherwise explicitly stated.

In addition, in describing the components of the present disclosure, terms such as first, second, A, B, (a), (b), etc. may be used. These terms are only for distinguishing the elements from other elements, and the essence, order, order, or number of the elements are not limited by the terms.

In the description of the positional relationship of the components, when two or more components are described as being "connected", "coupled" or "connected", the two or more components are directly "connected", "coupled" or "connected" ", but it will be understood that two or more components and other components may be further "interposed" and "connected," "coupled," or "connected." Here, other components may be included in one or more of two or more components that are “connected”, “coupled” or “connected” to each other.

In the description of the temporal flow relation related to the components, the operation method, the manufacturing method, etc., for example, a temporal precedence relationship such as "after", "after", "after", "before", etc. Or, when a flow precedence relationship is described, it may include a case where it is not continuous unless "immediately" or "directly" is used.

On the other hand, when numerical values or corresponding information (eg, level, etc.) for a component are mentioned, even if there is no explicit description, the numerical value or the corresponding information is based on various factors (eg, process factors, internal or external shock, Noise, etc.) may be interpreted as including an error range that may occur.

A wireless communication system in the present specification refers to a system for providing various communication services such as voice and data packets using radio resources, and may include a terminal, a base station, or a core network.

The present embodiments disclosed below may be applied to a wireless communication system using various wireless access technologies. For example, the present embodiments are CDMA (code division multiple access), FDMA (frequency division multiple access), TDMA (time division multiple access), OFDMA (orthogonal frequency division multiple access), SC-FDMA (single carrier frequency division multiple access) Alternatively, it may be applied to various various radio access technologies such as non-orthogonal multiple access (NOMA). In addition, the wireless access technology may mean not only a specific access technology, but also a communication technology for each generation established by various communication consultation organizations such as 3GPP, 3GPP2, WiFi, Bluetooth, IEEE, and ITU. For example, CDMA may be implemented with a radio technology such as universal terrestrial radio access (UTRA) or CDMA2000. TDMA may be implemented with a radio technology such as global system for mobile communications (GSM)/general packet radio service (GPRS)/enhanced datarates for GSM evolution (EDGE). OFDMA may be implemented with a wireless technology such as Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802-20, and evolved UTRA (E-UTRA). IEEE 802.16m is an evolution of IEEE 802.16e, and provides backward compatibility with a system based on IEEE 802.16e. UTRA is part of the universal mobile telecommunications system (UMTS). 3rd generation partnership project (3GPP) long term evolution (LTE) is a part of evolved UMTS (E-UMTS) using evolved-UMTSterrestrial radio access (E-UTRA), and employs OFDMA in downlink and SC- in uplink FDMA is employed. As such, the present embodiments may be applied to currently disclosed or commercialized radio access technologies, or may be applied to radio access technologies currently under development or to be developed in the future.

On the other hand, the terminal in the present specification is a comprehensive concept meaning a device including a wireless communication module for performing communication with a base station in a wireless communication system, WCDMA, LTE, NR, HSPA and IMT-2020 (5G or New Radio), etc. It should be interpreted as a concept including all of UE (User Equipment), MS (Mobile Station), UT (User Terminal), SS (Subscriber Station), wireless device, and the like in GSM. In addition, the terminal may be a user portable device, such as a smart phone, depending on the type of use, and in the V2X communication system may mean a vehicle, a device including a wireless communication module in the vehicle, and the like. In addition, in the case of a machine type communication (Machine Type Communication) system, it may mean an MTC terminal, an M2M terminal, a URLLC terminal, etc. equipped with a communication module to perform machine type communication.

A base station or cell in the present specification refers to an end that communicates with a terminal in terms of a network, a Node-B (Node-B), an evolved Node-B (eNB), gNode-B (gNB), a Low Power Node (LPN), Sector, site, various types of antennas, base transceiver system (BTS), access point, point (eg, transmission point, reception point, transmission/reception point), relay node (Relay Node) ), mega cell, macro cell, micro cell, pico cell, femto cell, RRH (Remote Radio Head), RU (Radio Unit), and small cell (small cell), etc. In addition, the cell may mean including a BWP (Bandwidth Part) in the frequency domain. For example, the serving cell may mean the Activation BWP of the UE.

In the various cells listed above, since there is a base station controlling one or more cells, the base station can be interpreted in two ways. 1) in relation to the radio area, it may be the device itself providing a mega cell, a macro cell, a micro cell, a pico cell, a femto cell, or a small cell, or 2) may indicate the radio area itself. In 1), the devices providing a predetermined radio area are controlled by the same entity, or all devices interacting to form a radio area cooperatively are directed to the base station. A point, a transmission/reception point, a transmission point, a reception point, etc. become an embodiment of a base station according to a configuration method of a wireless area. In 2), the radio area itself in which the signal is received or transmitted from the point of view of the user terminal or the neighboring base station may be indicated to the base station.

In the present specification, a cell is a component carrier having a coverage of a signal transmitted from a transmission/reception point or a coverage of a signal transmitted from a transmission/reception point, and the transmission/reception point itself. can

Uplink (Uplink, UL, or uplink) refers to a method of transmitting and receiving data by the terminal to and from the base station, and downlink (Downlink, DL, or downlink) refers to a method of transmitting and receiving data to and from the terminal by the base station do. A downlink may mean a communication or communication path from a multi-transmission/reception point to a terminal, and an uplink may mean a communication or communication path from the terminal to a multi-transmission/reception point. In this case, in the downlink, the transmitter may be a part of multiple transmission/reception points, and the receiver may be a part of the terminal. Also, in the uplink, the transmitter may be a part of the terminal, and the receiver may be a part of the multi-transmission/reception point.

The uplink and downlink transmit and receive control information through a control channel such as a Physical Downlink Control CHannel (PDCCH), a Physical Uplink Control CHannel (PUCCH), etc., and a Physical Downlink Shared CHannel (PDSCH), a Physical Uplink Shared CHannel (PUSCH), etc. Data is transmitted and received by configuring the same data channel. Hereinafter, a situation in which signals are transmitted and received through channels such as PUCCH, PUSCH, PDCCH and PDSCH may be expressed in the form of 'transmitting and receiving PUCCH, PUSCH, PDCCH and PDSCH'. do.

For clarity of explanation, the present technical idea will be mainly described below for a 3GPP LTE/LTE-A/NR (New RAT) communication system, but the present technical features are not limited to the corresponding communication system.

In 3GPP, after research on 4G (4th-Generation) communication technology, 5G (5th-Generation) communication technology is developed to meet the requirements of ITU-R's next-generation wireless access technology. Specifically, 3GPP develops LTE-A pro, which improves LTE-Advanced technology according to the requirements of ITU-R as a 5G communication technology, and a new NR communication technology separate from 4G communication technology. LTE-A pro and NR both refer to 5G communication technology. Hereinafter, 5G communication technology will be described with a focus on NR unless a specific communication technology is specified.

In the NR operation scenario, various operation scenarios were defined by adding consideration of satellites, automobiles, and new verticals to the existing 4G LTE scenarios. It is deployed in a range and supports the mMTC (Massive Machine Communication) scenario that requires a low data rate and asynchronous connection, and the URLLC (Ultra Reliability and Low Latency) scenario that requires high responsiveness and reliability and supports high-speed mobility. .

To satisfy this scenario, NR discloses a wireless communication system to which a new waveform and frame structure technology, low latency technology, mmWave support technology, and forward compatible technology are applied. In particular, in the NR system, various technical changes are presented in terms of flexibility in order to provide forward compatibility. The main technical features of NR will be described with reference to the drawings below.

<Normal NR system>

1 is a diagram schematically illustrating a structure of an NR system to which this embodiment can be applied.

1, the NR system is divided into a 5G Core Network (5GC) and an NR-RAN part, and the NG-RAN controls the user plane (SDAP/PDCP/RLC/MAC/PHY) and UE (User Equipment) It consists of gNBs and ng-eNBs that provide planar (RRC) protocol termination. The gNB interconnects or gNBs and ng-eNBs are interconnected via an Xn interface. gNB and ng-eNB are each connected to 5GC through the NG interface. 5GC may be configured to include an Access and Mobility Management Function (AMF) in charge of a control plane such as terminal access and mobility control functions, and a User Plane Function (UPF) in charge of a control function for user data. NR includes support for both frequency bands below 6 GHz (FR1, Frequency Range 1) and frequency bands above 6 GHz (FR2, Frequency Range 2).

gNB means a base station that provides NR user plane and control plane protocol termination to a terminal, and ng-eNB means a base station that provides E-UTRA user plane and control plane protocol termination to a terminal. The base station described in this specification should be understood as encompassing gNB and ng-eNB, and may be used as a meaning to refer to gNB or ng-eNB separately if necessary.

<NR Waveform, Pneumologic and Frame Structure>

In NR, a CP-OFDM waveform using a cyclic prefix is used for downlink transmission, and CP-OFDM or DFT-s-OFDM is used for uplink transmission. OFDM technology is easy to combine with MIMO (Multiple Input Multiple Output), and has advantages of using a low-complexity receiver with high frequency efficiency.

Meanwhile, in NR, since the requirements for data rate, delay rate, coverage, etc. are different for each of the three scenarios described above, it is necessary to efficiently satisfy the requirements for each scenario through the frequency band constituting an arbitrary NR system. . To this end, a technique for efficiently multiplexing a plurality of different numerology-based radio resources has been proposed.

Specifically, the NR transmission numerology is determined based on sub-carrier spacing and cyclic prefix (CP), and the μ value is used as an exponential value of 2 based on 15 kHz as shown in Table 1 below. is changed to

μ subcarrier spacing Cyclic prefix Supported for data Supported for synch 0 15 Normal Yes Yes One 30 Normal Yes Yes 2 60 Normal, Extended Yes No 3 120 Normal Yes Yes 4 240 Normal No Yes

As shown in Table 1 above, the NR pneumatology can be divided into five types according to the subcarrier spacing. This is different from that the subcarrier interval of LTE, one of the 4G communication technologies, is fixed at 15 kHz. Specifically, subcarrier intervals used for data transmission in NR are 15, 30, 60, and 120 kHz, and subcarrier intervals used for synchronization signal transmission are 15, 30, 12, 240 kHz. In addition, the extended CP is applied only to the 60khz subcarrier interval. On the other hand, as for the frame structure in NR, a frame having a length of 10 ms is defined, which is composed of 10 subframes having the same length of 1 ms. One frame can be divided into half frames of 5 ms, and each half frame includes 5 subframes. In the case of a 15 kHz subcarrier interval, one subframe consists of one slot, and each slot consists of 14 OFDM symbols. 2 is a diagram for explaining a frame structure in an NR system to which this embodiment can be applied.

Referring to FIG. 2 , a slot is fixedly composed of 14 OFDM symbols in the case of a normal CP, but the length in the time domain of the slot may vary according to the subcarrier interval. For example, in the case of a numerology having a 15 kHz subcarrier interval, the slot is 1 ms in length and is composed of the same length as the subframe. On the other hand, in the case of numerology having a 30 kHz subcarrier interval, a slot consists of 14 OFDM symbols, but two slots may be included in one subframe with a length of 0.5 ms. That is, the subframe and the frame are defined to have a fixed time length, and the slot is defined by the number of symbols, so that the time length may vary according to the subcarrier interval.

On the other hand, NR defines a basic unit of scheduling as a slot, and also introduces a mini-slot (or a sub-slot or a non-slot based schedule) to reduce transmission delay in a radio section. When a wide subcarrier interval is used, the length of one slot is shortened in inverse proportion, so that transmission delay in a radio section can be reduced. The mini-slot (or sub-slot) is for efficient support of the URLLC scenario and can be scheduled in units of 2, 4, or 7 symbols.

Also, unlike LTE, NR defines uplink and downlink resource allocation at a symbol level within one slot. In order to reduce HARQ delay, a slot structure capable of transmitting HARQ ACK/NACK directly within a transmission slot is defined, and this slot structure is named as a self-contained structure and will be described.

NR is designed to support a total of 256 slot formats, of which 62 slot formats are used in 3GPP Rel-15. In addition, a common frame structure constituting an FDD or TDD frame is supported through a combination of various slots. For example, a slot structure in which all symbols of a slot are set to downlink, a slot structure in which all symbols are set to uplink, and a slot structure in which downlink symbols and uplink symbols are combined are supported. In addition, NR supports that data transmission is scheduled to be distributed in one or more slots. Accordingly, the base station may inform the terminal whether the slot is a downlink slot, an uplink slot, or a flexible slot using a slot format indicator (SFI). The base station may indicate the slot format by indicating the index of the table configured through UE-specific RRC signaling using SFI, and may indicate dynamically through Downlink Control Information (DCI) or statically or through RRC. It can also be ordered quasi-statically.

<NR Physical Resources>

In relation to a physical resource in NR, an antenna port, a resource grid, a resource element, a resource block, a bandwidth part, etc. are considered do.

An antenna port is defined such that a channel on which a symbol on an antenna port is carried can be inferred from a channel on which another symbol on the same antenna port is carried. When the large-scale property of a channel carrying a symbol on one antenna port can be inferred from a channel carrying a symbol on another antenna port, the two antenna ports are QC/QCL (quasi co-located or QC/QCL) quasi co-location). Here, the wide range characteristic includes one or more of delay spread, Doppler spread, frequency shift, average received power, and received timing.

3 is a diagram for explaining a resource grid supported by a radio access technology to which this embodiment can be applied.

Referring to FIG. 3 , in the resource grid, since NR supports a plurality of numerologies on the same carrier, a resource grid may exist according to each numerology. In addition, the resource grid may exist according to an antenna port, a subcarrier interval, and a transmission direction.

A resource block consists of 12 subcarriers, and is defined only in the frequency domain. In addition, a resource element is composed of one OFDM symbol and one subcarrier. Accordingly, as in FIG. 3 , the size of one resource block may vary according to the subcarrier interval. In addition, NR defines "Point A" serving as a common reference point for a resource block grid, a common resource block, a virtual resource block, and the like.

4 is a diagram for explaining a bandwidth part supported by a radio access technology to which the present embodiment can be applied.

In NR, unlike LTE in which the carrier bandwidth is fixed at 20Mhz, the maximum carrier bandwidth is set from 50Mhz to 400Mhz for each subcarrier interval. Therefore, it is not assumed that all terminals use all of these carrier bandwidths. Accordingly, in NR, as shown in FIG. 4 , a bandwidth part (BWP) may be designated within the carrier bandwidth and used by the terminal. In addition, the bandwidth part is associated with one numerology and is composed of a subset of continuous common resource blocks, and may be dynamically activated according to time. A maximum of four bandwidth parts are configured in the terminal, respectively, in uplink and downlink, and data is transmitted/received using the activated bandwidth part at a given time.

In the case of a paired spectrum, the uplink and downlink bandwidth parts are set independently, and in the case of an unpaired spectrum, to prevent unnecessary frequency re-tunning between downlink and uplink operations For this purpose, the downlink and uplink bandwidth parts are set in pairs to share a center frequency.

<NR Initial Connection>

In NR, the terminal accesses the base station and performs a cell search and random access procedure in order to perform communication.

Cell search is a procedure in which the UE synchronizes the cell of the corresponding base station using a synchronization signal block (SSB) transmitted by the base station, obtains a physical layer cell ID, and obtains system information.

5 is a diagram exemplarily illustrating a synchronization signal block in a radio access technology to which the present embodiment can be applied.

Referring to FIG. 5, the SSB consists of a primary synchronization signal (PSS) and a secondary synchronization signal (SSS) occupying 1 symbol and 127 subcarriers, respectively, and a PBCH spanning 3 OFDM symbols and 240 subcarriers.

The UE receives the SSB by monitoring the SSB in the time and frequency domains.

SSB can be transmitted up to 64 times in 5ms. A plurality of SSBs are transmitted using different transmission beams within 5 ms, and the UE performs detection on the assumption that SSBs are transmitted every 20 ms when viewed based on one specific beam used for transmission. The number of beams that can be used for SSB transmission within 5 ms time may increase as the frequency band increases. For example, up to 4 SSB beams can be transmitted in 3 GHz or less, and SSB can be transmitted using up to 8 different beams in a frequency band of 3 to 6 GHz and up to 64 different beams in a frequency band of 6 GHz or more.

Two SSBs are included in one slot, and the start symbol and the number of repetitions within the slot are determined according to the subcarrier interval as follows.

On the other hand, the SSB is not transmitted at the center frequency of the carrier bandwidth, unlike the SS of the conventional LTE. That is, the SSB may be transmitted in a place other than the center of the system band, and a plurality of SSBs may be transmitted in the frequency domain when wideband operation is supported. Accordingly, the UE monitors the SSB using a synchronization raster, which is a candidate frequency location for monitoring the SSB. The carrier raster and synchronization raster, which are the center frequency location information of the channel for initial access, are newly defined in NR, and the synchronization raster has a wider frequency interval than the carrier raster, so that the terminal can support fast SSB search. can

The UE may acquire the MIB through the PBCH of the SSB. MIB (Master Information Block) includes minimum information for the terminal to receive the remaining system information (RMSI, Remaining Minimum System Information) broadcast by the network. In addition, the PBCH includes information on the position of the first DM-RS symbol in the time domain, information for the UE to monitor SIB1 (eg, SIB1 neurology information, information related to SIB1 CORESET, search space information, PDCCH related parameter information), offset information between the common resource block and the SSB (the position of the absolute SSB in the carrier is transmitted through SIB1), and the like. Here, the SIB1 neurology information is equally applied to some messages used in the random access procedure for accessing the base station after the UE completes the cell search procedure. For example, the neurology information of SIB1 may be applied to at least one of messages 1 to 4 for the random access procedure.

The aforementioned RMSI may mean System Information Block 1 (SIB1), and SIB1 is periodically broadcast (eg, 160 ms) in the cell. SIB1 includes information necessary for the UE to perform an initial random access procedure, and is periodically transmitted through the PDSCH. In order for the UE to receive SIB1, it must receive neurology information used for SIB1 transmission and CORESET (Control Resource Set) information used for scheduling SIB1 through the PBCH. The UE checks scheduling information for SIB1 by using SI-RNTI in CORESET, and acquires SIB1 on PDSCH according to the scheduling information. SIBs other than SIB1 may be transmitted periodically or may be transmitted according to the request of the terminal.

6 is a diagram for explaining a random access procedure in a radio access technology to which the present embodiment can be applied.

Referring to FIG. 6 , upon completion of cell search, the terminal transmits a random access preamble for random access to the base station. The random access preamble is transmitted through the PRACH. Specifically, the random access preamble is transmitted to the base station through a PRACH consisting of continuous radio resources in a specific slot that is periodically repeated. In general, when a UE initially accesses a cell, a contention-based random access procedure is performed, and when performing random access for beam failure recovery (BFR), a contention-free random access procedure is performed.

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), a UL grant (uplink radio resource), a temporary C-RNTI (Temporary Cell - Radio Network Temporary Identifier), and a Time Alignment Command (TAC). Since one random access response may include random access response information for one or more terminals, the random access preamble identifier may be included to inform which terminal the included UL Grant, temporary C-RNTI, and TAC are valid. The random access preamble identifier may be an identifier for the random access preamble received by the base station. The TAC may be included as information for the UE to adjust uplink synchronization. The random access response may be indicated by a random access identifier on the PDCCH, that is, RA-RNTI (Random Access - Radio Network Temporary Identifier).

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 UE applies the TAC and stores the temporary C-RNTI. In addition, data stored in the buffer of the terminal or newly generated data is transmitted to the base station by using the UL grant. In this case, information for identifying the terminal should be included.

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

<NR CORESET>

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

In this way, NR introduced the concept of CORESET in order to secure the flexibility of the system. CORESET (Control Resource Set) means a time-frequency resource for a downlink control signal. The UE may decode the control channel candidates by using one or more search spaces in the CORESET time-frequency resource. Quasi CoLocation (QCL) assumptions for each CORESET are set, and this is used for the purpose of notifying the characteristics of the analog beam direction in addition to the delay spread, Doppler spread, Doppler shift, and average delay, which are characteristics assumed by the conventional QCL.

7 is a diagram for explaining CORESET.

Referring to FIG. 7 , CORESET may exist in various forms within a carrier bandwidth within one slot, and CORESET may consist of up to three OFDM symbols in the time domain. In addition, CORESET is defined as a multiple of 6 resource blocks up to the carrier bandwidth in the frequency domain.

The first CORESET is indicated through the MIB as part of the initial bandwidth part configuration to receive additional configuration information and system information from the network. 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 this specification, frequencies, frames, subframes, resources, resource blocks, regions, bands, subbands, control channels, data channels, synchronization signals, various reference signals, various signals or various messages related to NR (New Radio) can be interpreted in various meanings used in the past or present or used in the future.

New Radio (NR)

As described above, NR conducted in 3GPP recently has been designed to satisfy various QoS requirements required for each segmented and detailed usage scenario as well as an improved data rate compared to LTE. In particular, eMBB (enhancement Mobile BroadBand), mMTC (massive MTC), and URLLC (Ultra Reliable and Low Latency Communications) were defined as representative usage scenarios of NR. flexible) frame structure design is required. Each usage scenario has different requirements for data rates, latency, reliability, coverage, etc. Accordingly, as a method for efficiently satisfying the requirements for each usage scenario through the frequency band constituting an arbitrary NR system, different numerology (eg subcarrier spacing, subframe, TTI, etc.) based radio resource unit ( unit) is designed to multiplex efficiently.

For example, for numerology with different subcarrier spacing values, a discussion is made on how to support multiplexing based on TDM, FDM, or TDM/FDM through one or multiple NR component carrier(s). lost. In addition, in configuring a scheduling unit in the time domain, a discussion has been made on a method of supporting one or more time units. In this regard, in NR, a subframe is defined as a type of time domain structure. As a reference numerology for defining the subframe duration, it was decided to define a single subframe duration composed of 14 OFDM symbols of the same 15 kHz Sub-Carrier Spacing (SCS)-based normal CP overhead as that of LTE. Accordingly, in NR, a subframe has a time duration of 1 ms. However, unlike LTE, the NR subframe is an absolute reference time duration, and slots and mini-slots may be defined as time units that are the basis of actual uplink/downlink data scheduling. In this case, the number of OFDM symbols constituting the slot, the y value, is determined to have a value of y=14 regardless of the SCS value in the case of normal CP.

Accordingly, an arbitrary slot consists of 14 symbols. In addition, all symbols may be used for DL transmission, or all symbols may be used for UL transmission, or may be used in the form of DL portion + (gap) + UL portion according to the transmission direction of the slot. have.

In addition, in any numerology (or SCS), a mini-slot composed of fewer symbols than the aforementioned slot is defined. A short time-domain scheduling interval for mini-slot-based uplink/downlink data transmission/reception may be configured, or a long time-domain scheduling interval for uplink/downlink data transmission/reception through slot aggregation may be configured. have. In particular, in the case of transmitting and receiving latency-sensitive data such as URLLC, it is difficult to satisfy the latency requirement if 1ms (14 symbols)-based slot-based scheduling defined in a numerology-based frame structure with a small SCS value such as 15kHz is performed. can Accordingly, scheduling that can satisfy the requirements of URLLC can be performed based on defining a mini-slot composed of fewer OFDM symbols than a slot composed of 14 symbols.

MBMS (Multimedia Broadcast Multicast Service) in LTE network

3GPP, which develops mobile communication standards, has developed LTE broadcast/multicast standards for video broadcasting from Rel-9. Since then, standards have been standardized to support other services such as public safety, IoT, and V2X in LTE. For NR, which is currently standardized, Rel-15 and Rel-16 standards do not support MBMS. It is judged that MBMS-related standards need to be further developed in the NR standards of future releases.

On the other hand, the conventional MBMS based on LTE provided two transmission schemes, a Multimedia Broadcast multicast service Single Frequency Network (MBSFN) transmission scheme and a Single Cell Point To Multipoint (SC-PTM) transmission scheme.

The MBSFN transmission method is suitable for providing media broadcasting in a large pre-planned area (MBSFN area). The MBSFN area is statically configured. Organized by O&M, for example. And it cannot be dynamically adjusted according to the user distribution. Synchronized MBMS transmission is provided within the MBSFN area, and aggregation is supported for MBMS transmission from multiple cells. Each MCH scheduling is performed by a multi-cell/multicast coordination entity (MCE), and a single transport block is used for each TTI for MCH transmission. In addition, all MCH transport blocks use MBSFN resources in their subframes. MTCH and MCCH may be multiplexed on the same MCH. MTCH and MCCH use RLC-UM mode. Even if all radio resources are not used in the frequency domain, unicast and multiplexing are not allowed in the same subframe. As such, the MBSFN transmission method is difficult to dynamically adjust, making it difficult to flexibly apply to small-scale broadcasting services.

The SC-PTM transmission method was developed as a method to improve the inefficiency of the MBSFN transmission method. MBMS is transmitted within single cell coverage. One SC-MCCH and one or more SC-MTCH(s) are mapped to the DL-SCH. Scheduling is provided by the base station. SC-MCCH and SC-MTCH are each indicated by one logical channel specific RNTI (SC-RNTI, G-RNTI) on the PDCCH. SC-MTCH and SC-MCCH use RLC-UM mode. A single transmission is used for the DL-SCH to which the SC-MCCH and the SC-MTCH are mapped, but blind HARQ repetition or RLC repetition is not provided. Therefore, SC-PTM transmission was difficult to provide reliable transmission.

A logical structure as shown in FIG. 8 may be used to provide MBMS through the above-described transmission methods.

8 is a diagram exemplarily illustrating a logical structure in MBMS.

Referring to FIG. 8 , each entity performs the following functions.

GCS AS entity

- Perform signaling exchange (eg, service announcement) related to terminal and GCS session and group management aspects.

- Receive uplink data from the terminal through unicast.

- Data transmission to terminals belonging to one group using unicast forwarding and/or multicast forwarding.

BM-SC entity

- Acts as a source of MBMS transmission, and starts or stops transmission of a session for the MBMS bearer service through MBMS session control signaling.

MBMS GW entity

- The sending/broadcasting of MBMS packets to each eNB transmitting the service.

- The MBMS GW uses IP Multicast as a means of forwarding MBMS user data to the eNB (The MBMS GW uses IP Multicast as the means of forwarding MBMS user data to the eNB).

- MBMS GW performs MBMS Session Control Signaling (Session start / update / stop) for E-UTRAN through MME (The MBMS GW performs MBMS Session Control Signaling (Session start/update/stop) towards the E-UTRAN via MME).

Multi-cell/multicast Coordination Entity (MCE) entity

- The admission control and the allocation of the radio resources used by all eNBs in the MBSFN area for multi-cell MBMS transmissions using MBSFN operation).

- The MCE does not establish a radio bearer of a new MBMS service(s) if the radio resources are not sufficient for the corresponding MBMS service(s) or if radio resources can be preempted from other radio bearer(s) of the MBMS service in progress according to ARP. The MCE decides not to establish the radio bearer(s) of the new MBMS service(s) if the radio resources are not sufficient for the corresponding MBMS service(s) or may pre-empt radio resources from other radio bearer (s) of ongoing MBMS service(s) according to ARP).

- This determines additional details of the radio configuration in addition to the allocation of time/frequency radio resources. For example, besides allocation of the time/ frequency radio resources this also includes deciding the further details of the radio configuration e.g. the modulation and coding scheme.

- Determining whether to use SC-PTM or MBSFN (deciding on whether to use SC-PTM or MBSFN).

- Counting and acquisition of counting results for MBMS service(s).

- For example, resumption of MBMS session(s) within MBSFN area(s) based on eg the ARP and/ or the counting results for the corresponding MBMS service(s)).

- For example, suspension of MBMS session(s) within MBSFN area(s) within MBSFN area(s) based eg the ARP based on the calculation result for ARP and/or corresponding MBMS service(s) and/or on the counting results for the corresponding MBMS service(s)).

9 is a diagram for explaining a procedure for starting an MBMS session.

Referring to FIG. 9 , an MBMS session is initiated through step 9 .

1. The MME transmits the MBMS session start request message to the MCE(s) controlling the eNB in the target MBMS service area. This message contains the IP multicast address, session properties and the minimum time to wait before passing the first data, and if possible a list of cell IDs (The MME sends MBMS session start request message to the MCE(s) controlling eNBs in the The message includes the IP multicast address, session attributes and the minimum time to wait before the first data delivery, and includes the list of cell identities if available).

2. The MCE decides whether to use SC-PTM or MBSFN to carry the MBMS bearer over the air interface.

The MCE confirms the reception of the MBMS session start request to the MME. This message can be sent before step 4. In SC-PTM operation, the MCE only confirms the reception of the MBMS session start request to the MME after the MME receives at least one confirmation from the eNB(s) (ie, step 4) (The MCE confirms the reception of the MBMS Session) This message can be transmitted before the step 4. In SC-PTM operation, the MCE only confirms the reception of the MBMS Session Start request to the MME, after the MCE receives at least one confirmation from the eNB( s) (ie Step 4)).

3. In SC-PTM operation, the MCE includes the SC-PTM information in the MBMS Session Start Request message sent to the corresponding eNB (In SC-PTM operation, the MCE includes the SC-PTM information, in the MBMS Session Start Request message to the relevant eNBs).

4. In SC-PTM operation, the eNB checks whether radio resources are sufficient to establish new MBMS service(s) in the area it controls. Otherwise, the eNB may decide not to establish a radio bearer of MBMS service(s) or may preempt radio resources from other radio bearer(s) according to ARP. The eNB confirms reception of the MBMS session start message (In SC-PTM operation, the eNB checks whether the radio resources are sufficient for the establishment of new MBMS service(s) in the area it controls. If not, eNB decides not to establish the radio bearers of the MBMS service(s), or may pre-empt radio resources from other radio bearer(s) according to ARP. eNB confirms the reception of the MBMS Session Start message).

Step 5 and 6 are only applicable to MBSFN operation.

5. The MCE transmits the MBMS scheduling information message including the updated MCCH information carrying the configuration information of the MBMS service to the eNB. This message can be transmitted before step 3 (MCE sends the MBMS Scheduling Information message to the eNB including the updated MCCH information which carries the MBMS service's configuration information. This message can be transmitted before the step 3).

6. The eNB confirms the reception of the MBMS Scheduling Information message.

7. eNB notifies MBMS session start to UE through MCCH change notification and updated MCCH information delivering configuration information of MBMS service (eNB indicates MBMS session start to UEs by MCCH change notification and updated MCCH information which carries the MBMS service's configuration information).

8. The eNB joins the IP multicast group to receive the MBMS User Plane data.

9. eNB sends the MBMS data to radio interface.

In order to provide MBMS like this, a complex control procedure was required between the core network entities and the wireless network. For example, a separate MCE entity for controlling a base station within a target MBMS service area had to perform an operation of determining a transmission method among the MBSFN method and the SC-PTM method and performing scheduling. Accordingly, it is difficult to dynamically turn on/off MBMS transmission directly for a cell associated with a specific base station. For example, even when there is only one UE receiving data through MBMS transmission in a specific cell, data must be transmitted inefficiently through MBMS transmission.

Method of providing service continuity of connected state terminal in LTE network

Radio bearer (eg MBMS radio bearer, SC-PTM radio bearer) setup / setup procedure for receiving MBMS data in LTE network is, for example, when starting an MBMS session (upon start of the MBMS session, upon (re-)entry) of the corresponding MBSFN service area, upon entering a cell providing via SC-MRB a MBMS service in which the UE has interest, upon becoming interested in the MBMS service, upon removal of UE capability limitations inhibiting reception of the concerned service) may be disclosed, and may be applied through system information/MCCH/SC-MCCH message reception.

Accordingly, when the connected state terminal moves, a procedure for controlling the handover of the terminal in relation to MBMS reception is unnecessary. However, the RRC connection state terminal interested in receiving the MBMS service in the LTE network informs the network of the MBMS interest information through the RRC message. When handover occurs according to the movement of the UE in the RRC connection state, the source BS transmits the MBMS interest information of the UE to the target BS in the handover preparation process.

(In RRC_CONNECTED, the UE that is receiving or interested to receive MBMS via MBSFN or SC-PTM informs the network about its MBMS interest via a RRC message and the network does its best to ensure that the UE is able to receive MBMS and unicast services subject to the UE's capabilities:

- the UE indicates the frequencies which provide the service(s) that the UE is receiving or is interested to receive simultaneously, and which can be received simultaneously in accordance with the UE capabilities.

- if the PCell broadcasts SystemInformationBlockType20 , the UE also indicates the list of services that the UE is receiving or is interested to receive on the indicated frequencies.

- the UE indicates its MBMS interest at RRC connection establishment (the UE does not need to wait until AS security is activated), and whenever the set of frequencies on which the UE is interested in receiving MBMS services has changed compared with the last indication sent to the network (eg due to a change of user interest or of service availability), and whenever the list of MBMS services that the UE is interested in receiving has changed compared with the last indication sent to the network.

- the UE may only indicate its interest when the PCell provides SystemInformationBlockType15 and after having acquired SystemInformationBlockType15 of the current PCell.

- the UE may indicate its MBMS interest even if the current configured serving cell(s) do not prevent it from receiving the MBMS services it is interested in.

- for handover preparation, the source eNB transfers the MBMS interest of the UE, if available, to the target eNB. After handover, the UE reads SystemInformationBlockType15 before updating its MBMS interest. If SystemInformationBlockType15 is provided on the target cell but not on the source cell, the UE indicates its MBMS interest after handover.)

As described above, in the prior art, since it was necessary to configure dedicated entities (eg BM-SC, MBMS GW, MCE) with specific functions to provide MBMS service, unicast transmission and multicast transmission for various multicast/broadcast services It was difficult to dynamically and flexibly provide Accordingly, in order for the connected state terminal to receive the corresponding service, it was necessary to perform the procedure of setting the multicast radio bearer again after changing the cell during the handover process.

The present disclosure devised to solve the above problems provides a method and apparatus for flexibly controlling various NR-based multicast/broadcast services. In particular, a method and apparatus for effectively controlling handover when a terminal receiving data through unicast moves to a cell providing an MBS service is proposed.

Hereinafter, a method for providing a multicast/broadcast service (hereinafter referred to as MBS: Multicast/Broadcast Service) and a handover method based on NR radio access technology according to the present embodiment will be described. However, this is for convenience of description and the present embodiment may be applied to any radio access technology. In this specification, information elements and operations specified in TS 38.331, which is a 3GPP NR RRC standard, are included, and detailed descriptions related thereto are omitted. Therefore, even if the terminal operation content related to the detailed definition of the corresponding information element is not included in the present specification, the corresponding content specified in the standard may be included and understood in this embodiment.

The MBS service providing method according to this embodiment is not only a large-scale broadcast service provided through a single frequency network (SFN), but also V2X, public safety, IoT service, software upgrade provided through one or more cells, It can be applied to any service such as file transfer.

The examples provided below may be applied individually or by selectively combining any method.

10 is a diagram for explaining an operation of a terminal according to an embodiment.

Referring to FIG. 10, the method for the terminal to receive MBS (Multicast/Broadcast Service) data is a step of receiving, through a source base station, radio bearer configuration information for MBS session data reception through a target base station when handover is determined. may be included (S1010). For example, the radio bearer configuration information may be information generated by the target base station and transmitted to the source base station.

Meanwhile, the source base station may transmit a handover request message to the target base station. The handover request message may be of various types. For example, it may be a handover preparation request message or the like. For example, the handover request message may include at least one of MBS session context information and PDU session context information associated with the MBS session.

The target base station checks whether the corresponding MBS session context is configured in the target base station using the information received from the source base station.

For example, when the MBS session context for MBS session data is not configured, the target base station transmits a message for requesting MBS session setup/setup to the core network AMF (Access and Mobility Management Function) entity. Then, the target base station receives a message for starting the MBS session from the AMF entity. Through this, the target base station can generate radio bearer configuration information. For example, the corresponding radio bearer may be a point-to-multipoint radio bearer for MBS data.

As another example, if the MBS session context for MBS session data is not configured, the target base station may generate radio bearer configuration information by using PDU session context information associated with the MBS session for MBS session data. For example, the corresponding radio bearer may be a point-to-point radio bearer for MBS data.

In addition, the target base station may determine a transmission type for MBS session data. In addition, the target base station may transmit a path switch request message for requesting a path change of MBS session data to the core network AMF (Access and Mobility Management Function) entity. For example, the path switch request message may include MBS session context information.

The method for the terminal to receive MBS (Multicast/Broadcast Service) data may include configuring a radio bearer for receiving MBS session data through a target base station based on radio bearer configuration information (S1020). When the terminal receives radio bearer configuration information from the source base station, it configures it in the terminal.

A method for the terminal to receive MBS (Multicast/Broadcast Service) data may include receiving MBS session data through a radio bearer (S1030).

For example, the UE may receive MBS session data through a radio bearer mapped with the MBS session. For example, the radio bearer and the MBS session associated with MBS session data transmission may be mapped 1:N. As another example, the radio bearer and the MBS session associated with MBS session data transmission may be configured by N:1 mapping. Here, N is a natural number greater than or equal to 1. That is, one radio bearer and a plurality of MBS sessions may be mapped, and conversely, one MBS session and a plurality of radio bearers may be mapped. Of course, the radio bearer and the MBS session may be mapped 1:1. For example, the radio bearer and MBS session mapping information may be included in the aforementioned radio bearer configuration information.

Through this operation, the terminal may receive MBS session data through the source base station and the target base station. In addition, there is no need to perform an operation for setting up an unnecessary MBS session.

Hereinafter, the operation from the viewpoint of the target base station with respect to the above-described operation will be described.

11 is a diagram for explaining an operation of a target base station according to an embodiment.

Referring to FIG. 11, the method for the target base station to control the reception of MBS (Multicast/Broadcast Service) data of the terminal is at least one of MBS session context information for the terminal from the source base station and PDU session context information associated with the MBS session. It may include the step of receiving a handover request message including the information (S1110).

The target base station may receive a handover request message from the source base station. The handover request message may be of various types. For example, it may be a handover preparation request message or the like. For example, the handover preparation request message may include at least one of MBS session context information and PDU session context information associated with the MBS session.

The target base station checks whether the corresponding MBS session context is configured in the target base station using the information received from the source base station.

The method by which the target base station controls the reception of multicast/broadcast service (MBS) data of the terminal may include generating radio bearer configuration information for the reception of MBS session data of the terminal (S1120).

As an example, in the step of generating radio bearer configuration information, if the MBS session context for MBS session data is not configured in the target base station, the core network AMF (Access and Mobility Management Function) entity for requesting the MBS session setup. The method may further include transmitting a message and receiving a message for starting the MBS session from the AMF entity. For example, the corresponding radio bearer may be a point-to-multipoint radio bearer for MBS data.

As another example, in the step of generating the radio bearer configuration information, when the MBS session context for the MBS session data is not configured in the target base station, the radio bearer is configured using the PDU session context information associated with the MBS session for the MBS session data. information can be generated. For example, the corresponding radio bearer may be a point-to-point radio bearer for MBS data.

As another example, generating the radio bearer configuration information may determine a transmission type for MBS session data.

The method by which the target base station controls the reception of multicast/broadcast service (MBS) data of the terminal may include transmitting radio bearer configuration information to the source base station (S1130).

For example, the radio bearer and the MBS session associated with MBS session data transmission may be mapped 1:N. As another example, the radio bearer and the MBS session associated with MBS session data transmission may be configured by N:1 mapping. Here, N is a natural number greater than or equal to 1. That is, one radio bearer and a plurality of MBS sessions may be mapped, and conversely, one MBS session and a plurality of radio bearers may be mapped. Of course, the radio bearer and the MBS session may be mapped 1:1. For example, the radio bearer and MBS session mapping information may be included in the aforementioned radio bearer configuration information.

In addition, the method for the target base station to control the reception of MBS (Multicast/Broadcast Service) data of the terminal includes transmitting a path switch request message for requesting a path change of the MBS session data to the core network AMF (Access and Mobility Management Function) object. may further include. For example, the path switch request message may include MBS session context information.

Through the above operation, the target base station can efficiently provide the MBS session data received by the handover target terminal.

Hereinafter, the operations of the aforementioned terminal, target base station, and source base station will be described in more detail. In addition, an embodiment of transmitting and receiving MBS session data between the source base station and the terminal will be described in detail. Each of the embodiments described below may be performed at specific stages of the aforementioned terminal, target base station, and source base station. Alternatively, some of the above-described steps may be separated or added as a separate step and performed. Meanwhile, each of the embodiments described below may be combined and performed in any combination.

An embodiment of transferring MBS session context information from a source base station to a target base station when the terminal moves from a unicast transmission cell to a multicast/broadcast transmission cell

In order to transmit MBS data (e.g. media, video, software downloading etc.), an MBS session must be established between the terminal and the core network entity. For convenience of explanation, the session between the multicast/broadcast receiving terminal and the UPF (or any MBS user plane function having an application function and interface for an external network MBS application server or an internal network MBS service) is denoted as an MBS session. . This is for convenience of description and may be replaced with any term meaning a multicast/broadcast session between the UE and the UPF. In addition, data through the MBS session will be described and described as MBS data or MBS session data.

The MBS session may be a one-way session dedicated to the downlink. Alternatively, the MBS session may be added with an uplink session (or a bidirectional session) associated with the downlink session. Alternatively, a unicast session (e.g. PDU session) associated with the downlink session may be added to the MBS session. The MBS session may be requested and established by terminal initiation or network initiation.

MBS data may be transmitted transparently through the 5G system (5GS). This is because it is desirable to support MBS by recycling the existing structure of the 5G system as much as possible. For this, the (MBS) application server of the external network can perform signaling with the control plane entity (e.g. AMF, SMF) of the 5G core network through the Network Exposure Function (NEF) (or PCF). Or as an entity/Function to provide an application function (AF: Application function) of the core network (for MBS service) or an MBS function of the core network (service center or application server for MBS and a signaling function to support it) For convenience, the MBS Service Function is denoted (which may be replaced by another name.) can perform signaling with the control plane entities (eg AMF, SMF) of the 5G core network through the Policy Control Function (PCF).

The application server of the external network can transmit MBS data to the base station through UPF (or MBS UPF). Alternatively, the application function (AF) of the core network or the MBS function of the core network may transmit MBS data to the base station through the UPF (or MBS UPF).

In providing the MBS service, as the number of users receiving the corresponding MBS session within one cell coverage increases, the transmission efficiency of multicast/broadcast delivery of the MBS session increases. On the other hand, if there are few users receiving the corresponding MBS session within the cell coverage, the multicast/broadcast delivery has lower transmission efficiency compared to the unicast transmission. That is, the MBS session has lower wireless transmission efficiency compared to unicast-based transmission in order to support data reception of multiple users. In consideration of these points, for one MBS service, it is necessary to transmit MBS data in a multicast/broadcast method in one cell and transmit MBS data in a unicast method in another cell. A method of transmitting MBS data will be described later.

When the terminal in the RRC connection state is receiving MBS data in a unicast manner in one cell, a cell change may occur according to the movement of the corresponding terminal. In this case, the target cell to which the terminal is handed over may be transmitting the corresponding MBS data in a multicast/broadcast manner. In this situation, it is necessary to coordinate between the source base station and the target base station in order to minimize service interruption for the MBS data being received.

For example, the source base station transmits a handover request message or a handover preparation information message (HandoverPreparationInformation RRC container, inter-node RRC message) included in the handover request message for the MBS session that the terminal is receiving in a unicast manner. information may be transmitted. For convenience of explanation, information about the MBS session that the terminal is receiving is indicated as MBS context information. This is for convenience of description and may be replaced with any other terminology.

MBS context information includes MBS session information, QoS flow information included in the corresponding MBS session, Transport Network Layer (TNL) information, the corresponding MBS data transmission/cast type in the corresponding base station/cell associated with the corresponding base station, the corresponding cell identification information, It may include one or more information among the corresponding base station identification information, the terminal identification information receiving the corresponding MBS data, one multicast address (eg IP multicast address), and the number of terminal(s) that have joined the corresponding MBS session. MBS session information includes at least one of MBS service ID, MBS session ID, TMGI, session-ID, IP multicast address, slice information (eg S-NSSAI) associated with the corresponding MBS session, MBS service area identifier, and MBS service cell identification information. may contain information. QoS flow information includes QoS information for the corresponding MBS session (eg 5QI/QCI, QoS flow Identifier, GBR QoS flow information (Maximum Flow Bit Rate, Guaranteed Flow Bit Rate, Maximum Packet Loss Rate), Allocation and Retention Priority, Priority Level Packet It may include one or more of Delay Budget and Packet Error Rate TNL information may include one of IP multicast address, IP source address and GTP DL TEID The identification information of the terminal receiving the corresponding MBS data is C- It may be at least one of RNTI, 5G-S-TMSI, I-RNTI, Subscription Concealed Identifier (SUCI)/Subscription Permarnent Identifier (SUPI), and 5G-GUTI.

As an example, the MBS context information may be classified using information for identifying the MBS session (e.g. MBS session information). As another example, MBS context information may be allocated as information to be distinguished from information for identifying an MBS session. The MBS context information may be associated with information for identifying an MBS session. For example, MBS context identification information may be allocated by a base station or one of UPF or AMF/SMF.

As another example, if MBS context information is included in the handover preparation information message, it will be defined as a new information element distinct from the information element (eg AS-Config, AS-Contex) included in the conventional handover preparation information message. can Alternatively, the MBS context information may be included in an AS configuration information element or an AS context information element included in the conventional handover preparation information message.

One or more of the above-described information may be directly included in the handover request message as an information element, and other one or more pieces of information may be included in the handover preparation information message. That is, the above-described information may be divided and included in two or more messages.

Of course, the above-described embodiment can also be applied when moving from a unicast transmission cell to a unicast transmission cell. For example, when a terminal in an RRC connection state is receiving MBS data in a unicast manner in one cell, a cell change may occur according to the movement of the corresponding terminal. At this time, the target cell to which the terminal is handed over may also be in a state in which multicast/broadcast transmission is not performed for the corresponding MBS session. Even in this case, the above-described embodiment may be applied.

On the other hand, through coordination between base stations, a multicast/broadcast (point-to-multipoint) radio bearer for a specific MBS session can be mapped to a unicast (point-to-point) radio bearer to the terminal and configured. Through this, the UE may receive data for the corresponding MBS session at a specific time (or after a specific time) through the unicast radio bearer. At a specific point in time, an RRC message including a handover command is received, random access is initiated to the target base station (Msg1/MsgA transmission), random first/initial uplink transmission to the target base station, successful random access to the target base station, the source cell is released, It may be one of the time points of applying/setting/reconfiguring/completing any L2 entity/configuration to the target cell and completing the handover.

An embodiment in which the target base station transmits whether multicast/broadcast transmission, etc. for the corresponding MBS session to the source base station

The target base station prepares handover having an L1/L2 configuration. The target base station may perform admission control on the received MBS session/MBS context. The target base station may transmit whether to transmit multicast/broadcast for the corresponding MBS session to the source base station. Alternatively, information for indicating that an arbitrary function (e.g. source cell maintenance) for reducing service interruption for the corresponding MBS session has been applied may be transmitted.

For example, the target base station may determine whether to accept the transmission in any transmission method/cast type (e.g. multicast/broadcast transmission, unicast transmission) for the corresponding MBS session requested by the source base station for the corresponding terminal. As another example, the target base station may directly determine the transmission method/cast type (e.g. multicast/broadcast transmission, unicast transmission) for the corresponding MBS session requested by the source base station for the corresponding terminal. As another example, the target base station may indicate to the source base station the transmission method/cast type for the corresponding MBS session requested by the source base station for the corresponding terminal. As another example, if the target base station is performing multicast/broadcast transmission for the corresponding MBS session, it may indicate to the source base station that multicast/broadcast transmission is being performed for the corresponding MBS session.

As another example, the target base station may transmit the accepted MBS session resource information (MBS Session Resource Admitted List) to the source base station. The corresponding information may include at least one of MBS session identification information, MBS session context information, TNL information, accepted QoS flow information, and target base station data forwarding information (e.g. DL data forwarding GTP-TEID). As another example, the corresponding information may be transmitted from the target base station to the source base station through a HANDOVER REQUEST ACKNOWLEDGE message. For example, the above-described MBS session resource information may be transmitted while being included in the radio bearer configuration information.

Meanwhile, the RRC connected state terminal receiving data for a specific MBS session may receive MBS data through the source cell during cell change.

For example, the terminal may receive data for the corresponding MBS session through the multicast/broadcast radio bearer through the source cell until a specific time point. Here, a specific point in time is RRC message reception including handover command, random access procedure start to target base station (Msg1/MsgA transmission), random initial/initial uplink transmission to target base station, successful random access to target base station, source cell release , arbitrary L2 entity/configuration application/setup/reconfiguration/completion to the target cell, handover completion, and system information and/or control information for the corresponding MBS session in the target cell (eg MCCH, SC-MCCH for MBS session Control logical channel, RRC message) may be one of the times of reception.

For another example, the terminal may receive data for the corresponding MBS session through the source cell through the unicast radio bearer until a specific time point. Here, a specific point in time is RRC message reception including handover command, random access procedure start to target base station (Msg1/MsgA transmission), successful random access to target base station, source cell release, arbitrary L2 entity/configuration application/ One of the times of setup/reconfiguration/completion, handover completion, and reception of system information or control information for the corresponding MBS session (eg RRC message belonging to the control logical channel for the MBS session similar to MCCH, SC-MCCH) from the target cell can be

Alternatively, after receiving the RRC message for handover, the terminal may complete successful random access to the target base station and maintain the source base station connection until releasing the source cell. Alternatively, after receiving the RRC message for handover, the terminal may maintain the connection to the source base station until the initial/initial uplink transmission to the target base station. Such information for instructing the connection maintenance of the terminal may be transmitted from the source base station to the target base station. Information for instructing connection maintenance of the terminal may be transmitted from the target base station to the source base station. Information for instructing the connection maintenance of the terminal may be transmitted from the target base station to the terminal.

An embodiment of performing MBS session data forwarding from a source base station to a target base station

The source base station may propose/request data forwarding for each QoS flow of the corresponding MBS session through the aforementioned handover request message. When the target base station accepts data forwarding for at least one QoS flow for the MBS session, the target base station sends the downlink TNL information for the QoS flow belonging to the corresponding MBS session through a HANDOVER REQUEST ACKNOWLEDGE message. can be transmitted to the base station.

If the MBS radio bearer is configured without a PDCP entity, packets of a QoS flow belonging to the corresponding MBS session may be forwarded through a DL (MBS radio bearer) forwarding tunnel mapped as RLC SDUs.

The source base station may receive a GTP-U end marker for the corresponding MBS session from the UPF (or MBS UPF). And when the data for the MBS session is no longer forwarded through the tunnel, the received endmarker may be transmitted (replicate) through each data forwarding tunnel. This operation may be performed after the source base station performs a procedure (described below) for transmitting a message for instructing/requesting modification/release of the DL tunnel between the UPF and the base station associated with the MBS session with AMF/SMF.

A unidirectional UM mode RLC entity without PDCP may be used to perform multicast/broadcast data transmission on the radio interface between the base station and the terminal. Even when unicast transmission is performed for the MBS session, the SDAP entity may be directly associated with the RLC entity without PDCP. The base station may indicate configuration information for indicating such entity association to the terminal.

As another example, a unidirectional UM mode RLC entity including PDCP may be used to perform multicast/broadcast data transmission on a radio interface between a base station and a terminal. When unicast transmission is performed for an MBS session, SDAP may be associated with a PDCP entity, and the PDCP entity may be configured to be associated with an RLC entity.

As another example, an AM mode RLC entity including PDCP may be used to perform multicast/broadcast data transmission on a radio interface between a base station and a terminal. When unicast transmission is performed for an MBS session, SDAP may be associated with a PDCP entity, and the PDCP entity may be configured to be associated with an RLC entity.

- When using RLC UM mode without PDCP

If the unicast radio bearer for the corresponding MBS session uses a UM mode RLC entity without PDCP in the source base station that unicast transmits MBS data, the target base station that transmits multicast/broadcast for the corresponding MBS session is a UM without PDCP Handover can be performed using all RLC entities. Since there is no PDCP entity, reset of PDCP SN or SFN or retransmission of PDCP SDUs is not required in the target base station.

As another example, when the UE moves from the unicast transmission cell to the unicast transmission cell, the unicast radio bearer for the MBS session at the source base station that unicasts MBS data uses a UM mode RLC entity without PDCP. A target base station that transmits unicast for a session may perform handover using a UM mode RLC entity without PDCP. Since there is no PDCP entity, reset of PDCP SN or SFN or retransmission of PDCP SDUs is not required in the target base station.

Meanwhile, radio bearer configuration information for an MBS session being transmitted by the target base station may be indicated to the terminal. The target base station includes radio bearer configuration information for the corresponding MBS session in an RRC dedicated message (e.g. RRC Reconfiguration message) and transmits it to the terminal. Alternatively, the radio bearer configuration information may be transmitted to the terminal through the source base station.

The UE may maintain/reconfigure the RLC entity to receive the RLC SDUs forwarded from the source base station to the target base station. When the reception of the forwarded RLC SDUs is completed, the UE may cancel/modify/reset it. For this purpose, RLC SDUs may contain end markers. This may be transmitted through an RLC control PDU. Alternatively, it may be transmitted as an RLC data PDU including a header of a specific format. Alternatively, it may be transmitted as any L2/L3 user plane data (e.g. RLC SDU) including a header of a specific format. Alternatively, it may be transmitted as any L2/L3 control plane data including a header of a specific format.

and/or the UE may reconfigure the RLC entity to receive RLC SDUs forwarded from the target base station. The target base station may transmit/retransmit all downlink data forwarded by the source base station. As another example, when the UE moves from a unicast transmission cell to a multicast/broadcast transmission cell as well as when moving from a unicast transmission cell to a unicast transmission cell, for in-sequence delivery and avoidance of duplication, the RLC sequence number (SN) uses the MBS. It may be maintained per radio bearer (unicast radio bearer and/or MBS radio bearer) for The source base station may inform the target base station about the next DL RLC SN to be assigned to a packet that does not have an RLC SN yet. For example, the handover request message may include corresponding notification information.

- When using RLC UM mode with PDCP

If the unicast radio bearer for the corresponding MBS session uses a UM mode RLC entity including PDCP in the source base station that unicast transmits MBS data, the target base station that transmits multicast/broadcast for the corresponding MBS session uses PDCP. Handover can be performed using the included UM mode RLC entity. The target base station resets the PDCP SN or SFN. Retransmissions for PDCP SDUs are not required.

As another example, when the UE moves from a unicast transmission cell to a unicast transmission cell, the unicast radio bearer for the corresponding MBS session in the source base station that unicast transmits MBS data uses a UM mode RLC entity including PDCP. A target base station transmitting unicast for the MBS session may perform handover using a UM mode RLC entity including PDCP. The target base station resets the PDCP SN or SFN. Retransmissions for PDCP SDUs are not required.

The radio bearer configuration information for the MBS session in which the target base station is performing transmission may be indicated to the terminal. The target base station includes radio bearer configuration information for the corresponding MBS session in an RRC dedicated message (e.g. RRC Reconfiguration message) and transmits it to the terminal. Alternatively, the radio bearer configuration information may be indicated to the terminal through the target base station.

The UE may maintain/reconfigure the PDCP entity to receive PDCP SDUs forwarded from the source base station to the target base station. Upon completion of reception of the forwarded PDCP SDUs, the UE may cancel/modify/reset them. For this purpose, PDCP SDUs may contain end markers. This may be transmitted through a PDCP control PDU. Alternatively, it may be transmitted as a PDCP data PDU including a header of a specific format. Alternatively, it may be transmitted as any L2/L3 user plane data (e.g. PDCP SDU) including a header of a specific format. Alternatively, it may be transmitted as any L2/L3 control plane data including a header of a specific format.

and/or the terminal may reconfigure the PDCP entity to receive PDCP SDUs forwarded from the target base station. The target base station may transmit/retransmit all downlink data forwarded by the source base station. As another example, when the UE moves from a unicast transmission cell to a multicast/broadcast transmission cell as well as from a unicast transmission cell to a unicast transmission cell, for in-sequence delivery and avoidance of overlap, PDCP SN (Sequence Number) uses MBS It may be maintained per radio bearer (unicast radio bearer and/or MBS radio bearer) for The source base station may inform the target base station about the next DL RLC SN to be assigned to a packet that does not have a PDCP SN yet. For example, the notification may be transmitted while being included in the handover request message. As another example, the corresponding notification may be transmitted while being included in the SN STATUS message.

- When using RLC AM mode with PDCP

If the unicast radio bearer for the MBS session uses an AM mode RLC entity including PDCP in the source base station that unicast transmits MBS data, the target base station that transmits multicast/broadcast for the corresponding MBS session uses PDCP. Handover can be performed using the included AM mode RLC entity. The target base station may maintain/reconfigure the PDCP entity to receive PDCP SDUs forwarded from the source base station in order or without loss.

As another example, when the UE moves from a unicast transmission cell to a unicast transmission cell, when the unicast radio bearer for the MBS session in the source base station that unicasts MBS data uses an AM mode RLC entity including PDCP, the corresponding A target base station transmitting unicast for the MBS session may perform handover using an AM mode RLC entity including PDCP. The radio bearer configuration information for the MBS session in which the target base station is transmitting may be indicated to the terminal. The target base station includes radio bearer configuration information for the corresponding MBS session in an RRC dedicated message (e.g. RRC Reconfiguration message) and transmits it to the terminal. Alternatively, the radio bearer configuration information may be indicated to the terminal through the source base station.

The UE may maintain/reconfigure the PDCP entity to receive PDCP SDUs forwarded from the source base station to the target base station. and/or the terminal may reconfigure the PDCP entity to receive PDCP SDUs forwarded from the target base station. As another example, when the UE moves from a unicast transmission cell to a multicast/broadcast transmission cell as well as from a unicast transmission cell to a unicast transmission cell, for in-sequence delivery and avoidance of overlap, PDCP SN (Sequence Number) uses MBS It may be maintained per radio bearer (unicast radio bearer and/or MBS radio bearer) for The source base station may inform the target base station about the next DL RLC SN to be assigned to a packet that does not have a PDCP SN yet. For example, the source base station may transmit a corresponding notification in a handover request message. As another example, the corresponding notification may be transmitted while being included in the SN STATUS message.

The target base station may transmit/retransmit all downlink data forwarded by the source base station. The target base station retransmits all downlink PDCP SDUs, starting from the oldest PDCP SDU not verified by RLC in the source base station. To this end, the source base station may transmit the unconfirmed SN to the target base station.

An embodiment of instructing/requesting DL tunnel modification/release between the UPF and the base station associated with the MBS session from the source base station to AMF/SMF

The UE synchronizes with the target cell and completes the RRC handover procedure by transmitting an RRCReconfigurationComplete message to the target base station.

If the target base station is performing multicast/broadcast transmission by already establishing a DL tunnel between the UPF (or MBS UPF) associated with the corresponding MBS session and the base station, or if the target base station is If the DL tunnel between the UPF and the base station is already established and unicast transmission is being performed to another terminal, the target base station does not need to perform a path switch request procedure. It may only be necessary to release the transmission path of the source base station. If the DL tunnel between the UPF and the base station associated with the corresponding MBS session has already been established, the target base station can transmit MBS data to the terminal by association/using it.

The target base station may identify the corresponding MBS session through the MBS session information/MBS context information received from the source base station. The target base station may add/modify/store DL tunnel information between the UPF and the base station already set in the MBS context information for the corresponding terminal. Alternatively, the target base station may associate the DL tunnel information between the base station and the UPF already set in the MBS context information for the corresponding terminal. Alternatively, the target base station may add/modify/store related information to the corresponding terminal in the MBS context information.

The target base station may transmit information for instructing the source base station to release/modify/change the DL tunnel between the UPF and the base station. For example, the target base station may transmit information for instructing to release/modify/change the DL tunnel between the UPF and the base station for the corresponding MBS session through the terminal context release message. Alternatively, the target base station may transmit information for indicating this through an arbitrary Xn interface message. Corresponding messages may include one or more pieces of information among the information exemplified in each embodiment herein, such as MBS session information/MBS session context information, cast type, and TNL information between the UPF and the source base station.

The source base station may transmit information for instructing to release/modify/change the DL tunnel between the UPF and the source base station to the AMF/SMF. This can be provided by including the information in the conventional PATH SWITCH request message and transmitting it. As another example, this may be transmitted through a message between the base station and the AMF/SMF interface that is distinct from the PATH SWITCH request message. Corresponding messages may include one or more pieces of information among the information exemplified in each embodiment herein, such as MBS session information/MBS session context information, cast type, and TNL information between the UPF and the source base station.

As another example, the source base station may transmit a message instructing/requesting setting/modification of a unicast session (e.g. PDU session) associated with the MBS session to AMF/SMF. The AMF/SMF may perform the session modification procedure by sending a unicast session (e.g. PDU session) modification request message related to the MBS session to the base station.

Hereinafter, an additional operation embodiment related to MBS data reception of the terminal will be described.

When the terminal in the RRC connection state is receiving MBS data in a multicast/broadcast manner in one cell, a cell change may occur according to the movement of the corresponding terminal. In this case, the cell to which the UE is handed over may not transmit the corresponding MBS data in a multicast/broadcast manner. Alternatively, the cell to which the terminal is handed over at this time may be a cell that does not support multicast/broadcast transmission. Alternatively, the cell to which the terminal is handed over at this time may be transmitting the corresponding MBS data in a multicast/broadcast manner.

At this time, in order to minimize service interruption for MBS data being received, coordination between the source base station and the target base station may be provided.

For example, a multicast/broadcast radio bearer for a specific MBS session may be mapped to a unicast radio bearer in the terminal through coordination between base stations and configured. Through this, the UE may receive data for the corresponding MBS session at a specific time (or after a specific time) through the unicast radio bearer. At a specific point in time, an RRC message including a handover command is received, random access is initiated to the target base station (Msg1/MsgA transmission), random first/initial uplink transmission to the target base station, successful random access to the target base station, the source cell is released, It may be one of the time points of applying/setting/reconfiguring/completing any L2 entity/configuration to the target cell and completing the handover.

For another example, if the target base station does not establish a tunnel (associated with QoS flows of the MBS session) between the UPF associated with the corresponding MBS session and the base station in the target base station, for starting the corresponding MBS session or for the corresponding MBS session To establish a tunnel between the UPF and the target base station, or to instruct/request establishment/modification of a unicast session (eg PDU session) associated with an MBS session, or to establish/set-up/modify/change the corresponding MBS session For this purpose, specific indication information may be transmitted to AMF/SMF. The AMF/SMF may perform the session establishment/modification procedure by sending a request message for setting/modifying the MBS session and/or the associated unicast session (e.g. PDU session) to the base station. Alternatively, the AMF/SMF may perform an MBS session start procedure for starting a corresponding MBS session with the base station.

For another example, in the target base station, a tunnel (associated with QoS flows of the MBS session) between the UPF associated with the corresponding MBS session and the base station is established in the target base station, and the tunnel is multicast/broadcast in the target cell If it is associated with a multicast/broadcast (point-to-multipoint) radio bearer for (point-to-multipoint) transmission, it can be configured by mapping the multicast/broadcast radio bearer to the corresponding terminal.

For another example, in the target base station, a tunnel (associated with QoS flows of the MBS session) between the UPF associated with the corresponding MBS session and the base station is established in the target base station, and the tunnel is unicast (point-to-point) in the target cell. ), it can be configured by mapping the tunnel between the UPF associated with the corresponding MBS session and the target base station to a new unicast (point-to-point) radio bearer for the corresponding terminal.

In order to easily perform dynamic switching in one cell for one UE, a unicast session and an MBS session may be simultaneously established. In order to easily perform dynamic switching in the cell change/handover process for one UE, a unicast session and an MBS session may be simultaneously established. For specific MBS data, the UE may receive the corresponding MBS data through a unicast session or an MBS session according to a network instruction. The base station may transmit MBS data only through either a unicast session or an MBS session at a specific time.

For the unicast session, the existing PDU session between the UE and the UPF may be used as it is or may be partially modified. For example, for a bidirectional PDU session, MBS data may be transmitted through a downlink PDU session. The UE transmits the application layer request information or control information (eg IGMP, MLD, IP multicast address) necessary for receiving MBS data through the uplink PDU session (or through any user plane connection) to the UPF or for IP multicast reception. It can be transmitted to the base station. The UPF or the base station can distinguish them. For example, the UPF may distinguish a corresponding packet through packet filtering. For another example, the base station may distinguish a corresponding packet through an arbitrary uplink L2 control PDU (e.g. MAC CE, RLC control PDU, PDCP control PDU, SDAP control PDU). Upon detecting the corresponding packet, the UPF or the base station can use it to change/modify the unicast session and the MBS session. For example, the detected information may be transmitted to the SMF/AMF/base station, or the UPF may instruct to select and transmit MBS data during a unicast session or an MBS session.

Alternatively, the UE transmits application layer request information necessary to receive MBS data through any uplink signaling (or any control plane connection) or control information (eg IGMP, MLD, IP multicast address) for IP multicast reception. can The AMF/UPF or the base station can distinguish them. For example, AMF/SMF may receive corresponding information through NAS signaling. For another example, the base station may receive the corresponding information through any uplink RRC message. When the corresponding information is detected, the AMF/SMF or the base station can use it to set/change/modify the unicast session and the MBS session. For example, the SMF/AMF may transmit detected information to the base station or may instruct the UPF to select and transmit MBS data during a unicast session or an MBS session.

UPF may support first hop router function to support IP multicast transmission. IGMP (Internet Group Management Protocol, in the case of IPv4) or MLD (Multicast Listener Discovery, in the case of IPv6) can be used for group management for the MBS session identified by the IP multicast address. For example, the UPF may receive membership/join information for the MBS session of the terminal by detecting the IGMP packet. As an example, membership/join information may be acquired in a multicast group. As another example, leave information may be obtained from the multicast group. As another example, the UPF may receive a report on membership/join/leave for a multicast session from the terminal by sending an IGMP Query message to the terminal. As another example, when there is no periodically received IGMP report, the UPF may know that it has left the multicast group of the corresponding terminal. To this end, the MBS session may be configured to have a unicast uplink session.

A unicast session may consist of a dedicated PDU session mapped one-to-one to an MBS session. Alternatively, the unicast session may be configured as a dedicated PDU session mapped one-to-many/many-to-one to one or more MBS sessions. Alternatively, the unicast session is performed under certain conditions (eg, when the terminal is interested in the MBS session, when the terminal transmits any uplink indication information/message for the MBS session to the base station or the network, when the terminal is receiving the MBS session ), it can be set and maintained without being released. The condition may be applied to one terminal or may be applied specifically to a cell. Alternatively, the radio bearer may be mapped one-to-many/many-to-one to one or more MBS sessions.

For this, messages included in the PDU session establishment procedure (eg PDU Session Establishment Request between the terminal and AMF, PDU SESSION RESOURCE SETUP REQUEST between the base station and AMF, PDU SESSION RESOURCE SETUP RESPONSE, Nsmf_PDUSession_CreateSMContex Request between AMF and SMF, Nsmf_PDUSession_CreateSMContex PDU Session establishment procedure related message) includes information for identifying the associated MBS session (MBS service ID, MBS session ID, TMGI, session-ID), TNL information (eg IP address for downlink tunnel between AMF and base station, GTP TEID) ), QoS flow information, session/cast type (information to distinguish one or more of multicast session, broadcast session, and unicast session), and MBS session type (identify one or more of IPv4, IPv6, IPv4IPv6, ethernet, unstructured) information for doing so) and may include at least one of information.

The MBS session may use the above-described MBS session start procedure (e.g. MBS session start request/response message).

The target base station prepares handover having an L1/L2 configuration. The target base station may perform admission control on the received MBS session/MBS context.

For example, the target base station transmits the MBS session requested by the source base station to the corresponding terminal in an arbitrary transmission method/cast type (eg multicast/broadcast (point-to-multipoint) transmission, unicast (point-to-point) transmission). You can decide whether to accept it or not. As another example, the target base station may determine the transmission method/cast type (e.g. multicast/broadcast transmission, unicast transmission) for the corresponding MBS session requested by the source base station for the corresponding terminal. As another example, the target base station may indicate to the source base station the transmission method/cast type for the corresponding MBS session requested by the source base station for the corresponding terminal. As another example, if the target base station is performing multicast/broadcast transmission for the corresponding MBS session, it may indicate to the source base station that multicast/broadcast transmission is being performed for the corresponding MBS session. As another example, the source base station and the target base station transmit method/cast type (eg multicast/broadcast transmission, unicast transmission) for MBS sessions through the Xn interface message between the base stations, session start time, end time, cell identification information, etc. Information related to any MBS session can be exchanged. To this end, the source base station and the target base station may request information between the base stations and receive a response, or may transmit it to a neighboring base station according to a specific trigger condition.

As another example, the target base station may transmit the accepted MBS session resource information (MBS Session Resource Admitted List) to the source base station. The corresponding information may include at least one of MBS session identification information, MBS session context information, TNL information, accepted QoS flow information, and target base station data forwarding information (e.g. DL data forwarding GTP-TEID). As another example, the corresponding information may be transmitted from the target base station to the source base station through a HANDOVER REQUEST ACKNOWLEDGE message.

As another example, the source base station may transmit transmission method/cast type (e.g. multicast/broadcast transmission, unicast transmission) information for the corresponding MBS session to the target base station. As another example, the source base station may transmit configuration information for the corresponding MBS session to the target base station for the corresponding terminal.

The source base station may transmit unicast session information associated with the MBS session together to the target base station. Through this, for example, when moving from a multicast/broadcast transmission cell to a unicast transmission cell, the target base station can configure DRB(s) according to the corresponding unicast session information. Through this, the MBS data flow can be mapped and configured to the DRB(s) through the unicast target cell. Alternatively, a service may be provided through DRB(s) for providing a unicast session associated with the corresponding MBS session by configuring a DRB according to the corresponding unicast session information in a target cell to be unicast handed over.

The source base station may propose/request data forwarding for each QoS flow of the corresponding MBS session through the aforementioned handover request message. If the target base station accepts data forwarding for at least one QoS flow for the MBS session, the target base station includes downlink TNL information for the QoS flow belonging to the corresponding MBS session through a HANDOVER REQUEST ACKNOWLEDGE message. can spend

If the MBS radio bearer is configured without a PDCP entity, packets of a QoS flow belonging to the corresponding MBS session may be forwarded through a DL (MBS radio bearer) forwarding tunnel mapped as RLC SDUs.

The source base station may receive a GTP-U end marker for the corresponding MBS session from the UPF (or MBS UPF). In addition, the source base station may transmit (replicate) the corresponding end marker through each data forwarding tunnel when no more data for the MBS session is forwarded through the tunnel. This can be performed by performing a procedure (described below) for the source base station to transmit a message for instructing/requesting modification/removal of a DL tunnel between the UPF and the base station associated with the MBS session with AMF/SMF.

A unidirectional UM mode RLC entity without PDCP may be used to perform multicast/broadcast data transmission on the radio interface between the base station and the terminal. Even when unicast transmission is performed for the MBS session, the SDAP entity may be directly linked to the RLC entity without PDCP. The base station may instruct the terminal with configuration information for indicating this for data reception of the terminal.

As another example, a unidirectional UM mode RLC entity including PDCP may be used to perform multicast/broadcast data transmission on a radio interface between a base station and a terminal. When unicast transmission is performed for an MBS session, SDAP may be associated with a PDCP entity, and a PDCP entity may be associated with an RLC entity.

As another example, an AM mode RLC entity including PDCP may be used to perform multicast/broadcast data transmission on a radio interface between a base station and a terminal. When unicast transmission is performed for an MBS session, SDAP may be associated with a PDCP entity, and a PDCP entity may be associated with an RLC entity.

12 is a diagram illustrating a downlink layer 2 structure in an LTE system.

Referring to FIG. 12, as in the 1200 structure, MBMS Point to Multipoint Radio Bearer (MRB) or SC-MRB for providing MBMS in conventional LTE is data transmitted based on RLC-UM that provides a segmentation function without a PDCP entity. . The LTE base station was able to distinguish the payload/data belonging to the MBMS session through the MBMS session and Transport Network Layer (TNL) information transmitted through the MBMS session start request message. For example, the information on the MBMS session may include information about one or more of TMGI, MBMS session-ID, and MBMS service area. Here, the MBMS service area information includes an MBMS service area identifier (MBMS Service Area Identity (SAI)). MBMS SAI consists of 2 octets and is coded and used to identify a group of cells in one PLMN. And it is independent of physical cell and location area/routing area. One cell may belong to one or more MBMS service areas. Thus, it may be addressed by one or more MBMS service area identities (SAIs).

The TNL information may include at least one of an IP multicast address, an IP source address, and a GTP DL TEID. The LTE base station classifies data belonging to the MBMS session through TNL information and transmits the data in association with the corresponding MBMS radio bearer (or RLC-UM entity).

In order to transmit MBS data (e.g. media, video, software downloading etc.), an MBS session must be established between the terminal and the core network entity. NR supports flow-based QoS processing for general user data. Therefore, it is desirable to support QoS granularity per flow when NR provides MBS. To this end, the MBS session start request message transmitted by the core network control plane entity (e.g. AMF) to the base station may include QoS flow setup request information in addition to the MBS session and TNL (Transport Network Layer) information.

The base station may receive a session start request message for a specific MBS session through any core network control plane entity (eg, AMF). For example, the corresponding message is identified as identification information for the corresponding MBS service (or MBS session) (for convenience of description, below, the identification information for the MBS session is indicated. This is for convenience of description, and MBS service ID, MBS session ID , TMGI, session-ID, IP multicast address, etc., may be replaced with any similar existing identification information or new term.), QoS information for the corresponding MBS session (eg 5QI/QCI, QoS flow Identifier, GBR QoS flow information ( Information on one or more of Maximum Flow Bit Rate, Guaranteed Flow Bit Rate, Maximum Packet Loss Rate), Allocation and Retention Priority, Priority Level Packet Delay Budget, and Packet Error Rate).

In order to limit the maximum transmission rate of the conventional terminal, UE-AMBR (Aggregate Maximum Bit Rate) or PDU Session AMBR is used. For each PDU session of one UE, the transmission rate could be limited through Session-AMBR, which is an aggregate rate limit QoS parameter for each session, and Session-AMBR, which is an aggregate rate limit QoS parameter for each UE. Accordingly, the base station set to the sum of the Session-AMBR of all PDU sessions having the active user plane up to the UE-AMBR value received from the AMF (Each (R)AN shall set its UE-AMBR to the sum of the Session-AMBR of all PDU Sessions with active user plane to this (R)AN up to the value of the received UE-AMBR from AMF). In the prior art, UE-AMBR and Session-AMBR were applied in both directions (uplink and downlink directions). And Session-AMBR was not applied to GBR QoS flow. For downlink traffic, Session-AMBR enforcement (refer to 3GPP TS 23.501) was performed in UPF. For uplink traffic, Session-AMBR execution was performed in the UE and UPF.

Unlike the conventional maximum transfer rate limitation, the operator may newly define information for limiting the maximum transfer rate of the MBS session and signal it.

For example, the MBS session may be provided as a GBR QoS flow. As another example, the MBS session may be provided as a non-GBR QoS flow. As another example, the operator may define and signal aggregate rate limit QoS parameters per session for the MBS session. As another example, the operator may define and signal an aggregate rate limit QoS parameter (e.g. UE-MBS_Seesions-AMBR) of the MBS session for each terminal for the MBS session. The aggregate rate limit QoS parameter of the MBS session for each UE may be set to a value equal to or smaller than that of the UE-AMBR. As another example, the above parameters may be applied only to the downlink direction. As another example, UE-AMBR may be set to the sum of Session-AMBR of all (unicast) PDU sessions having an active user plane except for the MBS session. As another example, the UE-AMBR may be set to the sum of the Session-AMBRs of all (unicast/multicast/broadcast) sessions having an active user plane, including the MBS session. The above-mentioned parameters may be signaled from AMF/SMF to a base station or from AMF/SMF to a terminal or from AMF/SMF to UPF. The signaling message is a signaling message according to a known standard (eg, PDU Session Establishment Request between the base station and AMF between the terminal and AMF, PDU SESSION RESOURCE SETUP REQUEST, PDU SESSION RESOURCE SETUP RESPONSE, Nsmf_PDUSession_CreateSMContex Request between AMF and SMF, Nsmf_PDUSession_Create PDU session establishment procedure related message).

Unlike LTE, which applies MBMS technology to terrestrial broadcast services or specific applications, NR is required to support MBS in various vertical domains. For this, it is necessary to support MBS that supports various requirements. For example, you may want to provide an MBS for V2X/Public safety/Industrial IoT service, etc., via a local area network/internally/via a Non Public Network/private network. For example, it may be desired to provide file transmission for software upgrade for a specific IoT terminal group through an MBS session. As another example, it may be desired to provide transmission of an emergency message through an MBS session.

Various MBS services may provide transmission differentiated through QoS flow request information. However, it was not possible to separate and control details such as the start time of the MBS session, the stop time of the MBS session, the duration of the MBS session, and the repetition of the MBS session. To this end, the MBS session start request message received by the base station may include information about one or more of MBS session start time, MBS session stop time, MBS session duration, MBS session repetition number, and MBS session repetition period. Here, the MBS session start time may indicate a time at which MBS data is transmitted in the base station/network through the MBS radio bearer. The MBS session stop time may indicate a time when MBS transmission is expected to be completed. The duration of the MBS session may indicate a transmission period of MBS data. The number of MBS session repetitions may indicate the number of times MBS data transmission is repeated, and the MBS session repetition period may indicate a cycle at which MBS data transmission is repeated. If that information is not included, the MBS data is transmitted immediately or is expected to be transmitted immediately. And it is stopped or expected to be stopped by a message instructing to stop the corresponding session.

The base station may calculate/convert the received information into scheduling information for MBS data transmission by the base station using or based on the received information. The base station may transmit the corresponding information through system information or logical channel information (e.g. MCCH, SC-MCCH) for MBS transmission. For example, the corresponding time information may be indicated by being linked/mapped/converted to Coordinated Universal Time (UTC) by the base station through system information (e.g. SIB9). The time information may be indicated through offset time information with UTC time information (timeInfoUTC) corresponding to the SFN boundary or immediately after the end boundary of the SI-window through which SIB9 is transmitted. As another example, the corresponding time information may be indicated by being linked/mapped/converted to the SFN. The start SFN, the repeating start SFN list, the start offset/frame/slot/subframe/time point, duration/duration/length, repetition period, and number of repetitions may be indicated through one or more of information. Through this, the UE may acquire scheduling information through which MBS data is transmitted in units of PDCCH slots. As another example, in order to reduce power consumption, scheduling information for instructing to discontinuously perform PDCCH monitoring for a corresponding specific RNTI may be indicated. The corresponding scheduling information may include one or more of an on-duration timer, an inactivity timer, a scheduling period, and a scheduling offset as a parameter for DRX reception.

As another example, the cell identification information to provide the MBS service area may be directly included in the MBS session start request message. Conventional MBMS coded (e.g. SAI) a designated service area and requested session start including corresponding code (SAI) information. In order to provide a flexible MBS service by reusing the 5G system as much as possible, it is desirable to dynamically designate a specific cell group to start an MBS session. For example, similar to the paging message, it may include cell identification information that will provide direct MBS transmission. To this end, the MBS session start request message may include cell information/cell list information through which the corresponding base station will transmit MBS data. Corresponding cell/cell list information includes at least one of physical cell identifier information, NR CGI (Cell Global Identifier: used to globally identify an NR cell), E-UTRA CGI, gNB ID, PLMN Identity, and NCI (NR Cell Identity) information can do.

For another example, the MBS session start request message contains information for distinguishing the type (or cast type) of the MBS session (or 1-bit information for distinguishing the cast type eg Multicast/Broadcast or 2 for distinguishing Multicast/Broadcast/Unicast bit information) or information for indicating the type of MBS session. Through this, the base station can perform appropriate MBS transmission in the wireless network by considering/classifying the MBS session type.

For another example, the MBS session start request message may include information on the number of terminals expected/expected to join (receive MBS) to the corresponding MBS session. For another example, the response message to the MBS session start request message may include information on the number of terminals that have actually joined (MBS received) the corresponding MBS session to the corresponding base station. Through this, the base station can perform appropriate MBS transmission in the wireless network by considering/classifying the MBS session type. For example, the MBS session may be transmitted in association with an MBS (point-to-multipoint) radio bearer. Alternatively, the MBS session may be transmitted in association with a unicast (point-to-point) radio bearer (DRB). To this end, the core network entity (e.g. one of AMF, SMF, UPF, and MBS Function) may count information on the number of terminals that have requested join/receive/interest in the corresponding MBS session.

As an example for this, a case in which the number of terminals information is counted through the UPF will be described.

IGMP (Internet Group Management Protocol, in the case of IPv4) or MLD (Multicast Listener Discovery, in the case of IPv6) can be used for group management for the MBS session identified by the IP multicast address. An MBS session may be established between the UE and the UPF. For this, the UPF must be able to receive the configuration information for the MBS session from the AMF/SMF. The UPF may transmit the corresponding MBS flow to the base station through packet filtering for the MBS flow. UPF may support first hop router function to support IP multicast transmission. For example, the UPF may receive membership/join information for the MBS session of the terminal by detecting the IGMP packet. As an example, membership/join information may be acquired in a multicast group. As another example, leave information may be obtained from the multicast group. As another example, the UPF may receive a report on membership/join/leave for a multicast session from the terminal by sending an IGMP Query message to the terminal. As another example, if there is no periodically received IGMP report, it can be known that the UPF has left the multicast group of the corresponding terminal. As an example for this, it is possible to have a unicast uplink session associated with the MBS session.

As another example, a PDU session for an MBS session (or a PDU session associated with an MBS session or a unicast PDU session associated with an MBS session) may be configured between the UE and the UPF. This may be provided through a normal PDU session establishment procedure. Messages included in the PDU session establishment procedure (eg PDU Session Establishment Request between terminal and AMF, PDU SESSION RESOURCE SETUP REQUEST between base station and AMF, PDU SESSION RESOURCE SETUP RESPONSE, Nsmf_PDUSession_CreateSMContex Request between AMF and SMF, Nsmf_PDUSession_CreateSMContex Response, etc. The setup procedure related message) includes information for identifying the associated MBS session (MBS service ID, MBS session ID, TMGI, session-ID, IP multicast address), TNL information, QoS flow information, and session type (multicast session, broadcast). information for distinguishing one or more of a cast session and a PDU session).

For another example, the corresponding PDU session may be configured by simultaneously connecting one to the unicast PDU session and the other to the MBS session.

In the conventional LTE technology, one MBSM session is mapped to one MBMS Point to Multipoint Radio Bearer (MRB)/Single Cell MRB (SC-MRB). For example, when setting up an MRB to start one MBMS session, the UE sets one RLC entity according to the default configuration, and the MTCH logical channel according to the logical channel identification information (logicalChannelIdentity) included in the MCCH (MBSFNAreaConfiguration) message. to constitute one MRB. For another example, when configuring SC-MRB to start one MBMS session, the UE configures one RLC entity according to the default configuration, and includes g-RNTI and scheduling information ( sc-mtch-SchedulingInfo), one SC-MRB was configured. Accordingly, SC-MCCH or SC-MTCH is fixed to one designated logical channel identifier (LCID 11001).

NR provides flow-based QoS. Therefore, when applying the MBS session in NR, it is desirable to provide flow unit classification processing.

For example, one MBS session may include one or more QoS flows having different QoS characteristics. To this end, the base station may associate the aforementioned identification information for the MBS session and one or more QoS flows mapped to the corresponding MBS session to one or more radio bearers. For convenience of description, a radio bearer associated with an MBS session is denoted as an MBS radio bearer. For example, it is assumed that one MBS session has three different flows (QFI1, QFI2, QFI2) and is associated with two MBS radio bearers (MBS-RB1, MBS-RB2). For example, a QoS flow may be mapped to an MBS radio bearer by configuring one Service Data Adaptation Protocol (SDAP) entity for each MBS session.

13 is a diagram exemplarily illustrating MBS radio bearer configuration information according to an embodiment.

Referring to FIG. 13, an example of MBS session configuration information for instructing to map QFI1 and QF2 to MBS-RB1 and QF3 to MBS-RB2 is shown. If the MBS-RB is configured without a PDCP entity, the PDCP-Config included in the MBS-RB configuration information in FIG. 13 may be deleted. Alternatively, PDCP-Config included in MBS-RB configuration information in FIG. 13 may be deleted and RLC-BearerConfig may be included. Alternatively, it can be configured by defining a mode for transparently transmitting PDCP. The corresponding mode may be transmitted without including the PDCP header. In this mode, PDCP functions (e.g. ROHC, Security) may not be performed.

14 is a diagram exemplarily illustrating MBS radio bearer configuration information according to another embodiment.

14, for all MBS sessions (for example, for all MBS sessions associated with one base station or for all MBS sessions associated with one terminal), one SDAP (Service Data Adaptation Protocol) entity By configuring, QoS flows can be mapped to MBS radio bearers. Since the MBS session can be configured specifically for a cell, one SDAP can be configured and provided for all MBS sessions. Accordingly, MBS session configuration information for instructing to map QFI1 and QF2 to MBS-RB1 and QFI3 to MBS-RB2 may be configured as shown in FIG. 14 .

The UE may designate and use a specific RNTI (e.g. M-RNTI, SC-RNTI, G-RNTI of conventional LTE technology) for MBS data reception.

For example, an RNTI capable of receiving data by multiplexing a plurality of MBS sessions (e.g., one cell-specific RNTI for the entire service similar to M-RNTI) may be used. If an RNTI capable of receiving data by multiplexing a plurality of MBS sessions (eg, one cell-specific RNTI for the entire service similar to -RNTI) is used, one or more QoS flows belonging to different MBS sessions are the same QoS It may be mapped and transmitted to one radio bearer having a characteristic. One radio bearer having the same QoS characteristics may be associated with one or more MBS sessions. For example, PDCP entity/RLC entity/logical channel identification information may be associated with one or more MBS session information. For example, through MBS session identification information and QFI (information for identifying a QoS flow within one MBS session), the UE can classify and process the MBS session.

As another example, the UE may use an RNTI (eg, a session-specific RNTI similar to SC-RNTI and G-RNTI) capable of receiving data by being classified for each MBS session. If an RNTI (eg SC-RNTI, similar to G-RNTI) that can receive data by being classified for each MBS session is used, one or more QoS flows belonging to different MBS sessions may have the same QoS characteristics even if they have the same QoS characteristics. It cannot be transmitted because it is mapped to a bearer. One or more QoS flows belonging to one MBS session may be mapped and transmitted to one radio bearer having the same QoS characteristics. One or more QoS flows belonging to one MBS session may be mapped and transmitted to respective radio bearers having different QoS characteristics. For example, PDCP entity/RLC entity/logical channel identification information may be associated with one MBS session information. For example, the UE distinguishes and processes the MBS session through the association information between SDAP configuration information (eg QFI (information for identifying QoS flows within one MBS session)) and PDCP entity/RLC entity/logical channel identification information. can

For this purpose, MBS radio bearer identification information/RLC radio bearer/logical channel identification information associated with each QoS flow associated with each MBS session may be indicated from the base station to the terminal. Accordingly, for example, a control logical channel (eg MBS Control Channel) and/or a traffic logical channel (eg MBS Traffic Channel) included in the same MBS session may be multiplexed with other logical channels included in the same MBS session within the same MAC PDU. can As another example, a control logical channel (e.g. MBS Control Channel) and/or a traffic logical channel (e.g. MBS Traffic Channel) included in the same MBS session may be multiplexed with other logical channels within the same MAC PDU. As another example, a control logical channel (eg MBS Control Channel) and/or a traffic logical channel (eg MBS Traffic Channel) included in the same MBS session is a control logical channel (eg MBS Control) included in different MBS sessions within the same MAC PDU. Channel) and/or traffic logical channels (eg MBS Traffic Channels) may be multiplexed.

15 is a diagram illustrating a layer 2 structure according to an exemplary embodiment.

Referring to FIG. 15 , data may be processed by including one multiplexing entity for two MBS sessions (or all MBS sessions) without including each multiplexing entity for each MBS session.

In providing the MBS service, as the number of users receiving the corresponding MBS session within one cell coverage increases, the transmission efficiency of the MBS session delivery increases. On the other hand, if there are few users receiving the corresponding MBS session within the corresponding cell coverage, transmission efficiency is reduced. For example, the MBS session is intended to support data reception by multiple users, and radio transmission efficiency is inevitably lower than that of unicast-based transmission. Therefore, if the network can dynamically switch/change unicast transmission and multicast/broadcast transmission for one MBS data, the efficiency of wireless transmission can be increased.

As such, in case of supporting dynamic change between unicast transmission and multicast/broadcast transmission in transmitting MBS data, modify/change from unicast transmission to multicast/broadcast transmission or multicast/broadcast transmission to transmit the corresponding MBS data. A procedure for modifying/changing from cast/broadcast transmission to unicast transmission may be required.

For example, a unicast session and an MBS session may be dually configured. To facilitate dynamic switching, a unicast session and an MBS session can be established at the same time. For specific MBS data, the UE may receive the corresponding MBS data through a unicast session or an MBS session according to a network instruction. The base station may transmit MBS data only through either a unicast session or an MBS session at a specific time.

For the unicast session, the existing PDU session between the UE and the UPF may be used as it is or may be partially modified. For example, for a bidirectional PDU session, MBS data may be transmitted through a downlink PDU session. The UE transmits the application layer request information or control information (eg IGMP, MLD, IP multicast address) necessary for receiving MBS data through the uplink PDU session (or through any user plane connection) to the UPF or for IP multicast reception. can be transmitted to the base station. The UPF or the base station can distinguish them. For example, the UPF may distinguish a corresponding packet through packet filtering. For another example, the base station may distinguish a corresponding packet through an arbitrary uplink L2 control PDU (e.g. MAC CE, RLC control PDU, PDCP control PDU, SDAP control PDU). Upon detecting the corresponding packet, the UPF or the base station can use it to change/modify the unicast session and the MBS session. For example, the detected information may be transmitted to the SMF/AMF/base station, or the UPF may instruct to select and transmit MBS data during a unicast session or an MBS session.

Alternatively, the UE may transmit application layer request information or control information for IP multicast reception (eg IGMP, MLD, IP multicast address) necessary to receive MBS data through any uplink signaling (or any control plane connection). have. The AMF/UPF or the base station can distinguish them. For example, AMF/SMF may receive corresponding information through NAS signaling. For another example, the base station may receive the corresponding information through any uplink RRC message. Upon detecting the corresponding information, the AMF/SMF or the base station can use it to change/modify the unicast session and the MBS session. For example, the SMF/AMF may transmit detected information to the base station or may instruct the UPF to select and transmit MBS data during a unicast session or an MBS session. UPF can be made to support first hop router function to support IP multicast transmission. For example, the UPF may receive membership/join information for the MBS session of the terminal by detecting the IGMP packet. As an example, membership/join information may be acquired in a multicast group. As another example, leave information may be obtained from the multicast group. As another example, the UPF may transmit an IGMP Query message to the terminal to receive a report on membership/join/leave for the multicast session from the terminal. As another example, if there is no periodically received IGMP report, it can be known that the UPF has left the multicast group of the corresponding terminal. As an example for this, the MBS session may have a unicast uplink session.

A unicast session may consist of a dedicated PDU session mapped one-to-one to an MBS session. Alternatively, the unicast session may be configured as a dedicated PDU session mapped one-to-many to one or more MBS sessions. Alternatively, the unicast session is performed under certain conditions (eg, when the terminal is interested in the MBS session, when the terminal transmits any uplink indication information/message for the MBS session to the base station or the network, when the terminal is receiving the MBS session ), it can be set and maintained without being released.

For this, messages included in the PDU session establishment procedure (eg PDU Session Establishment Request between the terminal and AMF, PDU SESSION RESOURCE SETUP REQUEST between the base station and AMF, PDU SESSION RESOURCE SETUP RESPONSE, Nsmf_PDUSession_CreateSMContex Request between AMF and SMF, Nsmf_PDUSession_CreateSMContex Request, etc. PDU session establishment procedure related message) includes information for identifying the associated MBS session (MBS service ID, MBS session ID, TMGI, session-ID), TNL information (eg IP address for downlink tunnel between AMF and base station, GTP) TEID), QoS flow information, session/cast type (information to distinguish at least one of multicast session, broadcast session, and unicast session), and MBS session type (at least one of IPv4, IPv6, IPv4IPv6, ethernet, unstructured). information for identification) may include at least one of information. The MBS session may use the above-described MBS session start procedure (e.g. MBS session start request/response message).

For another example, one unicast session may be modified/changed/switched into one MBS session according to a request of a base station/network/terminal. Alternatively, one MBS session may be modified/changed/switched into one unicast session according to the request of the base station/network/terminal. When modification/change/switching between sessions is performed, the previous session may be released and a new session may be established. Alternatively, when modification/change/switching between sessions is performed, a new session may be established first and then the previous session may be released.

For example, when the procedure for establishing a new session is completed, the base station/network/terminal may initiate a procedure for releasing the previous session.

An MBS session between the UPF and the base station may have one or more QoS flows. Each corresponding flow or one flow may have associated UP Transport layer information. This is information on the downlink tunnel between the UPF and the base station, and may include the base station's IP address and GTP-TEID. The base station maps the corresponding QoS flow identification information to the MBS radio bearer and transmits data. In this case, the base station may select unicast transmission or MBS transmission according to the determination of the base station or information determined and indicated by the core network entity.

In transmitting MBS data to a specific terminal, if the network determines unicast transmission to transmit data through a unicast session and when MBS transmission determines and transmits data through MBS session, different tunnels between the UPF and the base station Using , can be a significant overhead. Therefore, even when data is transmitted through a unicast session, it is desirable to transmit data by sharing a tunnel ( downlink tunnel between UPF and base station or between MBS user plane function and base station) transmitted to the base station through the MBS session. . Accordingly, one or more terminals can share and use a tunnel (a downlink tunnel between the UPF and the base station or a downlink tunnel between the MBS user plane function and the base station) transmitted to the base station through the MBS session. To this end, when setting/modifying a unicast PDU session for the UE, it is possible to include and transmit indication information for sharing the N3 tunnel between the UPF of the MBS session and the base station. For example, messages included in the PDU session establishment/modification procedure (eg PDU Session Establishment Request between UE and AMF, PDU SESSION RESOURCE SETUP REQUEST between base station and AMF, PDU SESSION RESOURCE SETUP RESPONSE, Nsmf_PDUSession_CreateSMContex Request between AMF and SMF, Nsmf_PDU Session Request_CreateSMContex Response) Information for identifying the associated MBS session (MBS service ID, MBS session ID, TMGI, session-ID, IP multicast address) and TNL information of the shared tunnel (eg AMF and base station) IP address for inter-downlink tunnel, GTP TEID, information to indicate shared tunnel), QoS flow information, session/cast type (information to distinguish one or more of multicast session, broadcast session, and unicast session) and MBS session type (information for distinguishing one or more of IPv4, IPv6, IPv4IPv6, ethernet, and unstructured) information.

An MBS session may be established between the UE and the UPF. For this, the UPF must be able to receive the configuration information for the MBS session from the AMF/SMF. The UPF may transmit the corresponding MBS flow to the base station through packet filtering for the MBS flow. UPF may support first hop router function to support IP multicast transmission. For example, the UPF may receive membership/join information for the MBS session of the terminal by detecting the IGMP packet. As an example, it is possible to obtain membership/join information in a multicast group. As another example, information about leaving a multicast group may be obtained. As another example, the UPF may receive a report on membership/join/leave for a multicast session from the terminal by sending an IGMP Query message to the terminal. As another example, when there is no periodically received IGMP report, the UPF may know that it has left the multicast group of the corresponding terminal.

As an example for this, the MBS session may have a unicast uplink session. As another example, a PDU session for an MBS session (or a PDU session associated with an MBS session or a unicast PDU session associated with an MBS session) may be configured between the UE and the UPF. This may be provided through a normal PDU session establishment procedure. Messages included in the PDU session establishment procedure (eg PDU Session Establishment Request between the base station and AMF between the terminal and AMF, PDU SESSION RESOURCE SETUP REQUEST, PDU SESSION RESOURCE SETUP RESPONSE, Nsmf_PDUSession_CreateSMContex Request between AMF and SMF, Nsmf_PDUSession_CreateSMContex Response, etc. Procedure-related messages) include information for identifying the associated MBS session (MBS service ID, MBS session ID, TMGI, session-ID), TNL information, QoS flow information, and session type (multicast session, broadcast session, PDU session). information for distinguishing one or more of them).

For another example, one corresponding PDU session may be drawn in a unicast PDU session and the other may be configured in connection with an MBS session at the same time. The MBS session may support an Ethernet type MBS session or a PDU session. When the UPF receives a Join message/leaver message, it can be transmitted to the base station and stored by being included in the terminal context of the corresponding terminal.

As described above, the present disclosure provides an effect of effectively handing over an RRC connected state terminal receiving an MBS service through coordination between base stations.

Hereinafter, configurations of a terminal capable of performing some or all of the above-described embodiments and a target base station will be described again with reference to the drawings.

16 is a diagram illustrating a terminal configuration according to an embodiment.

Referring to FIG. 16 , the terminal 1600 for receiving MBS (Multicast/Broadcast Service) data receives radio bearer configuration information for MBS session data reception through the target base station when handover is determined through the source base station. It may include a receiver 1630 and a controller 1610 that configures a radio bearer for receiving MBS session data through a target base station based on the radio bearer configuration information.

The receiver 1630 further receives MBS session data through the radio bearer, and radio bearer configuration information is information generated by the target base station and transmitted to the source base station.

Meanwhile, the source base station may transmit a handover request message to the target base station. The handover request message may be of various types. For example, it may be a handover preparation request message or the like. For example, the handover request message may include at least one of MBS session context information and PDU session context information associated with the MBS session. The target base station checks whether the corresponding MBS session context is configured in the target base station using the information received from the source base station.

For example, if the MBS session context for MBS session data is not configured, the target base station transmits a message for requesting MBS session setup to the core network Access and Mobility Management Function (AMF) entity. Then, the target base station receives a message for starting the MBS session from the AMF entity. Through this, the target base station can generate radio bearer configuration information.

As another example, if the MBS session context for MBS session data is not configured, the target base station may generate radio bearer configuration information by using PDU session context information associated with the MBS session for MBS session data.

In addition, the target base station may determine a transmission type for MBS session data. In addition, the target base station may transmit a path switch request message for requesting a path change of MBS session data to the core network AMF (Access and Mobility Management Function) entity. For example, the path switch request message may include MBS session context information.

When the control unit 1610 receives radio bearer configuration information from the source base station, it configures it in the terminal.

Also, the receiver 1630 may receive MBS session data through a radio bearer mapped with the MBS session. For example, the radio bearer and the MBS session associated with MBS session data transmission may be mapped 1:N. As another example, the radio bearer and the MBS session associated with MBS session data transmission may be configured by N:1 mapping. Here, N is a natural number greater than or equal to 1. That is, one radio bearer and a plurality of MBS sessions may be mapped, and conversely, one MBS session and a plurality of radio bearers may be mapped. Of course, the radio bearer and the MBS session may be mapped 1:1. For example, the radio bearer and MBS session mapping information may be included in the aforementioned radio bearer configuration information.

In addition to this, the controller 1610 controls the overall operation of the terminal 1600 according to MBS data reception and handover operation necessary for carrying out the above-described present disclosure.

The transmitter 1620 and the receiver 1630 are used to transmit/receive signals, messages, and data necessary for carrying out the present disclosure with a source base station, a target base station, and a core network entity.

17 is a diagram illustrating a configuration of a target base station according to an embodiment.

Referring to FIG. 17, the target base station 1700 for controlling the reception of multicast/broadcast service (MBS) data of the terminal includes at least one of MBS session context information for the terminal from the source base station and PDU session context information associated with the MBS session. A receiver 1730 that receives a handover request message including one piece of information, a controller 1710 that generates radio bearer configuration information for receiving MBS session data of the terminal, and a transmitter that transmits radio bearer configuration information to a source base station (1720).

The receiver 1730 may receive a handover request message from the source base station. The handover request message may be of various types. For example, it may be a handover preparation request message or the like. For example, the handover preparation request message may include at least one of MBS session context information and PDU session context information associated with the MBS session.

The control unit 1710 checks whether the corresponding MBS session context is configured in the target base station by using the information received from the source base station.

For example, if the MBS session context for MBS-free session data is not configured in the target base station, the transmitter 1720 may transmit a message for requesting MBS session setup to the core network Access and Mobility Management Function (AMF) entity. have. The receiver 1730 may receive a message for starting an MBS session from the AMF entity.

As another example, when the MBS session context for MBS session data is not configured in the target base station, the controller 1710 generates radio bearer configuration information using PDU session context information associated with the MBS session for MBS session data. can do.

As another example, the controller 1710 may determine a transmission type for MBS session data.

Meanwhile, the radio bearer and the MBS session associated with MBS session data transmission may be mapped 1:N. As another example, the radio bearer and the MBS session associated with MBS session data transmission may be configured by N:1 mapping. Here, N is a natural number greater than or equal to 1. That is, one radio bearer and a plurality of MBS sessions may be mapped, and conversely, one MBS session and a plurality of radio bearers may be mapped. Of course, the radio bearer and the MBS session may be mapped 1:1. For example, the radio bearer and MBS session mapping information may be included in the aforementioned radio bearer configuration information.

Also, the transmitter 1720 may transmit a path switch request message for requesting a path change of the MBS session data to the core network AMF (Access and Mobility Management Function) entity. For example, the path switch request message may include MBS session context information.

In addition to this, the controller 1710 controls the overall operation of the target base station 1700 according to the MBS data transmission and handover operation necessary for carrying out the above-described present disclosure.

The transmitter 1720 and the receiver 1730 are used to transmit/receive signals, messages, and data necessary for carrying out the present disclosure with the source base station, the terminal, and the core network entity.

The above-described embodiments may be supported by standard documents disclosed in at least one of IEEE 802, 3GPP and 3GPP2, which are wireless access systems. That is, steps, configurations, and parts not described in order to clearly reveal the technical idea of the present embodiments may be supported by the above-described standard documents. In addition, all terms disclosed in this specification can be explained by the standard documents disclosed above.

The above-described embodiments may be implemented through various means. For example, the present embodiments may be implemented by hardware, firmware, software, or a combination thereof.

In the case of implementation by hardware, the method according to the present embodiments may include one or more Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), Programmable Logic Devices (PLDs), FPGAs (Field Programmable Gate Arrays), may be implemented by a processor, a controller, a microcontroller or a microprocessor.

In the case of implementation by firmware or software, the method according to the present embodiments may be implemented in the form of an apparatus, procedure, or function that performs the functions or operations described above. The software code may be stored in the memory unit and driven by the processor. The memory unit may be located inside or outside the processor, and may transmit and receive data to and from the processor by various known means.

Also, as described above, terms such as "system", "processor", "controller", "component", "module", "interface", "model", or "unit" generally refer to computer-related entities hardware, hardware and software. may mean a combination of, software, or running software. For example, the aforementioned components may be, but are not limited to, a process run by a processor, a processor, a controller, a controlling processor, an object, a thread of execution, a program, and/or a computer. For example, both an application running on a controller or processor and a controller or processor can be a component. One or more components may reside within a process and/or thread of execution, and the components may be located on one device (eg, a system, computing device, etc.) or distributed across two or more devices.

The above description is merely illustrative of the technical spirit of the present disclosure, and various modifications and variations will be possible without departing from the essential characteristics of the present disclosure by those skilled in the art to which the present disclosure pertains. In addition, the present embodiments are not intended to limit the technical spirit of the present disclosure, but rather to explain, so the scope of the present technical spirit is not limited by these embodiments. The protection scope of the present disclosure should be construed by the following claims, and all technical ideas within the scope equivalent thereto should be construed as being included in the scope of the present disclosure.

Claims (24)

In a method for a terminal to receive MBS (Multicast / Broadcast Service) data,
when handover is determined, receiving radio bearer configuration information for MBS session data reception through the target base station through the source base station;
configuring a radio bearer for receiving MBS session data through the target base station based on the radio bearer configuration information; and
Receiving the MBS session data through the radio bearer,
The radio bearer configuration information is information generated by the target base station and transmitted to the source base station. The method of claim 1,
The source base station,
Transmitting a handover request message to the target base station,
The handover request message is
A method comprising at least one of MBS session context information and PDU session context information associated with the MBS session. The method of claim 1,
The MBS session associated with the radio bearer and the MBS session data transmission,
1:N mapping or N:1 mapping is configured, wherein N is a natural number of 1 or more. The method of claim 1,
The target base station,
If the MBS session context for the MBS session data is not configured,
Transmits a message to request MBS session setup to the core network AMF (Access and Mobility Management Function) object,
Receiving a message for starting the MBS session from the AMF entity. The method of claim 1,
The target base station,
If the MBS session context for the MBS session data is not configured,
Method according to claim 1, characterized in that the radio bearer configuration information is generated by using PDU session context information associated with the MBS session for the MBS session data. The method of claim 1,
The target base station,
Method for determining a transmission type for the MBS session data. The method of claim 1,
The target base station,
Transmitting a path switch request message requesting a path change of the MBS session data to the core network AMF (Access and Mobility Management Function) entity,
The path switch request message method, characterized in that it includes MBS session context information. In the method for the target base station to control the reception of MBS (Multicast / Broadcast Service) data of the terminal,
Receiving a handover request message including at least one of MBS session context information for the terminal and PDU session context information associated with the MBS session from the source base station;
generating radio bearer configuration information for receiving the MBS session data of the terminal; and
and transmitting the radio bearer configuration information to the source base station. 9. The method of claim 8,
The MBS session associated with the radio bearer and the MBS session data,
1:N mapping or N:1 mapping is configured, wherein N is a natural number of 1 or more. 9. The method of claim 8,
The generating of the radio bearer configuration information comprises:
If the MBS session context for the MBS session data is not configured in the target base station,
Transmitting a message for requesting the MBS session setup to the core network AMF (Access and Mobility Management Function) entity; and
The method further comprising receiving a message for starting the MBS session from the AMF entity. 9. The method of claim 8,
The generating of the radio bearer configuration information comprises:
If the MBS session context for the MBS session data is not configured in the target base station,
The radio bearer configuration information is generated by using PDU session context information associated with the MBS session for the MBS session data. 9. The method of claim 8,
The generating of the radio bearer configuration information comprises:
Method for determining a transmission type for the MBS session data. 9. The method of claim 8,
Further comprising the step of transmitting a path switch request message requesting a path change of the MBS session data to the core network AMF (Access and Mobility Management Function) entity,
The path switch request message comprises the MBS session context information. In the terminal for receiving MBS (Multicast / Broadcast Service) data,
a receiver configured to receive radio bearer configuration information for receiving MBS session data through a target base station through a source base station when handover is determined; and
A control unit configured to configure a radio bearer for receiving MBS session data through the target base station based on the radio bearer configuration information,
The receiving unit,
Further receiving the MBS session data through the radio bearer,
The radio bearer configuration information is information generated by the target base station and transmitted to the source base station. 15. The method of claim 14,
The source base station,
Transmitting a handover request message to the target base station,
The handover request message is
A terminal including at least one of MBS session context information and PDU session context information associated with the MBS session. 15. The method of claim 14,
The MBS session associated with the radio bearer and the MBS session data,
The terminal is configured by 1:N mapping or N:1 mapping, wherein N is a natural number of 1 or more. 15. The method of claim 14,
The target base station,
If the MBS session context for the MBS session data is not configured,
Transmits a message to request MBS session setup to the core network AMF (Access and Mobility Management Function) object,
Terminal, characterized in that receiving a message for starting the MBS session from the AMF entity. 15. The method of claim 14,
The target base station,
If the MBS session context for the MBS session data is not configured,
The terminal, characterized in that for generating the radio bearer configuration information by using the PDU session context information associated with the MBS session for the MBS session data. 15. The method of claim 14,
The target base station,
Method for determining a transmission type for the MBS session data. In the target base station for controlling MBS (Multicast / Broadcast Service) data reception of the terminal,
a receiving unit for receiving a handover request message including at least one of MBS session context information for the terminal and PDU session context information associated with the MBS session from the source base station;
a control unit for generating radio bearer configuration information for receiving the MBS session data of the terminal; and
and a transmitter for transmitting the radio bearer configuration information to the source base station. 21. The method of claim 20,
The MBS session associated with the radio bearer and the MBS session data,
1:N mapping or N:1 mapping is configured, wherein N is a natural number of 1 or more. 21. The method of claim 20,
If the MBS session context for the MBS session data is not configured in the target base station,
The transmitter transmits a message for requesting MBS session setup to a core network AMF (Access and Mobility Management Function) entity,
The receiving unit, a target base station for receiving a message for starting the MBS session from the AMF entity. 21. The method of claim 20,
The control unit is
If the MBS session context for the MBS session data is not configured in the target base station,
Target base station, characterized in that for generating the radio bearer configuration information by using the PDU session context information associated with the MBS session for the MBS session data. 21. The method of claim 20,
The transmitter is
Transmitting a path switch request message requesting a path change of the MBS session data to the core network AMF (Access and Mobility Management Function) entity,
The path switch request message target base station, characterized in that it includes the MBS session context information.

Images