KR20240003872A - Method and apparatus for controlling handover - Google Patents

Abstract

In the handover control method, the present disclosure provides a method for controlling mobile relays and terminals served by mobile relays to migrate/move/handover between different donor base stations.

Description

Handover control method and device {METHOD AND APPARATUS FOR CONTROLLING HANDOVER}

The present invention proposes a handover control method and device for a mobile communication system.

In one aspect, the present embodiments may provide a method of controlling a mobile relay and a terminal served by the mobile relay to migrate/move/handover between different donor base stations.

Figure 1 is a diagram briefly illustrating the structure of an NR wireless communication system to which this embodiment can be applied.
Figure 2 is a diagram for explaining the frame structure in an NR system to which this embodiment can be applied.
FIG. 3 is a diagram illustrating a resource grid supported by wireless access technology to which this embodiment can be applied.
Figure 4 is a diagram for explaining the bandwidth part supported by the wireless access technology to which this embodiment can be applied.
Figure 5 is a diagram illustrating a synchronization signal block in a wireless access technology to which this embodiment can be applied.
Figure 6 is a diagram for explaining a random access procedure in wireless access technology to which this embodiment can be applied.
Figure 7 is a diagram to explain CORESET.
Figure 8 is a diagram showing an example of the IAB structure according to this embodiment.
FIG. 9 is a diagram illustrating an example of the relationship between a parent node and a child node for an IAB node according to this embodiment.
Figure 10 is a diagram illustrating an example of the F1-U protocol stack according to this embodiment.
FIG. 11 is a diagram illustrating an example of a protocol stack for terminal access using mobile relaying according to this embodiment.
Figure 12 is a diagram showing an example of the BAP data PDU format according to this embodiment.
Figure 13 is a diagram illustrating an example of the Inter IAB-donor-CU topology adaptation procedure according to this embodiment.
FIG. 14 is a diagram illustrating an example of a protocol structure in mobile relay handover according to this embodiment.
FIG. 15 is a diagram illustrating an example of a protocol structure in mobile relay handover according to this embodiment.
FIG. 16 is a diagram illustrating an example of a protocol structure in mobile relay handover according to this embodiment.
Figure 17 is a diagram showing the configuration of a base station according to another embodiment.
Figure 18 is a diagram showing the configuration of a user terminal according to another embodiment.

Hereinafter, some embodiments of the present disclosure will be described in detail with reference to illustrative drawings. In adding reference numerals to components in each drawing, the same components may have the same reference numerals as much as possible even if they are shown in different drawings. Additionally, 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 may be omitted. When “comprises,” “has,” “consists of,” etc. mentioned in the specification are used, other parts may be added unless “only” is used. When a component is expressed in the singular, it can also include the plural, unless specifically stated otherwise.

Additionally, in describing the components of the present disclosure, terms such as first, second, A, B, (a), and (b) may be used. These terms are only used to distinguish the component from other components, and the nature, sequence, order, or number of the components are not limited by the term.

In the description of the positional relationship of 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 should be understood that two or more components and other components may be further "interposed" and "connected," "combined," 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 temporal flow relationships related to components, operation methods, production methods, etc., for example, temporal precedence relationships such as “after”, “after”, “after”, “before”, etc. Or, when a sequential relationship is described, non-continuous cases may be included unless “immediately” or “directly” is used.

On the other hand, when a numerical value or corresponding information (e.g., level, etc.) for a component is mentioned, even if there is no separate explicit description, the numerical value or corresponding information is related to various factors (e.g., process factors, internal or external shocks, It can be interpreted as including the error range that may occur due to noise, etc.).

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

The present embodiments disclosed below can be applied to wireless communication systems using various wireless access technologies. For example, the present embodiments include code division multiple access (CDMA), frequency division multiple access (FDMA), time division multiple access (TDMA), orthogonal frequency division multiple access (OFDMA), and single carrier frequency division multiple access (SC-FDMA). Alternatively, it can be applied to a variety of different wireless access technologies such as NOMA (non-orthogonal multiple access). In addition, wireless access technology not only refers to a specific access technology, but also refers to communication technology for each generation established by various communication consultative organizations such as 3GPP, 3GPP2, WiFi, Bluetooth, IEEE, and ITU. For example, CDMA can be implemented as a wireless technology such as universal terrestrial radio access (UTRA) or CDMA2000. TDMA may be implemented with wireless technologies such as global system for mobile communications (GSM)/general packet radio service (GPRS)/enhanced data rates for GSM evolution (EDGE). OFDMA can be implemented with wireless technologies such as IEEE (institute of electrical and electronics engineers) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802-20, E-UTRA (evolved UTRA), etc. IEEE 802.16m is an evolution of IEEE 802.16e and provides backward compatibility with systems based on IEEE 802.16e. UTRA is part of the universal mobile telecommunications system (UMTS). 3GPP (3rd generation partnership project) LTE (long term evolution) is a part of E-UMTS (evolved UMTS) that uses E-UTRA (evolved-UMTS terrestrial radio access), employing OFDMA in the downlink and SC- in the uplink. FDMA is adopted. In this way, the present embodiments can be applied to wireless access technologies currently disclosed or commercialized, and can also be applied to wireless access technologies currently under development or to be developed in the future.

Meanwhile, the terminal in this specification is a comprehensive concept meaning a device including a wireless communication module that communicates with a base station in a wireless communication system, and is used in WCDMA, LTE, NR, HSPA, and IMT-2020 (5G or New Radio), etc. It should be interpreted as a concept that includes not only UE (User Equipment), but also MS (Mobile Station), UT (User Terminal), SS (Subscriber Station), and wireless devices in GSM. In addition, a terminal may be a user portable device such as a smart phone depending on the type of use, and in a V2X communication system, it may mean a vehicle, a device including a wireless communication module within the vehicle, etc. Additionally, in the case of a machine type communication system, it may mean an MTC terminal, M2M terminal, URLLC terminal, etc. equipped with a communication module to perform machine type communication.

The base station or cell in this specification refers to an end point that communicates with a terminal in terms of a network, and includes Node-B (Node-B), evolved Node-B (eNB), gNode-B (gNB), Low Power Node (LPN), Sector, site, various types of antennas, BTS (Base Transceiver System), access point, point (e.g. transmission point, reception point, transmission/reception point), relay node ), mega cell, macro cell, micro cell, pico cell, femto cell, RRH (Remote Radio Head), RU (Radio Unit), and small cell. Additionally, a cell may mean including a bandwidth part (BWP) in the frequency domain. For example, a serving cell may mean the UE's Activation BWP.

Since the various cells listed above have a base station that controls one or more cells, base station can be interpreted in two ways. 1) It may be the device itself that provides mega cells, macro cells, micro cells, pico cells, femto cells, and small cells in relation to the wireless area, or 2) it may indicate the wireless area itself. In 1), all devices providing a predetermined wireless area are controlled by the same entity or all devices that interact to collaboratively configure the wireless area are directed to the base station. Depending on how the wireless area is configured, a point, transmission/reception point, transmission point, reception point, etc. become an example of a base station. In 2), the wireless area itself where signals are received or transmitted from the user terminal's perspective or the neighboring base station's perspective may be indicated to the base station.

In this specification, a cell refers to the coverage of a signal transmitted from a transmission/reception point, a component carrier having coverage of a signal transmitted from a transmission point or transmission/reception point, or the transmission/reception point itself. You can.

Uplink (UL, or uplink) refers to a method of transmitting and receiving data from a terminal to a base station, and downlink (Downlink, DL, or downlink) refers to a method of transmitting and receiving data from a base station to a terminal. do. Downlink may refer to communication or a communication path from multiple transmission/reception points to a terminal, and uplink may refer to communication or a communication path from a terminal to multiple transmission/reception points. At this time, in the downlink, the transmitter may be part of a multiple transmission/reception point, and the receiver may be part of the terminal. Additionally, in the uplink, a transmitter may be part of a terminal, and a receiver may be part of a multiple transmission/reception point.

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

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

Following research on 4G (4th-Generation) communication technology, 3GPP develops 5G (5th-Generation) communication technology to meet the requirements of ITU-R's next-generation wireless access technology. Specifically, 3GPP develops LTE-A pro, which is a 5G communication technology that improves LTE-Advanced technology to meet the requirements of ITU-R, and a new NR communication technology that is separate from 4G communication technology. Both LTE-A pro and NR refer to 5G communication technology, and hereinafter, 5G communication technology will be explained focusing on NR in cases where a specific communication technology is not specified.

The operating scenario in NR defines a variety of operating scenarios by adding consideration of satellites, automobiles, and new verticals to the existing 4G LTE scenario, and in terms of service, the eMBB (Enhanced Mobile Broadband) scenario has a high terminal density but is wide. It is deployed in a wide range of applications, supporting mMTC (Massive Machine Communication) scenarios that require low data rates and asynchronous connections, and URLLC (Ultra Reliability and Low Latency) scenarios that require high responsiveness and reliability and can support high-speed mobility. .

To satisfy this scenario, NR is launching a wireless communication system with new waveform and frame structure technology, low latency technology, ultra-high frequency band (mmWave) support technology, and forward compatible technology. In particular, the NR system proposes various technical changes in terms of flexibility to provide forward compatibility. The main technical features of NR are explained below with reference to the drawings.

<NR system general>

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

Referring to Figure 1, the NR system is divided into 5GC (5G Core Network) and NR-RAN parts, and NG-RAN controls the user plane (SDAP/PDCP/RLC/MAC/PHY) and UE (User Equipment). It consists of gNB and ng-eNB providing flat (RRC) protocol termination. gNB interconnection or gNB and ng-eNB are interconnected through Xn interface. gNB and ng-eNB are each connected to 5GC through the NG interface. 5GC may be composed of an Access and Mobility Management Function (AMF), which is responsible for the control plane such as terminal access and mobility control functions, and a User Plane Function (UPF), which is responsible for controlling user data. NR includes support for both the frequency band below 6 GHz (FR1, Frequency Range 1) and the frequency band above 6 GHz (FR2, Frequency Range 2).

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

<NR wave form, numerology and frame structure>

In NR, the CP-OFDM wave form 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 the advantage of being able to use a low-complexity receiver with high frequency efficiency.

Meanwhile, in NR, the requirements for data rate, delay rate, coverage, etc. are different for each of the three scenarios described above, so it is necessary to efficiently satisfy the requirements for each scenario through the frequency band that constitutes an arbitrary NR system. . To this end, a technology for efficiently multiplexing wireless resources based on a plurality of different numerologies has been proposed.

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

μ Subcarrier spacing Cyclic prefix Supported for data Supported for synchronization 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, NR's numerology can be divided into five types depending on the subcarrier spacing. This is different from the subcarrier spacing of LTE, one of the 4G communication technologies, which is fixed at 15kHz. Specifically, the subcarrier intervals used for data transmission in NR are 15, 30, 60, and 120 kHz, and the subcarrier intervals used for synchronization signal transmission are 15, 30, 120, and 240 kHz. Additionally, the extended CP applies only to the 60kHz subcarrier spacing. Meanwhile, the frame structure in NR is defined as a frame with a length of 10ms consisting of 10 subframes with the same length of 1ms. One frame can be divided into half-frames of 5ms, and each half-frame contains 5 subframes. In the case of 15 kHz subcarrier spacing, one subframe consists of one slot, and each slot consists of 14 OFDM symbols.

Figure 10 is a diagram for explaining the frame structure in an NR system to which this embodiment can be applied.

Referring to FIG. 10, a slot is fixedly composed of 14 OFDM symbols in the case of normal CP, but the length of the slot in the time domain may vary depending on the subcarrier spacing. For example, in the case of numerology with a 15 kHz subcarrier spacing, a slot is 1 ms long and has the same length as a subframe. In contrast, in the case of numerology with a 30 kHz subcarrier spacing, a slot consists of 14 OFDM symbols, but two slots can be included in one subframe with a length of 0.5 ms. That is, subframes and frames are defined with a fixed time length, and slots are defined by the number of symbols, so the time length may vary depending on the subcarrier interval.

Meanwhile, NR defines the basic unit of scheduling as a slot, and also introduces a mini-slot (or sub-slot or non-slot based schedule) to reduce transmission delay in the wireless section. When a wide subcarrier spacing is used, the length of one slot is shortened in inverse proportion, so transmission delay in the wireless section can be reduced. Mini-slots (or sub-slots) are designed to efficiently support URLLC scenarios and can be scheduled in units of 2, 4, or 7 symbols.

Additionally, unlike LTE, NR defines uplink and downlink resource allocation at the symbol level within one slot. In order to reduce HARQ delay, a slot structure that can transmit HARQ ACK/NACK directly within the transmission slot has been defined, and this slot structure is described as a self-contained structure.

NR is designed to support a total of 256 slot formats, of which 62 slot formats are used in 3GPP Rel-15. In addition, it supports a common frame structure that forms an FDD or TDD frame through a combination of various slots. For example, a slot structure in which all slot symbols 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. Additionally, NR supports scheduling data transmission distributed over one or more slots. Therefore, the base station can use a slot format indicator (SFI) to inform the terminal whether the slot is a downlink slot, an uplink slot, or a flexible slot. The base station can indicate the slot format by indicating the index of the table configured through UE-specific RRC signaling using SFI, and can indicate it dynamically through DCI (Downlink Control Information) or statically or through RRC. It can also be indicated semi-statically.

