WO2019212249A1 - Method for data processing through relay node and apparatus thereof - Google Patents

Abstract

The present invention relates to techniques for data processing and data re-transmission through a relay node. In one embodiment, provided are a method for a terminal to transmit data through at least one relay node and an apparatus thereof, the method comprising: a step in which a packet data convergence protocol (PDCP) entity transmits PDCP data for an acknowledged mode data radio bearer (AMDRB) to a donor base station through at least one relay node; a step in which the PDCP entity receives, from the donor base station, re-transmission instruction information which instructs the PDCP entity to re-transmit the PDCP data; and a step in which the PDCP entity re-transmits, on the basis of the re-transmission instruction information, a PDCP data protocol data unit (PDU) or a PDCP data service data unit (SDU).

Description

Method and apparatus for processing data through relay node

The present disclosure relates to data processing and data retransmission techniques through relay nodes.

In wireless communication systems, relay technology has been used to extend cell coverage using additional network nodes.

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

In other words, the relay technology to which the conventional LTE technology is applied provides only a single hop relay function to provide a simple service, and most of the configuration is indicated and configured through static OAM (Operations, administration and management). As a result, a plurality of hop relays could not be configured.

In addition, in the case of supporting the multi-hop relay through the conventional LTE technology, data cannot be divided and processed through a plurality of relay nodes, and signaling and data processing on the IP layer may increase delay.

In order to solve this problem, researches on a technology for accurately delivering user data to a base station by configuring a multi-hop have been conducted. In the case of transmitting / receiving data based on a multi-hop, problems regarding data processing and retransmission methods are expected.

In the background described above, an embodiment of the present disclosure is to propose a technique for securing reliability of transmission / reception data between a terminal and a donor base station when a plurality of relay hops are configured.

In addition, an embodiment proposes a data processing operation according to a change of a backhaul link in a multi-hop relay structure.

According to an embodiment of the present invention, in a method in which a terminal transmits data through one or more relay nodes, a Packet Data Convergence Protocol (PDCP) entity includes one PDCP data for an AM Acknowledged Mode Data Radio Bearer (DRB). The PDCP data protocol data unit (PDU) or SDU (Service) service in the PDCP entity based on the step of transmitting to the donor base station through the relay node, the step of receiving retransmission indication information indicating PDCP data retransmission from the donor base station, and the retransmission indication information. Retransmitting Data Unit) is provided.

In addition, an embodiment is a method in which a donor base station transmits data through one or more relay nodes, wherein a Packet Data Convergence Protocol (PDCP) entity receives PDCP data for an AM Acknowledged Mode Data Radio Bearer (DRB) at least one relay node. Retransmitting the PDCP data protocol data unit (PDU) or service data unit (SDU) in the PDCP entity based on the step of transmitting to the terminal through the terminal, receiving retransmission indication information indicating the retransmission of PDCP data from the terminal, and retransmission indication information. It provides a method comprising the steps of.

In addition, according to an embodiment, in a terminal transmitting data through one or more relay nodes, a packet data convergence protocol (PDCP) entity may donor PDCP data for an AM Acknowledged Mode Data Radio Bearer (DRB) through one or more relay nodes. Retransmit the PDCP data protocol data unit (PDU) or service data unit (SDU) in the PDCP entity based on the transmitter and the retransmission instruction instructing the transmitter to transmit the PDCP data retransmission from the donor base station. It provides a terminal device including a control unit for controlling.

In addition, an embodiment of the present invention provides a donor base station that transmits data through one or more relay nodes, wherein a Packet Data Convergence Protocol (PDCP) entity receives PDCP data for an AM Acknowledged Mode Data Radio Bearer (DRB) through one or more relay nodes. Control the PDCP entity to retransmit the PDCP data PDU (Service Data Unit) or SDU (Service Data Unit) on the basis of the transmitter and the retransmission instruction that receives the retransmission instruction information instructing the retransmission of PDCP data from the terminal. It provides a donor base station device including a control unit.

The present disclosure provides the effect of improving the reliability of data transmission by using a plurality of relay hops.

1 is a diagram schematically illustrating a structure of an NR wireless communication system to which an embodiment of the present invention may be applied.

2 is a view for explaining a frame structure in an NR system to which the present embodiment can be applied.

3 is a diagram for describing a resource grid supported by a radio access technology to which the present embodiment can be applied.

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

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

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

7 is a diagram illustrating an example of a relay-based user plane protocol structure in LTE technology.

8 (A) and 8 (B) illustrate a relay node start up procedure in a LTE technology.

9 to 13 are diagrams for describing various examples of an L2-based relay structure according to an embodiment.

14 is a diagram for describing a data retransmission operation of a terminal, according to an exemplary embodiment.

15 illustrates a data retransmission operation of a donor base station according to an embodiment.

16 is a diagram illustrating a PDCP data PDU format according to an embodiment.

17 illustrates a peering model of a UM RLC entity.

18 is a diagram illustrating AM RLC configuration information according to an embodiment.

19 is a block diagram illustrating a terminal configuration according to an embodiment.

20 is a block diagram illustrating a donor base station configuration according to an embodiment.

Hereinafter, some embodiments of the present invention will be described in detail with reference to exemplary drawings. In adding reference numerals to components of each drawing, the same components may have the same reference numerals as much as possible even though they are shown in different drawings. In addition, in describing the technical idea, when it is determined that a detailed description of a related well-known configuration or function may obscure the gist of the present invention, the detailed description may be omitted.

In addition, in describing the components of the exemplary embodiments, terms such as first, second, A, B, (a), and (b) may be used. These terms are only to distinguish the components from other components, and the terms are not limited in nature, order, order, or number of the components. If a component is described as being "connected", "coupled" or "connected" to another component, that component may be directly connected to or connected to that other component, but between components It is to be understood that the elements may be "interposed" or each component may be "connected", "coupled" or "connected" through other components.

In addition, terms and technical names used in the present specification are for explaining a specific embodiment, and technical ideas are not limited to the terms. Unless otherwise defined, the terms described below may be interpreted as meanings generally understood by those skilled in the art to which the technical idea belongs. When the term is an incorrect technical term that does not accurately express the technical idea, it should be replaced with a technical term that can be understood by those skilled in the art. In addition, the general terms used herein should be interpreted as defined in the dictionary, or according to the context before and after, and should not be interpreted in an excessively reduced sense.

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

The embodiments disclosed below may be applied to a wireless communication system using various wireless access technologies. For example, the embodiments of the present invention may include code division multiple access (CDMA), frequency division multiple access (FDMA), timedivision multiple access (TDMA), orthogonal frequency division multiple access (OFDMA), and single carrier frequency division multiple access (SC-FDMA). It can be applied to various radio access technologies, such as. CDMA may be implemented by a radio technology such as universal terrestrial radio access (UTRA) or CDMA2000. TDMA may be implemented in a wireless technology such as global system for mobile communications (GSM) / general packet radio service (GPRS) / enhanced data rates for GSM evolution (EDGE). OFDMA may be implemented in wireless technologies such as Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802-20, evolved UTRA (E-UTRA), and the like. 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 a universal mobile telecommunications system (UMTS). 3rd generation partnership project (3GPP) long term evolution (LTE) is part of evolved UMTS (E-UMTS) using evolved-UMTS terrestrial radio access (E-UTRA), employing OFDMA in downlink and SC- in uplink FDMA is adopted. As such, the embodiments may be applied to a wireless access technology that is currently disclosed or commercialized, and may be applied to a wireless access technology that is currently under development or will be developed in the future.

Meanwhile, the terminal in the present specification is a comprehensive concept of a device including a wireless communication module for communicating with a base station in a wireless communication system, and includes a UE in WCDMA, LTE, HSPA, and IMT-2020 (5G or New Radio). (User Equipment), of course, should be interpreted as a concept that includes a mobile station (MS), a user terminal (UT), a subscriber station (SS), a wireless device, and the like in GSM. In addition, the terminal may be a user portable device such as a smart phone according to a usage form, and may mean a vehicle, a device including a wireless communication module in a vehicle, and the like in a V2X communication system. In addition, in the case of a machine type communication (Machine Type Communication) system may mean an MTC terminal, an M2M terminal equipped with a communication module to perform machine type communication.

A base station or a cell of the present specification refers to an end point that communicates with a terminal in terms of a network, and includes a Node-B, an evolved Node-B, an eNB, a gNode-B, a Low Power Node, and an LPN. Sector, site, various types of antenna, base transceiver system (BTS), access point, access point (for example, transmission point, reception point, transmission point and reception point), relay node ), A mega cell, a macro cell, a micro cell, a pico cell, a femto cell, a remote radio head (RRH), a radio unit (RU), and a small cell.

Since the various cells listed above have a base station for controlling each cell, the base station may be interpreted in two meanings. 1) the device providing the mega cell, the macro cell, the micro cell, the pico cell, the femto cell, the small cell in relation to the wireless area, or 2) the wireless area itself. In 1) all devices that provide a given radio area are controlled by the same entity or interact with each other to cooperatively configure the radio area to the base station. According to the configuration of the wireless area, a point, a transmission point, a transmission point, a reception point, and the like become one embodiment of a base station. In 2), the base station may indicate the radio area itself that receives or transmits a signal from the viewpoint of the user terminal or the position of a neighboring base station.

In the present specification, a cell refers to a component carrier having a coverage of a signal transmitted from a transmission / reception point or a signal transmitted from a transmission point or a transmission / reception point, and the transmission / reception point itself. Can be.

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

Uplink and downlink transmit and receive control information through a control channel such as a physical downlink control channel (PDCCH), a physical uplink control channel (PUCCH), a physical downlink shared channel (PDSCH), a physical uplink shared channel (PUSCH), and the like. Data is transmitted and received by configuring the same data channel. Hereinafter, a situation in which a signal is transmitted and received through a channel such as PUCCH, PUSCH, PDCCH, and PDSCH is described as 'transmit and receive PUCCH, PUSCH, PDCCH, and PDSCH'. do.

For clarity, the following description focuses on the 3GPP LTE / LTE-A / NR (New RAT) communication system, but the technical features are not limited thereto.

After researching 4G (4th-Generation) communication technology, 3GPP is conducting research on 5G (5th-Generation) communication technology to meet the requirements of ITU-R next generation wireless access technology. Specifically, 3GPP is conducting research on a new NR communication technology separate from LTE-A pro and 4G communication technology, in which LTE-Advanced technology is enhanced to meet the requirements of ITU-R as 5G communication technology. LTE-A pro and NR both appear to be submitted in 5G communication technology, but for the convenience of description, the following describes the embodiments of the present invention mainly on NR.

