KR20210118366A - Method for controlling relay node and apparatuses thereof - Google Patents

Abstract

The present disclosure relates to a relay technology. In one aspect, provided is a method, in a method for a target integrated access and backhaul (IAB) donor central unit (CU) to change a parent IAB node of an IAB node, comprising the steps of: receiving a handover request message from a source IAB donor CU; setting up a terminal context for a target parent IAB node and a migration target IAB node; and transmitting an RRC message to the migration target IAB node through a source IAB donor CU.

Description

METHOD FOR CONTROLLING RELAY NODE AND APPARATUSES THEREOF

The present disclosure relates to a technique for controlling an IAB node performing an NR-based radio relay function.

In a wireless communication system, the relay technology is used for the purpose of extending cell coverage by using additional network nodes.

Therefore, the relay technology to which the conventional LTE technology is applied supports data transfer at the IP packet level of the relay node, and only one relay node is configured to transfer the IP packet between the terminal and the base station.

That is, the relay technology to which the conventional LTE technology is applied provides only a single-hop relay function to provide a simple service, and most configurations are directed and configured through static operations, administration and management (OAM). Accordingly, a multi-hop relay could not be configured.

In addition, in the case of supporting multi-hop relay through the conventional LTE technology, data could not be separately processed through a plurality of relay nodes, and there is a problem in that signaling and data processing above the IP layer may increase delay.

In order to solve this problem, research is being conducted on a technology for accurately delivering user data to a base station by configuring a multi-hop, and problems in data processing and retransmission methods are expected when transmitting/receiving data based on multi-hop. In particular, there is a need for a method for solving this when data processing is concentrated on a specific IAB node.

The present disclosure, devised in the above-mentioned background, relates to a method and apparatus for an IAB node performing an NR-based radio relay function to change/migration/modify a serving parent node.

In one aspect, the present disclosure provides a method for a target Integrated Access and Backhaul (IAB) donor (Central Unit) to change a parent IAB node of an IAB node, a handover request from a source IAB donor CU A method comprising the steps of receiving a message, setting up a terminal context for a target parent IAB node and a migrating target IAB node, and sending an RRC message to the migration target IAB node through a source IAB donor CU provides

In one aspect, the present disclosure provides a method for a source Integrated Access and Backhaul (IAB) donor (Central Unit) to change a parent IAB node of an IAB node, the measurement received from the migration target IAB node Determining a change of the parent IAB node of the migration target IAB node based on the information, and when the change of the parent IAB node of the migration target IAB node is determined, transmitting a handover request message to the target IAB donor CU; When the terminal context for the target parent IAB node and the migration target IAB node is set up in the IAB donor CU, receiving an RRC message from the target IAB donor CU and transmitting the RRC message to the migration target IAB node method to include.

In one aspect, the present disclosure provides a handover request message from a source IAB donor CU in a target IAB (Integrated Access and Backhaul) donor (Central Unit) CU that changes the parent IAB node of the IAB node. A target IAB donor comprising a receiving unit that receives, a target parent IAB node, a control unit that sets up a terminal context for a migrating target IAB node, and a transmitting unit that transmits an RRC message to the migration target IAB node through the source IAB donor CU Provides CU devices.

In one aspect, the present disclosure relates to a source IAB (Integrated Access and Backhaul) donor (Central Unit) CU (Central Unit) that changes the parent IAB node of the IAB node, measurement information received from the migration target IAB node. Based on the control unit that determines the change of the parent IAB node of the migration target IAB node, and when the change of the parent IAB node of the migration target IAB node is determined, the transmitter and the target IAB donor transmit a handover request message to the target IAB donor CU When the terminal context for the target parent IAB node and the migration target IAB node is set up in the CU, a receiving unit receiving an RRC message from the target IAB donor CU is included, wherein the transmitting unit transmits the RRC message to the migration target IAB node to provide the source IAB donor CU device.

The present disclosure has the effect of providing a method and apparatus for changing/migrating/modifying a serving parent node by an IAB node performing an NR-based radio relay function.

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 and 9 are diagrams exemplarily illustrating an IAB structure to which the present embodiment can be applied.
10 is a diagram for explaining a relationship between a parent node and a child node for an IAB node to which this embodiment can be applied.
11 is a diagram for explaining the operation of a target Integrated Access and Backhaul (IAB) donor CU (Central Unit) according to an embodiment.
12 is a view for explaining the operation of a source IAB (Integrated Access and Backhaul) donor (Donor) CU (Central Unit) according to an embodiment.
13 is a diagram exemplarily illustrating an Inter IAB-donor-CU movement/adaptation procedure according to an embodiment.
14 is a diagram exemplarily illustrating a protocol stack for F1-C protocol support between IAB nodes according to an embodiment.
15 is a diagram for describing an F1 setup procedure according to an embodiment.
16 is a diagram for explaining the configuration of a target Integrated Access and Backhaul (IAB) donor CU (Central Unit) according to an embodiment.
17 is a diagram for explaining the configuration of a source Integrated Access and Backhaul (IAB) donor CU (Central Unit) 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) that uses evolved-UMTSterrestrial radio access (E-UTRA), and employs OFDMA in the downlink and SC- in the 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 a 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 focusing 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 distinguish gNB or ng-eNB as needed.

<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 the fact 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, 120, 240 kHz. In addition, the extended CP is applied only to the 60 kHz 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 long 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, etc.), 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.

A donor IAB CU (Central Unit) in the present specification may mean a device, part, or configuration corresponding to a central unit in the base station. A base station-CU (gNB-CU) represents a logical node hosting the RRC, SDAP and PDCP protocols of an NR base station (gNB). A donor IAB Distributed Unit (DU) may mean a device, part, or configuration corresponding to a distributed unit within the base station. Base station-DU (gNB-DU) represents a logical node hosting the RLC, MAC and PHY layers of an NR base station (gNB). A CU and a DU may be logically or physically separated. Accordingly, the IAB donor CU and the IAB donor DU may be included in the base station, and each may mean a base station if necessary. The DU may also be configured in an IAB node other than the base station.