<NR physical resources>

Regarding physical resources in NR, antenna port, resource grid, resource element, resource block, bandwidth part, etc. are considered. do.

An antenna port is defined so that a channel carrying a symbol on the antenna port can be inferred from a channel carrying another symbol on the same antenna port. If the large-scale properties of the channel carrying the symbols on one antenna port can be inferred from the channel carrying the symbols on the other antenna port, the two antenna ports are quasi co-located or QC/QCL. It can be said that they are in a quasi co-location relationship. Here, the wide range characteristics include one or more of delay spread, Doppler spread, frequency shift, average received power, and received timing.

FIG. 3 is a diagram illustrating a resource grid supported by wireless access technology to which this embodiment can be applied.

Referring to FIG. 3, since NR supports multiple numerology on the same carrier, a resource grid may exist for each numerology. Additionally, resource grids may exist depending on antenna ports, subcarrier spacing, and transmission direction.

A resource block consists of 12 subcarriers and is defined only in the frequency domain. Additionally, a resource element consists of one OFDM symbol and one subcarrier. Therefore, as shown in FIG. 3, the size of one resource block may vary depending on the subcarrier spacing. Additionally, NR defines "Point A", which serves as a common reference point for the resource block grid, common resource blocks, virtual resource blocks, etc.

Figure 10 is a diagram for explaining the bandwidth part supported by the wireless access technology to which this embodiment can be applied.

In NR, unlike LTE, where 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, the terminal can use a designated bandwidth part (BWP) within the carrier bandwidth as shown in FIG. 4. Additionally, the bandwidth part is linked to one numerology and consists of a subset of consecutive common resource blocks, and can be activated dynamically over time. The terminal is configured with up to four bandwidth parts for each uplink and downlink, and data is transmitted and received using the bandwidth parts activated 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 bandwidth parts of the downlink and uplink are set in pairs so that they can share the center frequency.

<NR initial access>

In NR, the terminal performs cell search and random access procedures to connect to the base station and perform communication.

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

Figure 5 is a diagram illustrating a synchronization signal block in a wireless access technology to which this embodiment can be applied.

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

The terminal monitors the SSB in the time and frequency domains and receives the SSB.

SSB can be transmitted up to 64 times in 5ms. Multiple SSBs are transmitted through different transmission beams within 5ms, and the terminal performs detection assuming that SSBs are transmitted every 20ms period based on one specific beam used for transmission. The number of beams that can be used for SSB transmission within 5ms time can increase as the frequency band becomes higher. For example, up to 4 different SSB beams can be transmitted under 3 GHz, up to 8 different beams can be used in the frequency band from 3 to 6 GHz, and up to 64 different beams can be used in the frequency band above 6 GHz.

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

Meanwhile, unlike SS in conventional LTE, SSB is not transmitted at the center frequency of the carrier bandwidth. In other words, SSBs can be transmitted even in places other than the center of the system band, and when broadband operation is supported, multiple SSBs can be transmitted in the frequency domain. Accordingly, the terminal 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, have been newly defined in NR, and the synchronization raster has a wider frequency interval than the carrier raster, supporting fast SSB search of the terminal. You can.

The UE can obtain the MIB through the PBCH of the SSB. MIB (Master Information Block) contains the minimum information required for the terminal to receive the remaining system information (RMSI, Remaining Minimum System Information) broadcast by the network. In addition, the PBCH includes information about the location of the first DM-RS symbol in the time domain, information for the terminal to monitor SIB1 (e.g., SIB1 numerology 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 within the carrier is transmitted through SIB1), etc. Here, the SIB1 numerology information is equally applied to some messages used in the random access procedure for accessing the base station after the terminal completes the cell search procedure. For example, numerology information of SIB1 may be applied to at least one of messages 1 to 4 for the random access procedure.

The above-mentioned RMSI may mean SIB1 (System Information Block 1), and SIB1 is broadcast periodically (ex, 160ms) in the cell. SIB1 contains information necessary for the terminal to perform the initial random access procedure and is transmitted periodically through PDSCH. In order for the terminal to receive SIB1, it must receive numerology information used for SIB1 transmission and CORESET (Control Resource Set) information used for scheduling SIB1 through the PBCH. The UE uses SI-RNTI in CORESET to check scheduling information for SIB1 and acquires SIB1 on the PDSCH according to the scheduling information. Except for SIB1, the remaining SIBs may be transmitted periodically or according to the request of the terminal.

Figure 6 is a diagram for explaining a random access procedure in wireless access technology to which this embodiment can be applied.

Referring to FIG. 6, when cell search is completed, the terminal transmits a random access preamble for random access to the base station. The random access preamble is transmitted through PRACH. Specifically, the random access preamble is transmitted to the base station through PRACH, which consists of continuous radio resources in a specific slot that is repeated periodically. Generally, when a UE initially accesses a cell, a contention-based random access procedure is performed, and when random access is performed for beam failure recovery (BFR), a non-contention-based 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), UL Grant (uplink radio resource), temporary C-RNTI (Temporary Cell - Radio Network Temporary Identifier), and TAC (Time Alignment Command). Since one random access response may include random access response information for one or more terminals, the random access preamble identifier may be included to indicate to 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. TAC may be included as information for the terminal to adjust uplink synchronization. The random access response may be indicated by a random access identifier on the PDCCH, that is, RA-RNTI (Random Access - Radio Network Temporary Identifier).

The terminal that has received a valid random access response processes the information included in the random access response and performs scheduled transmission to the base station. For example, the terminal applies TAC and stores temporary C-RNTI. Additionally, using the UL Grant, data stored in the terminal's buffer or newly generated data is transmitted to the base station. In this case, information that can identify the terminal must be included.

Finally, the terminal receives a downlink message to resolve contention.

<NR CORESET>

The downlink control channel in NR is transmitted in CORESET (Control Resource Set) with a length of 1 to 3 symbols, and transmits uplink/downlink scheduling information, SFI (Slot format Index), and TPC (Transmit Power Control) information. .

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

Figure 7 is a diagram to explain CORESET.

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

The first CORESET is directed through the MIB as part of the initial bandwidth part configuration to enable it to receive additional configuration and system information from the network. After establishing a connection with the base station, the terminal can receive and configure one or more 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 a variety of meanings that may be used in the past or present, or may be used in the future.

The present invention relates to a method and device for controlling handover/topology for a mobile relay and linking and controlling terminal handover served by a mobile relay.

Integrated Access and Backhaul (IAB)

IAB nodes enable wireless relaying in 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 base station with additional functions to support IAB. gNB with additional functionality to support IAB).

Figure 8 shows the IAB structure. And Figure 9 shows the parent node and child node relationship for the IAB node. As shown in Figure 8, the IAB node supports stand alone mode and non-stand alone mode. The IAB node is a gNB-DU defined in 3GPP TS 38.401, which terminates the NR access interface (NR Uu) to the IAB node of the terminal and the next hop, and terminates the F1 protocol for 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 may be referred to as IAB-DU. (The IAB-node DU is also referred to as IAB-DU.) The IAB node supports 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, e.g., 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).

Meanwhile, 3GPP approved items for mobile relay based on the NR IAB structure and protocol standardized in previous releases. This item is intended to support a vehicle-mounted mobile IAB node scenario that provides 5G coverage/capacity improvements for onboard and/or surrounding terminals.

Mobile IAB nodes support in-band and out-of-band backhauling. Mobile IAB nodes do not have descendant IAB nodes. In other words, the mobile IAB node serves only terminals.

However, the conventional IAB technology basically assumed to operate in a fixed position for a certain period of time. For example, IAB nodes are stationary. IAB node migration between donor nodes did not support normal IAB node handover, in which the migrating IAB node disconnects from the source donor node and connects to the target donor node to transmit and receive data. Therefore, there was a problem in efficiently supporting control and user data transmission according to the movement of mobile IAB. Additionally, during the mobile IAB topology adjustment process, it was not possible to link and provide handover of terminals serviced by mobile IAB.

Conventional IAB technology was difficult to efficiently support control and user data transmission according to IAB movement, and could not effectively support handover of terminals served by mobile IAB during the mobile IAB topology adjustment process.

The purpose of the present invention, which was devised to solve the above problems, is to provide a control method and device for effectively migrating/moving/handing over mobile relays and terminals served by mobile relays between different donor base stations.

For convenience of explanation, the following describes the relay/IAB node control method based on NR technology. However, this is for convenience of explanation, and the present invention can be applied to relays based on any wireless access (e.g. 6G, LTE, etc.) technology.

The embodiment described in the present invention includes information elements and operations specified in the NR/5GS standard (e.g. TS38.300, a stage 2 standard, TS 38.321, a MAC standard, TS 38.331, a NR RRC standard, TS 23.501, a system architecture standard, etc.) Includes the contents of Even if the definition of the corresponding information element and the related terminal operation content are not included in this specification, the corresponding content specified in the standard specification, which is a known technology, may be included in the present invention.

Any function described below is defined as an individual terminal capability (UE radio capability or UE Core network capability) and can be transmitted by the terminal to the base station/core network entity (e.g. AMF/SMF) through corresponding signaling. . Alternatively, arbitrary functions may be combined/combined, defined as the terminal capability, and transmitted by the terminal to the base station/core network entity through corresponding signaling.

The base station may transmit/instruct the terminal to allow/support/configure any function or combination of functions described below through an RRC message (e.g. dedicated RRC message or System information). You can. For example, this may be instructed to the terminal prior to configuration/application of the function/function combination or simultaneously with configuration/application of the function/function combination.

The functions described below can be performed individually and independently. It is obvious that the functions described below can be implemented in any combination/combination and that this is also included in the scope of the present invention. For example, one or more functions may be applied simultaneously or sequentially in any order.

For convenience of explanation, mobile IAB nodes are referred to as mobile relays below. This is for convenience of explanation and may be changed to any other name.

Protocol structure for mobile relay support

Figure 10 shows a protocol structure for transmitting user plane data through an IAB node in the prior art. On wireless backhaul, the IP layer is carried through a Backhaul Adaptation Protocol (BAP) layer that enables routing over multiple hops. As such, IAB according to the prior art assumed a multi-hop-based structure and had to support complex routing accordingly.

To reduce complexity, mobile relays can be provided through a single-hop architecture. For example, a mobile relay may not have a descendent IAB node. The mobile relay is an IAB-donor (or base station/donor base station/gNB-CU; for convenience of explanation, IAB-donor is indicated as a donor base station. This is only for convenience of explanation. In FIG. 10, IAB-donor or base station (gNB) ) or can be interpreted as gNB-CU.) can be directly connected to. It can be configured so that there is no intermediate IAB node (e.g. IAB-node1 in FIG. 10) between the mobile relay and the donor base station.

Figure 11 shows an example of a protocol stack for terminal access using mobile relaying.

For example, user plane data can be transmitted and received between a terminal and a donor base station through an F1-U/GTP-U tunnel linked to the terminal and the corresponding DRB (DRB-ID/RB-ID/LogicalChannelID).

For another example, the user plane data between the terminal and the donor base station is the corresponding terminal (UE-ID/C-RNTI/base station terminal identifier), the corresponding DRB (DRB-ID/RB-ID/LogicalChannelID)), and the corresponding mobile relay (mobile Relay identifier/base station identifier/Global-NG-RAN-Node-ID) can be transmitted and received by including one or more index/identification information/address information(s) in the BAP header. Through this, user data can be transmitted and received in connection with the backhaul RLC channel/backhaul RLC bearer without an F1-U/GTP-U tunnel. The mobile relay can transmit and receive PDCP-PDU/RLC-SDU/RLC-PDU received from the terminal by linking it to the backhaul RLC channel/backhaul RLC bearer between the mobile relay and the donor base station. The mobile relay can transmit and receive RLC-SDU/BAP-PDU/BAP-SDU received from the donor base station by linking it to the RLC channel/RLC bearer between the terminal and the mobile relay. Information for configuring this can be configured by being instructed to the mobile relay through an F1AP message or RRC message. The information for identifying the terminal described above may be information allocated by the mobile relay to identify the terminal. Alternatively, the information for identifying the terminal may be information allocated by the donor base station to identify the terminal. Information for identifying the terminal may be included and indicated in the RRC setup message, RRC reconfiguration message, and RRC reestablishment message.

Adaptation protocol (e.g. BAP or adaptation protocol to support mobile relaying distinct from BAP) is an adaptation protocol that uses one or more information among the terminal identifier, the DRB identifier of the terminal, and the mobile relay identifier that provides access/service to the terminal. Can be included in the protocol header. For example, when using the BAP PDU format, the R field(s) of FIG. 12 can be used/modified to indicate that it is differentiated from the conventional format. In addition, one or more information among the terminal identifier, the DRB identifier of the terminal, and the mobile relay identifier that provides access to the terminal may be included in the adaptation protocol header.

For convenience of explanation, the following describes the mobile relay handover/topology adjustment based on FIG. 11 and/or the handover method of the terminal(s) served by the mobile relay. This is for convenience of explanation, and use without an F1-U/GTP-U tunnel by changing the adaptation protocol header is also included in the scope of the present invention.