Operational scenarios in NR defined various operational scenarios by adding considerations to satellites, automobiles, and new verticals in the existing 4G LTE scenarios.In terms of services, they have eMBB (Enhanced Mobile Broadband) scenarios and high terminal density. Supports a range of mass machine communication (MMTC) scenarios that require low data rates and asynchronous connections, and Ultra Reliability and Low Latency (URLLC) scenarios that require high responsiveness and reliability and support high-speed mobility. .

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

<NR system general>

1 is a diagram schematically illustrating a structure of an NR system to which the present embodiment may be applied.

Referring to FIG. 1, an NR system is divided into a 5G core network (5GC) and an NR-RAN part, and the NG-RAN controls a user plane (SDAP / PDCP / RLC / MAC / PHY) and a user equipment (UE). It consists of gNB and ng-eNBs providing a planar (RRC) protocol termination. The gNB interconnects or gNBs and ng-eNBs are interconnected via an Xn interface. gNB and ng-eNB are each connected to 5GC through the NG interface. The 5GC may be configured to include an access and mobility management function (AMF) that is in charge of a control plane such as a terminal access and mobility control function, and a user plane function (UPF), which is in charge of a control function in user data. NR includes support for sub-6 GHz frequency bands (FR1, Frequency Range 1) and 6 GHz and higher frequency bands (FR2, Frequency Range 2).

gNB means a base station providing the NR user plane and control plane protocol termination to the terminal, ng-eNB means a base station providing the E-UTRA user plane and control plane protocol termination to the terminal. The base station described in the present specification should be understood to mean gNB and ng-eNB, and may be used to mean gNB or ng-eNB.

<NR Waveforms, Neutral and Frame Structures>

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

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

값이 2의 지수 값으로 사용되어 지수적으로 변경된다.Specifically, the NR transmission neuron is determined based on sub-carrier spacing and cyclic prefix (CP), and based on 15khz as shown in Table 1 below.

The value is used as an exponential value of 2 and is changed exponentially.

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

As shown in Table 1, the NR's pneumoroller may be classified into five types according to the subcarrier spacing. This is different from the fixed subcarrier spacing of LTE, which is one of 4G communication technologies, to be 15 kHz. Specifically, the subcarrier spacing used for data transmission in NR is 15, 30, 60, 120khz, and the subcarrier spacing used for synchronization signal transmission is 15, 30, 12, 240khz. In addition, the extended CP is applied only to the 60khz subcarrier interval. On the other hand, the frame structure (frame) in NR is a frame having a length of 10ms consisting of 10 subframes having the same length of 1ms is defined. One frame may be divided into half frames of 5 ms, and each half frame includes five subframes. In the case of a 15khz subcarrier interval, one subframe consists of one slot, and each slot consists of 14 OFDM symbols. 2 is a view for explaining a frame structure in an NR system to which the present embodiment can be applied. Referring to FIG. 2, the slot is fixedly configured with 14 OFDM symbols in the case of a normal CP, but the length of the slot may vary depending on the subcarrier spacing. For example, in the case of a newerology with a 15khz subcarrier spacing, the slot has a length of 1 ms and the same length as the subframe. On the contrary, in the case of a numerology having a 30khz subcarrier spacing, the slot includes 14 OFDM symbols, but two slots may be included in one subframe with a length of 0.5 ms. That is, the subframe and the frame are defined with a fixed time length, the slot is defined by the number of symbols, the time length may vary according to the subcarrier interval. Meanwhile, NR defines a basic unit of scheduling as a slot, and also introduces a mini slot (or subslot or non-slot based schedule) to reduce transmission delay of a radio section. The use of a wide subcarrier spacing shortens the length of one slot in inverse proportion, thereby reducing the transmission delay in the radio section. The mini slot (or sub slot) is for efficient support for the URLLC scenario and can be scheduled in units of 2, 4, and 7 symbols.

In addition, unlike LTE, NR defines uplink and downlink resource allocation at a symbol level in one slot. In order to reduce the HARQ delay, a slot structure capable of transmitting HARQ ACK / NACK directly within a transmission slot has been defined, and this slot structure will be 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 the Rel-15. In addition, a combination of various slots supports a common frame structure constituting an FDD or TDD frame. For example, a slot structure in which all symbols of a slot are set to downlink, a slot structure in which all symbols are set to uplink, and a slot structure in which downlink symbol and uplink symbol are combined are supported. NR also supports that data transmission is distributed and scheduled in one or more slots. Accordingly, the base station can inform the terminal whether the slot is a downlink slot, an uplink slot, or a flexible slot by using a slot format indicator (SFI). The base station may indicate the slot format by using the SFI to indicate the index of the table configured through the RRC signaling to the terminal specific, and may be indicated dynamically through the downlink control information (DCI) or statically or quasi-statically through the RRC. It may be.

<NR Physical Resource>

With regard to physical resources in NR, antenna ports, resource grids, resource elements, resource blocks, bandwidth parts, etc. are considered Can be.

The antenna port is defined such that the channel on which the symbol is carried on the antenna port can be inferred from the channel on which another symbol on the same antenna port is carried. If the large-scale property of a channel carrying a symbol on one antenna port can be deduced from the channel carrying the symbol on another antenna port, then the two antenna ports are quasi co-located or QC / QCL. quasi co-location relationship. Here, the broad characteristics include one or more of delay spread, Doppler spread, frequency shift, average received power, and received timing.

3 is a diagram for describing a resource grid supported by a radio access technology to which the present embodiment can be applied.

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

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

FIG. 4 is a diagram for describing a bandwidth part supported by a radio access technology to which the present 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 the NR, as shown in FIG. 4, the bandwidth part can be designated within the carrier bandwidth and used by the terminal. In addition, the bandwidth part is associated with one neuralology and consists of a subset of consecutive common resource blocks and can be dynamically activated over time. The UE is configured with up to four bandwidth parts, respectively, uplink and downlink, and data is transmitted and received using the bandwidth part activated at a given time.

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

<NR initial connection>

In NR, the UE performs a cell search and random access procedure to access and communicate with a base station.

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

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

Referring to FIG. 5, an SSB is composed of a primary synchronization signal (PSS) and a secondary synchronization signal (SSS), which occupy one symbol and 127 subcarriers, respectively, three OFDM symbols, and a PBCH spanning 240 subcarriers.

The terminal monitors the SSB in the time and frequency domain to receive the SSB.

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

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

On the other hand, SSB is not transmitted at the center frequency of the carrier bandwidth, unlike the SS of the conventional LTE. That is, the SSB may be transmitted even where the center of the system band is not, and when supporting broadband operation, a plurality of SSBs may be transmitted in the frequency domain. Accordingly, the terminal monitors the SSB using a synchronization raster, which is a candidate frequency position for monitoring the SSB. The carrier raster and the synchronization raster, which are the center frequency position information of the channel for initial access, are newly defined in the NR, and the synchronization raster has a wider frequency interval than the carrier raster, and thus supports fast SSB search of the terminal. Can be.

The UE may acquire the MIB through the PBCH of the SSB. The Master Information Block (MIB) includes minimum information for the UE to receive the remaining system information (RMSI) that the network broadcasts. In addition, the PBCH is information about the position of the first DM-RS symbol in the time domain, information for the UE to monitor SIB1 (for example, SIB1 neuronological information, information related to SIB1 CORESET, search space information, PDCCH Related parameter information, etc.), offset information between the common resource block and the SSB (the position of the absolute SSB in the carrier is transmitted through SIB1), and the like. Here, the SIB1 neuronological information is equally applied to message 2 and message 4 of the random access procedure for accessing the base station after the terminal completes the cell search procedure.

The aforementioned RMSI means System Information Block 1 (SIB1), and SIB1 is broadcast periodically (ex, 160 ms) in a cell. SIB1 includes information necessary for the UE to perform an initial random access procedure and is periodically transmitted through the PDSCH. In order to receive the SIB1, the UE needs to receive the information of the neuterology used for the SIB1 transmission and the control resource set (CORESET) information used for the scheduling of the SIB1 through the PBCH. The UE checks scheduling information on SIB1 using SI-RNTI in CORESET and acquires SIB1 on PDSCH according to the scheduling information. The remaining SIBs other than SIB1 may be transmitted periodically or may be transmitted at the request of the terminal.

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

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

The terminal receives a random access response to the transmitted random access preamble. The random access response may include a random access preamble identifier (ID), a UL grant (uplink radio resource), a temporary C-RNTI (Temporary Cell-Radio Network Temporary Identifier), and a time alignment command (TAC). Since one random access response may include random access response information for one or more terminals, the random access preamble identifier may be included to indicate to which UE the included UL Grant, temporary C-RNTI, and TAC are valid. The random access preamble identifier may be an identifier for the random access preamble received by the base station. The TAC may be included as information for the UE to adjust uplink synchronization. The random access response may be indicated by a random access identifier on the PDCCH, that is, a Random Access-Radio Network Temporary Identifier (RA-RNTI).

Upon receiving the valid random access response, the terminal processes the information included in the random access response and performs the scheduled transmission to the base station. For example, the terminal applies a TAC and stores a temporary C-RNTI. In addition, by using the UL Grant, data or newly generated data stored in the buffer of the terminal is transmitted to the base station. In this case, information that can identify the terminal should be included.

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

In this specification, frequencies, frames, subframes, resources, resource blocks, regions, bands, subbands, control channels, data channels, synchronization signals, various reference signals, various signals, and various messages related to NR (New Radio). May be interpreted as meaning used in the past or present, or various meanings used in the future.

The present disclosure relates to a radio link control method for lossless transmission in an integrated access and backhaul (IAB) infrastructure using 5G NR wireless communication technology. In addition, the present disclosure discloses a retransmission processing operation of a radio layer 2 entity, and describes a processing operation when a radio link failure occurs.

LTE relay technology

In LTE technology, relay technology has been used for the purpose of extending cell coverage through the use of an additional network node called a relay node (RN). The LTE RN relays user plane data and control plane data at the IP packet level. In addition, a service is provided only through a single RN between a donor base station (Denor eNB, DeNB) serving a relay node and a terminal. That is, only relay through a single hop was supported between the UE and the DeNB.

7 is a diagram illustrating an example of a relay-based user plane protocol structure in LTE technology.

Referring to FIG. 7, the terminal 700 communicates with the donor base station 720 through the relay node 710. The donor base station 720 transmits data of the terminal 700 to the gateway 730. The terminal 700 includes an L1 physical layer and an L2 layer, IP, TCP / UDP, App. It is organized in layers. The relay node 710 is connected to the terminal 700 through the L1 and L2 layers, and is connected to the donor base station 720 through the GTP-u layer above the IP layer to transmit and receive data. To this end, the relay protocol in LTE technology is configured as shown in FIG.