Integrated Access and Backhaul (IAB)

The IAB node enables radio relaying in the NG-RAN. The relaying node, referred to as IAB-node, supports access and backhauling via NR. The terminating node of NR backhauling on network side is referred to as the IAB-donor, which represents a gNB with additional functionality to support IAB).

8 and 9 are diagrams exemplarily illustrating an IAB structure to which the present embodiment can be applied.

As shown in FIG. 8 , the IAB node may support a stand alone mode. Alternatively, the IAB node may support a non-stand alone mode as shown in FIG. 9 . The IAB node terminates the NR access interface (NR Uu) to the terminal and the IAB node of the next hop, and the gNB-DU as defined in 3GPP TS 38.401, terminating the F1 protocol to the gNB-CU function for the IAB donor. The IAB-node supports gNB-DU functionality, as defined in TS 38.401, to terminate the NR access interface to UEs and next-hop IAB-nodes, and to terminate the F1 protocol to the gNB-CU functionality, as defined in TS 38.401, on the IAB-donor). (The IAB-node DU is also referred to as IAB-DU.) The IAB node supports a part of the terminal function called IAB-MT (In addition to the gNB-DU) functionality, the IAB-node also supports a subset of the UE functionality referred to as IAB-MT, which includes, eg, physical layer, layer-2, RRC and NAS functionality to connect to the gNB-DU of another IAB-node or the IAB-donor, to connect to the gNB-CU on the IAB-donor, and to the core network).

10 is a diagram for explaining a relationship between a parent node and a child node for an IAB node to which this embodiment can be applied.

Referring to FIG. 10 , with respect to a specific IAB node, the uplink direction is described as a parent node and the downlink direction is described as a child node. The IAB node relays data by performing both IAB-MT and IAB-DU functions.

When a specific IAB node receives data from an upper direction (base station direction, uplink data transmission direction), the IAB-MT function may be used. In contrast, when transmitting downlink data to a child node, a specific IAB node may use the IAB-DU function. Accordingly, the parent node or child node may have both the functions of IAB-MT and IAB-DU. In addition, the terms parent node and child node are determined based on each IAB node, and should be understood as relative terms and concepts.

Meanwhile, the operator may want to change the parent node by increasing the load on the parent node. Alternatively, when the IAB node experiences radio link failure, it may be necessary to change the parent node. In the prior art, an IAB node could only migrate to another parent node under the same IAB donor CU that controls the corresponding IAB node. Accordingly, it is impossible to move to another parent node under an IAB donor CU that is different from the current serving IAB donor CU, so there is a problem in flexibility when the operator wants to move the IAB node in the network operation.

To solve this problem, the present disclosure discloses an embodiment of an operation for providing mobility to another parent node under (under control) different IAB donor CUs.

For convenience of description, an IAB node control method based on NR technology will be described below. However, this is for convenience of description, and the present embodiment may be applied to any radio access technology-based relay. The embodiment provided below may be used when relaying NR technology-based access of an NR terminal to an NR base station through an NR backhaul. The embodiment provided below may be used when the LTE technology-based access of the LTE terminal is relayed to the LTE base station through the NR backhaul. The embodiment provided below may be used when relaying NR technology-based access of an NR terminal to an LTE base station providing EN-DC through an NR backhaul.

11 is a diagram for explaining the operation of a target Integrated Access and Backhaul (IAB) donor CU (Central Unit) according to an embodiment.

Referring to FIG. 11, in a method for a target Integrated Access and Backhaul (IAB) donor CU (Central Unit) to change a parent IAB node of an IAB node, a handover request message from a source IAB donor CU A step of receiving is performed (S1100).

For example, the source IAB donor CU may determine the change of the parent IAB node for a particular IAB node. In this case, the parent IAB node to be changed and the target parent IAB node may operate under the control of different IAB donor CUs. When changing the parent IAB node of a specific IAB node to a parent IAB node controlled by different IAB donor CUs, the target IAB donor CU controlling the target parent IAB node receives a handover request message from the source IAB donor CU can do.

For example, the handover request message includes Backhaul Adaptation Protocol (BAP) address information for the migration target IAB node, Backhaul Adaptation Protocol (BAP) routing ID information, backhaul RLC channel information, IP address information, and IAB DU ( It may include at least one of transport layer address request information for F1 transmission between the distributed unit) and the target IAB donor CU.

As another example, BAP (Backhaul Adaptation Protocol) address information for the migration target IAB node, BAP (Backhaul Adaptation Protocol) routing ID information, backhaul RLC channel information, IP address information, and IAB DU (Distributed Unit) of the migration target IAB node and At least one piece of transport layer address request information for F1 transmission between the target IAB donor CUs may be received by being included as an information field in an RRC container (eg HandoverPreparationInformation message) in a handover request message.

Here, the migration target IAB node means an IAB node that changes the parent IAB node to a node controlled by a different IAB donor CU for any reason. That is, from the point of view of the migration target IAB node, the parent IAB node is changed, and the changed parent IAB node is a node controlled by another IAB donor CU. Therefore, the migration target IAB node can be processed similarly to changing the base station.

The target IAB donor CU performs a step of setting up a terminal context for the target parent IAB node and the migration target IAB node (S1110).

For example, the target IAB donor CU may use information included in the received handover request message to set up a terminal context for the target parent IAB node and the migration target IAB node.

As an example, the target IAB donor CU sends a terminal context setup request message for configuring a backhaul RLC channel and a Backhaul Adaptation Protocol (BAP) layer root entry on a path between the migration target IAB node and the target IAB donor CU, the target parent IAB node can be sent to

For example, the terminal context setup request message may include Backhaul Adaptation Protocol (BAP) address information and backhaul RLC channel information for the migration target IAB node.

As another example, the target parent IAB node may establish a connection by performing a terminal context setup operation with the migration target IAB node using information in the terminal context setup request message.

