Method and apparatus for allocating IP addresses to DUs in an integrated access and backhaul system

Abstract

The present disclosure relates to a communication method and system for integrating a fifth generation (5G) communication system with an Internet of Things (IoT) technology to support a higher data rate than a fourth generation (4G) system. The present disclosure can be applied to smart services based on 5G communication technology and IoT-related technologies, such as smart homes, smart buildings, smart cities, smart cars, connected cars, health care, digital education, smart retail, security and safety services.

Description

Technical Field

[0001] The present disclosure relates to a method for allocating an IP address to a distributed unit (DU) in an integrated access and backhaul (IAB) system of a mobile communication system. The present disclosure also relates to a method and apparatus for failure recovery through conditional handover in the event of an IAB node failure in a wireless communication system. Background Art

[0002] In order to meet the growing demand for wireless data services since the deployment of 4G communication systems, efforts have been made to develop improved 5G or quasi-5G communication systems. Therefore, 5G or quasi-5G communication systems are also referred to as "super 4G networks" or "post-LTE systems". 5G communication systems are considered to be implemented in higher frequency (millimeter wave) bands, such as the 60GHz band, in order to achieve higher data rates. In order to reduce the propagation loss of radio waves and increase the transmission distance, in 5G communication systems, beamforming, massive multiple input multiple output (MIMO), full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming and massive antenna technology are discussed. In addition, in 5G communication systems, development of system network improvements based on advanced small cells, cloud radio access networks (RAN), ultra-dense networks, device-to-device (D2D) communications, wireless backhaul, mobile networks, collaborative communications, coordinated multi-point (CoMP), receiving-end interference elimination, etc. is underway. In 5G systems, hybrid FSK and QAM modulation (FQAM), and sliding window superposition coding (SWSC) have been developed as advanced coding modulation (ACM), and filter bank multi-carrier (FBMC), non-orthogonal multiple access (NOMA) and sparse code multiple access (SCMA) as advanced access technologies.

[0003] The Internet, a human-centered connectivity network where humans generate and consume information, is now developing towards the Internet of Things (IoT), in which distributed entities of the IoT (such as things) exchange and process information without human intervention. Through connection with cloud servers, the Internet of Everything (IoE), which combines IoT technology with big data processing technology, has come into being. Since IoT implementation requires technical elements such as "sensing technology", "wired / wireless communication and network infrastructure", "service interface technology" and "security technology", sensor networks, machine-to-machine (M2M) communication, machine type communication (MTC), etc. have been studied recently. This IoT environment can provide intelligent Internet technology services that create new value for human life by collecting and analyzing data generated between connected things. Through the integration and combination between existing information technology (IT) and various industrial applications, IoT can be applied to various fields, including smart homes, smart buildings, smart cities, smart cars or connected cars, smart grids, health care, smart appliances, and advanced medical services.

[0004] In line with this, various attempts have been made to apply 5G communication systems to IoT networks. For example, technologies such as sensor networks, machine type communications (MTC), and machine-to-machine (M2M) communications can be implemented through beamforming, MIMO, and array antennas. The application of the cloud radio access network (RAN), which is the big data processing technology described above, can also be considered as an example of the fusion between 5G technology and IoT technology. Summary of the invention

[0005] [Technical issues]

[0006] The present disclosure relates to a method for allocating an IP address to a DU in an integrated access and backhaul (IAB) system of a mobile communication system. In addition, the present disclosure provides a method and apparatus for failure recovery through conditional handover in the event of an IAB node failure in a wireless communication system.

[0007] [Technical solution]

[0008] Technical objectives to be achieved in the embodiments of the present disclosure are not limited to those described above, and other technical objectives not mentioned will be clearly understood by ordinary technicians in the field to which the present disclosure belongs from the following description.

[0009] In order to solve the above problems, in the present disclosure, a method for a first entity in an integrated access and backhaul system includes: receiving OAM data from an administration and maintenance (OAM) server through an established data radio bearer (DRB); identifying whether an IP address is assigned based on the received OAM data; sending a first message for requesting IP address assignment to a second entity if no IP address is assigned; and receiving a second message from the second entity, the second message including information associated with the IP address based on the first message.

[0010] In some examples, the first message and the second message are radio resource control (RRC) messages.

[0011] In some examples, the first message includes possible information regarding at least one of IP version 4 or IP version 6 as an indicator.

[0012] In some examples, when the second message does not include information associated with the IP address, the previous IP address is maintained; and when the second message includes information associated with the IP address, the previous IP address is changed to the received IP address.

[0013] In another example of the present disclosure, a method for a second entity in an integrated access and backhaul system includes: receiving a first message for requesting IP address allocation from a first entity when it is identified that no IP address is allocated based on OAM data sent by an administration and maintenance (OAM) server to the first entity; and sending a second message including information associated with the IP address to the first entity based on the first message, wherein the OAM data is sent from the OAM server to the first entity via an established data radio bearer (DRB).

[0014] In another example of the present disclosure, a first entity in an integrated access and backhaul system includes: a transceiver capable of sending and receiving at least one signal; and a controller connected to the transceiver, wherein the controller is configured to: receive OAM data from an administration and maintenance (OAM) server via an established data radio bearer (DRB); identify whether an IP address is assigned based on the received OAM data; send a first message for requesting IP address assignment to a second entity if no IP address is assigned; and receive a second message including information associated with the IP address from the second entity based on the first message.

[0015] In another example of the present disclosure, a second entity in an integrated access and backhaul system includes: a transceiver capable of sending and receiving at least one signal; and a controller connected to the transceiver, wherein the controller is configured to: receive a first message for requesting IP address allocation from the first entity when it is identified that no IP address is allocated based on OAM data sent by an administration and maintenance (OAM) server to the first entity; and send a second message including information associated with the IP address to the first entity based on the first message, and wherein the OAM data is sent from the OAM server to the first entity via an established data radio bearer (DRB).

[0016] [Beneficial Effects]

[0017] According to embodiments of the present disclosure, various methods for efficiently allocating IP addresses to DUs in an integrated access and backhaul (IAB) system of a mobile communication system are described. In addition, according to embodiments of the present disclosure, it is possible to efficiently recover from IAB node failures through conditional handover. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 is a diagram showing the architecture of an existing LTE system.

[0019] Figure 2 is a diagram showing the structure of a radio protocol in an existing LTE system.

[0020] Figure 3 is a diagram showing the architecture of a next-generation mobile communication system to which the present disclosure can be applied.

[0021] Figure 4 is a diagram showing a structure of a radio protocol in a next-generation mobile communication system to which the present disclosure can be applied.

[0022] Figure 5 is a block diagram showing the internal structure of a user equipment to which the present disclosure is applied.

[0023] Figure 6 is a block diagram showing the configuration of an NR base station according to the present disclosure.

[0024] Figure 7 : is a diagram showing a case where IP address allocation of a distributed unit part in an IAB node is pre-configured to be performed by using OAM.

[0025] Figure 8 is a diagram showing a case where IP address allocation of a distributed unit part in an IAB node is not pre-configured to be performed using OAM through DRB after a connection is established.

[0026] Fig. 9is a diagram showing IP address allocation in response to SCG failure (SCGFailure) in the case of EN-DC.

[0027] Fig.10 is a diagram showing IP address allocation in response to link failure in the case of NR single connectivity.

[0028] Fig.11 is a diagram showing IP address allocation in response to SCGFailure in the case of NR-DC.

[0029] Fig.12 is a diagram showing IP address allocation when the MCG failure (MCGFailure) procedure succeeds in the case of NR-DC.

[0030] Fig.13 is a diagram showing IP address allocation when the MCGFailure procedure fails in the case of NR-DC.

[0031] Fig.14 is a diagram showing IP address allocation according to an embodiment of the present disclosure.

[0032] Fig.15 is a diagram illustrating a process of performing conditional handover when an IAB node receives an RLF recovery failure notification from a parent node according to an embodiment.

[0033] Fig.16 is a diagram illustrating a method of configuring a separate cell in which handover is to be performed when an IAB node receives a recovery failure notification according to an embodiment.

[0034] Fig.17 is a diagram illustrating a process of performing conditional handover given a separate cell to perform handover and additional determination criteria when an IAB node receives an RLF recovery failure notification according to an embodiment. DETAILED DESCRIPTION

[0035] Hereinafter, the operating principle of the present disclosure will be described in detail with reference to the accompanying drawings. In the following description of the present disclosure, the description of the well-known functions and structures incorporated herein may be omitted to avoid confusing the subject matter of the present disclosure. In addition, the terms described below are defined in consideration of their functions in the present disclosure, and these terms may vary according to the intentions or habits of users and operators. Therefore, their meanings should be determined based on the entire content of this specification.