FIG. 8 is a diagram illustrating a relay node start-up procedure in LTE technology.

In the LTE relay technology, the RN startup procedure of FIGS. 8A and 8B for initiating RN operation is used to configure the necessary parameters for the RN.

8 (A) and 8 (B), after the RN 800 is powered on (S805), the RN 800 performs a two-step start procedure. When the RN 800 is powered on, it has two steps because the RN 800 does not know which cell is allowed for network attach. Since not all base stations support serving the RN 800, the RN 800 needs to identify which cell supports the RN 800 operation. If the RN 800 already knows accessible cells, phase I may be omitted and phase II may be performed immediately.

Hereinafter, Phase I will be described with reference to FIG. 8A.

Phase I: Attach for RN preconfiguration.

The RN 800 connects to the E-UTRAN / EPC as a terminal at power up (S815), and retrieves an initial configuration parameter including a list of DeNB cells from the RN OAM 850 (S825). After the operation S825 is completed, the RN 800 disconnects from the network as a terminal (S835) and triggers Phase II described below. The MME 820 performs S-GW and P-GW 830 selection for the RN 800 as a general terminal. (The RN attaches to the E-UTRAN / EPC as a UE at power-up and retrieves initial configuration parameters, including the list of DeNB cells, from RN OAM.After this operation is complete, the RN detaches from the network as a UE and triggers Phase II.The MME performs the S-GW and P-GW selection for the RN as a normal UE.)

Hereinafter, Phase II will be described with reference to FIG. 8 (B).

Phase II: Attach for RN operation.

Referring to FIG. 8B, the RN 800 connects to the DeNB 810 selected from the list collected in Phase I to start the relaying operation (S806).

 When DeNB 810 starts to establish bearer for S1 / X2, RN 800 starts to establish S1 and X2 connections with DeNB 810. In addition, the DeNB 810 initiates an RN reconfiguration procedure through RRC signaling for an RN specific parameter (S807). (The RN connects to a DeNB selected from the list acquired during Phase I to start relay operations.After the DeNB initiates setup of bearer for S1 / X2, the RN initiates the setup of S1 and X2 associations with the DeNB.In addition, the DeNB may initiate an RN reconfiguration procedure via RRC signaling for RN-specific parameters.)

The DeNB 810 performs an S1 eNB configuration update procedure when the configuration data is updated to the RN connection after performing S1 setup with the RN 800 (S808) (S809). In addition, after performing the X2 setup with the RN 800 (S811), the DeNB 810 updates the cell information by performing an X2 eNB configuration update procedure (S812). (After the S1 setup, the DeNB performs the S1 eNB Configuration Update procedure (s), if the configuration data for the DeNB is updated dueto the RN attach.After the X2 setup, the DeNB performs the X2 eNB Configuration Update procedure (s) to update the cell information). In phase II the RN cells' ECGIs are configured by RN OAM.

When the Phase II phase is completed, the RN 800 starts to operate as a relay (S813).

As such, since the RN of the conventional LTE relay technology supports only a single hop relay, the configuration of the relay is mostly provided through a static OAM. From the perspective of the terminal, the RN acts as a base station, and the RN recognizes the donor base station as a core network entity and forms a terminal context in the RN. Therefore, the RN is configured by indicating most of the configuration through the static OAM, and only the radio configuration (for example, the RN subframe configuration) specific to the entire RN device has been indicated and configured by the decision of the donor base station. Accordingly, when multi-hop is supported between the terminal and the base station (donor base station), it is difficult to efficiently configure the service requirements for each terminal. If there is a desire to support a multi-hop relay through the conventional LTE technology, there is a problem in that there is no method for processing data separately through a plurality of relay nodes. In addition, signaling and data processing on the upper IP layer has a problem that can increase the delay.

High layer functionalsplit

Next-generation wireless access networks (hereinafter referred to as NR or 5G or NG-RAN for ease of explanation) are distributed with centralized nodes (hereafter referred to as central units (CUs) for ease of explanation) to support efficient network deployment. Nodes (hereinafter referred to as DUs (Distributed Units for convenience)) may be provided separately. That is, the base station may be configured divided into CU and DU in a logical or physical aspect. In the present disclosure, the base station is a base station to which the NR technology is applied and may be referred to as gNB to distinguish it from an LTE base station (eNB). In addition, NR technology may be applied to the base station, the donor base station, and the relay node unless otherwise described below.

CU refers to logical nodes hosting RRC, SDAP and PDCP protocols. Alternatively, CU means a logical node hosting RRC and upper layer L2 protocol (PDCP). The CU controls the operation of one or more DUs. The CU terminates the F1 interface associated with the DU (gNB Central Unit (gNB-CU): a logical node hosting RRC, SDAP and PDCP protocols, and controls the operation of one or more gNB-DUs.The gNB-CU also terminates F1 interface connected with the gNB-DU.)

DU means a logical node hosting the RLC, MAC and PHY layers. The operation of the DU is partly controlled by the CU. One DU supports one or a plurality of cells. One cell is supported by only one DU. The DU terminates the F1 interface connected to the CU (gNB Distributed Unit (gNB-DU): a logical node hosting RLC, MAC and PHY layers, and its operation is partly controlled by gNB-CU.One gNB-DU supportsone or multiplecells One cell is supportedby only one gNB-DU.The gNB-DU terminates F1 interface connected with the gNB-CU.)

(The NG-RAN consists of a set of gNBs connected to the 5GC through the NG.) Connected to a 5G Core network (5GC) via an NG interface.

The base stations may be interconnected through the Xn interface. (GNBs can be interconnected through the Xn.) A base station may consist of one CU and DUs (A gNB may consist of a gNB-CU and gNB-DUs). . CU and DU are connected via F1 interface. (A gNB-CU and a gNB-DU is connected via F1 logical interface.) One DU is connected to only one CU. (One gNB-DU is connected to only one gNB-CU). For NG-RAN, the NG and Xn-C interfaces for a gNB consisting of a gNB-CU and gNB- DUs, terminate in the gNB-CU.)

As such, the F1 interface is an interface providing an interconnection between the CU and the DU, and the F1AP (The F1 Application Protocol) is used to provide a signaling procedure on the interface.

For EN-DC, the S1-U interface and X2-C interface for one base station consisting of CU and DU are terminated at the CU (For EN-DC, the S1-U and X2-C interfaces for a gNB). consisting of a gNB-CU and gNB-DUs, terminate in the gNB-CU.) The DU connected to the CU is visible to other base stations and the 5GC as only one base station (The gNB-CU and connected gNB-DUs are only visible to other gNBs and the 5GC as a gNB).

NR (New Radio) based multi-hop relay

3GPP is working on the initial specification for 5G wireless communication technology (NR) to meet various requirements of technological development. In the NR, which can use high frequency bands, the use of relay technology can be increased due to the higher bandwidth and the use of multi-beam systems compared to LTE. This makes it easier for operators to build a dense network of self-backhauled NR cells that provide their own backhaul function. However, millimeter wave bands can have the disadvantage of experiencing severe short-term blocking. In addition, small coverage and beam operations in the millimeter wave band may need to be connected to base stations connected to wired / fiber via multi-hop relays. In this case, the terminal cannot be connected to a base station connected to a wired / optical line by using a relay technology according to the conventional LTE technology. In particular, as multi-hop relays must process data in multi-hop, it can be difficult to use for delay-sensitive 5G service transmission. In addition, L2-based relay transmission is preferable to L3-based relay transmission such as LTE in order to support low latency data transmission and QoS function.

Various relay structures can be considered to solve this problem and to support necessary functions.

9 to 13 are diagrams for describing various examples of an L2-based relay structure according to an embodiment.

For example, an L2 relay structure as shown in FIGS. 9 to 13 may be considered.

For example, referring to FIG. 9, the terminal 900 may separately configure an RLC ARQ and an RLC Seg function. In addition, the IAB nodes 910 and 915 have only an RLC Seg function, and the RLC ARQ function may be configured in the IAB donor base station 920. Through this, the terminal 900 and the IAB donor base station 920 may perform ARQ operation on the data of the RLC entity to ensure transmission and reception of data without missing. However, there is a problem that the structure must be configured separately from the RLC protocol entity.

As another example, referring to FIGS. 10 and 11, the IAB nodes 910 and 915 may deliver data on an AM RLC basis. That is, when the terminal 900 transmits data, the IAB node 910 transmits the successful reception of the corresponding data in the RLC entity. When the RLC entity of the terminal 900 receives the successful reception of the data, the RLC entity recognizes that the data has been successfully transmitted. Equally, the IAB node 910 forwards the data to another IAB node 915 and, upon receiving information about the successful receipt of the data at the RLC entity, recognizes that the data has been successfully transmitted. The other IAB node 915 forwards the data to the donor base station 920 and, upon receiving information about successful reception of the data at the RLC entity, recognizes that the data has been successfully transmitted. 10 and 11 show whether the RLC entity is above or below the Adaptation entity, but there is a difference.

As another example, referring to FIG. 12, as shown in FIGS. 10 and 11, successful transmission of data based on AM RLC may be recognized as hop by hop. However, the IAB node 910 is associated with the CU of the IAB donor base station 920 in the SDAP, PDCP, UDP, GTP-U layer and the like. In addition, the CU of the IAB donor base station 920 is connected to the terminal 900 and the PDCP, SDAP layer. The UPF may be associated with the IAB node 910 at the IP layer. However, in the case of FIG. 12, as shown in FIGS. 10 and 11, it is possible to guarantee transmission reliability of data through a hop-by-hop structure based on AM RLC.

Referring to FIG. 13, it is assumed that the IAB donor base station 920 is not a DU / CU separation structure, but may be a separation structure as described above. As described above, the IAB nodes 910 and 915 can deliver data hop by hop in an AM RLC structure. Here, the BAP (Backhaul Adaptation Protocol) object is the same or similar to the Adaptation object described above.

When a layer 2 based relay structure is configured to transmit data based on the AM RLC described above, an ARQ function may be configured as hop by hop along an access and backhaul link.

However, in this case, the PDCP entity of the terminal (or donor base station) may receive an indication of confirmation of successful transmission of the previous radio link from the RLC entity, and thus may consider the PDCP SDU transmitted successfully.

If the ARQ function is configured with hop by hop, if the RLC packet is lost on any next radio link, the transmission of that packet cannot be guaranteed. For example, in the case of PDCP data recovery or PDCP resetting, packets that are recognized as being successfully transmitted are deleted so that retransmission of the corresponding packets cannot be performed and thus packets may be lost.