One or more terminals are on board a vehicle equipped with a mobile relay. As the vehicle moves, the installed mobile relay and the terminals serviced through the mobile relay can move together. Handover/migration/topology adaptation procedures for the mobile relay and/or handover for the terminal(s) served by the mobile relay to support the mobility of the mobile relay. Procedures may be provided.

Figure 13 shows an example of a procedure for providing topology coordination by handing over a mobile relay through different donor base stations/IAB-donor-CU. For convenience of explanation, the procedure is explained in a base station separation structure where the base station/donor base station consists of CU/IAB-donor-CU and DU/IAB-donor-DU. However, this is for convenience of explanation, and even if the CU/IAB-donor-CU and DU/IAB-donor-DU included in the base station/donor base station are implemented as a single node/logical entity/physical entity, it is within the scope of the present invention. It is obvious that it is included in .

The mobile relay can switch the RRC connection and/or data radio bearer for the mobile relay's own signaling and data traffic. RRC connection and/or data radio bearer of mobile relay from previous donor base station/IAB-donor-CU/IAB-donor-DU/parent node to new donor base station/IAB-donor-CU/IAB-donor -Can be changed to DU/Parent Node. For convenience of explanation, the previous donor base station/IAB-donor-CU/ IAB-donor-DU/parent node is referred to as the source donor base station/IAB-donor-CU/ IAB-donor-DU/parent node. And the new donor base station/IAB-donor-CU/ IAB-donor-DU/parent node is denoted as the target donor base station/IAB-donor-CU/ IAB-donor-DU/parent node.

1. The source donor base station/IAB-donor-CU transmits a handover request message to the target donor base station/IAB-donor-CU.

The handover request message may include an RRC container (e.g. Handoverpreparation message) with information necessary to prepare for handover on the target side. The handover request message or RRC container includes BAP address information of the moving mobile relay, TNL address information (e.g. IP address information for the mobile relay and/or uplink/for mobile relay-user plane-traffic/F1-U traffic). It may contain one or more of the following information: downlink Transport-layer-address/IP-address, GTP-TEID(s)), and mobile relay identifier.

The handover request message may include information indicating that the handover is for mobile relay handover (or information indicating that mobile relay is supported). The target donor base station/IAB-donor-CU can recognize and process the handover as being for mobile relay.

The handover request message may include information to support/provide/instruct mobility for a terminal served through the corresponding mobile relay (e.g. a terminal in an RRC connection state by accessing the corresponding mobile relay). This will be described later. For example, when handover/topology adjustment of a mobile relay is performed, processing to provide service continuity for terminals served by the mobile relay (e.g. PCI change of the mobile relay providing cell, Depending on the handover/cell change/RRC reset of the terminal served through the mobile relay and the backhaul link change/switching between the mobile relay and the donor base station, PDCP recovery or PDCP reset of the terminal served by the mobile relay can be performed simultaneously or in conjunction. there is.

2. The target donor base station/IAB-donor-CU can perform acceptance control. The target donor base station/IAB-donor-CU can transmit a handover request confirmation/response message to the source donor base station/IAB-donor-CU. RRC configuration may be provided as part of the handover request acknowledge/response message. The handover request confirmation/response message or RRC configuration includes BAP address information, default backhaul RLC channel information, default BAP routing ID, and uplink/downlink TNL address information for the mobile relay connected to the target donor base station/IAB-donor-CU. , may include one or more information among the mobile relay identifiers. This information can be used as information for mapping F1-C and/or F1-U and/or non-F1 traffic to the target donor base station/IAB-donor-CU (via target path).

The handover request confirmation/response message may include information to support/provide/instruct mobility for a terminal served through the corresponding mobile relay (e.g. a terminal in an RRC connection state by accessing the corresponding mobile relay). This will be described later. For example, when handover/topology adjustment of a mobile relay is performed, processing to provide service continuity for terminals served by the mobile relay (e.g. PCI change of the mobile relay providing cell, Contains information to support (handover/cell change/RRC reset of the terminal served through the mobile relay, PDCP recovery or PDCP reset of the terminal served by the mobile relay according to the backhaul link change/switching between the mobile relay and the donor base station) You can.

The source donor base station/IAB-donor-CU can include/encapsulate the corresponding RRC message(s)/RRC container(s) in the downlink RRC message Transfer message and transmit it to the source IAB-donor-DU.

Processing to provide service continuity for terminals served by the mobile relay when handover/topology adjustment of the mobile relay is performed (e.g. PCI change of the mobile relay providing cell, service service through the cell according to the PCI change) When supporting PDCP recovery or PDCP reset of a terminal served by the mobile relay according to handover/cell change/RRC reset of the terminal, change/switching of the backhaul link between the mobile relay and the donor base station, For the terminal, the source donor base station/IAB-donor-CU can include/encapsulate the corresponding RRC message(s)/RRC container(s) in the downlink RRC message Transfer message and transmit it to the mobile relay (or mobile relay DU). .

3. The source donor base station/IAB-donor-CU/IAB-donor-DU can transmit the received RRC reconfiguration message to the mobile relay.

4. The mobile relay can perform a random access procedure with the target donor base station/IAB-donor-DU.

5. The mobile relay can transmit an RRC reconfiguration completion message to the target donor base station/IAB-donor-DU/IAB-donor-CU. The target IAB-donor-DU can include/encapsulate the corresponding RRC message in the uplink RRC message Transfer message and transmit it to the target donor base station/IAB-donor-CU.

6. The target donor base station/IAB-donor-CU can perform core network (e.g. AMF) and PATH SWITCH procedures. The target donor base station/IAB-donor-CU can transmit a PATH SWITCH REQUEST message to AMF. The target donor base station/IAB-donor-CU can receive a PATH SWITCH REQUEST ACKNOWLEDGE message from AMF. The corresponding route switch procedure may indicate a change in the route of the data radio bearer for the mobile relay's own data traffic. (e.g. Change the data transmission path from the core network to the source donor base station to the data transmission path from the core network to the target donor base station)

7. The target donor base station/IAB-donor-CU may transmit a terminal context release request message to the source donor base station/IAB-donor-CU.

The source donor base station/IAB-donor-CU may transmit an F1AP message to indicate release of the terminal context to the source IAB-donor-DU.

The source IAB-donor-DU can release the context of the mobile relay and send a message to the source donor base station/IAB-donor-CU to indicate completion of terminal context release.

The source donor base station/IAB-donor-CU/IAB-donor-DU can release the backhaul RLC channel and BAP layer root entry on the source path between the mobile relay and the source donor base station/IAB-donor-CU/IAB-donor-DU. You can.

Terminal handover serviced by mobile relay

During the movement/cell change/handover/topology adjustment of the mobile relay or together with the movement/cell change/handover/topology adjustment of the mobile relay or in conjunction with the movement/cell change/handover/topology adjustment of the mobile relay, the mobile relay Handover may be required for the terminal(s) served by.

For example, when a mobile relay performs handover/topology adjustment for a mobile relay through a different donor base station/IAB-donor-CU, the PCI/system information for the cell being served by the mobile relay may be changed. It can cause Accordingly, handover to the terminal(s) served by the mobile relay may be necessary.

For another example, when a mobile relay performs handover/topology adjustment for a mobile relay through a different donor base station/IAB-donor-CU, the wireless backhaul link between the mobile relay and the source donor base station is connected to the mobile relay and the target donor base station. Changes to a wireless backhaul link. When the wireless backhaul link is changed, packet/PDU loss may occur in the wireless link. In the case of a wireless bearer with a backhaul RLC channel operating in RLC AM mode, lossless transmission becomes difficult because the corresponding RLC entity is reset when the wireless backhaul link is changed. To compensate for this, handover to the terminal(s) served by the mobile relay may be necessary. Alternatively, it may be necessary to retransmit lost packets/PDUs.

Handover/topology adjustment of the mobile relay and handover for one or more terminals served by the mobile relay can be performed simultaneously or in conjunction.

For example, when performing handover/topology adjustment of a mobile relay, each handover procedure can be applied together to each terminal served by the mobile relay to enable handover.

For example, in step 1 of FIG. 13, when the source donor base station/IAB-donor-CU transmits a handover request message for the mobile relay to the target donor base station/IAB-donor-CU, each terminal served by the mobile relay A handover request message can be transmitted together. The handover request message for the mobile relay transmitted from the source donor base station/IAB-donor-CU to the target donor base station/IAB-donor-CU includes handover request messages for each terminal served by the mobile relay. You can. When the source donor base station/IAB-donor-CU determines handover for the mobile relay, it can also determine handover and/or lost packet retransmission for the terminal(s)/terminal group served by the mobile relay.

As another example, in step 1 of FIG. 13, when the source donor base station/IAB-donor-CU transmits a handover request message for the mobile relay to the target donor base station/IAB-donor-CU, the target donor base station/IAB-donor-CU

When performing handover to the mobile relay, it may be determined whether handover and/or retransmission of lost packets to the terminal(s)/terminal group served by the mobile relay is necessary. An example would be if a PCI change is deemed necessary. The target donor base station/IAB-donor-CU can transmit a handover request confirmation/response message or a handover preparation failure message including information to indicate this to the source donor base station/IAB-donor-CU. The source donor base station/IAB-donor-CU transmits a handover request message(s) for each terminal served by the mobile relay to the target donor base station/IAB-donor-CU and sends a handover request confirmation/response message to the target donor base station/IAB-donor-CU. (s) can be received.

As another example, when the source donor base station/IAB-donor-CU transmits an RRC reconfiguration message for handover to the mobile relay, the RRC reconfiguration message(s) for each terminal served by the mobile relay is sent to the handover to the mobile relay. It can be sent with an RRC reconfiguration message for override. For example, the RRC container(s) carrying the RRC reconfiguration message for handover to the mobile relay and the RRC container(s) carrying the RRC reconfiguration message(s) for each terminal served by the mobile relay are source IAB-donor. -Can be transmitted to mobile relay through DU.

Alternatively, when the source donor base station/IAB-donor-CU transmits an RRC reconfiguration message for handover to the mobile relay, the RRC reconfiguration message(s) for each terminal served by the mobile relay is sent to the handover to the mobile relay. It can be sent by including it in the RRC reconfiguration message for override. For example, the RRC reconfiguration message for handover to the mobile relay may include RRC reconfiguration message(s) for each terminal served by the mobile relay as each information element. Or, by the mobile relay at a specific point in time when the source donor base station/IAB-donor-CU transmits an RRC reconfiguration message for handover to the mobile relay, for example, before transmission, during transmission, or after transmission. RRC reconfiguration message(s) for each serviced terminal can be transmitted to the mobile relay. For example, before the source donor base station/IAB-donor-CU transmits the RRC reconfiguration message for handover to the mobile relay, it sends the RRC reconfiguration message(s) for each terminal served by the mobile relay to the mobile relay. Can be transmitted.

As another example, when the mobile relay completes the RRC handover procedure by sending an RRC reconfiguration complete message to the target donor base station/IAB-donor-CU, the RRC reconfiguration complete message(s) for each terminal served by the mobile relay is sent. can be transmitted along with the RRC reconfiguration completion message for the mobile relay. For example, the RRC container carrying the RRC reconfiguration complete message for the mobile relay and the RRC container(s) carrying the RRC reconfiguration complete message(s) for each terminal served by the mobile relay are targeted at IAB-donor-DU. It can be transmitted to the target donor base station/IAB-donor-CU.

Alternatively, when the mobile relay transmits the RRC reconfiguration complete message to the target donor base station/IAB-donor-CU, the RRC reconfiguration complete message(s) for each terminal served by the mobile relay is sent as the RRC reconfiguration complete message to the mobile relay. You can send it with . For example, the RRC reconfiguration complete message for the mobile relay may include RRC reconfiguration complete message(s) for each terminal served by the mobile relay as each information element.

Alternatively, the mobile relay may receive the RRC reconfiguration complete message(s) for each terminal served by the mobile relay before transmitting the RRC reconfiguration complete message to the target donor base station/IAB-donor-CU.

As another example, when the target donor base station/IAB-donor-CU transmits a PATH SWITCH request message to the core network (e.g. AMF/SMF) to change the path of the mobile relay's own data traffic, each terminal served by the mobile relay A PATH SWITCH request message(s) for can be transmitted together. Alternatively, the target donor base station/IAB-donor-CU includes the PATH SWITCH request message(s) for each terminal served by the mobile relay in the PATH SWITCH request message for changing the route of the mobile relay's own data traffic. Can be transmitted. Alternatively, the target donor base station/IAB-donor-CU sends a PATH SWITCH request message to the core network (e.g. AMF) to change the route of the mobile relay's own data traffic, for each terminal served by the mobile relay. RRC reconfiguration completion message(s) can be received.

As another example, when the core network (e.g. AMF/SMF) transmits a PATH SWITCH request confirmation/response message to the mobile relay transmitted to the target donor base station/IAB-donor-CU, the message for each terminal served by the mobile relay is transmitted. PATH SWITCH request confirmation/response message(s) can be transmitted together. Alternatively, the PATH SWITCH request confirmation/response message for the mobile relay transmitted by the core network (e.g. AMF/SMF) to the target donor base station/IAB-donor-CU confirms the PATH SWITCH request for each terminal served by the mobile relay. /Can be transmitted including response message(s). Or, before the core network (e.g. AMF/SMF) transmits the PATH SWITCH request confirmation/response message for the mobile relay to the target donor base station/IAB-donor-CU, the PATH SWITCH for each terminal served by the mobile relay Request message(s) may be received.

As another example, when the target donor base station/IAB-donor-CU transmits a UE Context release message for mobile relay transmitted to the source donor base station/IAB-donor-CU, UE Context release for each terminal served by the mobile relay Message(s) can be transmitted together. Alternatively, the UE Context release message for mobile relay transmitted from the target donor base station/IAB-donor-CU to the source donor base station/IAB-donor-CU is a UE Context release message(s) for each terminal served by the mobile relay. ) can be transmitted including. Or, before transmitting the UE Context release message for the mobile relay transmitted from the target donor base station/IAB-donor-CU to the source donor base station/IAB-donor-CU, PATH SWITCH for each terminal served by the mobile relay Request confirmation/response message(s) may be received.

For another example, when performing handover/topology adjustment of a mobile relay, one or more terminals (or all terminals, a set of terminals, or a group of terminals, or a group terminal) served by the mobile relay , for convenience of explanation, hereinafter referred to as one or more terminals, this is for convenience of explanation. This refers to all terminals serviced by the relevant mobile relay, and terminals of a specific group serviced through cells provided by the relevant mobile relay. A handover can be performed (grouped) for any number of terminals, such as a terminal group with a specific configuration (e.g. AM RLC)/function/characteristic/capability. Through one handover procedure, handover/topology adjustment of the mobile relay and (grouped) handover for one or more terminals served by the mobile relay can be performed. Mobility/handover can be supported for mobile relay and the terminals served through it.

As an example, a group handover request message may be defined to indicate a handover/topology adjustment of the mobile relay and/or a (grouped) handover resource preparation request for one or more terminals served by the mobile relay. For convenience of explanation, this is hereinafter referred to as a group handover request message. This is for convenience of explanation and can be replaced with any name. This message can be defined separately from a handover request message that requests resource preparation for handover to one terminal.

As another example, information for indicating handover/topology adjustment of the mobile relay and/or request for (grouped) handover resource preparation for one or more terminals served by the mobile relay may be defined and included in the handover request message.

As another example, the above-described group handover request message or a handover request message containing information for instructing a group handover includes the source base station node terminal XnAP ID for the mobile relay, terminal context information for the mobile relay, and the mobile relay. For one or more terminal(s) served by, the source base station node terminal XnAP ID for each terminal and terminal context information for each corresponding terminal may be included.

As another example, if the target donor base station/IAB-donor-CU fails to accept at least one PDU session resource for the corresponding terminal from one or more terminals served by the mobile relay or a failure occurs during handover preparation, the target donor base station/IAB-donor-CU IAB-donor-CU can transmit the source base station node terminal XnAP ID and the corresponding cause for the corresponding terminal to the source donor base station/IAB-donor-CU. For example, the information can be transmitted through a group handover request confirmation/response message or a handover request confirmation/response message. Alternatively, an individual handover preparation failure message can be sent to the corresponding terminal. Source Source donor base station/IAB-donor-CU can handover the terminal to a neighboring cell other than the cell provided by the target donor base station/IAB-donor-CU or to a neighboring cell other than the cell provided by the mobile relay.

As another example, the target donor base station/IAB-donor-CU sends a group handover request confirmation/response message or group handover to the aforementioned group handover request message or a handover request message containing information for instructing group handover. A handover request confirmation/response message containing information to inform about prepared resources may be transmitted. The group handover request confirmation/response message or the handover request confirmation/response message containing information to inform about the prepared resources for the group handover includes the source base station node terminal XnAP ID for the mobile relay, the target base station node terminal XnAP ID, Accepted PDU session resource list, handover command/RRC reconfiguration message and/or source base station node terminal XnAP ID for each terminal for one or more terminal(s) served by the corresponding mobile relay, target base station node terminal XnAP ID , may include accepted PDU session resource list information, and handover command/RRC reconfiguration message.

As another example, index information for mapping one or more of the source base station node terminal XnAP ID, target base station node terminal XnAP ID, and accepted PDU session resource list can be defined and used. The information can be included in the message.

As another example, information to identify a group of terminals serviced by a mobile relay can be defined and used. The information can be included in the message.

As another example, when the source donor base station/IAB-donor-CU transmits an RRC reconfiguration message for handover to the mobile relay, it sends an RRC reconfiguration message (RRC reconfiguration message) for each terminal to one or more terminal(s) served by the mobile relay. s) can be sent along with an RRC reconfiguration message for handover to the mobile relay. For example, the RRC container(s) carrying the RRC reconfiguration message for handover to the mobile relay and the RRC container(s) carrying the RRC reconfiguration message(s) for each terminal served by the mobile relay are source IAB-donor. -Can be transmitted to mobile relay through DU.