[0036] For ease of description, the terms used in the following description for identifying access nodes, indicating network entities, indicating messages, indicating interfaces between network entities, and indicating various identification information are used as illustrations. Therefore, the present disclosure is not limited by the terms to be described later, and other terms referring to objects with equivalent technical meanings may be used.

[0037] For ease of description, the present disclosure uses terms and names defined in the 3rd Generation Partnership Project Long Term Evolution (3GPP LTE) standard. However, the present disclosure is not limited by the above terms and names and can be equally applied to systems conforming to other standards.

[0038] Figure 1 is a diagram showing the architecture of an existing LTE system.

[0039] Reference Figure 1 As shown in the figure, the radio access network of the LTE system may be composed of a next generation base station (evolved node B, ENB, node B or base station) 1-05, 1-10, 1-15 or 1-20, a mobility management entity (MME) 1-25 and a serving gateway (S-GW) 1-30. User equipment (UE or terminal) 1-35 may be connected to an external network through the ENB 1-05, 1-10, 1-15 or 1-20 and the S-GW 1-30.

[0040] exist Figure 1 In the present invention, ENB 1-05, 1-10, 1-15 and 1-20 correspond to the existing Node B of the Universal Mobile Telecommunications System (UMTS). The ENB is connected to the UE 1-35 through a wireless channel, and performs more complex functions than the existing Node B. In the LTE system, all user services including real-time services such as VoIP (Voice over IP) services can be served through a shared channel. Therefore, a device for performing scheduling based on the collected state information about the buffer, available transmission power and channel of the UE is required, and the ENB 1-05, 1-10, 1-15 and 1-20 can be responsible for this task. In a typical case, one ENB can control multiple cells. In order to achieve a data rate of, for example, 100Mbps in a bandwidth of, for example, 20MHz, the LTE system can use orthogonal frequency division multiplexing (OFDM) as a radio access technology. In addition, the LTE system can apply adaptive modulation and coding (AMC) to determine the modulation scheme and channel coding rate according to the channel state of the UE. The S-GW 1-30 is an entity that provides a data bearer, and may create and remove a data bearer under the control of the MME 1-25. The MME is an entity responsible for various control functions including a mobility management function of a UE, and may be connected to a plurality of ENBs.

[0041] Figure 2This is a diagram showing the structure of a radio protocol in a conventional LTE system.

[0042] Reference Figure 2 In the UE or ENB, the radio protocol of the LTE system may consist of a packet data convergence protocol (PDCP) 2-05 or 2-40, a radio link control (RLC) 2-10 or 2-35, and a medium access control (MAC) 2-15 or 2-30. PDCP may perform compression and decompression of IP headers. The main functions of PDCP may be summarized as follows.

[0043] -Header compression and decompression function (Header compression and decompression: ROHC only)

[0044] -User data transmission function (user data transmission)

[0045] - In-sequence delivery function (delivering higher layer PDUs in sequence during PDCP reestablishment of RLC AM)

[0046] - Reordering function (for distributed bearers in DC (supports RLC AM only): routing of transmitted PDCP PDUs and reordering of received PDCP PDUs)

[0047] -Duplicate detection function (duplicate detection of lower layer SDU during PDCP reestablishment of RLC AM)

[0048] - Retransmission functionality (for distributed bearers in DC, retransmit PDCP SDUs at handover, and for RLC AM, retransmit PDCP PDUs during PDCP data recovery)

[0049] -Encryption and decryption functions (encryption and decryption)

[0050] -Timer-based SDU discard function (timer-based SDU discard in uplink)

[0051] The Radio Link Control (RLC) 2-10 or 2-35 may reconfigure a PDCP PDU (Packet Data Unit) into an appropriate size and perform an Automatic Repeat Request (ARQ) operation. The main functions of the RLC may be summarized as follows.

[0052] -Data transmission function (transmission of high-level PDU)

[0053] -ARQ function (error correction through ARQ (only for AM data transmission))

[0054] - Concatenation, segmentation and reassembly function (concatenation, segmentation and reassembly of RLC SDU (only for UM and AM data transmission))

[0055] - Re-segmentation function (resegmentation of RLC data PDU (only for AM data transmission))

[0056] - Reordering function (reordering of RLC data PDUs (only for UM and AM data transmission))

[0057] - Duplicate detection function (Duplicate detection (only for UM and AM data transmission))

[0058] - Error detection function (protocol error detection (for AM data transmission only))

[0059] -RLC SDU discard function (RLC SDU discard (only for UM and AM data transmission))

[0060] -RLC reestablishment function (RLC reestablishment)

[0061] MAC 2-15 or 2-30 can be connected with multiple RLC entities in the UE, and it can multiplex RLC PDUs into MAC PDUs and demultiplex MAC PDUs into RLC PDUs. The main functions of MAC can be summarized as follows.

[0062] - Mapping function (mapping between logical channels and transport channels)

[0063] - Multiplexing and demultiplexing functions (multiplexing / demultiplexing MAC SDUs belonging to one or different logical channels into transport blocks (TBs) transmitted to the physical layer on transport channels, or multiplexing / demultiplexing MAC SDUs belonging to one or different logical channels from transport blocks (TBs) transmitted by the physical layer on transport channels)

[0064] -Scheduling information reporting function (Scheduling information reporting)

[0065] -HARQ function (error correction through HARQ)

[0066] - Priority handling function between logical channels (priority handling between logical channels of a UE)

[0067] - Priority handling function between UEs (priority handling between UEs through dynamic scheduling)

[0068] -MBMS service identification function (MBMS service identification)

[0069] -Transmission format selection function (transmission format selection)

[0070] -Filling function (fill)

[0071] The physical (PHY) layer 2-20 or 2-25 may convert high-layer data into OFDM symbols through channel coding and modulation, and transmit the OFDM symbols through a wireless channel; or may demodulate OFDM symbols received through a wireless channel, perform channel decoding, and forward the result to a high layer.

[0072] Figure 3 is a diagram showing the architecture of a next-generation mobile communication system.

[0073] Reference Figure 3 , the radio access network of the next generation mobile communication system (hereinafter referred to as NR or 5g) can be composed of a new radio node B (hereinafter referred to as NR gNB or NR base station) 3-10 and a new radio core network (NR CN) 3-05. The new radio user equipment (hereinafter referred to as NR UE or terminal) 3-15 can be connected to an external network through the NR gNB 3-10 and the NR CN 3-05.

[0074] exist Figure 3 In the next generation mobile communication system, the NR gNB 3-10 may correspond to the evolved Node B (eNB) of the existing LTE system. The NR gNB may be connected to the NR UE 3-15 through a wireless channel, and it may provide services superior to those of the existing Node B. In the next generation mobile communication system, all user services may be served through a shared channel. Therefore, an entity that performs scheduling by collecting status information such as buffer status, available transmit power status, and channel status of individual UEs is required, and the NRNB 3-10 may be responsible for this task. One NR gNB may control multiple cells. Compared to the current LTE, in order to achieve ultra-high-speed data transmission, a bandwidth exceeding the existing maximum bandwidth may be utilized. In addition, beamforming technology may also be combined with orthogonal frequency division multiplexing (OFDM) used as a radio access technology. In addition, an adaptive modulation and coding (AMC) scheme may be applied, which determines the modulation scheme and channel coding rate to match the channel status of the UE. The NRCN 3-05 may perform functions such as mobility support, bearer configuration, and quality of service (QoS) configuration. NR CN is an entity responsible not only for mobility management but also for various control functions of UE, and can be connected to multiple base stations. In addition, the next generation mobile communication system can interoperate with the existing LTE system, and NR CN can be connected to MME 3-25 through a network interface. MME can be connected to eNB 3-30 which is an existing base station.

[0075] Figure 4 is a diagram showing a structure of a radio protocol in a next-generation mobile communication system to which the present disclosure can be applied.

[0076] Reference Figure 4In the UE or NR gNB, the radio protocol of the next generation mobile communication system consists of NR Service Data Adaptation Protocol (SDAP) 4-01 or 4-45, NR PDCP 4-05 or 4-40, NR RLC 4-10 or 4-35, and NR MAC 4-15 or 4-30.

[0077] The main functions of NR SDAP 4-01 or 4-45 may include some of the following functions.

[0078] -User data transmission function (transmission of user plane data)

[0079] - Mapping function between QoS flows and data bearers for uplink and downlink (mapping between QoS flows and DRBs for both DL and UL)

[0080] -QoS flow ID marking function for uplink and downlink (marking QoS flow ID in both DL packets and UL packets)

[0081] - For uplink SDAP PDU, the function of mapping reflective QoS flow to data bearer (Mapping of reflective QoS flow of UL SDAP PDU to DRB)