The target IAB donor CU performs a step of transmitting an RRC message to the migration target IAB node through the source IAB donor CU (S1120).

For example, when terminal context setup of the target parent IAB node and the migration target IAB node is completed, the target IAB donor CU transmits an RRC message to the source IAB donor CU. The source IAB donor CU forwards the received RRC message to the migration target IAB node.

For example, the RRC message may include IP address information allocated to the migration target IAB node. Here, the IP address information is allocated by the target IAB donor CU and delivered to the migration target IAB node through the source IAB donor CU.

The migration target IAB node can receive the IP address information and use the corresponding IP address information when transmitting and receiving data through the target parent IAB node.

Through the above-described operation, a parent IAB node of a specific IAB node (a migration target IAB node) may be changed to an IAB node controlled by another base station (another IAB donor). This has the effect of more efficiently using radio resources from the operator's point of view.

12 is a diagram for explaining the operation of a source IAB (Integrated Access and Backhaul) donor (Central Unit) CU (Central Unit) according to an embodiment.

12, the source IAB (Integrated Access and Backhaul) donor (Central Unit) CU (Central Unit) determines the change of the parent IAB node of the migration target IAB node based on the measurement information received from the migration target IAB node. step may be performed (S1200).

For example, the source IAB donor CU may receive measurement information from the migration target IAB node. The measurement information may include channel state information, data load information on a relay path, and the like. Measurement information may be transferred from the migration target IAB node to the source IAB donor CU through the source parent IAB node.

The source IAB donor CU may determine whether to migrate the migration target IAB node based on the measurement information. For example, the source IAB donor CU may use the measurement information to determine the need to change the current parent IAB node of the migration target IAB node.

When the change of the parent IAB node of the migration target IAB node is determined, the source IAB donor CU may perform a step of transmitting a handover request message to the target IAB donor CU (S1210).

For example, the handover request message includes Backhaul Adaptation Protocol (BAP) address information for the migration target IAB node, Backhaul Adaptation Protocol (BAP) routing ID information, backhaul RLC channel information, IP address information, and IAB DU ( Distributed Unit) and at least one of transport layer address request information for F1 transmission between the target IAB donor CU.

As another example, BAP (Backhaul Adaptation Protocol) address information for the migration target IAB node, BAP (Backhaul Adaptation Protocol) routing ID information, backhaul RLC channel information, IP address information, and IAB DU (Distributed Unit) of the migration target IAB node and At least one piece of transport layer address request information for F1 transmission between the target IAB donor CUs may be transmitted by being included as an information field in an RRC container in the handover request message.

When the terminal context for the target parent IAB node and the migration target IAB node is set up in the target IAB donor CU, the source IAB donor CU may perform a step of receiving an RRC message from the target IAB donor CU (S1220). ).

For example, the target IAB donor CU determines the target parent IAB node assigned to the migration target IAB node based on the handover request message, and controls terminal context setup operations of the target parent IAB node and the migration target IAB node. can do.

When the terminal contexts of the target parent IAB node and the migration target IAB node are set up, the source IAB donor CU receives an RRC message from the target IAB donor CU.

For example, the RRC message may include IP address information allocated to the migration target IAB node.

The source IAB donor CU may perform a step of transmitting the RRC message to the migration target IAB node (S1230).

The source IAB donor CU may forward the received RRC message to the migration target IAB node. The migration target IAB node can receive the IP address information and use the corresponding IP address information when transmitting and receiving data through the target parent IAB node.

Through the above-described operation, a parent IAB node of a specific IAB node (a migration target IAB node) may be changed to an IAB node controlled by another base station (another IAB donor). This has the effect of more efficiently using radio resources from the operator's point of view.

Below, more various embodiments will be described with respect to each operation of the aforementioned IAB donor. Each of the embodiments described below may be applied individually or in any combination.

Procedure embodiment for IAB movement/adaptation through different donor base stations/CUs

First, a detailed procedure is needed to provide a move to another parent node under a different IAB donor CU. In this procedure, the target parent node is served by a target IAB donor CU different from the source IAB donor CU. In the corresponding procedure, the target parent node may use a target IAB donor DU different from the source IAB donor DU.

13 is a diagram exemplarily illustrating an Inter IAB-donor-CU movement/adaptation procedure according to an embodiment.

In FIG. 13, for convenience of description, the source donor DU is omitted between the source parent IAB node and the source donor CU. Also, the target donor DU is omitted between the target parent IAB node and the target donor CU. This is for convenience of understanding, and the IAB donor CU may transmit/receive related data through the IAB donor DU.

Referring to FIG. 13 , the parent IAB node of the migration target IAB node may be changed through the following operation.

1. The migrating IAB node MT may forward the measurement report message to the source parent IAB node.

2. The source parent IAB node DU sends a UL RRC Transfer message to the source IAB donor CU to transfer the received measurement report.

3. For example, the source IAB donor CU transmits a handover request message to the target IAB donor CU. For another example, the source IAB donor CU transmits a move/adapt request message on the Xn interface for the move/adapt request procedure to the target IAB donor CU. For convenience of explanation, a corresponding message is hereinafter referred to as a handover request message, and the following embodiments may be equally applied to the above-described movement/adaptation request message.

For example, the handover request message may include an RRC container (Handoverpreparation message) having information necessary for the target side to prepare for handover. An embodiment of the handover request message or the information included in the RRC container included in the handover request message will be separately described later.

4. Acceptance control may be performed by the target IAB donor CU. To create a terminal context for the moving IAB node MT and to set up one or more bearers, the target IAB donor CU sends a terminal context setup request message to the target parent IAB node DU. These bearers are used by the moving IAB node MT to carry its own data and signaling traffic. A backhaul RLC channel mapping rule for transmitting own data and signaling traffic may be included together by the corresponding IAB node MT.

5. The target parent IAB node DU transmits a terminal context setup response message to the target IAB donor CU.