Alternatively, when the source donor base station/IAB-donor-CU transmits an RRC reconfiguration message for handover to the mobile relay, an RRC reconfiguration message for each terminal (s) for one or more terminal(s) served by the mobile relay s) can be sent included in the RRC reconfiguration message for handover to the mobile relay. For example, the RRC reconfiguration message for handover to the mobile relay may include RRC reconfiguration message(s) for each terminal served by the mobile relay as each information element. Or, by the mobile relay at a specific point in time when the source donor base station/IAB-donor-CU transmits an RRC reconfiguration message for handover to the mobile relay, for example, before transmission, during transmission, or after transmission. RRC reconfiguration message(s) for each serviced terminal can be transmitted to the mobile relay. For example, before the source donor base station/IAB-donor-CU transmits the RRC reconfiguration message for handover to the mobile relay, RRC reconfiguration for each terminal for one or more terminal(s) served by the mobile relay. Message(s) can be transmitted via mobile relay.

As another example, handover configuration for one or more terminal(s) served by a mobile relay (or common configuration information included in radio resource configuration for handover, or one or more information elements included in reconfiguration with sync, t304, cell Common configuration information (spCellConfigCommon/ServingCellConfigCommon)) can be broadcast to the terminal through system information. A terminal that supports the corresponding capability can obtain the corresponding system information. The handover configuration for one or more terminal(s) served by the mobile relay includes common configuration information (e.g. t304, cell common configuration information) included in the radio resource configuration for handover received through the above-described system information. It can be created/transmitted without doing so.

As another example, when the mobile relay completes the RRC handover procedure by sending an RRC reconfiguration completion message to the target donor base station/IAB-donor-CU, it sends a message to each terminal for one or more terminal(s) served by the mobile relay. The RRC reconfiguration complete message(s) for the mobile relay can be transmitted together with the RRC reconfiguration complete message for the mobile relay. For example, an RRC container carrying an RRC reconfiguration complete message for a mobile relay and an RRC container(s) carrying an RRC reconfiguration complete message(s) for each terminal for one or more terminal(s) served by the mobile relay. ) can be transmitted to the target donor base station/IAB-donor-CU through the target IAB-donor-DU.

Alternatively, when the mobile relay transmits the RRC reconfiguration complete message to the target donor base station/IAB-donor-CU, it sends the RRC reconfiguration complete message(s) for each terminal to one or more terminal(s) served by the mobile relay. It can be sent by including it in the RRC reconfiguration completion message for the mobile relay. For example, the RRC reconfiguration complete message for the mobile relay may include the RRC reconfiguration complete message(s) for each terminal for one or more terminal(s) served by the mobile relay as each information element.

Alternatively, the mobile relay sends an RRC reconfiguration complete message(s) for each terminal to one or more terminal(s) served by the mobile relay before transmitting the RRC reconfiguration complete message to the target donor base station/IAB-donor-CU. can receive.

As another example, changing the data traffic route of the mobile relay (e.g. changing the data traffic route to change the downlink termination point of the NG-U transmission bearer to a new termination point) and/or (for one or more terminals served by the mobile relay) A group path change request message can be defined to indicate a grouped data traffic path change request. Alternatively, information for instructing a data traffic path change of the mobile relay and/or a (grouped) data traffic path change request for one or more terminals serviced by the mobile relay is defined in a Path Switch Request message. may be included. A group route change request message or a route change request message containing information for instructing a data traffic route change of a mobile relay and/or a (grouped) data traffic route change request for one or more terminals served by the mobile relay. Base station node terminal NGAP ID for the mobile relay, AMF terminal NGAP ID, PDU session resource list to be switched in the downlink, and/or base station node terminal for each terminal for one or more terminal(s) served by the corresponding mobile relay. It may include the NGAP ID, the AMF terminal NGAP ID, and the PDU session resource list switched in the downlink.

As another example, the target donor base station/IAB-donor-CU sends a group route change request message or a data traffic route change request for the mobile relay and/or a (grouped) data traffic route change request for one or more terminals served by the mobile relay. Before transmitting a route change request message containing information for indication, an RRC reconfiguration complete message(s) for each terminal may be received for one or more terminal(s) served by the mobile relay.

As another example, to instruct a route change request confirmation/response to notify that the route change of the mobile relay has been successfully completed and/or a (grouped) route change request confirmation/response to one or more terminals served by the mobile relay. You can define a group path change request confirmation/response message. Or, information for instructing the route change request confirmation/response of the mobile relay and/or the (grouped) route change request confirmation/response for one or more terminals served by the mobile relay is defined and the route change request confirmation/response ( Path Switch Request Acknowledge) message. Information for instructing a group route change request confirmation/response message, or a route change request confirmation/response of the mobile relay and/or a (grouped) route change request confirmation/response for one or more terminals served by the mobile relay. The route change request confirmation/response message includes the base station node terminal NGAP ID for the mobile relay, the AMF terminal NGAP ID, the PDU session resource list switched in the downlink, and/or one or more terminal(s) served by the mobile relay. For each terminal, it may include a base station node terminal NGAP ID, AMF terminal NGAP ID, and a PDU session resource list switched in the downlink.

As another example, index information for mapping one or more of the base station node terminal NGAP ID, AMF terminal NGAP ID, and downlink switched PDU session resource list can be defined and used. As another example, information to identify a group of terminals serviced by a mobile relay can be defined and used. The information can be included in the message.

As another example, to instruct the target donor base station/IAB-donor-CU to release the resources of the mobile relay to the source donor base station/IAB-donor-CU and/or the target donor base station/IAB-donor-CU to the source donor base station/ With IAB-donor-CU, a group terminal context release message can be defined to indicate release of (grouped) resources for one or more terminals served by the mobile relay. Alternatively, information for instructing resource release of the mobile relay and/or release of (grouped) resources for one or more terminals served by the mobile relay may be defined and included in the terminal context release message. A group terminal context release message or a terminal context release message containing information for instructing the release of resources of the mobile relay and/or the release of (grouped) resources for one or more terminals served by the mobile relay is sent to the mobile relay. Source base station node terminal XnAP ID, target source base station node terminal XnAP ID, and/or source base station node terminal May include XnAP ID. As another example, index information for mapping one or more of the source base station node terminal XnAP ID and the target source base station node terminal XnAP ID can be defined and used. As another example, information to identify a group of terminals serviced by a mobile relay can be defined and used. The information can be included in the message.

Terminal operations served by the mobile relay during handover/topology coordination of the mobile relay

During handover/topology adjustment of the mobile relay, one or more terminals served by the mobile relay can transmit and receive data while maintaining an RRC connection through a cell provided by the mobile relay.

For example, when the mobile relay performs a handover/topology adjustment procedure without changing the PCI for any cell provided by the mobile relay, on the wireless interface (Uu) between the terminal served by the mobile relay and the mobile relay. You can send and receive data while maintaining a wireless connection. However, as the wireless backhaul link between the mobile relay and the source donor base station is changed to a wireless backhaul link between the mobile relay and the target donor base station, packet/PDU loss may occur in the wireless link. Accordingly, loss occurs in the wireless/wireless backhaul section for terminal(s) configured with a wireless bearer operating in RLC AM mode. To improve this, during the handover/topology adjustment of the mobile relay, the target donor base station/IAB-donor-CU (or source donor base station/IAB-donor-CU) checks the terminal(s) served by the mobile relay, if the terminal If a radio bearer with RLC AM mode is configured, one of PDCP data recovery and PDCP entity re-establishment can be instructed for the radio bearer. For example, this can be indicated in step 2, step 3, or any step in FIG. 13.

When the terminal receives information indicating PDCP data recovery, it can perform retransmission for all PDCP Data PDUs previously submitted to the corresponding AM RLC entity in ascending order of the COUNT value for which successful delivery has not been confirmed by the lower layer. (perform retransmission of all the PDCP Data PDUs previously submitted to AM RLC entities in ascending order of the associated COUNT values for which the successful delivery has not been confirmed by lower layers). Here, the corresponding AM RLC entity may be in one of the following states: reset, released, set after being released, reconfigured, or maintain previous configuration.