Specifically, a packet is normally transmitted between the terminal and the IAB node 1 so that the terminal may receive a confirmation thereof. However, the packet may not be transmitted between the IAB node 1 and the IAB node 2. Or, the packet may not be transmitted between the IAB node 2 and the donor base station. In this case, the packet transmitted by the terminal was not eventually delivered to the donor base station, but by the hop-by-hop ARQ operation, the terminal recognizes that the packet is normally transmitted.

In order to solve this problem, the present disclosure provides various embodiments for effectively providing lossless data transmission in a layer 2 based relay structure.

The embodiments disclosed below may be implemented individually or in combination with each other in part or in whole. In addition, hereinafter, for convenience of understanding, a case where the NR access to the NR terminal is relayed to the NR base station (donor base station) through NR-based wireless self-backhauling will be described. However, this is only an example for description, and each embodiment described below may be applied to a case in which LTE access for an LTE terminal is relayed to an LTE base station (donor base station) through NR-based wireless self-backhauling.

The donor base station herein refers to a radio network node (or base station or gNB or part of gNB) that terminates an interface to a core network (NG interface (eg, N2, N3 interface)). The donor base station may be physically connected to the core network or another base station through a wired / optical line. In addition, the donor base station may configure a backhaul with other NR nodes such as a base station, a CU, a DU, a core network node (AMF, UPF, etc.) using an NR radio technology. The donor base station may be composed of one CU and one or more DUs in the same manner as the NR base station. The donor base station may be replaced with various terms such as IAB-DN, DgNB, DN, and Donor base station.

Meanwhile, an integrated access and backhaul (IAB) node refers to a node that supports access to a terminal and wireless self-backhauling using NR radio technology. The IAB node may configure backhaul to other NR nodes (IAB-node-MT's next hop neighbor node) and child nodes (IAB-node-DU's next hop neighbor node) using NR radio technology. In addition, IAB nodes are not physically connected to other NR nodes via wired / optical lines. The IAB node may be replaced with various terms such as a relay node, an NR-RN, an NR relay, or an integrated node. Hereinafter, the description will be given as a relay node or an IAB node.

In addition, the Un interface represents an interface between an IAB node and an IAB node or an interface between an IAB node and a donor base station. The Un interface may be replaced with various terms such as IAB backhaul interface, U-IAB interface, Ui interface, NR Uu interface, and F1 interface.

14 is a diagram for describing a data retransmission operation of a terminal, according to an exemplary embodiment.

Referring to FIG. 14, a method in which a terminal transmits data through one or more relay nodes may include a packet data convergence protocol (PDCP) entity that provides PDCP data for AM Acknowledged Mode Data Radio Bearer (DRB) through one or more relay nodes. It may include the step of transmitting to the base station (S1400).

For example, the terminal may transmit uplink data to the donor base station through the relay node. That is, the PDCP layer delivers the PDCP PDU or SDU to the RLC entity, and the terminal transmits uplink data to the relay node associated with the terminal.

The uplink data (ex, PDCP data) is for the AM DRB, ARQ operation for transmission confirmation should be performed. For example, the PDCP entity of the terminal may transmit PDCP data for the AM DRB to the AM RLC entity to perform uplink data transmission.

In this case, the terminal may receive an acknowledgment of whether the transmission was successful according to the ARQ operation of the AM RLC entity from the relay node (eg, the DU of the relay node) that transmitted the uplink data. If the acknowledgment of the successful transmission is not received or if a response indicating the transmission failure is received, the terminal performs a retransmission operation on the corresponding packet. The retransmission operation may be performed in the AM RLC entity.

However, as described above, the relay node directly connected to the terminal through the Uu interface successfully received the terminal data, but may not be associated with the next relay node or the data may not be successfully delivered to the donor base station. In this situation, the UE has no recognizable method and cannot perform the retransmission operation. For example, the AM RLC entity performs an acknowledgment of successful transmission for a particular packet, and the PDCP entity flushes that packet. Alternatively, the packet is discarded upon expiration of the PDCP Discard timer. Therefore, the packet is lost if the packet is not successfully delivered to the donor base station.

Meanwhile, the one or more relay nodes may refer to an integrated access and backhaul (IAB) node connected to the terminal through a wireless access and connected between the relay nodes or the donor base station through a wireless backhaul.

In order to solve this problem, the present disclosure can receive retransmission indication information as follows.

The method of transmitting data through the one or more relay nodes by the terminal may include receiving retransmission indication information indicating PDCP data retransmission from the donor base station (S1410).

For example, the retransmission indication information may be included in the PDCP status report. Alternatively, the PDCP status report message itself may function as retransmission indication information. The PDCP status report can be triggered by a specific trigger event. Alternatively, unlike the existing trigger condition, the PDCP status report may be triggered to transmit periodically. That is, the PDCP status report may be transmitted periodically even if a trigger event such as PDCP data recovery or PDCP reset does not occur. The PDCP Status Report message may be triggered and sent in the PDCP entity.

As another example, the retransmission indication information may be included in a radio resource control (RRC) message. For example, the RRC message including the retransmission indication may be triggered by a trigger cause distinct from the PDCP data recovery cause and the PDCP reset cause. Alternatively, the RRC message may indicate retransmission including an information element distinguished from the PDCP data recovery cause and the PDCP reset cause. Alternatively, the RRC message may be set to be transmitted periodically.

As described above, the transmission of the retransmission indication information may be triggered by various causes. For example, the retransmission indication information may be periodically triggered transmission. As another example, the retransmission indication may be triggered when the donor base station detects a backhaul link failure for one or more relay nodes. As another example, retransmission indication information may be triggered in response to a data transmission path change event.

For a backhaul link between relay nodes or between a relay node and a donor base station, when a backhaul link failure is detected, the relay node may transmit backhaul link detection information to another relay node associated with the relay node. In addition, when the relay node detects a backhaul link failure, the relay node may transmit backhaul failure detection information to the donor base station.

The method of transmitting data through the one or more relay nodes by the terminal may include retransmitting a PDCP data protocol data unit (PDU) or service data unit (SDU) in the PDCP entity based on the retransmission indication information (S1420). .

When the retransmission indication information is received, the terminal selects and retransmits the PDCP data PDU or SDU requiring retransmission using the retransmission indication information.

For example, the retransmitted PDCP data PDUs or SDUs may include PDCP data PDUs or SDUs whose delivery has been confirmed by a Radio Link Control (RLC) entity of the UE. That is, although successful transmission is confirmed according to the ARQ operation of the RLC entity, retransmission may be performed for the PDCP data PDU or SDU for which retransmission is indicated. For example, retransmission may be made for all PDCP data PDUs or SDUs previously sent to the corresponding AM RLC entity (the card timer has not expired). For another example, retransmission may be made for all PDCP data PDUs or SDUs stored within the transmitting PDCP entity.

As another example, the retransmitted PDCP data PDU or SDU may include only PDCP data PDUs or SDUs whose delivery has not been confirmed by the PDCP status report message. In this case, retransmission indication information is indicated by the PDCP status report message. When the terminal receives the PDCP status report message, the terminal may check data not normally delivered to the donor base station by the corresponding PDCP status report information, and may retransmit only the PDCP data PDU or SDU of the corresponding data.

As another example, the retransmitted PDCP data PDU or SDU may include the entire PDCP data PDU or SDU indicated by the PDCP status report message or RRC message.

Through this operation, the terminal can perform a reliable data transmission operation without packet loss to the donor base station through a plurality of multi-hop relay node. In addition, it is possible to prevent the occurrence of packet loss that may occur when performing a hop by hop ARQ operation.

In the above, the case where the terminal transmits uplink data has been described. However, the present disclosure can also be applied to downlink data, which will be described with reference to FIG. 15.

15 illustrates a data retransmission operation of a donor base station according to an embodiment.

Referring to FIG. 15, in a method in which a donor base station transmits data through one or more relay nodes, a Packet Data Convergence Protocol (PDCP) entity may transmit PDCP data for AM DRB (Acknowledged Mode Data Radio Bearer) to one or more relay nodes. It may include transmitting to the terminal through (S1500).

For example, the donor base station may transmit downlink data to the terminal through the relay node. That is, the PDCP layer delivers the PDCP PDU or SDU to the RLC entity, and the donor base station transmits downlink data to the relay node associated with the donor base station.

The downlink data (ex, PDCP data) is for the AM DRB, the ARQ operation for transmission confirmation should be performed. For example, the PDCP entity of the donor base station may perform downlink data transmission by transferring PDCP data for the AM DRB to the AM RLC entity. As described above, when data is delivered by hop by hop in the case of a multi-hop relay, the packet may not be delivered. Therefore, the following operation is necessary to confirm this. Meanwhile, the one or more relay nodes may refer to an integrated access and backhaul (IAB) node connected to the terminal through a wireless access and connected between the relay nodes or the donor base station through a wireless backhaul.

The method of transmitting data through the one or more relay nodes by the donor base station may include receiving retransmission indication information indicating PDCP data retransmission from the terminal (S1510).

For example, the retransmission indication information may be included in the PDCP status report. Alternatively, the PDCP status report message itself may function as retransmission indication information. The PDCP status report can be triggered by a specific trigger event. Alternatively, unlike the existing trigger condition, the PDCP status report may be triggered to transmit periodically. That is, the PDCP status report may be transmitted periodically even if a trigger event such as PDCP data recovery or PDCP reset does not occur. The PDCP Status Report message may be triggered and sent in the PDCP entity.

As another example, the retransmission indication information may be included in a radio resource control (RRC) message. For example, the RRC message including the retransmission indication may be triggered by a trigger cause distinct from the PDCP data recovery cause and the PDCP reset cause. Alternatively, the RRC message may indicate retransmission including an information element distinguished from the PDCP data recovery cause and the PDCP reset cause. Alternatively, the RRC message may be set to be transmitted periodically.

As described above, the transmission of the retransmission indication information may be triggered by various causes. For example, the retransmission indication information may be periodically triggered transmission. As another example, the retransmission indication may be triggered when the donor base station detects a backhaul link failure for one or more relay nodes. As another example, retransmission indication information may be triggered in response to a data transmission path change event.

For a backhaul link between relay nodes or between a relay node and a donor base station, when a backhaul link failure is detected, the relay node may transmit backhaul link detection information to another relay node associated with the relay node. In addition, when the relay node detects a backhaul link failure, the relay node may transmit backhaul failure detection information to the donor base station.

The method of transmitting data through the one or more relay nodes by the donor base station may include retransmitting a PDCP data protocol data unit (PDU) or service data unit (SDU) in the PDCP entity based on the retransmission indication information (S1520). ).

When the retransmission indication information is received, the donor base station selects and retransmits PDCP data PDUs or SDUs requiring retransmission using the retransmission indication information.