[0082] For the SDAP entity, the UE can be configured through a radio resource control (RRC) message as to whether to use the header of the SDAP entity or whether to use the functions of the SDAP entity for each PDCP entity, bearer or logical channel. If the SDAP header is configured, the SDAP entity can use the 1-bit NAS (non-access stratum) reflective QoS indication and the 1-bit AS (access stratum) reflective QoS indication of the SDAP header to instruct the UE to update or reconfigure the mapping information between the QoS flows and data bearers for uplink and downlink. The SDAP header may include QoS flow ID information indicating QoS. QoS information can be used as data processing priority and scheduling information to support smooth business.

[0083] The main functions of NR PDCP 4-05 or 4-40 may include some of the following functions.

[0084] -Header compression and decompression function (Header compression and decompression: ROHC only)

[0085] -User data transmission function (transmission of user data)

[0086] - In-order delivery function (in-order delivery of higher-level PDUs)

[0087] - Out-of-order delivery function (out-of-order delivery of higher-level PDUs)

[0088] - Reordering function (for reordering of received PDCP PDUs)

[0089] - Duplicate detection function (duplicate detection of lower layer SDU)

[0090] -Retransmission function (retransmission of PDCP SDU)

[0091] -Encryption and decryption functions (encryption and decryption)

[0092] -Timer-based SDU discard function (timer-based SDU discard in uplink)

[0093] In the above description, the reordering function of the NR PDCP entity may mean reordering the PDCP PDUs received from the lower layer according to the PDCP sequence number (SN). The reordering function of the NR PDCP entity may include delivering data to the upper layer in the reordered order, directly delivering data without considering the order, recording the lost PDCP PDUs by reordering, reporting the status of the lost PDCP PDUs to the transmitting end, or requesting retransmission of the lost PDCP PDUs.

[0094] The main functions of NR RLC 4-10 or 4-35 may include some of the following functions.

[0095] -Data transmission function (transmission of high-level PDU)

[0096] - In-order delivery function (in-order delivery of higher-level PDUs)

[0097] - Out-of-order delivery function (out-of-order delivery of higher-level PDUs)

[0098] -ARQ function (error correction through ARQ)

[0099] - Concatenation, segmentation and reassembly function (concatenation, segmentation and reassembly of RLC SDU)

[0100] - Re-segmentation function (resegmentation of RLC data PDU)

[0101] - Reordering function (reordering of RLC data PDU)

[0102] -Duplicate detection function (duplicate detection)

[0103] -Error detection function (protocol error detection)

[0104] RLC SDU discard function (RLC SDU discard)

[0105] -RLC reestablishment function (RLC reestablishment)

[0106] In the above description, the in-sequence delivery of the NR RLC device may mean that the RLC SDU received from the lower layer is delivered to the upper layer in sequence. The in-sequence delivery of the NR RLC device may include reassembling and delivering the RLC SDUs when multiple RLC SDUs belonging to one original RLC SDU are received after segmentation.

[0107] The in-sequence delivery of the NR RLC device may include reordering the received RLC PDU based on the RLC sequence number (SN) or the PDCP SN, recording the lost RLC PDU through the reordering, reporting the status of the lost RLC PDU to the transmitter, and requesting retransmission of the lost RLC PDU.

[0108] If there is a lost RLC SDU, the in-sequence delivery of the NR RLC device may include delivering only the RLC SDU preceding the lost RLC SDU to the higher layer in-sequence.

[0109] Despite the presence of lost RLC SDUs, if a designated timer has expired, the in-sequence delivery of the NR RLC device may include delivering to higher layers in-sequence all RLC SDUs received before the timer is started.

[0110] Despite the presence of lost RLC SDUs, if a designated timer has expired, the in-sequence delivery of the NR RLC device may include delivering all RLC SDUs received so far to higher layers in-sequence.

[0111] The NR RLC device may process the RLC PDUs in the order of reception without considering the order of sequence numbers and deliver them to the NR PDCP entity in an out-of-order delivery manner.

[0112] In case of received segmentation, the NR RLC device can reconstruct a complete RLC PDU from the segments stored in the buffer or received later and transmit it to the NR PDCP device.

[0113] The NR RLC layer may not include the cascading function, which may be performed by the NR MAC layer or may be replaced by the multiplexing function of the NR MAC layer.

[0114] In the above description, the out-of-order delivery of the NR RLC device may mean a function of directly delivering the RLC SDU received from the lower layer to the higher layer regardless of their order. If multiple RLC SDUs belonging to one original RLC SDU are received after segmentation, the out-of-order delivery of the NR RLC device may include reassembling and delivering these RLC SDUs. The out-of-order delivery of the NR RLC device may include storing the RLC SN or PDCP SN of the received RLC PDU and instructing them to record the lost RLC PDU.

[0115] NR MAC 4-15 or 4-30 can be connected to several NR RLC layer devices configured in one UE, and the main functions of NR MAC may include some of the following functions.

[0116] - Mapping function (mapping between logical channels and transport channels)

[0117] -Multiplexing and demultiplexing functions (MAC SDU multiplexing / demultiplexing)

[0118] -Scheduling information reporting function (Scheduling information reporting)

[0119] -HARQ function (error correction through HARQ)

[0120] - Priority handling function between logical channels (priority handling between logical channels of a UE)

[0121] - Priority handling function between UEs (priority handling between UEs through dynamic scheduling)

[0122] -MBMS service identification function (MBMS service identification)

[0123] -Transmission format selection function (transmission format selection)

[0124] -Filling function (fill)

[0125] The NR PHY layer 4-20 or 4-25 may compose an OFDM symbol from the high-layer data through channel coding and modulation, and transmit the OFDM symbol through a wireless channel; or may demodulate and channel-decode the OFDM symbol received through a wireless channel, and forward the result to a high-layer.

[0126] Figure 5 is a block diagram showing the internal structure of a user equipment to which the present disclosure is applied.

[0127] Referring to the drawings, the UE includes a Radio Frequency (RF) processor 5-10, a baseband processor 5-20, a storage device 5-30, and a controller 5-40.

[0128] The RF processor 5-10 performs functions such as signal band conversion and amplification for sending and receiving signals through a wireless channel. That is, the RF processor 5-10 performs up-conversion of the baseband signal provided by the baseband processor 5-20 to the RF band signal, and transmits it through the antenna, and performs down-conversion of the RF band signal received by the antenna to the baseband signal. For example, the RF processor 5-10 may include a transmit filter, a receive filter, an amplifier, a mixer, an oscillator, a digital-to-analog converter (DAC), and an analog-to-digital converter (ADC). Although only one antenna is shown in the accompanying drawings, multiple antennas can be provided for the UE. Moreover, the RF processor 5-10 may include multiple RF chains. In addition, the RF processor 5-10 may perform beamforming. For beamforming, the RF processor 5-10 may adjust the phase and amplitude of the signal sent and received by multiple antennas or antenna elements. In addition, the RF processor may perform MIMO, and may receive multiple layers during MIMO operation.

[0129] The baseband processor 5-20 performs conversion between baseband signals and bit strings according to the physical layer specification of the system. For example, during data transmission, the baseband processor 5-20 generates complex symbols by encoding and modulating the transmission bit string. In addition, during data reception, the baseband processor 5-20 recovers the received bit string by demodulating and decoding the baseband signal provided from the RF processor 5-10. For example, in the case of using orthogonal frequency division multiplexing (OFDM), for data transmission, the baseband processor 5-20 generates complex symbols by encoding and modulating the transmission bit string, maps the complex symbols to subcarriers, and writes OFDM symbols by inverse fast Fourier transform (IFFT) operation and cyclic prefix (CP) insertion. In addition, for data reception, the baseband processor 5-20 divides the baseband signal provided from the RF processor 5-10 in units of OFDM symbols, recovers the signal mapped to the subcarrier by fast Fourier transform (FFT) operation, and recovers the received bit string by demodulation and decoding.

[0130] As described above, the baseband processor 5-20 and the RF processor 5-10 send and receive signals. Therefore, the baseband processor 5-20 and the RF processor 5-10 can be referred to as a transmitter, a receiver, a transceiver or a communication unit. In addition, in order to support different radio access technologies, at least one of the baseband processor 5-20 or the RF processor 5-10 may include a plurality of communication modules. In addition, in order to process signals of different frequency bands, at least one of the baseband processor 5-20 or the RF processor 5-10 may include different communication modules. For example, different radio access technologies may include wireless LAN (e.g., IEEE 802.11), cellular networks (e.g., LTE), etc. In addition, different frequency bands may include ultra-high frequency (SHF) bands and millimeter wave (mm wave) bands (e.g., 60GHz).