6. The target IAB donor CU prepares for handover/movement/adaptation with the L1/L2 configuration for the moving IAB node MT. For example, the target IAB donor CU sends a handover request confirmation message to the source IAB donor CU. For another example, the target IAB donor CU sends a move/adaptation confirmation message on the Xn interface for the move/adaptation procedure to the source IAB donor CU. For convenience of explanation, a corresponding message is hereinafter referred to as a handover request confirmation message. Information included in the handover request confirmation message or the RRC container (RRC reconfiguration message) included in the handover request confirmation message will be separately described later.

7. The source IAB donor CU transmits a terminal context modification request message to the source parent IAB node. The corresponding message may include the generated RRC reconfiguration message.

8. The source parent IAB node DU forwards the received RRC reconfiguration message to the moving IAB node MT.

9. The source parent IAB node DU transmits a terminal context modification response message to the source IAB donor CU.

10. The moving IAB node MT may perform a random access procedure with the target parent IAB node DU.

11. The moving IAB node MT transmits an RRC reconfiguration complete message to the target parent IAB node DU.

12. In order to transfer the received RRC reconfiguration complete message, the target parent IAB node DU sends an uplink RRC Transfer message to the target IAB donor CU.

After receiving the uplink RRC Transfer message, the target IAB donor CU configures a backhaul RLC channel and a BAP layer root entry on the target path between the moving IAB node and the target IAB donor CU.

After receiving the uplink RRC Transfer message, all F1-U tunnels and F1-Cs between the moving IAB node DU and the IAB donor CU may be switched/changed/modified. In this case, as an example, a transport network layer address (TNL address) allocated by the moving IAB node may be used. As another example, the transport network layer address of the moving IAB node allocated and received from the target IAB donor CU may be used. For example, an IAB node DU moving for an F1-U tunnel and/or F1-C switch/change/modification may initiate an F1-C setup procedure with a target IAB donor CU. The moving IAB node DU may receive information related to an access cell to provide a radio access service and/or a backhaul link to provide a backhaul service from the target IAB donor CU. The moving IAB node DU may apply/modify/change/resume the configuration for the corresponding cell and/or backhaul link with the received information. For another example, the moving IAB node DU may initiate the F1-C setup procedure with the target IAB donor CU. The moving IAB node DU may receive information related to an access cell to provide a radio access service and/or a backhaul link to provide a backhaul service from the target IAB donor CU. The moving IAB node DU may apply/modify/change/resume the configuration for the corresponding cell and/or backhaul link with the received information. This will be described later.

As another example, the operation of configuring the backhaul RLC channel and the BAP layer root entry on the target path between the IAB node to which the target IAB donor CU moves and the target IAB donor CU may be performed faster than step 12 . For example, it may be performed after step 4 . For another example, in step 4, the terminal context setup request message includes related information (e.g. backhaul RLC channel and BAP layer root entry) and may be transmitted and performed after receiving the message.

13. The target IAB donor CU can perform AMF and PATH SWITCH procedures. Upon receiving the PATH SWITCH REQUEST ACKNOWLEDGE message from the AMF, the target IAB donor CU transmits a terminal context release request message to the source IAB donor CU to notify the handover success.

14. The source IAB donor CU sends a terminal context release command message to the source parent IAB node DU.

15. The source parent IAB node DU releases the context of the moving IAB node MT and responds to the source IAB donor CU with a terminal context release complete message.

The source donor CU may release the backhaul RLC channel and BAP layer root entry on the source path between the moving IAB node and the source IAB donor CU.

Through the above-described operation, the parent IAB node of the migration target IAB node may be changed to an IAB node controlled by another base station.

An embodiment of transferring radio access cell/backhaul link information associated with an IAB node from a source base station (source IAB donor CU) to a target base station (target IAB donor CU)

As described above, the source IAB donor CU may transmit information necessary for changing the parent IAB node of the migration target IAB node to the target IAB donor CU through a handover request message or the like.

The handover request message according to the prior art specified in TS 38.423 includes target cell information, corresponding UE identification information, and UE context information required to configure a handover command (e.g. RRC reconfiguration with sync) for the UE. Specifically, the handover request message includes a source base station terminal XnAP identifier (Source NG-RAN node UE XnAP ID reference), a target cell global identifier (Target CGI: Cell Global ID), a GUAMI (Globally Unique AMF Identifier), UE History Information, a terminal Global NG-RAN Node ID, S-NG-RAN node UE XnAP ID included in context reference, and AMF UE NGAP ID (NG-C UE associated Signaling reference) included in UE context information, AMF's IP address of the SCTP association (Signalling TNL association address at source NG-C side), UE security capabilities, AS security information, Index to RAT/Frequency Selection Priority, UE Aggregate Maximum Bit Rate, PDU session information to be set up (PDU Session) Resources To Be Setup List), HandoverPreparationInformation message (RRC context), Location Reporting Information, and at least one of the Mobility Restriction List was included.

If you want to provide a movement/adaptation/handover procedure for the IAB node MT, the handover request message (or the RRC container included in the handover request message) includes the target cell information required to configure the RRC reconfiguration message for the IAB MT and The corresponding IAB MT identification information and the corresponding IAB MT context information may be included.

On the other hand, the IAB node includes IAB MT as well as IAB DU function. Accordingly, the handover request message (or the RRC container included in the handover request message) may additionally include information necessary to generate a configuration for the IAB DU (or IAB node).

For example, the handover request message includes Backhaul Adaptation Protocol (BAP) address information for the migration target IAB node, Backhaul Adaptation Protocol (BAP) routing ID information, backhaul RLC channel information, IP address information, and IAB DU of the migration target IAB node. It may include at least one of transport layer address request information for F1 transmission between (Distributed Unit) and the target IAB donor CU.