For example, the retransmitted PDCP data PDUs or SDUs may include PDCP data PDUs or SDUs whose delivery is confirmed in a Radio Link Control (RLC) entity of the donor base station. That is, although successful transmission is confirmed according to the ARQ operation of the RLC entity, retransmission may be performed for the PDCP data PDU or SDU for which retransmission is indicated. For example, retransmission may be made for all PDCP data PDUs or SDUs previously sent to the corresponding AM RLC entity (the card timer has not expired). For another example, retransmission may be made for all PDCP data PDUs or SDUs stored within the transmitting PDCP entity.

As another example, the retransmitted PDCP data PDU or SDU may include only PDCP data PDUs or SDUs whose delivery has not been confirmed by the PDCP status report message. In this case, retransmission indication information is indicated by the PDCP status report message. When the PDCP status report message is received, the donor base station may check data not normally delivered to the terminal by the corresponding PDCP status report information, and may retransmit only PDCP data PDU or SDU of the corresponding data.

As another example, the retransmitted PDCP data PDU or SDU may include the entire PDCP data PDU or SDU indicated by the PDCP status report message or RRC message.

Through this operation, the donor base station can also perform a reliable data transmission operation without packet loss to the terminal through a plurality of multi-hop relay node. In addition, it is possible to prevent the occurrence of packet loss that may occur when performing a hop by hop ARQ operation.

Hereinafter, the above-described data retransmission operation will be described by dividing more various embodiments for each embodiment. The above-described relay non-node may be described as an IAB node, and the base station may mean a donor base station. In addition, although each embodiment is described based on downlink or uplink transmission for convenience of description, it may be applied to both uplink and downlink data transmission.

For lossless data transmission between a terminal and a donor base station through a multi-hop IAB node, the following methods may be used individually or in combination / combination.

Method for allowing UE to continuously transmit PDCP status report in PDCP entity and perform retransmission at base station

For AM DRBs that are conventionally configured to send PDCP status reports uplink by the higher layer (RRC), the PDCP entity reports the PDCP status report when it requests a PDCP object reset at the higher layer or when the upper layer requests PDCP data recovery. Had to trigger. For example, an RRC connection reconfiguration message provided (temporarily) PDCP status reporting only if the radio bearer was modified / reconfigured / changed. (For AM DRBs configured by upper layers to send a PDCP status report in the uplink, the receiving PDCP entity shall trigger a PDCP status report when:

upper layer requests a PDCP entity re-establishment;

-upper layer requests a PDCP data recovery.)

However, in the present embodiment, when a terminal is connected through an IAB node, a PDCP status report may be transmitted by a receiving PDCP entity between a terminal and a donor base station for a radio bearer requiring lossless data transmission. Based on this, data retransmission can be continued in the transmitting PDCP entity to perform lossless data transmission.

Specifically, when the terminal is connected to the donor base station through one or more IAB nodes, configures an AM RLC entity on each radio link for radio bearers requiring lossless data transmission, and an RLC ARQ operation on each radio link. Performing can cause significant delays. And confirmation of successful transmission of the corresponding radio link by the AM RLC status report in each radio link may not guarantee successful transmission of the corresponding data in the end-to-end radio link. In addition, a method of providing an ARQ end-to-end by configuring an RLC ARQ entity in a terminal and a donor base station has a problem of complicating an existing RLC protocol to distinguish and operate an RLC protocol entity.

Therefore, regardless of the configuration of the RLC entity on each radio link or to perform a simple RLC operation on each radio link, and constantly during data transmission on the PDCP entity of the terminal and the donor base station (or continuously after the radio bearer configuration) By devising and configuring a method for providing ARQ, it is possible to efficiently perform lossless data transmission. The RLC entity operation will be described later.

Regardless of the ARQ operation configuration, the donor base station can control the terminal to trigger status reporting in uplink (or in a PDCP receiving entity between the donor base station and the terminal) even when the above-described conventional trigger condition does not occur for the radio bearer. Can be. The donor base station may configure the terminal with indication information for PDCP status reporting of the terminal. The donor base station may configure one or more information elements below or an information element for a function described below or a combination thereof through the RRC connection reconfiguration message in the terminal.

Periodic status report triggering

For example, for a radio bearer for lossless data transmission connected through an IAB by a donor base station, a period for periodic PDCP status reporting (for example, PDCP status report Periodicity) may be indicated to the terminal. This may include a PDCP status reporting period value at which the UE triggers PDCP status report / reporting / PDU for the corresponding radio bearer. For example, the period information may be configured for a radio data bearer configured through the IAB.

-Triggering status reporting indication information by polling

For example, for a radio bearer for lossless data transmission connected via an IAB by a donor base station, indication information for PDCP status PDU polling may be transmitted to the terminal. For example, when a PDCP data PDU with the polling bit set to polling (eg, 1) is received, the terminal may instruct to compile and send a PDCP status report.

For another example, for a radio bearer for lossless data transmission connected via an IAB by a donor base station, information for instructing the transmitting PDCP entity of the terminal to set the polling bit in the PDCP data PDU may be indicated to the terminal. . For example, a pollPDU or pollByte value for indicating that the UE includes a poll / polbit in the PDCP PDU may be indicated for the corresponding radio bearer. pollPDU represents a parameter used by the sending PDCP entity to trigger a poll for each PDU of every pollPDU. pollByte represents a parameter used by the sending PDCP object to trigger a poll for every byte of pollByte. To this end, a terminal or donor base station on the PDCP data PDU format may include a 1-bit field for indicating polling when the PDCP status report triggers.

16 is a diagram illustrating a PDCP data PDU format according to an embodiment. For example, one of three R fields shown in FIG. 16 may be used as a field for polling. This may be configured only for the radio data bearer configured through the IAB. The method for the UE to add the polling bit to the PDCP data PDU in the transmitting PDCP entity and transmit it will be described later.

Triggering enable indication of status reporting operation by polling and / or polling (or PDCP status reporting enable / disable indication);

For example, for a radio bearer for lossless data transmission connected through an IAB by a donor base station, instructing enable (or disable) of a PDCP status reporting operation and / or a terminal polling operation according to PDCP status report polling Instruction information for the terminal may be configured. This may only be configured for radio data bearers configured via IAB.

Configuring information to instruct polling and / or send status reporting in PDCP objects

For example, the donor base station may configure the terminal with indication information for instructing the terminal to continuously send polling and / or PDCP status reporting to the radio bearer. For example, the base station may send indication information for instructing the terminal to send a PDCP status report periodically or by polling of the base station. This may be configured only for the radio data bearer configured through the IAB.

-Configure information for instructing retransmission according to receiving status reporting

For example, the donor base station, when the terminal receives PDCP status reporting for the radio bearer, information for instructing the PDCP entity of the terminal to retransmit unreceived or unreceived PDCP PDUs (or SDUs) by the donor base station. Can be configured in the terminal. For example, the retransmitted PDCP data PDUs or SDUs may include PDCP data PDUs or SDUs whose delivery is confirmed in a Radio Link Control (RLC) entity of the terminal.

This may be configured only for the radio data bearer configured through the IAB.

The terminal compiles the PDCP status report by at least one of the various methods.

For example, a lossless data transmission connected via IAB or when an indication is configured to send PDCP status reporting continuously by polling or by periodic reporting or by periodic reporting when polling is triggered. When the radio bearer is configured for, the terminal compiles the PDCP status report as follows. As another example, the PDCP status report can be triggered via an RRC message or any PDCP control PDU.

The terminal sets the FMC field to the RX_DELIVE value. Where FMC represents the first missing COUNT value (This field indicates the COUNT value of the first missing PDCP SDU within the reordering window, ie RX_DELIV.) Where RX_DELIV represents the COUNT value of the first PDCP SDU that was not delivered to the upper layer. (This state variable indicates the COUNT value of the first PDCP SDU not delivered to the upper layers, but still waited for.The initial value is 0.)

If RX_DELIV <RX_NEXT, allocate a bitmap field of the same bit length as the number of COUNTs up to and including PDCP SDUs that do not contain the first lost PDCP SDU and out of the last order. bits equal to the number of COUNTs from and not including the first missing PDCP SDU up to and including the last out-of-sequence PDCP SDUs, rounded up to the next multiple of 8, or up to and including a PDCP SDU for which the resulting PDCP Control PDU size is equal to 9000 bytes, whichever comes first)

Where RX_NEXT represents the COUNT value of the next PDCP SDU expected to be received. (This state variable indicates the COUNT value of the next PDCP SDU expected to be received.The initial value is 0.)

Set to '0' for all PDCP SDUs not received in the bitmap field. (setting in the bitmap field as '0' for all PDCP SDUs that have not been received, and optionally PDCP SDUs for which decompression have failed;)

Set to '1' for all PDCP SDUs received in the bitmap field. (setting in the bitmap field as '1' for all PDCP SDUs that have been received;)

As another example, when the PDCP data PDU with the polling bit set to polling (for example, 1) is received, the terminal compiles and transmits a PDCP status report.

As another example, a period for triggering a PDCP status report is configured, and if a timer for triggering periodic PDCP status reporting is running, the terminal stops the timer. The UE starts a timer for triggering PDCP status reporting with a period value that triggers the received PDCP status reporting.

If the timer for triggering PDCP status reporting expires, the terminal compiles and transmits a PDCP status report. The UE starts a timer for triggering PDCP status reporting with a period value that triggers a PDCP status report.

Method for transmitting by adding polling bit to PDCP data PDU in transmitting PDCP entity of UE

An embodiment of adding a polling bit to a PDCP data PDU in a transmitting PDCP entity according to the PDCP status reporting method described above will be described.

For example, for a radio bearer for lossless data transmission connected via IAB by a donor base station, or for any radio bearer requiring lossless data transmission, the transmitting PDCP entity of the terminal polls the PDCP data PDU. Information for instructing to set may be instructed to the terminal.

For example, the information indicated to the terminal may include a pollPDU or pollByte value for indicating that the terminal includes a poll / polbit in the PDCP PDU for the corresponding radio bearer. pollPDU represents a parameter used by the sending PDCP entity to trigger a poll for each PDU of every pollPDU. pollByte represents a parameter used by the sending PDCP object to trigger a poll for every byte of pollByte. To this end, the terminal or the donor base station on the PDPC data PDU format may include a 1-bit field for indicating polling when the PDCP status report triggers.

The state variables needed to set the polling bit in the transmitting PDCP entity of the terminal are PDUs without poll (PDU_WITHOUT_POLL, hereinafter referred to as PWP for convenience of explanation) and / or pollless bytes (BYTE_WITHOUT_POLL, BWP hereinafter for convenience of explanation). It is necessary to define. The PWP is a count of the number of PDUs since the most recent poll bit was transmitted, initially set to zero. The BWP is a count of the number of data bytes since the most recent poll bit was sent, and this value is initially set to zero.