[0131] The storage device 5-30 stores data for the operation of the UE, such as basic programs, applications, and configuration information. In particular, the storage device 5-30 may store information about a second access node that performs wireless communication using a second radio access technology. The storage device 5-30 provides the stored data in response to a request from the controller 5-40.

[0132] The controller 5-40 controls the overall operation of the UE. For example, the controller 5-40 sends and receives signals through the baseband processor 5-20 and the RF processor 5-10. In addition, the controller 5-40 writes data to the storage device 5-40 or reads data from the storage device 5-40. To this end, the controller 5-40 may include at least one processor. For example, the controller 5-40 may include a communication processor (CP) for controlling communication and an application processor (AP) for controlling a high layer such as an application program.

[0133] Figure 6 is a block diagram showing the structure of an NR base station according to the present disclosure.

[0134] As shown, the base station includes an RF processor 6-10, a baseband processor 6-20, a backhaul communication unit 6-30, a storage device 6-40, and a controller 6-50.

[0135] The RF processor 6-10 performs functions such as signal band conversion and amplification for sending and receiving signals through a wireless channel. That is, the RF processor 6-10 performs up-conversion of the baseband signal provided by the baseband processor 6-20 to the RF band signal, and transmits the converted signal through the antenna, and performs down-conversion of the RF band signal received by the antenna to the baseband signal. For example, the RF processor 6-10 may include a transmit filter, a receive filter, an amplifier, a mixer, an oscillator, a DAC, and an ADC. Although only one antenna is shown in the accompanying drawings, the first access node may be provided with multiple antennas. In addition, the RF processor 6-10 may include multiple RF chains. In addition, the RF processor 6-10 may perform beamforming. For beamforming, the RF processor 6-10 may adjust the phase and amplitude of the signal sent and received by multiple antennas or antenna elements. The RF processor may perform downlink MIMO operations by sending one or more layers.

[0136] The baseband processor 6-20 performs conversion between baseband signals and bit strings according to the physical layer specification of the first radio access technology. For example, for data transmission, the baseband processor 6-20 generates complex symbols by encoding and modulating the transmission bit string. In addition, for data reception, the baseband processor 6-20 recovers the received bit string by demodulating and decoding the baseband signal provided from the RF processor 6-10. For example, in the case of utilizing OFDM, for data transmission, the baseband processor 6-20 generates complex symbols by encoding and modulating the transmission bit string, maps the complex symbols to subcarriers, and writes OFDM symbols by IFFT operation and CP insertion. In addition, for data reception, the baseband processor 6-20 divides the baseband signal provided from the RF processor 6-10 in units of OFDM symbols, recovers the signal mapped to the subcarrier by FFT operation, and recovers the received bit string by demodulation and decoding. As described above, the baseband processor 6-20 and the RF processor 6-10 send and receive signals. Therefore, the baseband processor 6-20 and the RF processor 6-10 may be referred to as a transmitter, a receiver, a transceiver, a communication unit, or a wireless communication unit.

[0137] The backhaul communication unit 6-30 provides an interface for communicating with other nodes in the network. That is, the backhaul communication unit 6-30 converts a bit string to be sent from the master base station to another node (eg, a secondary base station or a core network) into a physical signal, and converts a physical signal received from another node into a bit string.

[0138] The storage device 6-40 stores data such as basic programs, applications, and configuration information for the operation of the master base station. In particular, the storage device 6-40 can store information about the bearers assigned to the connected UEs and the measurement results reported from the connected UEs. In addition, the storage device 6-40 can store information used as a criterion for determining whether to provide or suspend multiple connectivity to the UE. In addition, the storage device 6-40 provides the stored data in response to a request from the controller 6-50.

[0139] The controller 6-50 controls the overall operation of the main base station. For example, the controller 6-50 sends and receives signals through the baseband processor 6-20 and the RF processor 6-10 or through the backhaul communication unit 6-30. In addition, the controller 6-50 writes data to the storage device 6-40 or reads data from the storage device 6-40. To this end, the controller 6-50 may include at least one processor.

[0140] In this disclosure, IAB means "Integrated Access and Backhaul".

[0141] The MT, which is a "mobile terminal", is the part of the IAB node responsible for communicating with the parent node.

[0142] DU is an abbreviation of “Distributed Unit”, and is a part in the IAB node responsible for transmission / reception functions with sub-nodes connected to the IAB node and regular UEs.

[0143] CU is an abbreviation of “Central Unit” and refers to a logical node hosting RRC and a higher layer L2 protocol (PDCP), and it can control the operation of one or more DUs.

[0144] BAP is an abbreviation of "Backhaul Adaptation Protocol", and is a layer existing in MT / DU of the IAB node.

[0145] Figure 7 is a diagram showing a case where IP address allocation of a DU part in an integrated access and backhaul (IAB) node is pre-configured to be performed by using administration and maintenance (OAM).

[0146] Specifically, Figure 7This is the case where IAB node 2 (700) selects IAB node 1 (720) as a parent node and performs connection establishment. IAB node 2 (700) may be pre-configured so that the IP address allocation of the DU therein is performed by using OAM (step 701). Therefore, after IAB node 2 (700) completes the RRC connection (steps 702 to 708) and performs the transmission and reception of the RRC reconfiguration (RRCreconfiguration) message (steps 709 and 710) to establish a data radio bearer (DRB) (step 711), it may download OAM data from the OAM server (step 712). IAB node 2 (700) may retrieve the IP address to be allocated to the DU from the downloaded OAM data, and may set the corresponding address to the DU (step 713).

[0147] Figure 8 is a diagram showing a case where IP address allocation of a DU part in an IAB node is not pre-configured to be performed using OAM through a data radio bearer (DRB) after a connection is established.

[0148] Specifically, Figure 8 This is the case where IAB node 2 (800) selects IAB node 1 (820) as a parent node and performs connection establishment. After IAB node 2 (800) completes RRC connection setup (steps 801 to 807) and performs transmission and reception of RRCreconfiguration messages (steps 808 and 809) to establish DRB (step 810), it can download OAM data from the OAM server. Since IP address allocation is not configured in advance via OAM, IAB node 2 (800) can identify whether the IP address to be allocated to the DU exists in the downloaded OAM data (step 811). If so, IAB node 2 (800) can retrieve the corresponding address and set it to the DU (step 812).

[0149] However, if Figure 8As shown in , if there is no IP address in the OAM data, the mobile terminal (MT) of the IAB node 2 (800) can request the donor centralized unit (CU) 840 to allocate an IP address through an RRC message (step 813). When the above message is transmitted to the donor CU 840 through the IAB node 1 (820) (step 814), the donor CU 840 can allocate a new IP address and send it to the MT of the IAB node 2 (800) again through the IAB node 1 (820) by using an RRC message (step 815). Based on the received message, the MT of the IAB node 2 (800) can allocate an IP address to the DU (step 816). The message that can be used when requesting an IP address can be an RRC reconfiguration complete (RRCreconfigurationComplete) message, a UL information transfer (ULInformationTransfer) message, or a new UL RRC message. In addition, the message that the donor CU 840 receiving the request can use to allocate the IP address to the MT of the IAB node 2 (800) can be an RRCreconfiguration message, a DL information transfer (DLInformationTransfer) message, or a new DL RRC message. The following is a possible pair of an RRC message for an IP address request and an RRC message for IP address allocation, but any combination of the above messages can be used for the request and allocation pair without limitation. For example, it can be as shown in the following Table 1.

[0150] [Table 1]

[0151] ask distribute Maybe 1 RRCreconfigurationComplete RRCreconfiguration message immediately after the request 2 RRCreconfigurationComplete DLinformationTransfer 3 ULInformationTransfer DLinformationTransfer 4 RRCreconfigurationComplete RRCReconfiguration 5 ULInformationTransfer New DL RRC message 6 New UL RRC message New DL RRC message

[0152] When an IP address is received, the RRC message for allocation may be divided into an MCG part and an SCG part; when a connection is performed via single connectivity, the IP address may be signaled in the MCG part.

[0153] Fig. 9 is a diagram showing IP address allocation in response to SCGFailure in case of E-UTRAN New Radio Dual Connectivity (EN-DC).