For example, the handover request message may include radio access cell/backhaul link information for providing an IAB DU function terminating the NR access interface (NR Uu) to the terminal and the IAB node of the next hop. An IAB node may include one or more radio access cells/backhaul links. Accordingly, the handover request message (or the RRC container included in the handover request message) may include one or more radio access cells/backhaul link information. The one or more radio access cells/backhaul link information may include cell identification information, for example, one or more of NR CGI and PCI information. For another example, the handover request message may include BAP routing entry information, IP address information, and backhaul RLC channel information of the moving IAB node. Corresponding information included in the handover request message may be information related to a radio access cell/backhaul link.

Through this, the target IAB donor CU may maintain one or more of radio access cell/backhaul link information, BAP routing entry information, IP address information, and backhaul RLC channel information. Here, the BAP routing entry information indicates information for performing routing in the IAB node. For example, it may include a BAP routing ID and a next hop BAP address. Routing in the IAB node uses the BAP routing ID in the BAP layer. BAP routing ID is configured through RRC message by IAB donor CU, and consists of BAP address and BAP Path ID. For example, for a user packet, the BAP routing ID is carried in the packet's BAP header, and the IAB node uses the BAP routing ID to determine the next hop node (or BAP address of the next hop node) to be mapped.

An embodiment of transferring information for TNL setup and F1 setup from a source base station (source IAB donor CU) to a target base station (target IAB donor CU) to quickly perform IAB node DU part setup

When a moving IAB node MT moves/adapts to another parent node under the same IAB donor CU that controls the IAB node, the moving IAB node DU moves because F1 setup with the IAB donor CU has already been performed. A new F1 setup was unnecessary between the IAB node DU and the IAB donor CU. However, when moving to a parent node controlled by another IAB donor CU as in the present embodiment, the migration target IAB node DU may need to set up F1 with the target IAB donor CU.

14 is a diagram exemplarily illustrating a protocol stack for F1-C protocol support between IAB nodes according to an embodiment.

Referring to FIG. 14 , in order for an IAB node to perform a radio relay function, an IAB node integration procedure must be performed. The IAB node integration procedure includes IAB DU setup. IAB DU setup initiates the transport network layer setup. Indicates that the DU function is configured by initiating the F1 setup procedure between the IAB DU and the IAB donor CU. According to TS38.473, the 3GPP standard specification for the F1 application protocol, the F1 setup procedure is a procedure for exchanging application-level data necessary for correct interaction on the F1 interface between DU and CU. TNL linkage between DU and CU cannot be operated. (The purpose of the F1 Setup procedure is to exchange application level data needed for the gNB-DU and the gNB-CU to correctly interoperate on the F1 interface. This procedure shall be the first F1AP procedure triggered for the F1- C interface instance after a TNL association has become operational). Also, as shown in FIG. 15, the corresponding procedure was triggered only by the DU.

15 is a diagram for describing an F1 setup procedure according to an embodiment.

Referring to FIG. 15 , when an F1 setup is required, the gNB-DU 1500 transmits an F1 setup request message to the gNB-CU 1550 ( S1510 ). This initiates the F1 setup procedure. Thereafter, the gNB-CU 1550 performs F1 setup and transmits an F1 setup response message to the gNB-DU 1500 ( S1520 ).

Therefore, when the moving IAB node MT moves/adapts to another parent node under the same IAB donor CU that controls the IAB node, the F1 setup procedure has already been performed between the IAB node DU and the IAB donor CU. No additional F1 setup required.

However, as described above, when the moving IAB node MT moves/adapts to the parent node under the target IAB donor CU different from the source IAB donor CU controlling the corresponding IAB node, the moving IAB node DU and the target IAB donor Since F1 setup is not performed between CUs, F1 setup needs to be preceded in order for a moving IAB node DU to transmit/receive data through a target IAB donor CU.

However, in the prior art, when the F1 setup procedure is performed, any application-level configuration data and signaling connection existing between two nodes, such as a reset procedure, are erased. And this procedure erases any existing application level configuration data in the two nodes and replaces it by the one received. This procedure also re-initialises the F1AP UE-related contexts (if any) and erases all related signaling connections in the two nodes like a Reset procedure would do).

Therefore, if the moving IAB node DU performs F1 setup at any time after step 11 or step 12 of FIG. 13, there may be a problem in that the terminal context of the IAB node MT or the IAB node DU is reinitialized or erased. . Also, service interruption may occur during the corresponding F1 setup.

In order to solve this problem, the present disclosure intends to propose the following embodiments. The examples below may be applied individually or in any combination.

first embodiment

For example, after step 11 or after step 12 of FIG. 13 , the following procedure may be performed.

1. The moving IAB node DU sends an F1 setup request message to the target IAB donor CU.

For example, the F1 setup request message may include one or more of an IAB node DU ID, a cell/backhaul link list serviced by the IAB node DU, and Transport Network Layer (TNL) address information (e.g. IP address). For example, the cell/backhaul link list serviced by the IAB node DU included in the F1 setup request message indicates a cell/backhaul link list associated with the moving IAB node. And TNL (Transport Network Layer) address information represents the transport layer address request information of the IAB node for F1 transmission between the transport layer address information (IP address) or the IAB node DU and the target IAB donor CU requested for the moving IAB node. can Alternatively, in the F1 setup request message, the cell/backhaul link list serviced by the IAB node DU includes serviced cell information (NR CGI, NR PCI, Tracking Area Code (TAC), PLMN Id, Measurement timing configuration, RANAC) and system information. It may include more than one. The TNL address information may include one or more of IP Sec Transport Address information and GTP Transport Layer Addresses. For example, the TNL address information may include a Transport Layer Address (e.g. IP address) and a GTP-TEID for the GTP tunnel. For Transport Layer Address, the matters described in 3GPP TS 38.414 can be applied. For example, the Transport Layer Address may be a Transport Layer address and a downlink TEID in the IAB node DU.

2. The target IAB donor CU sends an F1 setup response message to the moving IAB node DU.