When a PDCP PDU containing a PDCP SDU not previously transmitted is submitted for transmission, the following operations are performed for each PDCP PDU.

The sending PDCP entity increments the PWP by one.

The sending PDCP entity increments the BWP by every new byte of the data field element that maps to the data field of the PDCP PDU (or PDCP SDU).

-If PWP is greater than or equal to pollPDU or

-If BWP is greater than or equal to pollByte

-Include the poll in the PDCP PDU (set the poll bit to 1).

-Set the PWP to zero. Set the BWP to zero.

Method for retransmitting lost packets when receiving PDCP status report from PDCP entity of UE

In one example, for AM DRBs or for radio bearers for lossless data transmission connected via IAB by a donor base station, when a PDCP status report is received in downlink, the transmitting PDCP entity, for each PDCP SDU, If present, the bit set to "1" in the bitmap or associated COUNT value less than the value of the FMC field is considered successful. The PDCP SDU is discarded.

As another example, for a radio bearer for AM DRBs or lossless data transmission of a terminal connected via an IAB by a donor base station, when a PDCP status report is received in downlink, the transmitting PDCP entity for each PDCP SDU If present, the bit set to "0" in the bitmap is considered unsuccessful (or missing or PDCP SDU / PDU required to retransmit). The PDCP SDU is retransmitted. This may be done in ascending order of the associated COUNT value.

PDCP status reports and PDCP data retransmission by persistent or any new trigger may be provided without resetting the PDCP entity. Therefore, retransmission for the PDCP PDU may be performed instead of retransmission for the PDCP SDU.

In one example, for AM DRBs or for radio bearers for lossless data transmission connected via IAB by a donor base station, when a PDCP status report is received in downlink, the transmitting PDCP entity, for each PDCP SDU, If present, the bit set to "0" in the bitmap is considered unsuccessful (or lost or PDCP SDU / PDU required to retransmit). The PDCP PDU is then retransmitted. This may be done in ascending order of the associated COUNT value.

As another example, for a radio bearer for lossless data transmission connected to an IAB by a donor base station for an AM DRBs, when a PDCP status report is received in downlink, the transmitting PDCP entity, for each PDCP PDU, If present, the bit set to "0" in the bitmap is considered to be unsuccessful (or lost or PDCP SDU / PDU required to be retransmitted). The PDCP PDU is then retransmitted. This may be done in ascending order of the associated COUNT value.

The PDCP status report and PDCP data retransmission by persistent or any new trigger may be provided in a different way than the recovery procedure of the PDCP entity.

For example, the retransmitted PDCP data PDUs or SDUs may include PDCP data PDUs or SDUs whose delivery is confirmed by a Radio Link Control (RLC) entity of the UE. That is, although successful transmission is confirmed according to the ARQ operation of the RLC entity, retransmission may be performed for the PDCP data PDU or SDU for which retransmission is indicated. For example, retransmission may be made for all PDCP data PDUs or SDUs previously sent to the corresponding AM RLC entity (the card timer has not expired). For another example, retransmission may be made for all PDCP data PDUs or SDUs stored within the transmitting PDCP entity.

As another example, information for indicating such PDCP retransmission may be configured in the terminal through an RRC message. The retransmission indication information may indicate an information element distinguished from a conventional PDCP data recovery cause and a PDCP reset cause. As another example, the indication information for triggering such PDCP retransmission may be indicated through any PDCP control PDU separated from the PDCP status report. As another example, the indication information for triggering such PDCP retransmission may be indicated through an RRC message.

In addition, the transmission of the retransmission indication information may be triggered by various causes. For example, the retransmission indication information may be periodically triggered transmission. As another example, the retransmission indication may be triggered when the donor base station detects a backhaul link failure for one or more relay nodes. As another example, retransmission indication information may be triggered in response to a data transmission path change event.

Configure simple actions for RLC objects

When the terminal is connected to the donor base station via one or more IAB nodes, an RLC session / channel / bearer may be configured on each radio link between the terminal and the IAB node, between the IAB node and the IAB node, and between the IAB node and the donor base station. For example, RLC sessions / channels / bearers may be configured on each radio link in the various relay structures described above.

On each radio link between the terminal and the IAB node, between the IAB node and the IAB node, between the IAB node and the donor base station, the donor base station may transmit information for configuring a peering RLC entity to the terminal. Alternatively, an IAB node close to the donor base station may indicate information for configuring a peering RLC entity on another IAB node forming a radio link with the corresponding IAB node. At this time, performing the ARQ operation on each radio link as described above may be an inefficient operation.

therefore. The RLC entity may be configured to simply operate on one or more radio links of each radio link between the terminal and the IAB node, between the IAB node and the IAB node, and between the IAB node and the donor base station.

For example, a radio link may be configured as a UM RLC entity to perform a UM RLC operation on a radio link for a corresponding radio bearer. 17 illustrates a peering model of a UM RLC entity. Referring to FIG. 17, the UM RLC entity may perform simple operation in a radio link by submitting / receiving RLC PDUs through a DL DTCH or UL DTCH logical channel and performing only segmentation operation when necessary without an ARQ operation.

As another example, information for instructing the radio bearer to disable ARQ operation for the AM RLC entity on the radio link may be configured. This allows the transmitting side of an AM RLC entity not to perform retransmission of RLC SDUs or RLC SDU segments. And / or through this, the receiving side of an AM RLC entity may not trigger a status report.

As another example, the radio bearer may be configured not to indicate to the upper layer an acknowledgment message for successful transmission on the radio link.

As described above, according to the present disclosure, when a terminal is connected to a donor base station through a multi-hop relay node, data of a radio bearer requiring lossless data transmission can be effectively transmitted and received.

Meanwhile, an embodiment of a processing method when a radio link failure occurs in the above-described multi-hop relay structure will be described.

As described above, in case of the hop-by-hop ARQ operation, the corresponding packet may be lost in case of PDCP data recovery or PDCP reset. In addition, in the structure shown in FIG. 9, an ARQ may be provided end-to-end by configuring an RLC ARQ entity between the UE and the donor base station. However, there is a problem in that an RLC protocol entity must be separately configured in such a structure. In particular, when the terminal reaches the maximum number of retransmissions in the end-to-end RLC entity in the structure as shown in FIG. 9, service interruption is detected by detecting a radio link failure and transitioning to an RRC IDLE state or executing an RRC Connection Re-establishment procedure accordingly. Can be generated.

However, even when the maximum number of retransmissions is reached in the end-to-end RLC entity of the terminal and the donor base station, the radio state between the radio link between the terminal and the first hop IAB node may be stable. Therefore, in this case, changing the state of the terminal to the RRC Idle state, or performing the RRC connection reset operation will cause unnecessary operation of the terminal.

Radio link failure in the prior art (LTE)

The UE in the RRC connection state detects RLF (Radio Link Failure) in the following cases.

-Radio link failure detection from physical layer

 Upon receiving N310 consecutive "out-of-sync" indications for the PCell from lower layers while neither T300, T301, T304 nor T311 is running: UE start T310), if the timer expires, detect radio link failure]

(Upon triggering a measurement report for a measurement identity for which T312 has been configured, while T310 is running), when the T312 started receiving N311 consecutive in-sync indications from the lower layer, etc. Upon receiving N311 consecutive in-sync indications from lower layers, upon triggering the handover procedure, upon initiating the connection re-establishment procedure, and upon the expiry of T310)

-Random access problem indication from MCG MAC while neither T300, T301, T304 nor T311 is running

-Up indication from MCG RLC that the maximum number of retransmissions has been reached for an SRB in the RLC layer (e.g., from MCG RLC to SRB or MCG DRB or split DRB) or for an MCG or split DRB)]

The terminal detects / considers a radio link failure for the MCG. When the terminal detects the RLF, the RLF information is stored in the VarRLF-Report. If AS security is not activated, the terminal leaves the RRC Connected state. That is, move to RRC IDLE state. Otherwise, if AS security is activated, perform the RRC Connection Re-establishment procedure.

Therefore, in a structure in which the UE and the donor base station configure an RLC ARQ entity and provide ARQ to end-to-end, when the UE follows the conventional radio link failure detection and recovery operation, the UE transitions to the RRC IDLE state or executes the RRC Connection Re-establishment procedure. There was a problem that caused the interruption. In order to solve this problem, the present disclosure provides a method and apparatus for effectively handling an RLC retransmission failure.

Hereinafter, operations of a terminal and a donor base station for solving a problem caused by radio link failure detection in a multi-hop relay structure will be described. For convenience of description, a description will be given based on a structure for performing an ARQ operation in end-to-end by configuring an RLC ARQ entity between the UE and the donor base station of FIG.

First embodiment: a method of configuring an RLC retransmission count to an infinite value

For example, the donor base station may instruct the terminal to information for configuring an RLC entity peered to the RLC entity of the donor base station. Alternatively, the IAB node close to the donor base station may instruct the terminal to information for configuring an RLC entity peered with the corresponding IAB node.

18 is a diagram illustrating AM RLC configuration information according to an embodiment.

Referring to FIG. 18, the conventional uplink AM RLC configuration information may be configured as shown in FIG. 18. The corresponding AM RLC configuration information may be indicated to the terminal. maxRetxThreshold represents the maximum retransmission threshold of the RLC. In the prior art, a value from 1 to 32 was applicable. Therefore, it is possible to change the maximum retransmission threshold so that no radio link failure occurs.

For example, if the maximum retransmission threshold can be set to an infinite value, the terminal may not detect a radio link failure in the corresponding RLC entity. As a result, it is not necessary to perform an inefficient operation that is caused later. Problems on each radio link can be solved by other alternatives, such as RLF detection at the physical layer of the radio link. Alternatively, if a problem is found on each radio link, the connection can be resumed, for example, with relay path switching.

As another example, the current maximum retransmission threshold is not a value that can be selectively configured, but is a value that must be configured in the terminal. If the information element is changed to a configurable value selectively and the information element is not configured, the radio link failure may not be detected.

Second Embodiment: The upper layer (RRC) transmits an RRC message including a cause thereof to the donor base station without resetting the RRC connection in the RRC connected state.

For example, when the maximum retransmission threshold is reached in the terminal RLC entity peered to the RLC entity of the donor base station, the terminal RLC entity delivers it to the RRC layer. For example, if the retransmission count is equal to the maximum retransmission threshold value (maxRetxThreshold), the terminal RLC entity indicates that the maximum retransmission has been reached to the higher layer (RRC).