When the terminal receives information indicating PDCP entity reset, successful delivery of the corresponding PDCP Data PDU is performed in ascending order of the COUNT value associated with the PDCP SDU before PDCP entity reset, starting with the first PDCP SDU for which the lower layer has not confirmed the successful delivery. Can perform retransmission or transmission of all PDCP SDUs that already have PDCP SNs (from the first PDCP SDU for which the successful delivery of the corresponding PDCP Data PDU has not been confirmed by lower layers, perform retransmission or transmission of all the PDCP SDUs already associated with PDCP SNs in ascending order of the COUNT values associated to the PDCP SDU prior to the PDCP entity re-establishment).

The donor base station/IAB-donor-CU can use a dedicated RRC message (e.g. RRC reconfiguration message) to instruct the corresponding terminal through the mobile relay. For example, a dedicated RRC message can be used to instruct legacy terminals that do not support this function. As another example, the donor base station/IAB-donor-CU can use system information to instruct the corresponding terminal through a mobile relay. For example, system information can be used to indicate which terminal supports the corresponding function. Transmission of system information via the mobile relay may be directed using any of the methods described herein.

For another example, when the mobile relay performs a handover/topology adjustment procedure involving PCI change for any cell provided by the mobile relay, the terminal served by the mobile relay undergoes cell change/handover (reconfiguration). with sync) operation must be performed. For example, start the T304 timer, start downlink synchronization to the target cell, initiate random access, apply the BCCH configuration specified in TS38.331 9.1.1.1 for the target cell, obtain the MIB, and add the source cell to the target cell group for each SRB. RLC entity setting with the same configuration as the group, logical channel setting with the same configuration as the source cell group, applying a new UE-Identity value from the target cell group to the C-RNTI, MAC reset, lower layer configuration (configure) lower layers in accordance with the received spCellConfigCommon, configure lower layers in accordance with any additional fields, not covered in the previous, if included in the received reconfigurationWithSync, e.g. DRB configuration), logged measurement available to the terminal, available If there is one or more of the following: connection establishment failure, available connection resumption failure, available radio link failure, available handover failure, the RRC reconfiguration complete message has a log measurement available, an available connection establishment failure, or an available handover failure. Partial application of CSI reporting configuration, scheduling request configuration, and sounding RS configuration that does not require the terminal to know the SFN of the target cell, including information held during connection resumption failure, available radio link failure, and available handover failure ( Operations such as apply the parts of the CSI reporting configuration, the scheduling request configuration and the sounding RS configuration that do not require the UE to know the SFN of the respective target SpCell, if any) must be performed. The terminal(s) served by the mobile relay must perform a cell change/handover operation according to the PCI change, but there is no significant change in the basic wireless channel status between the terminal(s) and the mobile relay. Therefore, the terminal served by the mobile relay does not need to perform one or more of the above-described cell change/handover (reconfiguration with sync) operations or can be simplified to perform them. The operations include starting the T304 timer, starting downlink synchronization to the target cell, starting random access, applying the BCCH configuration specified in TS38.331 9.1.1.1 to the target cell, obtaining MIB, and assigning the source cell group to the target cell group for each SRB. Setting RLC entity with same configuration, setting logical channel with same configuration as source cell group, applying new UE-Identity value from target cell group to C-RNTI, MAC reset, lower layer configuration, terminal available If there is one or more of the following: a logged measurement, an available connection establishment failure, an available connection resumption failure, an available radio link failure, or an available handover failure, the RRC reconfiguration complete message contains a logged measurement available. ), CSI reporting configuration that does not require the terminal to know the SFN of the target cell, including information held during available connection establishment failure, available connection resumption failure, available wireless link failure, and available handover failure, scheduling request Configuration, can be a partial application of the sounding RS configuration.

To support this, as an example, when a terminal served by a mobile relay performs a cell change/handover according to a PCI change or when a handover is performed according to a handover/topology adjustment of the mobile relay, simplified operations are instructed. You can define the information to do this and instruct the relevant terminal(s). For example, when a terminal served by a mobile relay performs a cell change/handover according to a PCI change or a handover according to a handover/topology adjustment of the mobile relay, a new device is used as a C-RNTI. There is no need to specify and apply a terminal identifier. The same C-RNTI can be used in the source cell and target cell. If the donor base station/IAB-CU is not changed, the existing SRB can be used as is without setting the RLC entity or logical channel for the SRB, and there is no need to include log measurement or failure information in the RRC reconfiguration complete message. Upon receiving the corresponding indication information, the terminal can perform cell change/handover in the cell provided by the mobile relay without performing one or more of the cell change/handover (reconfiguration with sync) operations described above. As another example, for each DRB, the terminal sets up/reconfigures/maintains an RLC entity with the same configuration as the source cell group in the target cell group, sets up/reconfigures/maintains a logical channel with the same configuration as the source cell group, and sets up/reconfigures/maintains a logical channel with the same configuration as the source cell group. One or more of the following can be performed: setting/reconfiguring/maintaining a PDCP entity with the same configuration as the cell group, and setting/reconfiguring/maintaining an SDAP entity with the same configuration as the source cell group. This can be indicated to the corresponding terminal(s) through the information for indicating this. As another example, the terminal may configure/reconfigure/maintain any radio resource configuration parameters configured in the source cell group for the target cell group to have the same configuration as the source cell group. For example, except for parameters for synchronization and random access procedures, data transmission and reception can be resumed by maintaining the same configuration as the source cell group for any configuration for transmitting and receiving data through the control channel/data channel. This can be indicated to the corresponding terminal(s) through information for indicating this. The corresponding instruction information can be indicated through individual instruction information for each parameter using the same configuration as the source cell. Alternatively, one or more parameters can be indicated through one instruction information.

As another example, the mobile relay is connected to the source cell group during the handover/topology adjustment of the mobile relay, during a specific operation/step of the handover/topology adjustment of the mobile relay, or during the target cell synchronization and random access procedure of the mobile relay. The configured RRC connection, RRC configuration parameters, and corresponding cell/MCG transmission can be suspended. Or, the terminal may use the RRC configured in the source cell group during handover/topology adjustment of the mobile relay, during a specific operation/step of handover/topology adjustment of the mobile relay, or during the synchronization and random access procedure of the terminal. You can suspend the connection, RRC configuration parameters, and the corresponding cell/MCG transmission.

When synchronization to the target cell successfully completes random access, the corresponding RRC connection, RRC configuration parameters, and corresponding cell/MCG transmission can be resumed to transmit and receive data. This can be indicated to the corresponding terminal(s) through information for indicating this. As another example, the terminal may suspend the RRC connection, RRC configuration parameters, and corresponding cell/MCG transmission configured in the source cell group while synchronizing to the PCI cell changed by the mobile relay. When synchronizing to a PCI changed cell and sending an RRC reconfiguration complete message, data can be transmitted and received by resuming the RRC connection, RRC configuration parameters, and cell/MCG transmission. This can be indicated to the corresponding terminal(s) through information for indicating this.

As another example, the donor base station/IAB-donor-CU may indicate the arbitrary indication information described above to the corresponding terminal through the mobile relay using a dedicated RRC message (e.g. RRC reconfiguration message). For example, a dedicated RRC message can be used to instruct legacy terminals that do not support this function. As another example, the donor base station/IAB-donor-CU can use system information to instruct the corresponding terminal through a mobile relay. For example, system information can be used to indicate which terminal supports the corresponding function. Transmission of system information via the mobile relay may be directed using any of the methods described herein.

As another example, the mobile relay sends information to indicate that the PCI change is initiated/performed/applied when or before the PCI change to the cell provided by the mobile relay is initiated/performed/applied to the donor base station/IAB serving the mobile relay. It can be transmitted with -donor-CU.

How to perform conditional handover/RRC reset

During PCI change and/or handover/topology adjustment of the mobile relay, it is considerable to perform the handover procedure by transmitting handover commands to individual terminals in a short period of time for multiple terminals served by the mobile relay. This may cause signaling load. Some terminals may not be able to perform handover in an appropriate time. Accordingly, a wireless link failure/handover failure may occur/detect in the terminal. The terminal may initiate an RRC reset procedure. In order to restore the RRC connection, time is required for radio link failure/handover failure detection, cell selection, and RRC reset signaling. In order to reduce this service interruption, the donor base station/IAB-donor-CU configures conditional handover or conditional RRC connection reset for the terminal(s) served by the mobile relay, and when the conditions are met, the terminal A handover or RRC reset can be initiated/performed.

For example, the donor base station/IAB-donor-CU configures the terminal with instructions/help information to trigger conditional handover/conditional RRC reset/RRC reset for the terminal(s) served by the mobile relay. You can. The instruction/help information is one of the following: PCI of the cell to be changed, conditional handover trigger condition/event, conditional handover configuration, (conditional) RRC reset trigger condition/event, and PCI change/cell change/handover timing information. It may include more. Conditional handover configuration and PCI change/cell change timing information may be provided according to any embodiment included in the present invention. For example, the help information may be indicated to the terminal through RRC-specific information. Alternatively, the help information may be indicated to the terminal through system information. As another example, the conditional handover trigger condition/event or (conditional) RRC reset trigger condition/event may be a time-based trigger condition using PCI change timing information or cell change timing information. Time-based trigger conditions using PCI change/cell change timing can be configured together with measurement-based trigger conditions (e.g. CHO A3/A4/A5). Alternatively, time-based trigger conditions using PCI change/cell change timing can be configured without measurement-based trigger conditions (e.g. CHO A3/A4/A5). If the PCI change/cell change time is configured as a specific absolute time/time/point in time, there is no need to configure measurement-based trigger conditions together. As another example, the A2 event may be defined to be used as a trigger condition for conditional handover or conditional RRC reset. In the prior art, only A3/A4/A5 were used as measurement-based trigger conditions/events for conditional handover. However, a PCI change can be detected by the serving cell as Event A2 (Serving becomes worse than threshold), in which the measurement value becomes worse than a certain threshold. Therefore, the A2 event can be additionally defined and used as a trigger condition for conditional handover or conditional RRC reset. For example, a conditional event (condEventA2) can be defined in the conditional trigger configuration (CondTriggerConfig) information element. The conditional event information element may include a2-threshld, hysteresis, and timeToTrigger information as detailed information elements. As another example, a time-based trigger condition using PCI change/cell change timing can be configured with arbitrary wireless link failure criteria. For example, it may be configured with arbitrary wireless link failure criteria such as Expiry of a radio problem timer started after indication of radio problems from the physical layer, RLC failure, etc. Alternatively, conditional handover/conditional RRC reset/RRC reset may be initiated when arbitrary wireless link failure criteria are met. As another example, the candidate cell configuration for conditional handover/conditional RRC reset/RRC reset may be configured with a changed PCI value. As another example, when initiating/executing conditional handover/conditional RRC reset/RRC reset, the terminal may initiate/execute conditional handover/conditional RRC reset/RRC reset when a cell using the indicated PCI value is selected. You can. The terminal can apply the stored conditional handover configuration (e.g. condRRCReconfig) associated with the selected cell. As another example, a conditional handover configuration may be provided according to any embodiment included in the present invention.

For another example, precise time control is required when PCI change/cell change occurs. Before the switch point, (all) terminals (or RRC connected terminals) served by the mobile relay must receive a conditional handover/conditional RRC reset/handover command and/or transmit a confirmation message for receiving an RRC message. . It is possible to prevent certain operations for handover (e.g. target cell synchronization, random access procedure to the target cell) from starting before the switch point. do. A specific operation for handover can be initiated after the switch point.

For another example, in the prior art, if a handover failure occurs when the UE performs a handover, the UE transmits the PCI, C-RNTI, and shortMAC-I/MAC-I of the source PCell in the RRC reset request message. do. The base station that received the message uses the PCI and C-RNTI of the source PCell to identify the terminal. If the terminal fails in handover during the PCI change process and the PCI of the cell provided by the mobile relay is changed and the PCI before the change is deleted/released/discarded, the base station detects/extracts the terminal context for the corresponding terminal and performs RRC. Connection cannot be re-established/maintained. Therefore, when PCI is changed, it is necessary to maintain information about the change history. As another example, if a handover failure occurs when the terminal performs a handover due to a PCI change, the terminal includes one or more of the target PCell's PCI, C-RNTI, and shortMAC-I/MAC-I in the RRC reset request message. You can send it. Alternatively, one or more of the target PCell's PCI, C-RNTI, shortMAC-I/MAC-I and the source PCell's PCI, C-RNTI, shortMAC-I/MAC-I can be included and transmitted in the RRC reset request message. .

Method of processing user plane data of terminal serviced by mobile relay

During handover/topology adjustment of the mobile relay and/or during handover of the terminal(s) served by the mobile relay, service continuity must be provided/supported for the terminal(s) served through the mobile relay. For example, lossless forwarding must be supported for radio bearers using RLC-AM. Alternatively, handover operations for the corresponding terminal must be supported to minimize service interruption.

14, 15, and 16 show an example of a protocol structure for user plane data transmission of a terminal served by a mobile relay during and/or after handover/topology adjustment of the mobile relay. One or more of FIGS. 14, 15, and 16 may be used in any order, and the structure of any one of FIGS. 14, 15, and 16 may be used.

As described above, the data radio bearer (DRB) of the terminal served by the mobile relay is set up/connected in connection with the F1-U protocol (F1-U GTP-U tunnel) between the mobile relay and the donor base station/IAB-donor-CU. /can be configured.