[0154] IAB node 2 (920) is connected to IAB node 1 (940) acting as a parent node of a secondary node (SN), and is connected to LTE eNB 960 acting as a master node (MN). When the MT of IAB node 2 (920) detects a radio link failure (RLF) in the IAB node 1 (940) link, or receives an RLF notification from IAB node 1 (940), or a PSCell change failure occurs (step 901), it can send a SCG failure information (SCGFailureInformation) message to MN 960 through the LTE link (step 902). MN 960 can send a SCGFailure related report to donor CU 980 (step 903). Donor CU 980 can determine to change the PSCell to a new PSCell, compose a corresponding RRC message (handover command), identify the donor DU connected to the determined new PSCell, and if the donor DU is different from the previously connected donor DU, allocate a new IP address (step 904). The allocated address may be included in the handover command and transmitted to the LTE MN 960 (step 905). The MN 960 may send an LTE RRCconnectionReconfiguration message (i.e., NRRRRCreconfiguration message) including a corresponding RRC message to the IAB node 2 (920) (step 906). Upon receiving the above message, the MT of the IAB node 2 (920) may apply the corresponding NR RRCreconfiguration message (step 907), and at this time, the IP address included therein may also be set to the DU. Thereafter, the IAB node 2 (920) may send an LTE RRCconnectionReconfigurationComplete message to the LTE MN 960 (step 908). Then, the IAB node 2 (920) may perform a random access procedure with the IAB node 3 (900) (step 909).

[0155] As another embodiment, after applying NR RRCreconfiguration, information for requesting an IP address may be included in an F1-AP container in an LTE ULInformationTransferMRDC message, which is then sent to the LTE MN 960 (step 910). Upon receiving the information, the LTE MN 960 may send the request information to the donor gNB 980 (step 911), and if a new IP address needs to be allocated, the donor gNB 980 may allocate a new IP address and send it back to the LTE MN 960 (step 912). The LTE MN 960 may include the IP address in an F1-AP container in a DLInformationTransferMRDC message, which is then sent to the MT of the IAB node 2 (920) (step 913).

[0156] Fig.10 is a diagram showing IP address allocation in response to link failure in the case of NR single connectivity.

[0157] IAB node 2 (1040) is connected to IAB node 1 (1060) acting as a parent node. When the MT of IAB node 2 (1040) detects RLF at the link of IAB node 1 (1060) or receives RLF recovery failure notification from IAB node 1 (1060) (step 1001), the MT of IAB node 2 (1040) can perform cell selection, perform a random access procedure with the selected cell (step 1002), and perform RRC reestablishment (step 1003). In this case, the donor CU 1000 can identify the newly connected IAB node 2 (1040) and allocate a new IP address related to the newly selected IAB node 3 (1020) to IAB node 2 (1040) (step 1004). Here, the IP address can be included in the container corresponding to the MCG by using the RRC reestablishment message (step 1005). Upon receiving the above message, IAB node 2 (1040) can allocate the received IP address to the DU (step 1006). Then, the IAB node 2 (1040) may send an RRC re-establishment completion message to the IAB node 3 (1020) (step 1007).

[0158] In another embodiment, without allocating an IP address through RRC re-establishment, when the IAB node 2 (1040) receives the RRC re-establishment and sends a complete message for it, the donor CU 1000 can allocate an IP address (step 1008), include the IP address in the RRCreconfiguration message, and send it to the IAB node 2 (1040) via the IAB node 3 (1020) (step 1009). Upon receiving the information, the IAB node 2 (1040) can allocate the corresponding information to the DU (step 1010). Thereafter, the IAB node 2 (1040) can send an RRC re-establishment complete message to the IAB node 3 (1020) (step 1011).

[0159] Fig.11 is a diagram showing IP address allocation in response to SCGFailure in the case of New Radio Dual Connectivity (NR-DC).

[0160] IAB node 3 (1120) is connected to IAB node 1 (1140) acting as a SN parent node, and is connected to IAB node 2 (1160) acting as a MN parent node. When the MT of IAB node 3 (1120) detects RLF in the link of IAB node 1 (1140), or receives RLF notification from IAB node 1 (1140), or a PSCell change failure occurs (step 1101), it can send an SCGFailureInformation message to IAB node 2 (1160) through the MN link (step 1102). IAB node 2 (1160) can send an SCGFailure related report to donor CU 1180 (step 1103). The donor CU 1180 may determine to change the PSCell to another PSCell, compose a corresponding RRC message (handover command), identify the donor DU 1180 connected to the determined new PSCell, and if the donor DU 1180 is different from the previously connected donor DU 1180, assign a new IP address (step 1104). The assigned address may be included in the handover command and transmitted to the IAB node 2 (1160) (step 1105). That is, here, the NR RRCreconfiguration message may be sent to the IAB node 2 (1160). Upon receiving the above message, the IAB node 2 (1160) may forward it to the IAB node 3 (1120) (step 1106). The MT of the IAB node 3 (1120) may apply the corresponding NR RRCreconfiguration message (step 1107), and at this time, the IP address included therein may also be set to the DU. In this case, the IP address included in the SCG part of the RRCreconfiguration may be signaled. Then, the IAB node 3 (1120) may send an RRCconnectionReconfigurationComplete message to the IAB node 2 (1160) (step 1108). Thereafter, the IAB node 3 (1120) may perform a random access procedure with the IAB node 4 (1100) (step 1109).

[0161] Fig.12 is a diagram showing IP address allocation when the MCGFailure procedure succeeds in the case of NR-DC.

[0162] IAB node 3 (1220) is connected to IAB node 1 (1240) acting as a SN parent node, and is connected to IAB node 2 (1260) acting as a MN parent node. When the MT of IAB node 3 (1220) detects RLF in the link of IAB node 2 (1260), or receives RLF notification from IAB node 2 (1260), or PCell change failure occurs (step 1201), it can send MCG failure information (MCGFailureInformation) message to IAB node 1 (1240) through the SN link (step 1202). IAB node 1 (1240) can send MCGFailure related report to donor CU 1280 (step 1203). The donor CU 1280 may determine to change the PCell to another PCell (handover), compose a corresponding RRC message (handover command), identify the donor DU 1280 connected to the determined new PCell, and if 1280 is different from the previously connected donor DU 1280, assign a new IP address (step 1204). The address assigned in this manner may be included in the handover command and transmitted to the IAB node 1 (1240) (step 1205). That is, here, the NR RRCreconfiguration message may be sent to the IAB node 1 (1240). Upon receiving the above message, the IAB node 1 (1240) may forward it to the IAB node 3 (1220) (step 1206). The MT of the IAB node 3 (1220) may apply the corresponding NR RRCreconfiguration message (step 1207), and at this time, the IP address included therein may also be set to the DU. In this case, the IP address included in the MCG part of the RRCreconfiguration message may be signaled. Then, the IAB node 3 (1220) may perform a random access procedure with the IAB node 4 (1200) (step 1208). Thereafter, the IAB node 3 (1120) may send an RRCconnectionReconfigurationComplete message to the IAB node 4 (1200) (step 1209).

[0163] Fig.13 is a diagram showing IP address allocation when the MCGFailure procedure fails in the case of NR-DC.

[0164] IAB node 3 (1320) is connected to IAB node 1 (1340) acting as a SN parent node, and is connected to IAB node 2 (1360) acting as a MN parent node. When the MT of IAB node 3 (1320) detects RLF in the link of IAB node 2 (1360) or receives RLF notification from IAB node 2 (1360), or PCell change failure occurs (step 1301), it can send MCGFailureInformation message to IAB node 1 (1340) through the SN link (step 1302). IAB node 1 (1340) can send MCGFailure related report to donor CU 1380 (step 1303). Donor CU 1380 may determine to change the PCell to another PCell (handover), compose a corresponding RRC message (handover command), identify the donor DU 1380 connected to the determined new PCell, and assign a new IP address if the donor DU 1380 is different from the previously connected donor DU 1280 (step 1304).

[0165] When sending the MCGFailureInformation message, the MT of the IAB node 3 (1320) can start a timer. If no RRC release or RRCreconfiguration message is received from the donor CU 1380 before the timer expires, the MT must select a new cell. After selecting the cell, the IAB node 3 (1320) can perform a random access procedure with the IAB node 4 (1300), where the IAB node 4 (1300) is the newly selected cell (step 1305), and perform an RRC reconstruction procedure (step 1306). When the RRC reconstruction request is transmitted to the newly selected cell (here is the IAB node 4) through the process, the IAB node 4 (1300) can send an RRC reconstruction message associated with the donor CU 1380 (step 1307), and can receive the RRC reconstruction message from the donor CU1380 and forward it to the IAB node 3 (1320). The above message may include the IP address newly allocated by the donor CU1380. Upon receiving the RRC re-establishment message including the allocated IP address, IAB Node 3 (1320) uses the received information as the IP address of the DU (step 1308).

[0166] In another embodiment, the MT of the IAB node 3 (1320) that has received the RRC re-establishment may send an RRC re-establishment complete message to the IAB node 4 (1300) (step 1309). After receiving the message, the IAB node 4 (1300) may send an RRCreconfiguration message back to the IAB node 3 (1320) (step 1310). The IP address may be included in the message sent. Upon receiving the above message, the IAB node 3 (1320) may assign the received corresponding IP address to its DU (step 1311). When assigning an IP address, both the RRCreconfiguration message and the previously sent RRC re-establishment message may include the IP address for signaling assigned in the MCG part.