As another example, when the maximum retransmission threshold is reached in the terminal RLC entity peered to the RLC entity of the IAB node close to the donor base station, the terminal RLC entity forwards it to the RRC layer. For example, the terminal RLC entity indicates that the maximum retransmission has been reached to the higher layer (RRC) if the retransmission count is equal to the maximum retransmission threshold value (maxRetxThreshold).

The RRC entity may allow the RRC connection to transmit / report an RRC message including cause information to the donor base station without resetting the RRC connection.

The RRC message may be transmitted through an SCG failure information message or a UL Information transfer message or a UE Information message or any uplink RRC message.

The cause information included in this case indicates new failure cause type information that is distinguished from existing wireless failure cause types. For example, the conventional radio failure type includes information indicating failure due to reaching a maximum number of retransmissions on a logical channel mapped to SCell for CA redundant transmission (for example, SCell-RLF) and information indicating a radio link failure of a secondary cell group ( For example, SCG-RLF), information to initiate transmission of SCG failure information messages (e.g. scg-ChangeFailure) to provide reconfiguration with synchronous failure information for the secondary cell group, SCG failure due to SRB3 IP check failurefh Information for initiating transmission of the information message (for example, srb3-IntegrityFailure), information for initiating transmission of the SCG failure information message due to SCG reconfiguration failure (for example, scg-reconfigFailure), and the like.

The radio link failure cause type according to the present embodiment may have a value of a newly defined cause type distinguished from the existing cause type. This allows the operator to identify those failures and pinpoint exactly what caused the failure.

The above-described RRC message transmitted to the donor base station by the terminal may include additional information on the IAB connection in addition to the above-described cause information. Alternatively, when the terminal detects the aforementioned failure, the terminal may store additional information regarding the corresponding radio link failure in the VarRLF-Report information. Then, the VarRLF-Report information may be transmitted to the base station through a normal RRC procedure (for example, UE information response message) to the base station.

The additional information described above may include IAB node path information, IAB donor address, IAB node address, root ID, IAB node identifier information, cell identifier information provided by the IAB node, measurement results in the last serving cell including RSRP and RSRQ, and corresponding radio. It may include one or more of bearer identifier information and IAB node path information of the radio bearer. For example, the IAB node path information is information to identify when there are multiple paths for data transfer with the IAB node between the IAB node and the IAB donor base station (or between the source IAB node and the destination IAB node). Included in the header may be used to distinguish the path when transmitting data to the destination IAB node or IAB donor base station.

The additional information may be included and stored in the VarRLF report even when performing the RLF operation as in the conventional operation. For example, any IAB node may include that additional information when it detects an RLF.

Third embodiment: Suspension for radio bearer in which radio link failure is detected

For example, when the maximum retransmission threshold is reached in the terminal RLC entity peered to the RLC entity of the donor base station, the terminal RLC entity delivers it to the RRC layer. For example, if the retransmission count is equal to the maximum retransmission threshold value (maxRetxThreshold), the terminal RLC entity indicates that the maximum retransmission has been reached to the higher layer (RRC).

As another example, when the maximum retransmission threshold is reached in the terminal RLC entity peered to the RLC entity of the IAB node close to the donor base station, the terminal RLC entity delivers it to the RRC layer. For example, if the retransmission count is equal to the maximum retransmission threshold value (maxRetxThreshold), the terminal RLC entity indicates that the maximum retransmission has been reached to the higher layer (RRC).

Upon receiving the above-mentioned indication from the terminal RLC entity, the RRC entity suspends the radio bearer. Alternatively, the RRC entity suspends all SRB (s) and DRB (s) provided through the cell / cell group of the corresponding IAB node except SRB0.

Fourth Embodiment: Delivering Indication Information on a Cause of Radio Link Failure to an Adjacent IAB Node (Child Node or Parent Node)

Here, the adjacent IAB node means a node located within a predetermined number of hops with a specific IAB node.

For example, when the maximum retransmission threshold is reached in the terminal RLC entity peered to the RLC entity of the donor base station, the terminal RLC entity delivers it to the RRC layer. For example, if the retransmission count is equal to the maximum retransmission threshold value (maxRetxThreshold), the terminal RLC entity indicates that the maximum retransmission has been reached to the higher layer (RRC).

As another example, when the maximum retransmission threshold is reached in the terminal RLC entity peered to the RLC entity of the IAB node (child node of the donor base station) close to the donor base station, the terminal RLC entity forwards it to the RRC. For example, the UE RLC entity If the retransmission count is equal to the maximum retransmission threshold value (maxRetxThreshold), it indicates that the maximum retransmission has been reached to the higher layer (RRC).

As another example, when the maximum retransmission threshold is reached in the RLC entity of any IAB node (e.g. IAB node MT), the RLC entity forwards it to the RRC. For example, the RLC entity If the retransmission count is equal to the maximum retransmission threshold value (maxRetxThreshold), it indicates that the maximum retransmission has been reached to the upper layer (RRC).

The terminal may wish to inform the IAB node (the IAB node receiving the terminal) that is wirelessly connected to the first hop that there is a problem on any radio link connected between the terminal and the donor base station. Or, it may want to inform the adjacent IAB node (child node or parent node) that there is a problem on the backhaul radio link associated with the IAB node. This allows the IAB node of the first hop adjacent to itself to resolve problems on the radio link with the IAB node of the next hop or to attempt to connect to the donor base station via another path. Alternatively, an IAB node of an adjacent first hop can be delivered to the IAB node of the next hop even if there is no problem on the radio link with the IAB node of the next hop. Through this, even if the terminal or the IAB node MT detects the RLF, the problem can be resolved by checking the path for each hop and changing the path. Therefore, the unnecessary terminal or the IAB node MT may not enter the RRC IDLE state or the RRC connection resetting operation. For example, such a problem may not occur when the dual connectivity-based multipath is set between the terminal and the donor base station. In another example, when a dual connectivity-based multipath is established between an IAB node and a donor base station, this problem may not occur.

Thus, it is necessary to transmit control information for indicating this between the UE and the IAB node of the first radio hop or between the IAB node and the IAB node of the next radio hop or between the IAB node and the IAB donor base station of the next radio hop.

In this case, the information may be transmitted through one of the following methods.

1) Transmission via MAC CE

The terminal, the IAB node, and the IAB donor base station all have MAC entities. Therefore, the control information can be delivered to the next hop in the corresponding radio link through the MAC control element. A node that receives the MAC CE by allocating an LCID for this may transmit it to the RRC. The RRC may trigger a path change to the donor base station. The MAC CE may include one or more of the above-described cause information and additional information. The MAC CE may be transmitted through a secondary path in which no RLF is generated.

2) Transmission via RLC control PDU

The terminal, the IAB node, and the IAB donor base station all have RLC entities. Therefore, the control information can be delivered to the next hop in the corresponding radio link through the RLC Control PDU. An IAB node that receives a corresponding RLC control PDU by assigning a Control PDU Type (CPT) field value for this may transmit it to the RRC. The RRC may trigger a path change to the donor base station. The RLC control PDU may include one or more of the above-described cause information and additional information. The RLC control PDU may be transmitted through a secondary path in which no RLF is generated.

3) Transmission via Adaptation control PDU

Both the IAB node and the IAB donor base station have adaptation objects. Therefore, the control information can be delivered to the next hop in the corresponding radio link through the adaptation control PDU. A node that receives a corresponding adaptation control PDU by assigning a Control PDU Type (CPT) field value for this may transmit it to the RRC. The RRC may trigger a path change to the donor base station. The adaptation control PDU may include one or more of the above-described cause information and additional information. The adaptation control PDU may be transmitted through a secondary path in which no RLF is generated.

As described above, the present disclosure provides an effect that when the terminal is configured through a multi-hop relay, the terminal can efficiently handle the occurrence of the RLC failure to transmit and receive data.

The configuration of the terminal and the donor base station capable of performing all or selectively each of the above-described embodiments will be briefly described again.

19 is a block diagram illustrating a terminal configuration according to an embodiment.

Referring to FIG. 19, a terminal 1900 for transmitting data through one or more relay nodes may include a packet data convergence protocol (PDCP) entity that transmits PDCP data for an AM Acknowledged Mode Data Radio Bearer (DRDR) to one or more relay nodes. The PDCP data protocol data unit (PDU) or SDU in the PDCP entity based on the transmitter 1920 transmitting the donor base station through the donor base station, the receiver 1930 receiving the retransmission indication information indicating the retransmission of the PDCP data from the donor base station, and the retransmission indication information. It may include a control unit 1910 for controlling to retransmit (Service Data Unit).

For example, the transmitter 1920 may transmit uplink data to the donor base station through the relay node. That is, the PDCP layer delivers the PDCP PDU or SDU to the RLC entity, and the transmitter 1920 transmits uplink data to the relay node associated with the terminal.

The uplink data (ex, PDCP data) is for the AM DRB, ARQ operation for transmission confirmation should be performed. For example, the PDCP entity of the terminal 1900 may perform uplink data transmission by transferring PDCP data for the AM DRB to the AM RLC entity.

One or more relay nodes may refer to an integrated access and backhaul (IAB) node connected to the terminal 1900 through wireless access and connected between relay nodes or a donor base station through a wireless backhaul.

For example, the retransmission indication information may be included in the PDCP status report. Alternatively, the PDCP status report message itself may function as retransmission indication information. The PDCP status report can be triggered by a specific trigger event. Alternatively, unlike the existing trigger condition, the PDCP status report may be triggered to transmit periodically. That is, the PDCP status report may be transmitted periodically even if a trigger event such as PDCP data recovery or PDCP reset does not occur. The PDCP Status Report message may be triggered and sent in the PDCP entity.

As another example, the retransmission indication information may be included in a radio resource control (RRC) message. For example, the RRC message including the retransmission indication may be triggered by a trigger cause distinct from the PDCP data recovery cause and the PDCP reset cause. That is, the RRC message may be set to be transmitted periodically.

As described above, the transmission of the retransmission indication information may be triggered by various causes. For example, the retransmission indication information may be periodically triggered transmission. As another example, the retransmission indication may be triggered when the donor base station detects a backhaul link failure for one or more relay nodes. As another example, retransmission indication information may be triggered in response to a data transmission path change event.

For a backhaul link between relay nodes or between a relay node and a donor base station, when a backhaul link failure is detected, the relay node may transmit backhaul link detection information to another relay node associated with the relay node. In addition, when the relay node detects a backhaul link failure, the relay node may transmit backhaul failure detection information to the donor base station.

When the retransmission instruction information is received, the transmitter 1920 selects and retransmits PDCP data PDUs or SDUs requiring retransmission using the retransmission instruction information.