A data radio bearer (DRB) that carries user data of a terminal served by a mobile relay, for example during handover/topology adjustment of the mobile relay and/or during handover of the terminal(s) served by the mobile relay. To link, an F1-U/GTP-U tunnel can be maintained between the mobile relay and the source donor base station/IAB-donor-CU. Even after the handover/topology adjustment of the mobile relay is completed, user data of the terminal served by the mobile relay can be transmitted and received through the corresponding F1-U protocol/GTP-U tunnel. The user plane traffic of the terminal served by the mobile relay can be delivered from the source donor base station/IAB-donor-CU to the core network.

The donor base station/IAB-donor-CU serving the mobile relay through handover/topology adjustment of the mobile relay and/or handover of the terminal(s) served by the mobile relay is the source donor base station/IAB-donor-CU. The target is changed to donor base station/IAB-donor-CU. The terminal context for the terminal served by the mobile relay can also be maintained at the source donor base station/IAB-donor-CU. And/or the terminal context for the terminal served by the mobile relay can be maintained by the target donor base station/IAB-donor-CU.

As an example, uplink user plane data of a terminal served by a mobile relay can be mapped/linked in the mobile relay and transmitted to the source donor base station/IAB-donor-CU through the target donor base station/IAB-donor-CU. . The uplink user plane data of the terminal served by the mobile relay can be mapped and transmitted on the GTP-U tunnel between the mobile relay and the source donor base station/IAB-donor-CU, as shown in FIG. 14. For example, the transmission path for user plane data of a terminal served by Mobile Relay goes from ‘Terminal <-> Source Donor Base Station <-> Core Network’ to ‘Terminal <-> Target Donor Base Station <-> Source Donor Base Station <-> -> It can be transmitted and received by switching the path to the ‘core network’. At this stage, the path switch procedure between the base station and the core network is not required.

The BAP entity of the mobile relay (e.g. the transmitting part of BAP entity) can receive BAP SDUs from the upper layer (e.g. GTP-U/UDP/IP). and the mobile received from the source donor base station/IAB-donor-CU (or from the target donor base station/IAB-donor-CU via the source donor base station/IAB-donor-CU, or from the target donor base station/IAB-donor-CU). Using the uplink user plane tunnel information to be set up in the relay, you can determine the BAP address and Path ID and add a BAP PDU header to create BAP Data PDUs. The source donor base station/IAB-donor-CU or target donor base station/IAB-donor-CU can indicate the uplink user plane tunnel information to be set up/modified in the mobile relay through the F1AP/RRC message. The uplink user plane tunnel information to be set up/modified indicated by the mobile relay includes the source base station terminal XnAP identifier, target base station terminal XnAP identifier, user plane DRB/RLC channel ID, and uplink user of the terminal served by the mobile relay. One or more of the plain TNL address (GTP tunnel, Transport-layer-address/IP-address, GTP-TEID) and backhaul information can be linked. Here, the backhaul information may include the BAP address of the target IAB-donor/IAB-donor-DU, BAP routing ID including Path ID, and next-hop BAP address.

One or more information included in the uplink user plane tunnel information to be set up/modified can be transmitted and received between the source donor base station/IAB-donor-CU and the target donor base station/IAB-donor-CU. As an example, the source donor base station/IAB-donor-CU may include one or more information (e.g. source base station terminal XnAP identifier, user plane DRB of the terminal served by the mobile relay) included in the uplink user plane tunnel information to be set up/modified. -ID/RLC channel ID/LCID, uplink user plane TNL address) can be included in the XnAP message and transmitted to the target donor base station/IAB-donor-CU. As another example, the target donor base station/IAB-donor-CU is one or more information included in the uplink user plane tunnel information to be set up/modified (e.g. target base station terminal XnAP identifier, target IAB-donor/IAB-donor-DU BAP routing ID) can be included in the XnAP message and transmitted to the source donor base station/IAB-donor-CU.

The source donor base station/IAB-donor-CU or target donor base station/IAB-donor-CU can transmit the uplink user plane tunnel information to be set up/modified through the F1AP/RRC message to the mobile relay.

The mobile relay or source donor base station/IAB-donor-CU can indicate the downlink user plane tunnel information to be set up/modified to the target donor base station/IAB-donor-CU through the F1AP/XnAP/RRC message. The downlink user plane tunnel information to be set up/modified indicated by the target donor base station/IAB-donor-CU includes the source base station terminal XnAP identifier, target base station terminal XnAP identifier, and user plane DRB- ID/RLC channel ID/LCID, downlink user plane TNL address (GTP tunnel, Transport-layer-address/IP-address, GTP-TEID) can be linked.

The transmission path for the user plane data of the terminal serviced by the mobile relay is 'Terminal <-> Source Donor Base Station <-> Core Network' to 'Terminal <-> Target Donor Base Station <-> Source Donor Base Station <-> Core In order to transmit and receive by switching paths to the network, the source donor base station/IAB-donor-CU and the target donor base station/IAB-donor-CU are included in the uplink user plane tunnel information to be set up/modified through coordination. The above information and one or more pieces of information included in the downlink user plane tunnel information to be set up/modified can be exchanged. For example, it can be transmitted and received in steps 1 and 2 of FIG. 13 by including it in the handover request message and handover request confirmation/response message. Alternatively, it can be transmitted and received by including it in an arbitrary XnAP message for switching the transmission path after step 7 of FIG. 13. Alternatively, in the case of conditional handover/RRC reset, after conditional handover is configured in the terminal, it can be transmitted and received by including it in an arbitrary XnAP message for switching the transmission path.

The source donor base station/IAB-donor-CU or the target donor base station/IAB-donor-CU sends the uplink user plane tunnel information to be set up/modified and the downlink user plane tunnel to be set up/modified through the F1AP/RRC message. Information can be transmitted via mobile relay.

When the mobile relay receives the F1AP/RRC message containing the above information, it can create BAP data PDUs including the BAP routing ID of the target donor base station/IAB-donor/IAB-donor-DU in the BAP header. Alternatively, the mobile relay can perform a BAP header rewriting operation when receiving the F1AP/RRC message containing the above-described information. For example, the mobile relay enters the BAP routing ID (BAP address, BAP Path ID) of the source donor base station/IAB-donor/IAB-donor-DU in the header of the BAP data PDU as source donor base station/IAB-donor/IAB-donor-DU. It can be changed to DU’s BAP routing ID. The rewriting operation may be performed at any step specified herein or by any instruction information. To this end, it may include information for instructing F1AP/RRC message BAP header rewriting and/or configuration information for this (e.g. source BAP routing ID, target BAP routing ID).

Data Radio Bearer (DRB) carrying user data of the terminal(s) served by the mobile relay, for example during handover/topology adjustment of the mobile relay and/or during handover of the terminal(s) served by the mobile relay. To link, the F1-U/GTP-U tunnel between the mobile relay and the target donor base station/IAB-donor-CU/IAB-donor-DU and/or the target donor base station/IAB-donor-CU and the source donor base station/IAB- You can configure/set up/modify the F-U/GTP-U tunnel between donor-CU/IAB-donor-DU. The user plane traffic of the terminal served by the mobile relay can be delivered from the source donor base station/IAB-donor-CU to the core network. At this stage, the path switch procedure between the base station and the core network is not required.

The donor base station/IAB-donor-CU serving the mobile relay through handover/topology adjustment of the mobile relay and/or handover of the terminal(s) served by the mobile relay is the source donor base station/IAB-donor-CU. The target is changed to donor base station/IAB-donor-CU. The terminal context for the terminal served by the mobile relay can also be maintained at the source donor base station/IAB-donor-CU. And/or the terminal context for the terminal serviced by the mobile relay can also be maintained in the target donor base station/IAB-donor-CU.

As an example, uplink user plane data of a terminal served by a mobile relay can be mapped/linked in the mobile relay and transmitted to the source donor base station/IAB-donor-CU through the target donor base station/IAB-donor-CU. . The uplink user plane data of the terminal served by the mobile relay is the F1-U tunnel/GTP-U tunnel between the mobile relay and the target donor base station/IAB-donor-CU and the target donor base station/IAB-donor-CU, as shown in Figure 15. It can be mapped and transmitted on the F1-U tunnel/GTP-U tunnel between the source donor base station/IAB-donor-CU. For example, the transmission path for user plane data of a terminal served by Mobile Relay goes from ‘Terminal <-> Source Donor Base Station <-> Core Network’ to ‘Terminal <-> Target Donor Base Station <-> Source Donor Base Station <-> -> It can be transmitted and received by switching the path to the ‘core network’.

The BAP entity of the mobile relay (e.g. the transmitting part of BAP entity) can receive BAP SDUs from the upper layer (e.g. GTP-U/UDP/IP). and the mobile received from the source donor base station/IAB-donor-CU (or from the target donor base station/IAB-donor-CU via the source donor base station/IAB-donor-CU, or from the target donor base station/IAB-donor-CU). Using the uplink user plane tunnel information to be set up in the relay, you can determine the BAP address and Path ID and add a BAP PDU header to create BAP Data PDUs. The source donor base station/IAB-donor-CU or target donor base station/IAB-donor-CU can indicate the uplink user plane tunnel information to be set up/modified in the mobile relay through the F1AP/RRC message. The uplink user plane tunnel information to be set up/modified indicated by the mobile relay includes the source base station terminal XnAP identifier, target base station terminal XnAP identifier, user plane DRB/RLC channel ID, and uplink user of the terminal served by the mobile relay. One or more of the plain TNL address (GTP tunnel, Transport-layer-address/IP-address, GTP-TEID) and backhaul information can be linked. Here, the backhaul information may include the BAP address of the target IAB-donor/IAB-donor-DU, BAP routing ID including Path ID, and next-hop BAP address.

One or more information included in the uplink user plane tunnel information to be set up/modified can be transmitted and received between the source donor base station/IAB-donor-CU and the target donor base station/IAB-donor-CU. As an example, the source donor base station/IAB-donor-CU may include one or more information (e.g. source base station terminal XnAP identifier, user plane DRB of the terminal served by the mobile relay) included in the uplink user plane tunnel information to be set up/modified. -ID/RLC channel ID/LCID, uplink user plane TNL address of target donor base station/IAB-donor-CU/IAB-donor-DU, uplink of source donor base station/IAB-donor-CU/IAB-donor-DU Link user plane TNL address) can be included in the XnAP message and transmitted to the target donor base station/IAB-donor-CU. As another example, the target donor base station/IAB-donor-CU is one or more information included in the uplink user plane tunnel information to be set up/modified (e.g. source base station terminal XnAP identifier, target base station terminal XnAP identifier, target IAB-donor/IAB -donor-DU BAP routing ID) can be included in the XnAP message and transmitted to the source donor base station/IAB-donor-CU.

The source donor base station/IAB-donor-CU or target donor base station/IAB-donor-CU can transmit the uplink user plane tunnel information to be set up/modified through the F1AP/RRC message to the mobile relay.

The mobile relay or source donor base station/IAB-donor-CU can indicate the downlink user plane tunnel information to be set up/modified to the target donor base station/IAB-donor-CU through the F1AP/XnAP/RRC message. The downlink user plane tunnel information to be set up/modified indicated by the target donor base station/IAB-donor-CU includes the source base station terminal XnAP identifier, target base station terminal XnAP identifier, and user plane DRB- ID/RLC channel ID/LCID, downlink user of mobile relay plane TNL address (GTP tunnel, transport-layer-address/IP-address, GTP-TEID), downlink user of target donor base station/IAB-donor-CU Plain TNL addresses can be linked.

The transmission path for the user plane data of the terminal serviced by the mobile relay is 'Terminal <-> Source Donor Base Station <-> Core Network' to 'Terminal <-> Target Donor Base Station <-> Source Donor Base Station <-> Core In order to transmit and receive by switching paths to the network, the source donor base station/IAB-donor-CU and the target donor base station/IAB-donor-CU are included in the uplink user plane tunnel information to be set up/modified through coordination. The above information and one or more pieces of information included in the downlink user plane tunnel information to be set up/modified can be exchanged. For example, it can be transmitted and received in steps 1 and 2 of FIG. 13 by including it in the handover request message and handover request confirmation/response message. Alternatively, it can be transmitted and received by including it in an arbitrary XnAP message for switching the transmission path after step 7 of FIG. 13. Alternatively, in the case of conditional handover/RRC reset, after conditional handover is configured in the terminal, it can be transmitted and received by including it in an arbitrary XnAP message for switching the transmission path.

The source donor base station/IAB-donor-CU or the target donor base station/IAB-donor-CU sends the uplink user plane tunnel information to be set up/modified and the downlink user plane tunnel to be set up/modified through the F1AP/RRC message. Information can be transmitted via mobile relay. The source donor base station/IAB-donor-CU sends the uplink user plane tunnel information to be set up/modified and the downlink user plane tunnel information to be set up/modified to the target donor base station/IAB-donor-CU through XnAP messages. Can be transmitted.