[0167] exist Fig.10 , Fig.11 , Fig.12 and Fig.13 In all cases where the failure is recovered; in these cases, the RRC message sent from the donor CU can allocate the IP address without requesting the IP address allocation process from the MT or child IAB node connected to it. The message can be an RRC reconstruction message, an RRCreconfiguration message, a DLInformationTransfer message, or a new DL RRC message.

[0168] Fig.14 is a diagram showing IP address allocation according to an embodiment of the present disclosure.

[0169] Reference Fig.14 , the RRC message can use the MCG-SCG delimiter to distinguish whether the transmitted IP address is an IP address corresponding to the MCG or an IP address corresponding to the SCG (step 1401). The MT of the IAB node that has received the message can transmit the IP address to the DU of the same IAB node distinguished by MCG and SCG. The IP address received in this way can be stored in a separate variable of the UE by using the MCG-SCG delimiter.

[0170] An example of a delimiter could be one of the following.

[0171] The RRCreconfiguration message may have a primary cell group (MCG) configuration IE and a secondary cell group (SCG) configuration IE as sub-messages, and may include an IP address value and version information under each of the MCG and SCG configurations. Optionally, an IAB IP address IE may be present in the RRCreconfiguration message, and the IP address and the delimiter that distinguishes the MCG and SCG may be allocated together under the corresponding IE.

[0172] In addition, for mobility, i.e., handover operations in connected mode except for failure recovery, in case of MCG PCell handover, the MCG part in the RRC message corresponding to the handover command may be assigned an IP address; in case of SCG PSCell change, the SCG part in the RRC message corresponding to the PSCell handover command may be assigned an IP address. Therefore, in case of specific mobility, two IP addresses may be signaled to the DU, i.e., the IP address of the donor DU connected to the MCG in the IP address space, and the IP address of the donor DU connected to the SCG in the IP address space.

[0173] Depending on the type of RRC message used for IP address allocation, there may be cases where delta signaling can be applied and cases where delta signaling cannot be applied. The IP address must always be set in the RRC reconstruction message. That is, delta signaling cannot be applied. The IAB node that has received the message must always change its current IP address to the IP address sent by signal. The IP address may or may not be signaled using the RRCreconfiguration message or a new DL RRC message. Basically, if it is not signaled, the IAB node can keep the previously received address unchanged. If the IP address is signaled, it can change the previously received address.

[0174] Upon receiving the message, the MT may determine which MCG and SCG delimiter the IP address corresponds to. If an IP address corresponding to the delimiter is previously stored, the previously stored IP address may be updated or changed to the received IP address corresponding to the delimiter. If an IP address for the delimiter is previously stored, but there is no IP address corresponding to the delimiter in the received message, the MT may use the previously stored IP address corresponding to the delimiter as is. Specifically, it may be determined whether an IP address was previously stored in the MCG field in the MT (step 1402). If an IP address was previously stored in the MCG field in the MT, it may be determined whether an IP address exists in the MCG field of the received RRC message (step 1403). If an IP address exists in the MCG field of the received RRC message, the IP address previously stored in the MCG field in the MT is changed to the received IP address (step 1404). However, if an IP address does not exist in the MCG field of the received RRC message, the IP address previously stored in the MCG field in the MT is used as is (step 1405). In addition, if the IP address is not previously stored in the MCG field in the MT, it is possible to determine whether the IP address exists in the MCG field of the received RRC message (step 1406). If the IP address exists in the MCG field of the received RRC message, the IP address in the MCG field of the received RRC message is reset (step 1407). Thereafter, it is possible to determine whether the IP address is previously stored in the SCG field in the MT (step 1408). If the IP address is previously stored in the SCG field in the MT, it is possible to determine whether the IP address exists in the SCG field of the received RRC message (step 1409). If the IP address exists in the SCG field of the received RRC message, the IP address previously stored in the SCG field in the MT is changed to the received IP address (step 1410). However, if the IP address does not exist in the SCG field of the received RRC message, the IP address previously stored in the SCG field in the MT is used as is (step 1411). In addition, if the IP address is not previously stored in the SCG field in the MT, it can be determined whether the IP address exists in the SCG field of the received RRC message (step 1412). If the IP address exists in the SCG field of the received RRC message, the IP address in the SCG field of the received RRC message is reset (step 1413).

[0175] As another embodiment, if the IP address allocation through OAM is not completed within a specific time period after the IAB node has established the RRC connection, the connected IAB node may request an IP address. To this end, the IAB node may start a timer after establishing the DRB. As a more specific operation, upon receiving an RRCreconfiguration message after the connection establishment is completed, or as a response message to the received RRCreconfiguration, the UE may send an RRCreconfigurationComplete message and start a timer. When it is confirmed that an IP address with OAM data has been received through the DRB, the timer may be stopped. If the timer expires, the IAB node may request an IP address allocation by using an RRC message.

[0176] All RRC messages requesting IP address allocation may include corresponding IAB node ID or DU ID information, and an indicator of which IP address system may be used, ie, information on IP version 4 or / and IP version 6.

[0177] As another embodiment, when the IAB node performs migration, the IAB donor CU transmits default UL backhaul information. Assuming dual connectivity, it may be the case that one of the two links and the BH RLC channel are explicitly transmitted. The IAB donor CU may instruct a specific IAB node to migrate or switch to another IAB parent node. If a specific IAB node (or IAB MT) is configured with dual connectivity, the message provided by the IAB donor CU in the RRCreconfiguration message may be transmitted as a switching command, a target DL frequency, and configuration information to be used in the corresponding cell, wherein the switching command includes the physical cell identifier of the IAB node used as the target cell. Default UL BH information may be transmitted therewith. The default UL BH information may include a routing ID for routing in the Backhaul Adaptation Protocol (BAP), and may include an exit BH RLC channel information. The exit BH RLC channel information may refer to a specific BH RLC channel ID defined in a specific exit link information and on the corresponding link. For IAB MT, the exit link information may indicate an indicator to MCG or SCG after handover is performed, or a BAP address of the next hop node at the BAP layer. In addition, via RRC messages, the IP address allocated by the IAB donor DU connected to the IAB parent node corresponding to the SCG or MCG may be configured separately for the MCG or SCG.

[0178] The IAB MT that has received the corresponding information can apply the received RRC configuration information by performing a handover to the target cell (i.e., the cell of the target parent IAB node). From the time point of applying the handover message, for the UL service generated in the higher layer, the BAP layer can discard the routing ID selection configuration information and the BH RLC channel mapping configuration information (assuming that there is no such information), or change the routing ID selection configuration information and the BH RLC channel mapping configuration information to the given default BH UL information. After application, for the generated F1-C / F1-AP service, or the BAP SDU received from the child IAB node and to be sent in the UL direction through the BH, the IAB MT can add the received routing ID information to the BAP header to create a BAPPDU, and send the corresponding BAP PDU (UL BAP PDU) via the exit link and exit BH RLC channel indicated by the default UL BH information. After the handover, when the IAB MT receives a new BAP layer routing information update from the IAB donor CU through the F1-AP, it can then initiate routing for the BAP PDU by using the updated routing configuration information. From now on, based on the received IP address of the MCG or SCG, the entry indicated by the corresponding IP address can be selected from the entries in the routing table and routing can be performed.

[0179] As another embodiment, information about only one BH RLC channel of one exit link has been added to the default UL BH information, but in specific cases, for example, when migration is performed in a dual connectivity case, two default UL backhaul information may be sent via an RRCreconfiguration message. In this case, the IAB donor CU may send an RRCreconfiguration message (or, another DL RRC message) at a specific time, the RRCreconfiguration message including one RRC message carrying the entire default UL backhaul information or a separate RRC message carrying its respective default UL backhaul information. Each default UL backhaul information may be set based on which cell group link is migrated when the RRC message is received (i.e., when the configuration information of the migration or handover command is applied). That is, each default UL backhaul information may be set by associating with an MCG or SCG indicator or by including in the MCG / SCG configuration information, and when performing PCell switching (or during migration of an MCG link), the UE may perform UL transmission through the backhaul by applying the default UL backhaul information set set to the MCG parameter. Similarly, when performing spcell switching (during migration of the SCG link), the default UL backhaul information set as the SCG parameters can be followed.

[0180] As another embodiment, in the case of establishing dual connectivity, the default UL BH information in the RRCreconfiguration message may be determined by not including a separate exit link without network configuration. Here, the possible exit link may be a link with a target cell that has performed HO, or may represent a link with a cell that has not yet performed HO.