For example, the F1 setup response message may include one or more of an IAB node CU ID, a cell/backhaul link list to be activated in the IAB node DU, and TNL address information. The cell/backhaul link list activated in the IAB node DU included in the F1 setup response message indicates a cell/backhaul link list to be activated associated with the moving IAB node determined by the target IAB donor CU. And Transport Network Layer (TNL) address information may indicate transport layer address information (IP address) for a moving IAB node allocated by the target IAB donor CU. The target IAB donor CU may be included in the request message by determining/allocating the transport layer address based on the requested transport layer address information (IP address) or the transport layer address request information.

For example, the TNL address information may be a Transport Layer address or an uplink TEID in the target IAB donor CU/target IAB donor CU-UP. As another example, the TNL address information may be a Transport Layer address or an uplink TEID in the target IAB donor DU. Alternatively, the F1 setup response message may include NR CGI and NR PCI for a cell to be activated/backhaul link list to be activated in the IAB node DU.

3. The target IAB donor CU transmits a terminal context setup request message (or terminal context modification request message) to the moving IAB node DU.

4. If the terminal context setup is successful, the moving IAB node DU transmits a terminal context setup response message (or terminal context modification response message) to the target IAB donor CU.

second embodiment

Meanwhile, as another example, after step 11 or after step 12, the following procedure may be performed.

1. The moving IAB node DU sends an F1 setup request message to the target IAB donor CU.

For example, the F1 setup request message may include one or more of an IAB node DU ID, a cell/backhaul link list serviced by the IAB node DU, and TNL address information. Alternatively, in the F1 setup request message, the cell/backhaul link list serviced by the IAB node DU includes serviced cell information (NR CGI, NR PCI, Tracking Area Code (TAC), PLMN Id, Measurement timing configuration, RANAC) and system information. It may include more than one. The TNL address information may include one or more of IP Sec Transport Address information and GTP Transport Layer Addresses. For example, the TNL address information may include a Transport Layer Address (e.g. IP address) and GTP-TEID for the GTP tunnel, and TS 38.414 may be referred to for the Transport Layer Address.

2. The target IAB donor CU sends an F1 setup response message to the moving IAB node DU.

For example, the F1 setup response message may include one or more of an IAB node CU ID, a cell/backhaul link list to be activated in the IAB node DU, and TNL address information. The F1 setup response message may include NR CGI and NR PCI for a cell to be activated/backhaul link list to be activated in the IAB node DU.

3. The moving IAB node DU transmits a UE CONTEXT MODIFICATION REQUIRED message to the target IAB donor CU.

4. The target IAB donor CU sends a UE CONTEXT MODIFICATION CONFIRM message to the moving IAB node DU to report the successful update of the UE context.

third embodiment

As another example, after step 11 or after step 12, the following procedure may be performed.

1. The moving IAB node DU transmits a request message for simultaneously performing F1 setup and UE context modification to the target IAB donor CU.

For example, the request message may be a new message distinct from the F1 setup request message or the terminal context modification required message. Alternatively, the request message may be an improved message including an additional trigger condition and related information in the F1 setup request message or the terminal context modification required message. The request message may include all or part of the information included in the F1 setup request message or the terminal context modification required message.

2. The target IAB donor CU transmits a response message for simultaneously performing a response to F1 setup and UE context modification to the moving IAB node DU.

The corresponding response message may be a new message distinct from the F1 setup response message or the terminal context modification confirmation message. Alternatively, the response message may be an improved message including additional response conditions and related information in the F1 setup request message or the terminal context modification confirm message. The corresponding response message may include all or part of information included in the F1 setup response message or the terminal context modification confirmation message.

4th embodiment

As another example, the following procedure may be performed.

It will be described with reference to FIG. 13 again.

1. The IAB node MT moving in step 11 may include information for requesting/indicating F1 setup and/or terminal context modification in an RRC Reconfiguration Complete message to the target parent IAB node.

2. In step 12, the target parent IAB node may transmit the RRC message to the target IAB donor CU through the uplink RRC Transfer message.

3. The target IAB donor CU transmits a terminal context setup request message (or terminal context modification request message) to the moving IAB node DU.

4. If the terminal context setup is successful, the moving IAB node DU transmits a terminal context setup response message (or terminal context modification response message) to the target IAB donor CU.

5th embodiment

As another example, the following procedure may be performed.

1. In step 3 of FIG. 13, the source IAB donor CU transmits a handover request message to the target IAB donor CU. The handover request message may include information for requesting/instructing F1 setup and/or terminal context modification/setup for the moving IAB node DU. The handover request message may include one or more of information included in the aforementioned F1 setup request message and/or terminal context modification/setup request message.

2. In step 6 of FIG. 13 , the target IAB donor CU sends a handover request confirmation message to the source IAB donor CU. The handover request confirmation message may include information for responding/confirming/confirming the F1 setup and/or terminal context modification/setup for the moving IAB node DU. Alternatively, the handover request confirmation message may include one or more of information included in the aforementioned F1 setup response message and/or terminal context modification response/confirmation/confirmation message.

3. The RRC Reconfiguration message included in step 6/step 7/step 8 of FIG. 13 includes information for responding/confirming/confirming the F1 setup and/or terminal context modification/setup for the moving IAB node DU. can The corresponding information may include one or more of information included in the aforementioned F1 setup response message and/or terminal context modification response/confirmation/confirmation message.

Through the operations described above, the present disclosure can improve radio resource efficiency by effectively moving a specific IAB node to a parent IAB node belonging to a different base station or CU.

Hereinafter, the configuration of the aforementioned IAB donor CU will be briefly described with reference to the drawings. All of the above-described operations may be performed according to each of the following configurations. In addition, the IAB donor CU may be replaced with a base station term, and in this case, the present disclosure may also be applied.

16 is a diagram for explaining the configuration of a target Integrated Access and Backhaul (IAB) donor CU (Central Unit) according to an embodiment.

Referring to FIG. 16 , the target IAB (Integrated Access and Backhaul) donor CU 1600 that changes the parent IAB node of the IAB node is a receiving unit that receives a handover request message from the source IAB donor CU. 1630 and a control unit 1610 that sets up a terminal context for the target parent IAB node and the migration target IAB node, and a transmission unit 1620 for transmitting an RRC message to the migration target IAB node through the source IAB donor CU may include.