When the mobile relay receives the F1AP/RRC message containing the above information, it can create BAP data PDUs including the BAP routing ID of the target donor base station/IAB-donor/IAB-donor-DU in the BAP header. Alternatively, the mobile relay can perform a BAP header rewriting operation when receiving the F1AP/RRC message containing the above-described information. For example, the mobile relay enters the BAP routing ID (BAP address, BAP Path ID) of the source donor base station/IAB-donor/IAB-donor-DU in the header of the BAP data PDU as source donor base station/IAB-donor/IAB-donor-DU. It can be changed to DU’s BAP routing ID. The rewriting operation may be performed at any step specified herein or by any instruction information. To this end, it may include information for instructing F1AP/RRC message BAP header rewriting and/or configuration information for this (e.g. source BAP routing ID, target BAP routing ID).

Data Radio Bearer (DRB) carrying user data of the terminal(s) served by the mobile relay, for example during handover/topology adjustment of the mobile relay and/or during handover of the terminal(s) served by the mobile relay. To link, you can configure/set up/edit the F1-U/GTP-U tunnel between the mobile relay and the target donor base station/IAB-donor-CU/IAB-donor-DU. The user plane traffic of the terminal served by the mobile relay can be transmitted from the target donor base station/IAB-donor-CU to the core network.

The donor base station/IAB-donor-CU serving the mobile relay through handover/topology adjustment of the mobile relay and/or handover of the terminal(s) served by the mobile relay is the source donor base station/IAB-donor-CU. The target is changed to donor base station/IAB-donor-CU. The terminal context for the terminal served by the mobile relay can be released from the source donor base station/IAB-donor-CU through a corresponding message (e.g. terminal context release message). And/or the terminal context for the terminal served by the mobile relay may be maintained in the target donor base station/IAB-donor-CU.

For example, uplink user plane data of a terminal served by a mobile relay can be mapped/linked in the mobile relay and transmitted to the core network through the target donor base station/IAB-donor-CU. The uplink user plane data of the terminal served by the mobile relay can be mapped and transmitted on the F1-U tunnel/GTP-U tunnel between the mobile relay and the target donor base station/IAB-donor-CU, as shown in FIG. 16. For example, the transmission path for user plane data of a terminal serviced by mobile relay is from ‘terminal <-> source donor base station <-> core network’ to ‘terminal <-> target donor base station <-> core network’. It can be transmitted and received by switching paths.

The BAP entity of the mobile relay (e.g. the transmitting part of BAP entity) can receive BAP SDUs from the upper layer (e.g. GTP-U/UDP/IP). and the mobile received from the source donor base station/IAB-donor-CU (or from the target donor base station/IAB-donor-CU via the source donor base station/IAB-donor-CU, or from the target donor base station/IAB-donor-CU). Using the uplink user plane tunnel information to be set up in the relay, you can determine the BAP address and Path ID and add a BAP PDU header to create BAP Data PDUs. The source donor base station/IAB-donor-CU or target donor base station/IAB-donor-CU can indicate the uplink user plane tunnel information to be set up/modified in the mobile relay through the F1AP/RRC message. The uplink user plane tunnel information to be set up/modified indicated by the mobile relay includes the source base station terminal XnAP identifier, target base station terminal XnAP identifier, user plane DRB/RLC channel ID, and uplink user of the terminal served by the mobile relay. One or more of the plain TNL address (GTP tunnel, Transport-layer-address/IP-address, GTP-TEID) and backhaul information can be linked. Here, the backhaul information may include the BAP address of the target IAB-donor/IAB-donor-DU, BAP routing ID including Path ID, and next-hop BAP address.

One or more information included in the uplink user plane tunnel information to be set up/modified can be transmitted and received between the source donor base station/IAB-donor-CU and the target donor base station/IAB-donor-CU. As an example, the source donor base station/IAB-donor-CU may include one or more information (e.g. source base station terminal XnAP identifier, user plane DRB of the terminal served by the mobile relay) included in the uplink user plane tunnel information to be set up/modified. -ID/RLC channel ID/LCID, uplink user plane TNL address of target donor base station/IAB-donor-CU/IAB-donor-DU) is included in the XnAP message and transmitted to target donor base station/IAB-donor-CU You can. As another example, the target donor base station/IAB-donor-CU is one or more information included in the uplink user plane tunnel information to be set up/modified (e.g. source base station terminal XnAP identifier, target base station terminal XnAP identifier, target IAB-donor/IAB -donor-DU BAP routing ID) can be included in the XnAP message and transmitted to the source donor base station/IAB-donor-CU.

The source donor base station/IAB-donor-CU or target donor base station/IAB-donor-CU can transmit the uplink user plane tunnel information to be set up/modified through the F1AP/RRC message to the mobile relay.

The mobile relay or source donor base station/IAB-donor-CU can indicate the downlink user plane tunnel information to be set up/modified to the target donor base station/IAB-donor-CU through the F1AP/XnAP/RRC message. The downlink user plane tunnel information to be set up/modified indicated by the target donor base station/IAB-donor-CU includes the source base station terminal XnAP identifier, target base station terminal XnAP identifier, and user plane DRB- ID/RLC channel ID/LCID, mobile relay's downlink user plane TNL address (GTP tunnel, Transport-layer-address/IP-address, GTP-TEID) can be linked.

The transmission path for the user plane data of the terminal served by the mobile relay switches from 'Terminal <-> Source Donor Base Station <-> Core Network' to 'Terminal <-> Target Donor Base Station <-> Core Network'. In order to transmit and receive, the source donor base station/IAB-donor-CU and the target donor base station/IAB-donor-CU must set up/modify one or more pieces of information included in the uplink user plane tunnel information to be set up/modified through coordination. One or more information included in the downlink user plane tunnel information to be modified may be exchanged. For example, it can be transmitted and received in steps 1 and 2 of FIG. 13 by including it in the handover request message and handover request confirmation/response message. Alternatively, it can be transmitted and received by including it in an arbitrary XnAP message for switching the transmission path after step 7 of FIG. 13. Alternatively, in the case of conditional handover/RRC reset, after conditional handover is configured in the terminal, it can be transmitted and received by including it in an arbitrary XnAP message for switching the transmission path.

The source donor base station/IAB-donor-CU or the target donor base station/IAB-donor-CU sends the uplink user plane tunnel information to be set up/modified and the downlink user plane tunnel to be set up/modified through the F1AP/RRC message. Information can be transmitted via mobile relay. The source donor base station/IAB-donor-CU sends the uplink user plane tunnel information to be set up/modified and the downlink user plane tunnel information to be set up/modified to the target donor base station/IAB-donor-CU through XnAP messages. Can be transmitted.

When the mobile relay receives the F1AP/RRC message containing the above information, it can create BAP data PDUs including the BAP routing ID of the target donor base station/IAB-donor/IAB-donor-DU in the BAP header. Alternatively, the mobile relay can perform a BAP header rewriting operation when receiving the F1AP/RRC message containing the above-described information. For example, the mobile relay enters the BAP routing ID (BAP address, BAP Path ID) of the source donor base station/IAB-donor/IAB-donor-DU in the header of the BAP data PDU as source donor base station/IAB-donor/IAB-donor-DU. It can be changed to DU’s BAP routing ID. The rewriting operation may be performed at any step specified herein or by any instruction information. To this end, it may include information for instructing F1AP/RRC message BAP header rewriting and/or configuration information for this (e.g. source BAP routing ID, target BAP routing ID).

For example, F1-C traffic between the mobile relay and the donor base station/IAB-donor-CU, or F1-C traffic containing control messages of the terminal served by the mobile relay, or user plane of the terminal served by the mobile relay. To support data transmission, the target donor base station/IAB-donor-CU has gNB-CU UE F1AP ID, gNB-DU UE F1AP ID, user plane DRB-ID/RLC channel ID/LCID, and downlink user of mobile relay. Plain TNL address, uplink TNL address of target donor base station/IAB-donor-CU, backhaul RLC channel (backhaul RLC channel ID), BAP routing entry (BAP routing ID, BAP address, BAP path id), target of mobile relay One or more of the downlink mapping information (e.g. TNL address information(s) of the mobile relay for F1-C traffic/user plane traffic) on the target IAB-donor-DU for the route. -Can be configured on the target path between DU/IAB-donor-CU.

The target IAB-donor-DU/IAB-donor-CU can configure/instruct the relevant information to the mobile relay through F1AP/RRC message.

For another example, the mobile relay provides a source donor base station/IAB-donor-CU for each user plane F1-U/GTP-U tunnel associated with each DBR, for the terminal(s) served by the mobile relay. It is possible to allocate new TNL address information that is different from the TNL and address used and transmit it to the source donor base station/IAB-donor-CU. The source donor base station/IAB-donor-CU can transmit the received information to the target donor base station/IAB-donor-CU. The target donor base station/IAB-donor-CU is the terminal identifier to be switched to the source donor base station/IAB-donor-CU, DRB identifier/RLC identifier/LCID, backhaul RLC channel identifier, uplink TNL address for user plane traffic, downlink You can reply including the link TNL address. Using the new TNL address information of the mobile relay, the F1-U connection between the mobile relay and the source donor base station/IAB-donor-CU can be switched to an F1-U connection between the mobile relay and the target donor base station/IAB-donor-CU. . The user plane traffic of the terminal served by the mobile relay can be transmitted from the target donor base station/IAB-donor-CU to the core network. The source donor base station/IAB-donor-CU can provide updated uplink backhaul information to the mobile relay based on the uplink backhaul information (backhaul routing ID) received from the target donor base station/IAB-donor-CU.

The operations described above may be performed at any step included in FIG. 13, before any step included in FIG. 13, or after any step included in FIG. 13. For convenience of explanation, the operation may be described at a specific step or before or after a specific step, but this is for convenience of explanation and may be described in any step included in FIG. 13 or before or after any step included in FIG. 13. It is obvious that operations performed after any steps included in 13 are also included within the scope of the present invention.

Hereinafter, another embodiment according to the present invention will be described.

The handover request message according to the prior art specified in the TS 38.423 Specifically, it is included in the source base station UE XnAP identifier (Source NG-RAN node UE Global NG-RAN Node ID, S-NG-RAN node UE 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 Mobility Restriction List.

For example, during the handover/topology adjustment procedure for the mobile relay, (when the mobile relay receives the RRC reconfiguration message) the cell provided by the source donor base station/IAB-gNB-CU is detached ( (or disconnect or disconnect the wireless link/connection between the mobile relay and the source donor base station/IAB-gNB-CU), and when connecting only the cells provided by the target donor base station/IAB-gNB-CU, the source donor base station/IAB-gNB-CU The CU may need to transmit or share the terminal context for the terminal(s) served by the corresponding mobile relay held by the source donor base station/IAB-gNB-CU to the target donor base station/IAB-gNB-CU.

For another example, during the handover/topology adjustment procedure for the mobile relay, the cell provided by the source donor base station/IAB-gNB-CU (when the mobile relay receives the RRC reconfiguration message) is not detached. (or maintain a wireless link/connection between the mobile relay and the source donor base station/IAB-gNB-CU), and when connecting to a cell provided by the target donor base station/IAB-gNB-CU, the source donor base station/IAB-gNB-CU The CU may need to transmit or share the terminal context for the terminal(s) served by the corresponding mobile relay held by the source donor base station/IAB-gNB-CU to the target donor base station/IAB-gNB-CU.

Through the -Can be sent to CU. Alternatively, the donor base station/IAB-gNB-CU can request and extract the information from the source donor base station/IAB-gNB-CU.

The corresponding It is obvious that it is also included within the scope of the present invention) is for one or more terminal(s) served by the mobile relay, the source base station terminal XnAP identifier (Source NG-RAN node UE reference), target cell global identifier (Target CGI: Cell Global ID), GUAMI (Globally Unique AMF Identifier), UE History Information, Global NG-RAN Node ID included in the UE context reference, S-NG-RAN node UE XnAP ID and AMF UE NGAP ID (NG-C UE associated Signalling reference) included in the terminal context information, AMF's IP address of the SCTP association (Signalling TNL association address at source NG-C side), terminal security capability (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, Mobility Restriction List It may contain one or more information. Here, the target cell global identifier can use the identifier of the cell provided by the mobile relay.

For another example, during the handover/topology adjustment procedure for the mobile relay, the cell provided by the source donor base station/IAB-gNB-CU (when the mobile relay receives the RRC reconfiguration message) is not detached. (Or maintain the wireless link/connection between the mobile relay and the source donor base station/IAB-gNB-CU) and connect to the cell provided by the target donor base station/IAB-gNB-CU. When the mobile relay receives an explicit release instruction from the target donor base station/IAB-gNB-CU (or from the source donor base station/IAB-gNB-CU), it releases the source donor base station/IAB-gNB-CU resources and configuration and releases the source Donor base station/IAB-gNB-CU and uplink/downlink transmission/reception can be stopped. The mobile relay can continue uplink/downlink transmission/reception with the source donor base station/IAB-gNB-CU until it receives an explicit release instruction. The source donor base station/IAB-gNB-CU (or RRC) may suspend subsequent handover/topology adjustment until the cell provided by the source donor base station/IAB-gNB-CU is released. Here, an explicit release instruction may be indicated through corresponding instruction information in an RRC reconfiguration message or F1AP message. Upon receiving the instruction information, the mobile relay resets the source MAC, deconfigures the source MAC, deconfigures the RLC entity, deconfigures the backhaul RLC entity, deactivates PDCP, deconfigures the physical channel, deconfigures the BAP entity, (source path) in the cell provided by the source donor base station. or release BAP routing entry (BAP routing ID, BAP address, BAP path id) (configured by source donor base station/IAB-gNB-CU), uplink/downlink (configured by source path or source donor base station/IAB-gNB-CU) You can perform one or more of the link TNL information releases. Alternatively, if the handover command for the mobile relay includes information indicating that the handover of terminals served by the mobile relay is performed together, upon receiving the corresponding RRC reconfiguration message (with reconfiguration with sync), the mobile relay is the source donor. In the cell provided by the base station, source MAC reset, source MAC configuration release, RLC entity release, backhaul RLC entity release, PDCP release, physical channel configuration release, BAP entity release, (source path or source donor base station/IAB-gNB-CU) You can perform one or more of the following: clearing BAP routing entries (BAP routing ID, BAP address, BAP path id) (configured by the source path or source donor base station/IAB-gNB-CU), and clearing uplink/downlink TNL information (configured by the source path or source donor base station/IAB-gNB-CU). there is.

The serving cell provided by the mobile relay may move depending on the movement/cell change/handover/topology adjustment of the mobile relay. Moving cells can cause PCI conflict issues. For example, PCI-collision/PCI-confusion may occur when two cells with the same PCI become adjacent neighbors. This can cause synchronization signal collisions, radio link failures, handover failures, contention in RACH attempts, etc. If unique PCIs are assigned to each cell within a specific area, this problem may not occur. Donor base station/IAB-donor-CU can detect/predict/estimate PCI-collision/PCI-confusion/RACH-contention.

The mobile relay can change the PCI information and/or PRACH configuration information of the cell being serviced by the mobile relay. The mobile relay can change the system information of the cell being serviced by the mobile relay through system information update.

For example, at any time, the mobile relay may change the PCI information and/or PRACH configuration information of the cell providing the service. The donor base station serving the mobile relay provides global cell ID (CGI: Cell Global ID), physical cell ID (PCI: Physical) for the cell provided by the donor base station, the cell provided by the corresponding mobile relay, and the cell provided by the adjacent base station. cell id) information. For example, the donor base station manages the Neighbor Cell Relation Table (NCRT) through the automatic Neighbor Cell Relation (ANR) function. NDF (Neighbor Detection Function) located within ANR can find neighbors through the terminal's measurement report and add them to NCRT. The donor base station can know the target cell identified by the source cell. As another example, the donor base station may receive report information about the random access procedure through the RACH report of the terminal. Content related to wireless link failure can be received through the RLF report of the donor base station's terminal. Through this information, the mobile relay/donor base station/terminal can know about cell information of the source cell or adjacent cell, RACH/PRACH configuration and related failure information in that cell.