[0181] When the IAB MT switches from idle mode or inactive mode to connected mode, not only in the case of receiving a HO command, but also in the case of receiving an RRC connection establishment message (for switching from idle mode to connected mode) or an RRC recovery message (for switching from inactive mode to connected mode) from a base station, the default UL BH information can be transmitted, wherein the above information can be included in the received message. Also in this case, the IAB node or IAB MT that has received the message can apply the configuration information included in the corresponding RRC message. As in the case of handover, the received default UL BH information can be applied. After the above application, for the generated F1-C / F1-AP service, the service generated in the upper layer of the BAP of the receiving node, or the BAP SDU received from the child IAB node and to be sent in the UL direction via the BH, the IAB MT can add the received routing ID information to the BAP header to create a BAP PDU, and send the corresponding BAP PDU (UL BAP PDU) through the exit link and exit BH RLC channel indicated by the default UL BH information. In case of handover or transition from inactive mode or idle mode to connected mode, when the IAB MT receives a new BAP layer routing information update from the IAB donor CU via F1-AP, it can thereafter initiate routing for the BAP PDU by using the updated routing configuration information. From now on, based on the received IP address of the MCG or SCG, it can select the entry indicated by the corresponding IP address from the entries in the routing table and perform routing.

[0182] Fig.15 is a diagram illustrating a process of performing conditional handover when an IAB node receives an RLF recovery failure notification from a parent node according to an embodiment.

[0183] IAB Node 2 (1520) may be connected to IAB Node 1 (1540) acting as a parent node, and IAB Node 1 (1540) may be connected to a donor DU and a donor CU of a donor gNB 1560 acting as a parent node.

[0184] When receiving an RLF recovery failure notification from a parent node via an RRC message from its donor gNB 1560 or donor eNB, the IAB node 2 (1520) in a connected state can receive an indication to perform conditional switching (step 1501).

[0185] Thereafter, the donor gNB 1560 may allocate a candidate cell ID or a conditional reconfiguration ID as configuration information of the target candidate cells on which conditional switching is to be performed, and information about the conditions for performing conditional switching on these cells, and configure them to the MT of the IAB node 2 (1520) (step 1502).

[0186] The target candidate cell information may include information about cells with good channel quality selected by the CU based on previous measurement reports. The configuration information received by the MT of the IAB node from the CU may include the information required for the corresponding UE to access the cell for transmission / reception, and may include information included in the handover command for conventional UEs. The above information may include access information for the target cell, bearer configuration information, radio resource configuration information, measurement configuration information, configuration information of each 1 / 2 layer protocol entity, etc. As information for identifying the target cell, information about the DL frequency where the cell is located, physical cell ID information, etc. may be included.

[0187] Upon receiving the information, the MT of the IAB node 2 (1520) may store the conditional handover execution condition, the target cell configuration information, and the conditional reconfiguration ID together (step 1503).

[0188] At a specific time point, the parent node of IAB node 2 (1520) may attempt RLF recovery, where the RLF recovery may be an RRC reestablishment process for IAB node 1 (1540). Optionally, the RLF recovery may be an SCGFailureInformation process or an MCGFailureInformation process for IAB node 1 (1540). If the recovery fails (step 1504), a corresponding RLF recovery failure indication may be sent to the child node via BAP control signaling (step 1505).

[0189] When the MT of the IAB node 2 (1520) receives the indication, it may perform cell selection. If the cell selected as a result of the cell selection is one of the candidate target cells previously received and stored, a handover may be performed on the selected cell. Here, among the configuration information of the candidate target cells previously received and stored, the configuration information of the selected cell may be applied and CHO may be performed (step 1506).

[0190] In another embodiment, the MT of IAB node 2 (1520) may select one of the currently stored candidate target cells without performing conventional cell selection, and perform handover by applying the configuration information stored in the selected candidate target cell. In this case, the cell selection criterion may be channel quality, for example, a cell with the best channel quality may be selected (step 1506). In addition, assuming that the selected candidate target cell is IAB node 3 (1500), the MT of IAB node 2 (1520) may send a random access preamble to IAB node 3 (1500) as a candidate target cell (step 1507), and receive a random access response (step 1508). Upon receiving the random access response, the MT of IAB node 2 (1520) may send an RRCreconfigurationComplete message (step 1509).

[0191] Fig.16 is a diagram illustrating a method of configuring a separate cell on which handover is to be performed when an IAB node receives a recovery failure notification according to an embodiment.

[0192] IAB Node 2 (1620) may be connected to IAB Node 1 (1640) acting as a parent node, and IAB Node 1 may be connected to a donor DU and a donor CU of a donor gNB 1660 acting as a parent node.

[0193] When receiving an RLF recovery failure notification from a parent node via an RRC message from its donor gNB 1660 or donor eNB, the IAB node 2 (1620) in a connected state may receive an indication to perform a conditional handover (step 1601). Configuration information of a target cell to be moved when performing a corresponding conditional handover may be sent together with or separately from the indication to perform a conditional handover. Here, a conditional reconfiguration ID or a candidate target cell ID may be sent together (step 1601).

[0194] The target candidate cell information may include information about cells with good channel quality selected by the CU based on previous measurement reports. The configuration information received by the MT of the IAB node from the CU may include the information required for the corresponding UE to access the cell for transmission / reception, and may include information included in the handover command for conventional UEs. The above information may include access information for the target cell, bearer configuration information, radio resource configuration information, measurement configuration information, configuration information of each 1 / 2 layer protocol entity, etc. As information for identifying the target cell, information about the DL frequency where the cell is located, physical cell ID information, etc. may be included.

[0195] Upon receiving the information, the MT (1620) of the IAB node 2 may store the target cell configuration information and the conditional reconfiguration ID together (step 1602).

[0196] At a specific time point, the parent node of IAB Node 2 (1620) may attempt RLF recovery, and if the recovery fails (step 1603), a corresponding RLF recovery failure indication may be sent to the child node through BAP control signaling (step 1604).

[0197] When the MT (1620) of the IAB node 2 receives the indication, it may perform handover on the candidate target cell indicated by the information received in step 1601. In this case, the target cell configuration information stored in step 1601 may be applied. If multiple cells and their configuration information are received (in step 1601), the MT of the IAB node 2 (1620) may select a cell with the best channel state from the multiple cells to perform handover (step 1605).

[0198] Here, assuming that the selected candidate target cell is IAB node 3 (1600), the MT of IAB node 2 (1620) can send a random access preamble to the candidate target cell (step 1606) and receive a random access response (step 1607). Upon receiving the random access response, the MT of IAB node 2 (1620) can send an RRCreconfigurationComplete message (step 1608).

[0199] Fig.17 is a diagram illustrating a process of performing conditional handover given a separate cell to perform handover and additional determination criteria when an IAB node receives an RLF recovery failure notification according to an embodiment.

[0200] IAB Node 2 (1720) may be connected to IAB Node 1 (1740) acting as a parent node, and IAB Node 1 (1740) may be connected to a donor DU and a donor CU of a donor gNB 1760 acting as a parent node.

[0201] When receiving an RLF recovery failure notification from a parent node via an RRC message from its donor gNB 1760 or donor eNB, the IAB node 2 (1720) in a connected state may receive an indication to perform a conditional handover (step 1701). Configuration information of a target cell to be moved when performing a corresponding conditional handover may be sent together with or separately from the indication to perform a conditional handover. Here, a conditional reconfiguration ID or a candidate target cell ID may be sent together (step 1701). In addition, information about the conditions for performing a handover to a corresponding target cell may be sent (step 1701).

[0202] The target candidate cell information may include information about cells with good channel quality selected by the CU based on previous measurement reports. The configuration information received by the MT of the IAB node from the CU may include the information required for the corresponding UE to access the cell for transmission / reception, and may include information included in the handover command for conventional UEs. The above information may include access information for the target cell, bearer configuration information, radio resource configuration information, measurement configuration information, configuration information of each 1 / 2 layer protocol entity, etc. As information for identifying the target cell, information about the DL frequency where the cell is located, physical cell ID information, etc. may be included.

[0203] The condition information may include measurements as a measurement object and a report configuration pair. In particular, the report configuration may indicate corresponding events A3, A4, or A5, and may correspond to multiple {report configuration, measurement object} pairs, i.e., a set of measurement IDs combined by AND or OR connectors. Conditional switching can only be performed when the composite condition is met. In addition, the measurement object must have smtc3. Here, smtc3 is a configuration value of the measurement time of the SSB sent by the DU of the adjacent IAB node, and unlike the existing smtc1 and smtc2, smtc3 is a value that only considers the SSB sent by the IAB node.