For example, the retransmitted PDCP data PDUs or SDUs may include PDCP data PDUs or SDUs whose delivery has been confirmed by a Radio Link Control (RLC) entity of the UE. That is, although successful transmission is confirmed according to the ARQ operation of the RLC entity, retransmission may be performed for the PDCP data PDU or SDU for which retransmission is indicated.

As another example, the retransmitted PDCP data PDU or SDU may include only PDCP data PDUs or SDUs whose delivery has not been confirmed by the PDCP status report message. In this case, retransmission indication information is indicated by the PDCP status report message. When the PDCP status report message is received, the controller 1910 may check data not normally delivered to the donor base station by the corresponding PDCP status report information, and control to retransmit only the PDCP data PDU or SDU of the corresponding data.

As another example, the retransmitted PDCP data PDU or SDU may include the entire PDCP data PDU or SDU indicated by the PDCP status report message or RRC message.

In addition, the controller 1910 controls the overall operation of the terminal 1900 according to the above-described retransmission operation and RLF detection and processing operation of the PDCP data PDU or SDU according to the present disclosure.

The transmitter 1920 and the receiver 1930 are used to transmit and receive a signal, a message, and data necessary for performing the above-described embodiment with a donor base station, a relay node, or another terminal.

20 is a block diagram illustrating a donor base station configuration according to an embodiment.

Referring to FIG. 20, a donor base station 2000 that transmits data through one or more relay nodes may include one or more relay nodes for PDCP data for an AM DRB (Acknowledged Mode Data Radio Bearer) by a Packet Data Convergence Protocol (PDCP) entity. A PDCP data protocol data unit (PDU) or SDU (PDDU) in the PDCP entity based on the transmitter 2020 for transmitting to the terminal through the receiver 2020 and the receiver 2030 for receiving retransmission instruction information indicating retransmission of the PDCP data from the terminal and the retransmission instruction information; And a control unit 2010 for controlling retransmission of the service data unit.

For example, the transmitter 2020 may transmit downlink data to the terminal through the relay node. That is, the PDCP layer delivers the PDCP PDU or SDU to the RLC entity, and the transmitter 2020 transmits downlink data to the relay node associated with the donor base station.

The downlink data (ex, PDCP data) is for the AM DRB, the ARQ operation for transmission confirmation should be performed. For example, the donor base station 2000 may transmit the downlink data by transmitting the PDCP data for the AM DRB to the AM RLC entity. As described above, when data is delivered by hop by hop in the case of a multi-hop relay, the packet may not be delivered. Therefore, the following operation is necessary to confirm this. Meanwhile, the one or more relay nodes may refer to an integrated access and backhaul (IAB) node that is connected to the terminal through a wireless access and is connected between the relay nodes or the donor base station 2000 with a wireless backhaul.

For example, the retransmission indication information may be included in the PDCP status report. Alternatively, the PDCP status report message itself may function as retransmission indication information. The PDCP status report can be triggered by a specific trigger event. Alternatively, unlike the existing trigger condition, the PDCP status report may be triggered to transmit periodically. That is, the PDCP status report may be transmitted periodically even if a trigger event such as PDCP data recovery or PDCP reset does not occur. The PDCP Status Report message may be triggered and sent in the PDCP entity.

As another example, the retransmission indication information may be included in a radio resource control (RRC) message. For example, the RRC message including the retransmission indication may be triggered by a trigger cause distinct from the PDCP data recovery cause and the PDCP reset cause. That is, the RRC message may be set to be transmitted periodically.

As described above, the transmission of the retransmission indication information may be triggered by various causes. For example, the retransmission indication information may be periodically triggered transmission. As another example, the retransmission indication information may be triggered when the control unit 2010 detects a backhaul link failure for one or more relay nodes. As another example, retransmission indication information may be triggered in response to a data transmission path change event.

With respect to the backhaul link between the relay nodes or between the relay node and the donor base station 2000, when the backhaul link is detected, the relay node may transmit backhaul link detection information to another relay node associated with the relay node. In addition, when the relay node detects a backhaul link failure, the relay node may transmit backhaul link detection information to the donor base station 2000.

When the retransmission indication information is received, the controller 2010 may control to retransmit the PDCP data PDU or SDU that needs retransmission by using the retransmission indication information.

For example, the retransmitted PDCP data PDUs or SDUs may include PDCP data PDUs or SDUs that are confirmed to be delivered in a Radio Link Control (RLC) entity of the donor base station 2000. That is, although successful transmission is confirmed according to the ARQ operation of the RLC entity, retransmission may be performed for the PDCP data PDU or SDU for which retransmission is indicated.

As another example, the retransmitted PDCP data PDU or SDU may include only PDCP data PDUs or SDUs whose delivery has not been confirmed by the PDCP status report message. In this case, retransmission indication information is indicated by the PDCP status report message. When the PDCP status report message is received, the controller 2010 may check data not normally delivered to the terminal by the corresponding PDCP status report information, and control to retransmit only PDCP data PDU or SDU of the corresponding data.

As another example, the retransmitted PDCP data PDU or SDU may include the entire PDCP data PDU or SDU indicated by the PDCP status report message or RRC message.

In addition, the control unit 2000 controls the overall operation of the donor base station 2000 according to the retransmission operation of the PDCP data PDU or SDU and the RLF detection and the processing operation according to the aforementioned disclosure.

The transmitter 2020 and the receiver 2030 are used to transmit and receive signals, messages, and data necessary for performing the above-described embodiment with a terminal, a relay node, or another base station.

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, components, and parts which are not described in order to clearly reveal the present technical spirit of the embodiments may be supported by the aforementioned standard documents. In addition, all terms disclosed herein may be described by the standard documents disclosed above.

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

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

In the case of an implementation by firmware or software, the method according to the embodiments may be implemented in the form of an apparatus, procedure, or function for performing the functions or operations described above. The software code may be stored in a memory unit and driven by a processor. The memory unit may be located inside or outside the processor, and may exchange data with the processor by various known means.

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

The above description is merely illustrative of the technical idea of the present disclosure, and various modifications and variations may be made by those skilled in the art without departing from the essential characteristics of the present disclosure. In addition, the present embodiments are not intended to limit the technical spirit of the present disclosure but to describe the scope of the present inventive concept. The protection scope of the present disclosure should be interpreted by the following claims, and all technical ideas within the scope equivalent thereto shall be interpreted as being included in the scope of the present disclosure.

CROSS-REFERENCE TO RELATED APPLICATION

This patent application is filed with Korea Patent Application No. 10-2018-0051283 filed on May 03, 2018 and Korea Patent Application No. 10-2018-0051286 filed on May 03, 2018 and April 2019 Priority is claimed to Korean Patent Application No. 10-2019-0050268 filed with Korea on the 30th in accordance with US Patent Law Article 119 (a) (35 USC § 119 (a)), all of which are hereby incorporated by reference. Incorporated into the application. In addition, if this patent application claims priority for the same reason for countries other than the United States, all its contents are incorporated into this patent application by reference.

Claims (19)

In the method for the terminal to transmit data through one or more relay nodes, A Packet Data Convergence Protocol (PDCP) entity transmitting PDCP data for AM Acknowledged Mode Data Radio Bearer (DRB) to the donor base station through one or more relay nodes; Receiving retransmission indication information indicative of retransmission of PDCP data from the donor base station; And Retransmitting a PDCP data protocol data unit (PDU) or service data unit (SDU) in the PDCP entity based on the retransmission indication information. The method of claim 1, The one or more relay nodes, And an integrated access and backhaul (IAB) node connected to the terminal through wireless access and connected to the relay node or to a wireless backhaul with the donor base station. The method of claim 1, The PDCP data PDU or SDU to be retransmitted, And a PDCP data PDU or SDU whose delivery is confirmed in a Radio Link Control (RLC) entity of the terminal. The method of claim 1, The retransmission instruction information, Method included in the PDCP status report message or RRC (Radio Resource Control) message. The method of claim 4, wherein The PDCP data PDU or SDU to be retransmitted, And only PDCP data PDUs or SDUs whose delivery has not been confirmed by the PDCP status report message. The method of claim 4, wherein The RRC message is, Wherein the transmission is triggered by a trigger cause distinct from the PDCP data recovery cause and the PDCP reset cause. The method of claim 1, The retransmission instruction information, Wherein the donor base station detects a backhaul link failure for the one or more relay nodes or triggers a data transfer path change event. The method of claim 7, wherein The relay node, Detecting backhaul link failure, forwarding the backhaul link detection information to the donor base station or the one or more relay nodes. In the method that the donor base station transmits data through one or more relay nodes, Transmitting, by a Packet Data Convergence Protocol (PDCP) entity, PDCP data for an AM Acknowledged Mode Data Radio Bearer (DRB) to a terminal through at least one relay node; Receiving retransmission indication information indicating PDCP data retransmission from the terminal; And Retransmitting a PDCP data protocol data unit (PDU) or service data unit (SDU) in the PDCP entity based on the retransmission indication information. The method of claim 9, The PDCP data PDU or SDU to be retransmitted, And a PDCP data PDU or SDU whose delivery has been confirmed in a Radio Link Control (RLC) entity of the donor base station. The method of claim 9, The retransmission instruction information, Method included in the PDCP status report message or RRC (Radio Resource Control) message. The method of claim 11, The RRC message is, Wherein the transmission is triggered by a trigger cause distinct from the PDCP data recovery cause and the PDCP reset cause. In the terminal for transmitting data through one or more relay nodes, A transmitter for transmitting, by a Packet Data Convergence Protocol (PDCP) entity, PDCP data for an AM Acknowledged Mode Data Radio Bearer (DRB) to a donor base station through one or more relay nodes; A receiving unit for receiving retransmission indication information indicating retransmission of PDCP data from the donor base station; And And a control unit controlling to retransmit a PDCP data PDU or a service data unit (SDU) in the PDCP entity based on the retransmission indication information. The method of claim 13, The PDCP data PDU or SDU to be retransmitted, And a PDCP data PDU or SDU whose delivery is confirmed by a Radio Link Control (RLC) entity of the terminal. The method of claim 13, The retransmission instruction information, Terminal included in the PDCP status report message or RRC (Radio Resource Control) message. The method of claim 15, The PDCP data PDU or SDU to be retransmitted, And only PDCP data PDUs or SDUs whose delivery has not been confirmed by the PDCP status report message. The method of claim 15, The RRC message is, And the transmission is triggered by a trigger cause distinct from the PDCP data recovery cause and the PDCP reset cause. The method of claim 13, The retransmission instruction information, The donor base station is characterized in that the transmission is triggered by detecting a backhaul link failure for the one or more relay nodes or the occurrence of a data transmission path change event. The method of claim 18, The relay node, And detecting the backhaul link failure, transmitting the backhaul failure detection information to the donor base station or the one or more relay nodes.

Images