For example, the controller 1610 may determine a change of the parent IAB node for a specific IAB node. In this case, the parent IAB node to be changed and the target parent IAB node may operate under the control of different IAB donor CUs. When changing the parent IAB node of a specific IAB node to a parent IAB node controlled by different IAB donor CUs, the receiver 1630 of the target IAB donor CU 1600 controlling the target parent IAB node is the source IAB donor A handover request message may be received from the CU.

For example, the handover request message includes Backhaul Adaptation Protocol (BAP) address information for the migration target IAB node, Backhaul Adaptation Protocol (BAP) routing ID information, backhaul RLC channel information, IP address information, and IAB DU ( Distributed Unit) and at least one of transport layer address request information for F1 transmission between the target IAB donor CU.

As another example, BAP (Backhaul Adaptation Protocol) address information for the migration target IAB node, BAP (Backhaul Adaptation Protocol) routing ID information, backhaul RLC channel information, IP address information, and IAB DU (Distributed Unit) of the migration target IAB node and At least one piece of transport layer address request information for F1 transmission between the target IAB donor CUs may be received as an information field included in the RRC container in the handover request message.

Meanwhile, the controller 1610 may set up a terminal context for the target parent IAB node and the migration target IAB node using information included in the received handover request message.

As an example, the control unit 1610 transmits a terminal context setup request message for configuring a backhaul RLC channel and a Backhaul Adaptation Protocol (BAP) layer root entry on a path between the migration target IAB node and the target IAB donor CU to the target parent IAB node. can be controlled to be transmitted to The transmitter 1620 transmits the terminal context setup request message to the target parent IAB node.

For example, the terminal context setup request message may include Backhaul Adaptation Protocol (BAP) address information and backhaul RLC channel information for the migration target IAB node. The target parent IAB node may establish a connection by performing a terminal context setup operation with the migration target IAB node using information in the terminal context setup request message.

Also, when the terminal context setup of the target parent IAB node and the migration target IAB node is completed, the transmitter 1620 transmits an RRC message to the target IAB donor CU to the source IAB donor CU. The source IAB donor CU forwards the received RRC message to the migration target IAB node.

For example, the RRC message may include IP address information allocated to the migration target IAB node. Here, the IP address information is allocated by the target IAB donor CU and delivered to the migration target IAB node through the source IAB donor CU. The migration target IAB node can receive the IP address information and use the corresponding IP address information when transmitting and receiving data through the target parent IAB node.

In addition to this, the controller 1610 controls the overall operation of the target IAB donor CU 1600 according to the relay control method necessary for performing the above-described embodiments.

The transmitter 1620 and the receiver 1630 are used to transmit/receive signals, messages, and data necessary for performing the above-described embodiment with the IAB node and the source IAB donor CU.

17 is a diagram for explaining the configuration of a source Integrated Access and Backhaul (IAB) donor CU (Central Unit) according to an embodiment.

Referring to FIG. 17 , in the source IAB (Integrated Access and Backhaul) Donor CU 1700, based on the measurement information received from the migration target IAB node, a change of the parent IAB node of the migration target IAB node is determined. When the change of the parent IAB node of the migration target IAB node is determined with the control unit 1710, the transmitter 1720 for transmitting a handover request message to the target IAB donor CU and the target IAB donor CU migrate to the target parent IAB node (Migrating) When the terminal context for the target IAB node is set up, it includes a receiving unit 1730 for receiving the RRC message from the target IAB donor CU. The transmitter 1720 may transmit the RRC message to the migration target IAB node.

For example, the receiver 1730 may receive measurement information from the migration target IAB node. The measurement information may include channel state information, data load information on a relay path, and the like. Measurement information may be transferred from the migration target IAB node to the source IAB donor CU through the source parent IAB node.

The controller 1710 may determine whether to migrate the migration target IAB node based on the measurement information. For example, the controller 1710 may determine the need to change the current parent IAB node of the migration target IAB node by using the measurement information.

On the other hand, the handover request message includes Backhaul Adaptation Protocol (BAP) address information for the migration target IAB node, Backhaul Adaptation Protocol (BAP) routing ID information, backhaul RLC channel information, IP address information, and IAB DU (Distributed DU) of the migration target IAB node. Unit) and at least one of transport layer address request information for F1 transmission between the target IAB donor CU.

As another example, BAP (Backhaul Adaptation Protocol) address information for the migration target IAB node, BAP (Backhaul Adaptation Protocol) routing ID information, backhaul RLC channel information, IP address information, and IAB DU (Distributed Unit) of the migration target IAB node and At least one piece of transport layer address request information for F1 transmission between the target IAB donor CUs may be transmitted by being included as an information field in an RRC container in the handover request message.

For example, the target IAB donor CU determines the target parent IAB node assigned to the migration target IAB node based on the handover request message, and controls terminal context setup operations of the target parent IAB node and the migration target IAB node. can do.

When the terminal context of the target parent IAB node and the migration target IAB node is set up, the receiving unit 1730 receives the RRC message from the target IAB donor CU. For example, the RRC message may include IP address information allocated to the migration target IAB node.

The transmitter 1720 may transmit the received RRC message to the migration target IAB node. The migration target IAB node can receive the IP address information and use the corresponding IP address information when transmitting and receiving data through the target parent IAB node.

In addition to this, the controller 1710 controls the overall operation of the source IAB donor CU 1700 according to the relay control method necessary for performing the above-described embodiments.

The transmitter 1720 and the receiver 1730 are used to transmit/receive signals, messages, and data necessary for performing the above-described embodiment with the IAB node and the target IAB donor CU.

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 for performing 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 (22)