For another example, when a PCI/RACH conflict is detected/predicted/estimated, the mobile relay provides CGI for the cell provided by the mobile relay, current PCI/system information that needs to be changed, PCI/system information to be changed, and changed/changed information. One or more of the following information may be transmitted to the donor base station: PRACH configuration information, information for requesting/instructing/notifying changes to PCI information/PRACH configuration/system information, and detected RACH failure information. The donor base station can instruct to change the PCI/PRACH configuration/system information of the cell provided by the corresponding mobile relay. Here, an example of PRACH configuration may include one or more of the information included in section 9.3.1.140 of TS 38.473 or rach-ConfigCommon in section 6.3.2 of TS 38.331.

For another example, when a PCI/RACH conflict is detected/predicted/estimated, the donor base station must change the CGI, the current PCI/PCI-set that needs to be changed, and the PCI/PCI-set/available-PCI to be changed/recommended. -lists/One or more information among system information, PRACH configuration information of a neighboring cell, and recommended PRACH configuration information can be transmitted to the mobile relay. The mobile relay may consider the received information when adjusting the PCI/PRACH configuration/system information of the cell it serves. When the mobile relay receives the message and/or changes the PCI/PRACH configuration/system information of the cell provided by the mobile relay, it can transmit a confirmation/response/notification message. The message may include one or more of CGI, current PCI that needs to be changed, changed/to be changed PCI/system information, and changed/to be changed PRACH configuration information.

For another example, when a mobile relay performs handover/topology adjustment for a mobile relay through a different donor base station/IAB-donor-CU, PCI/system information about the cell being served by the mobile relay is provided. Changes can be made (simultaneously or in conjunction).

The source donor base station/IAB-donor-CU and/or the target donor base station/IAB-donor-CU detects a PCI/RACH conflict for the cell provided by the mobile relay whose handover/topology adjustment is being performed during handover/topology adjustment. /predict/estimate.

As an example, the handover request message includes information indicating that the terminal to perform the handover is a mobile relay, cell identification information (e.g. CGI, PCI) for which the mobile relay is providing a service, and arbitrary cell configuration information for the cell (e.g. e.g. RACH/PRACH configuration information), information for indicating whether the corresponding cell is a cell provided by a mobile relay, information for instructing/requesting a change in arbitrary configuration information (e.g. PCI, system information) for the corresponding cell, Changes to arbitrary configuration information (e.g. PCI, system information) for the cell may include one or more pieces of information for instructing/requesting that changes be made simultaneously with (or in conjunction with) handover/topology adjustment of the mobile relay. .

As another example, when receiving one or more of the above-described information from the source donor base station/IAB-donor-CU and/or when a PCI/RACH conflict is detected/predicted/estimated at the target donor base station/IAB-donor-CU, the source donor The base station/IAB-donor-CU or the target donor base station/IAB-donor-CU can create/determine a configuration to instruct/process/respond to this.

As another example, the target donor base station/IAB-donor-CU can detect/predict/estimate PCI/RACH collisions and perform admission control for handover. Alternatively, the target donor base station/IAB-donor-CU detects/predicts/estimates PCI/RACH collisions and, if necessary, CGI for the cell served by the mobile relay in any step of performing the handover procedure, One or more of the following: current PCI/PCI-set that needs to be changed, PCI/PCI-set/available-PCI-lists/system information to be changed/changeable/recommended, PRACH configuration information of neighboring cells, and recommended PRACH configuration information. It can be transmitted including. For example, the handover request confirmation/response message (or handover preparation failure message) contains the CGI for the cell served by the mobile relay, the current PCI/PCI-set that needs to be changed, and the PCI to be changed/changeable/recommended. /PCI-set/available-PCI-lists/May include one or more of system information, PRACH configuration information of neighboring cells, and recommended PRACH configuration information. Corresponding arbitrary information may be provided for each cell (e.g. CGI). Alternatively, it may be provided as common information for the relevant mobile relay (e.g. or DU within the mobile relay).

As another example, the mobile relay can change PCI information for the cell being served by the mobile relay. The mobile relay can broadcast information to indicate/notify/announce PCI change/cell change of the corresponding cell (or handover of terminals served by the mobile relay) through system information. The system information may include one or more of the following: CGI for the cell serviced by the mobile relay, current PCI that needs to be changed, PCI to be changed, and PCI change/cell change timing information. PCI change/cell change timing refers to the time/time/point or time range/duration (start) at which the PCI change is expected/planned/anticipated/started/triggered/applied (or the cell in question is going to stop serving). It can represent time+offset/duration/elapsed time or start time+end time). For example, the time/time range/duration may be indicated as absolute time/UTC (Coordinated Universal Time, timeInfoUTC) and/or offset/duration/elapsed time. (e.g. The field counts the number of UTC seconds in 10 ms units since 00:00:00 on Gregorian calendar date 1 January, 1900 (midnight between Sunday, December 31, 1899 and Monday, January 1, 1900). As another example, the time /Time range/Duration can be expressed as start SFN, start subframe number, start slot offset, offset/duration/elapsed time (ms, number of slots). In another example, the time may be expressed as a specific reference time (e.g., reference SFN). , reference subframe number, reference slot offset, or reference UTC), the corresponding cell change can be indicated to be executed at the expected/planned/anticipated/started/triggered/applied offset/duration/elapsed time (ms, number of slots). there is.

As another example, the donor base station/IAB-donor-CU/mobile relay may notify/instruct PCI change/cell change and/or the aforementioned system information change and/or related system information change through a paging message. For example, this can be notified/instructed using a short message transmitted with P-RNTI through DCI. The paging message may include information to indicate this. The terminal that received the message can perform handover/RRC reset to the cell with the changed PCI. The terminal can transmit confirmation information about receipt of the message to the mobile relay. The confirmation information can be provided through arbitrary L1 (e.g. arbitrary L1 signaling such as UCI, HARQ ACK) / L2 (e.g. arbitrary L2 signaling such as MSG1, MAC CE, RLC ACK) / L3 (e.g. RRC message) signaling.

As another example, the mobile relay may notify/instruct PCI change/cell change and/or the aforementioned system information change and/or related system information change through a terminal-specific RRC-specific message (e.g. RRC reconfiguration message).

As another example, the target donor base station/IAB-donor-CU is a mobile relay that changes PCI/cell and/or changes the aforementioned system information and/or changes related system information for the cell provided by the mobile relay through an F1AP message. You can notify/instruct. The F1AP message can be transmitted through a Non-UE associated F1AP message.

For another example, the PCI of the cell where the mobile relay is providing services may change depending on the mobile relay's movement/cell change/handover/topology adjustment. The mobile relay can change the PCI/system information of the cell providing the service through system information updates, etc. Accordingly, RRC inactive terminals can perform RAN Notification Area update in cells providing services by mobile relay. The RRC inactive terminal is configured with RAN notification area information in one or more of the cell list consisting of the RAN area and the RAN area codes list for the RAN area. The RRC inactive UE initiates a RAN Notification Area update if the serving cell does not belong to the configured RAN notification area. If there are many RRC inactive terminals in a cell served by a mobile relay, this may cause signaling load. This signaling load is undesirable as there is significant signaling for handover of RRC connected terminals served by the mobile relay during PCI change.

As an example to solve this problem, the target donor base station/IAB-donor-CU or the source donor base station/IAB-donor-CU sends RAN Notification Area update via mobile relay at a random or indicated waiting time/backoff time/offset ( Information to be performed (distributed) can be instructed to the terminal served by the relevant mobile relay. The terminal may initiate an RRC connection resumption procedure according to a random or instructed waiting time/backoff time/offset.

As described above, the present invention has the effect of linking and providing mobility of mobile relays and/or terminals served by mobile relays through different donor base stations.

Figure 17 is a diagram showing the configuration of the base station 1000 according to another embodiment.

Referring to FIG. 17, a base station 1000 according to another embodiment includes a control unit 1010, a transmitter 1020, and a receiver 1030.

In the handover control method necessary to perform the present invention described above, the control unit 1010 controls the mobile relay and the terminal served by the mobile relay to migrate/move/handover between different donor base stations. Controls the overall operation of the base station 1000.

The transmitting unit 1020 and the receiving unit 1030 are used to transmit and receive signals, messages, and data necessary to perform the present invention described above with the terminal.

FIG. 18 is a diagram showing the configuration of a user terminal 1100 according to another embodiment.

Referring to FIG. 18, a user terminal 1100 according to another embodiment includes a receiving unit 1110, a control unit 1120, and a transmitting unit 1130.

The receiving unit 1110 receives downlink control information, data, and messages from the base station through the corresponding channel.

In addition, the control unit 1120 is used to control the migration/movement/handover of mobile relays and terminals served by mobile relays between different donor base stations in the handover control method required to perform the present invention described above. Controls the overall operation of the user terminal 1100.

The transmitter 1130 transmits uplink control information, data, and messages to the base station through the corresponding channel.

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

The above-described embodiments can 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 hardware implementation, the method according to the present embodiments uses one or more ASICs (Application Specific Integrated Circuits), DSPs (Digital Signal Processors), DSPDs (Digital Signal Processing Devices), PLDs (Programmable Logic Devices), and FPGAs. (Field Programmable Gate Arrays), processors, controllers, microcontrollers, or microprocessors.

In the case of implementation by firmware or software, the method according to the present embodiments may be implemented in the form of a device, procedure, or function that performs the functions or operations described above. Software code can be stored in a memory unit and run by a processor. The memory unit is located inside or outside the processor and can exchange data with the processor through various known means.

Additionally, terms such as "system", "processor", "controller", "component", "module", "interface", "model", or "unit" described above generally refer to computer-related entities hardware, hardware and software. It may refer to a combination of, software, or running software. By way of example, but not limited to, the foregoing components may be a process, processor, controller, control processor, object, thread of execution, program, and/or computer run by a processor. For example, both an application running on a controller or processor and the 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 a single device (e.g., system, computing device, etc.) or distributed across two or more devices.

The above description is merely an illustrative explanation of the technical idea of the present disclosure, and those skilled in the art will be able to make various modifications and variations without departing from the essential characteristics of the present disclosure. In addition, the present embodiments are not intended to limit the technical idea of the present disclosure, but rather to explain it, so the scope of the present technical idea is not limited by these embodiments. The scope of protection of this disclosure should be interpreted in accordance with the claims below, and all technical ideas within the equivalent scope should be interpreted as being included in the scope of rights of this disclosure.

Claims (1)

In the handover control method,
A method of controlling the migration/movement/handover of mobile relays and terminals served by mobile relays between different donor base stations.

Images