[0204] Upon receiving the information, the MT (1720) of the IAB node 2 may store the target cell configuration information and the conditional reconfiguration ID together (step 1702). In addition, the MT of the IAB node 2 (1720) may start a measurement operation and a condition determination operation for each execution condition. In another embodiment, the MT of the IAB node 2 (1720) may perform a measurement operation and a condition determination operation after receiving an RLF recovery failure notification from a parent node (step 1705).

[0205] At a specific time point, the parent node of IAB Node 2 (1720) may attempt RLF recovery, and if the recovery fails (step 1703), the parent node may send a corresponding RLF recovery failure indication to the child node through BAP control signaling (step 1704).

[0206] When the MT (1720) of the IAB node 2 receives the indication, it may also evaluate the execution condition associated with the candidate target cell received in step 1701. The MT of the IAB node 2 (1720) may select a candidate target cell that satisfies the execution condition and perform handover on the selected cell. In this case, the MT of the IAB node 2 (1720) may apply the target cell configuration information stored in step 1701. If configuration information of a plurality of cells and their execution conditions are received in step 1701, and there are a plurality of cells in the plurality of cells that satisfy their respective execution conditions, the MT of the IAB node 2 (1720) may perform handover (step 1705) by selecting the best cell from the plurality of cells based on the result of combining one or more of the following criteria. The criteria may be as follows.

[0207] - The cell with the best channel conditions, where the cell with the largest RSRP, RSRQ or RSSI value is selected

[0208] - The cell with the most good beams, where the MT may receive a threshold value for determining the channel status of a good beam from the network. Beams exceeding the threshold value may be defined as good beams.

[0209] - Load intensity applied to backhaul traffic. Select the cell with the minimum intensity

[0210] -Select the cell with the highest PHY radio resource availability

[0211] Here, assuming that the selected candidate target cell is IAB node 3 (1700), the MT of IAB node 2 (1720) can send a random access preamble to the candidate target cell (step 1706), and receive a random access response from IAB node 3 (1700) (step 1707). Upon receiving the random access response, the MT of IAB node 2 (1720) can send an RRCreconfigurationComplete message (step 1708).

[0212] In other embodiments, if the IAB node receives an RLF recovery failure notification from its SCG parent node, it may ignore the pre-configured conditional handover operation and perform the SCGFailureInfomration process. In this case, the conditional handover operation means performing a handover to a given candidate target cell when an RLF recovery failure notification is received from the parent node. On the contrary, regardless of the RLF recovery failure notification, the handover may still be performed by evaluating the channel conditions. The donor CU of the donor gNB may send an indicator to the IAB node in response to the RLF recovery failure notification received from the SCG parent node to indicate whether to perform the SCGFailureInformation operation or to perform a conditional handover.

[0213] The methods according to the embodiments described in the claims or the specification of the present disclosure may be implemented in the form of hardware, software, or a combination thereof.

[0214] When implemented in software, a computer-readable storage medium storing one or more programs (software modules) may be provided. One or more programs stored in the computer-readable storage medium are configured to be executed by one or more processors of an electronic device. One or more programs include instructions that cause the electronic device to perform the method according to the embodiments described in the claims or description of the present disclosure.

[0215] Such a program (software module, software) may be stored in a random access memory, a non-volatile memory (such as flash memory), a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic disk storage device, a compact disk ROM (CD-ROM), a digital versatile disk (DVD), other types of optical storage devices, or a magnetic tape cartridge. Or, such a program may be stored in a memory consisting of a combination of some or all of them. In addition, multiple component memories may be included.

[0216] In addition, such a program may be stored in an attachable storage device that can be accessed through a communication network such as the Internet, an intranet, a local area network (LAN), a wide area network (WLAN), or a storage area network (SAN), or through a communication network consisting of a combination thereof. Such a storage device can access a device that performs an embodiment of the present disclosure through an external port. In addition, a separate storage device on a communication network can access a device that performs an embodiment of the present disclosure.

[0217] In the specific embodiments of the present disclosure, the elements included in the present disclosure are represented in singular or plural form according to the specific embodiments proposed. However, for ease of description, singular or plural representation is appropriately selected according to the presented situation, and the present disclosure is not limited to a single element or multiple elements. Those elements described in plural form can be configured as a single element, and those elements described in singular form can be configured as multiple elements.

[0218] At the same time, the embodiments of the present disclosure disclosed in this specification and the accompanying drawings are provided as specific examples to easily explain the technical content of the present disclosure and help understand the present disclosure, and are not intended to limit the scope of the present disclosure. That is to say, it is obvious to a person skilled in the art in the field to which the present disclosure belongs that other modifications can be made based on the technical spirit of the present disclosure. In addition, the above embodiments can be combined with each other as needed. For example, a base station and a terminal can be operated by combining parts of one embodiment of the present disclosure with another embodiment. In addition, other modifications based on the technical ideas of the above embodiments can be performed in various systems such as FDD LTE systems, TDD LTE systems, 5G or NR systems.

Claims

1. A method performed by a mobile terminal MT, the method comprising: receiving a first message from a donor central unit CU, the first message comprising a list of integrated access and backhaul IAB Internet Protocol IP addresses associated with a first IAB IP address for a secondary cell group SCG in a multi-radio dual connectivity MR-DC, and Based on the list of the IAB IP addresses, the first IAB IP address for the SCG is added.

2. The method according to claim 1, further comprising: sending a message related to the allocation of the IAB IP address to the donor CU, the message including information associated with IP version 4 or IP version 6, and The first message is a radio resource control RRC message.

3. The method according to claim 1, further comprising: Based on the list of the IAB IP addresses, an IAB-MT configuration associated with the first IAB IP address is changed.

4. The method according to claim 2, wherein: In case the message is sent via a node associated with an Evolved-UMTS Terrestrial Radio Access Network (E-UTRAN), the message is a ULInformationTransferMRDC message.

5. A method performed by a donor central unit CU, the method comprising: sending a first message to a mobile terminal MT, the first message comprising a list of integrated access and backhaul IAB Internet Protocol IP addresses associated with a first IAB IP address for a secondary cell group SCG in a multi-radio dual connectivity MR-DC, and Wherein, the first IAB IP address for the SCG is added based on the list of the IAB IP addresses.

6. The method according to claim 5, further comprising: receiving a message from the MT regarding allocation of the IAB IP address, the message including information associated with IP version 4 or IP version 6, and The first message is a radio resource control RRC message.

7. The method according to claim 5, wherein: An IAB-MT configuration associated with the first IAB IP address is changed based on the list of IAB IP addresses.

8. The method according to claim 6, wherein: In case the message is sent via a node associated with an Evolved-UMTS Terrestrial Radio Access Network (E-UTRAN), the message is a ULInformationTransferMRDC message.

9. A mobile terminal MT, comprising: a transceiver capable of transmitting and receiving at least one signal; as well as a controller, coupled to the transceiver, Wherein, the controller is configured as: receiving a first message from a donor central unit CU, the first message comprising a list of integrated access and backhaul IAB Internet Protocol IP addresses associated with a first IAB IP address for a secondary cell group SCG in a multi-radio dual connectivity MR-DC, and Based on the list of the IAB IP addresses, the first IAB IP address for the SCG is added.

10. The MT according to claim 9, wherein: The controller is also configured to: sending a message related to the allocation of the IAB IP address to the donor CU, the message including information associated with IP version 4 or IP version 6, and The first message is a radio resource control RRC message.

11. The MT according to claim 9, wherein: The controller is also configured to: Based on the list of the IAB IP addresses, an IAB-MT configuration associated with the first IAB IP address is changed.

12. The MT according to claim 10, wherein: In case the message is sent via a node associated with an Evolved UM TS Terrestrial Radio Access Network (E-UTRAN), the message is a ULInformationTransferMRDC message.

13. A donor central unit CU, the donor CU comprising: a transceiver capable of transmitting and receiving at least one signal; as well as a controller, coupled to the transceiver, Wherein, the controller is configured as: sending a first message to a mobile terminal MT, the first message comprising a list of integrated access and backhaul IAB Internet Protocol IP addresses associated with a first IAB IP address for a secondary cell group SCG in a multi-radio dual connectivity MR-DC, and Wherein, the first IAB IP address for the SCG is added based on the list of the IAB IP addresses.

14. The donor CU according to claim 13, wherein: The controller is configured to: receiving a message from the MT regarding allocation of the IAB IP address, the message including information associated with IP version 4 or IP version 6, and The first message is a radio resource control RRC message.

15. The donor CU according to claim 14, wherein: an IAB-MT configuration associated with the first IAB IP address is changed based on the list of the IAB IP addresses, and Wherein, in the case where the message is sent via a node associated with an Evolved-UMTS Terrestrial Radio Access Network E-UTRAN, the message is a ULInformationTransferMRDC message.

Images