In the method for the target IAB (Integrated Access and Backhaul) donor (Donor) CU (Central Unit) to change the parent (Parents) IAB node of the IAB node,
receiving a handover request message from a source IAB donor CU;
setting up a terminal context for the target parent IAB node and the migration target IAB node; and
sending an RRC message to the migration target IAB node via the source IAB donor CU. The method of claim 1,
The handover request message is
Backhaul Adaptation Protocol (BAP) address information for the migration target IAB node, Backhaul Adaptation Protocol (BAP) routing ID information, backhaul RLC channel information, IP address information, and IAB DU (Distributed Unit) of the migration target IAB node and the target A method comprising at least one of transport layer address request information for F1 transmission between IAB donor CUs. 3. The method of claim 2,
Backhaul Adaptation Protocol (BAP) address information for the migration target IAB node, Backhaul Adaptation Protocol (BAP) routing ID information, backhaul RLC channel information, IP address information, and IAB DU (Distributed Unit) of the migration target IAB node and the target At least one of the transport layer address request information for F1 transmission between IAB donor CUs,
A method included in the RRC container in the handover request message. The method of claim 1,
The step of setting up the terminal context is,
Transmitting a terminal context setup request message for configuring a backhaul RLC channel and a Backhaul Adaptation Protocol (BAP) layer root entry on a path between the migration target IAB node and the target IAB donor CU to the target parent IAB node. How to include more. 5. The method of claim 4,
The terminal context setup request message is,
A method including Backhaul Adaptation Protocol (BAP) address information and the backhaul RLC channel information for the migration target IAB node. The method of claim 1,
The RRC message transmitted to the migration target IAB node through the source IAB donor CU is,
Method including IP address information allocated to the migration target IAB node. 7. The method of claim 6,
The IP address information is
The method is allocated by the target IAB donor CU and delivered to the migration target IAB node through the source IAB donor CU. In a method for a source IAB (Integrated Access and Backhaul) donor (Central Unit) CU (Central Unit) to change the parent IAB node of the IAB node,
determining a change of a parent IAB node of the migration target IAB node based on measurement information received from the migration target IAB node;
transmitting a handover request message to the target IAB donor CU when the change of the parent IAB node of the migration target IAB node is determined;
receiving an RRC message from the target IAB donor CU when a terminal context for a target parent IAB node and the migration target IAB node is set up in the target IAB donor CU; and
and sending the RRC message to the migration target IAB node. 9. The method of claim 8,
The handover request message is
Backhaul Adaptation Protocol (BAP) address information for the migration target IAB node, Backhaul Adaptation Protocol (BAP) routing ID information, backhaul RLC channel information, IP address information, and IAB DU (Distributed Unit) of the migration target IAB node and the target A method comprising at least one of transport layer address request information for F1 transmission between IAB donor CUs. 9. The method of claim 8,
The RRC message is
Method including IP address information allocated to the migration target IAB node. 11. The method of claim 10,
The IP address information is
How the target IAB donor CU allocates. In the target IAB (Integrated Access and Backhaul) Donor CU (Central Unit) to change the parent IAB node IAB node,
a receiving unit for receiving a handover request message from the source IAB donor CU;
a control unit for setting up a terminal context for the target parent IAB node and the migration target IAB node; and
and a transmitter configured to transmit an RRC message to the migration target IAB node through the source IAB donor CU. 13. The method of claim 12,
The handover request message is
Backhaul Adaptation Protocol (BAP) address information for the migration target IAB node, Backhaul Adaptation Protocol (BAP) routing ID information, backhaul RLC channel information, IP address information, and IAB DU (Distributed Unit) of the migration target IAB node and the target A target IAB donor CU including at least one of transport layer address request information for F1 transmission between IAB donor CUs. 14. The method of claim 13,
Backhaul Adaptation Protocol (BAP) address information for the migration target IAB node, Backhaul Adaptation Protocol (BAP) routing ID information, backhaul RLC channel information, IP address information, and IAB DU (Distributed Unit) of the migration target IAB node and the target At least one of the transport layer address request information for F1 transmission between IAB donor CUs,
A target IAB donor CU included in the RRC container in the handover request message. 13. The method of claim 12,
The transmitter is
A target for further transmitting a terminal context setup request message for configuring a backhaul RLC channel and a Backhaul Adaptation Protocol (BAP) layer root entry on a path between the migration target IAB node and the target IAB donor CU to the target parent IAB node IAB donor CU. 16. The method of claim 15,
The terminal context setup request message is,
A target IAB donor CU including Backhaul Adaptation Protocol (BAP) address information and the backhaul RLC channel information for the migration target IAB node. 13. The method of claim 12,
The RRC message transmitted to the migration target IAB node through the source IAB donor CU is,
A target IAB donor CU including IP address information allocated to the migration target IAB node. 18. The method of claim 17,
The IP address information is
A target IAB donor CU allocated by the target IAB donor CU and delivered to the migration target IAB node through the source IAB donor CU. In the source IAB (Integrated Access and Backhaul) Donor CU (Central Unit) that changes the parent IAB node of the IAB node,
a control unit that determines a change of a parent IAB node of the migration target IAB node based on measurement information received from the migration target IAB node;
a transmitter configured to transmit a handover request message to a target IAB donor CU when the change of the parent IAB node of the migration target IAB node is determined; and
When a terminal context for a target parent IAB node and the migration target IAB node is set up in the target IAB donor CU, a receiver configured to receive an RRC message from the target IAB donor CU;
The transmitter is
A source IAB donor CU that transmits the RRC message to the migration target IAB node. 20. The method of claim 19,
The handover request message is
Backhaul Adaptation Protocol (BAP) address information for the migration target IAB node, Backhaul Adaptation Protocol (BAP) routing ID information, backhaul RLC channel information, IP address information, and IAB DU (Distributed Unit) of the migration target IAB node and the target A source IAB donor CU containing at least one of transport layer address request information for F1 transfer between IAB donor CUs. 20. The method of claim 19,
The RRC message is
A source IAB donor CU including IP address information allocated to the migration target IAB node. 22. The method of claim 21,
The IP address information is
The source IAB donor CU, characterized in that the target IAB donor CU allocates.

Images