KR20200035609A - Method and apparatus for performing iab in a wireless communication system - Google Patents

Abstract

The present invention may provide a method of a terminal for performing integrated access and backhaul (IAB) in a wireless communication system. The method for performing IAB may comprise the steps of: receiving a downlink delivery status report; starting a wait timer for information gathering; and stopping the wait timer and gathering information. According to the present invention, in a wireless communication system, a terminal can perform communication through an IAB node.

Description

Method and apparatus for performing IAB in wireless communication system {METHOD AND APPARATUS FOR PERFORMING IAB IN A WIRELESS COMMUNICATION SYSTEM}

The present invention relates to a method and apparatus for performing Integrated Access and Backhaul (IAB) in a wireless communication system.

The International Telecommunication Union (ITU) is developing the International Mobile Telecommunication (IMT) framework and standards, and is currently in the process of discussing 5G (5G) communication through a program called "IMT for 2020 and beyond." .

In order to meet the requirements presented by "IMT for 2020 and beyond," the 3rd Generation Partnership Project (3GPP) New Radio (NR) system takes into account various scenarios, service requirements, potential system compatibility, etc., and time-frequency It is discussed in the direction of supporting various numerology of resource unit standards.

The present invention can provide a method and apparatus for performing communication through an IAB node in a wireless communication system.

The present invention can provide a method and apparatus for preventing the downlink buffer overflow of an IAB node in a wireless communication system.

The present invention can provide a method and apparatus for solving a downlink congestion problem of an IAB node in a wireless communication system.

The present invention can provide a method of performing IAB (Integrated Access and Backhaul). At this time, the method of performing the IAB may include receiving a downlink delivery status report, starting a standby timer for information collection, stopping a standby timer, and collecting information.

According to the present invention, in a wireless communication system, a terminal can perform communication through an IAB node.

According to the present invention, it is possible to prevent the downlink buffer overflow of the IAB node in the wireless communication system.

According to the present invention, it is possible to solve the downlink congestion problem of the IAB node in the wireless communication system.

The effects obtainable in the present disclosure are not limited to the above-mentioned effects, and other effects not mentioned may be clearly understood by those skilled in the art from the following description. will be.

1 is a view showing a wireless communication system to which the present invention is applied.
2 shows a structure considered in the IAB according to an example.
3 is a diagram showing various IAB node configurations.
4 shows a structure considered by IAB according to another example.
5 shows a communication structure considering an adaptation layer.
6 shows a structure supporting one-to-one bearer mapping.
7 shows a structure for supporting QoS bearer mapping.
8 is a diagram showing an ARQ mode.
9 may be a method for performing hop-by-hop flow control.
10 is a diagram showing the configuration of an adaptation header.
11 is a diagram showing the configuration of a STATUS PDU.
12 is a diagram showing the configuration of MAC CE.
13 is a diagram illustrating a method of expressing a downlink delivery state.
14 is a diagram showing another method of expressing a downlink delivery state.
15 is a flowchart illustrating an example of an operation of performing a downlink delivery status report of an IAB node according to the present disclosure.
16 may be a method for performing end-to-end flow control.
17 is a diagram showing the configuration of an adaptation header.
18 is a diagram showing the configuration of a STATUS PDU.
19 is a diagram illustrating a method of expressing a downlink delivery state.
20 is a diagram showing another method of expressing a downlink delivery state.
21 is a diagram for explaining end-to-end flow control.
22 is a flowchart illustrating an example of an operation for performing a downlink delivery status report of an IAB node according to the present disclosure.
23 is a view showing the configuration of an IAB donor and an IAB node device according to the present disclosure.

Hereinafter, exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings so that those skilled in the art to which the present disclosure pertains can easily carry out the embodiments. However, the present disclosure can be implemented in many different forms and is not limited to the embodiments described herein.

In describing the embodiments of the present disclosure, when it is determined that a detailed description of a known configuration or function may obscure the subject matter of the present disclosure, detailed description thereof will be omitted. In the drawings, parts irrelevant to the description of the present disclosure are omitted, and similar reference numerals are used for similar parts.

In the present disclosure, when a component is said to be "connected", "coupled" or "connected" with another component, this is not only a direct connection relationship, but also an indirect connection relationship in which another component exists in the middle It may also include. Also, when a component is said to "include" or "have" another component, this means that other components may be further included instead of excluding other components unless specifically stated to the contrary. .

In the present disclosure, terms such as first and second are used only for the purpose of distinguishing one component from other components, and do not limit the order or importance of components, etc., unless otherwise specified. Accordingly, within the scope of the present disclosure, the first component in one embodiment may be referred to as a second component in another embodiment, and likewise the second component in one embodiment may be the first component in another embodiment It can also be called.

In the present disclosure, the components that are distinguished from each other are for clarifying each feature, and the components are not necessarily separated. That is, a plurality of components may be integrated to be composed of one hardware or software unit, or one component may be distributed to be composed of a plurality of hardware or software units. Accordingly, such integrated or distributed embodiments are included within the scope of the present disclosure, unless otherwise stated.

In the present disclosure, components described in various embodiments are not necessarily essential components, and some may be optional components. Accordingly, an embodiment comprised of a subset of components described in one embodiment is also included in the scope of the present disclosure. Also, embodiments that include other elements in addition to the elements described in various embodiments are included in the scope of the present disclosure.

In addition, this specification is described for a wireless communication network, the work performed in the wireless communication network is performed in the process of controlling the network and transmitting data in a system (for example, a base station) in charge of the wireless communication network, or the wireless The operation can be performed at the terminal coupled to the network.

That is, it is apparent that various operations performed for communication with a terminal in a network composed of a plurality of network nodes including a base station can be performed by a base station or other network nodes other than the base station. 'Base Station (BS)' may be replaced by terms such as a fixed station, a Node B, an eNodeB (eNB), a gNodeB (gNB), an ng-eNB, or an access point (AP). . Also, 'terminal' may be replaced with terms such as user equipment (UE), mobile station (MS), mobile subscriber station (MSS), subscriber station (SS), and non-AP STA (non-AP STA). You can.

In the present disclosure, transmitting or receiving a channel includes transmitting or receiving information or a signal through the corresponding channel. For example, transmitting a control channel means transmitting control information or a signal through the control channel. Similarly, transmitting a data channel means transmitting data information or a signal through the data channel.

1 is a view showing a wireless communication system to which the present invention is applied.

The network structure illustrated in FIG. 1 may be a network structure of Evolved-Universal Mobile Telecommunications System (E-UMTS). The E-UMTS system may include a Long Term Evolution (LTE), an Advanced (LTE-A) system, or may include a fifth generation mobile communication network, a new radio (NR), and the like.

Referring to FIG. 1, a base station (BS) and a user equipment (UE) 12 in a wireless communication system 10 may wirelessly transmit and receive data. In the wireless communication system 10, the base station 11 may provide a communication service to a terminal existing in the coverage of the base station through a specific frequency band. Coverage serviced by a base station can also be expressed in terms of a site. A site may include a number of areas 15a, 15b, 15c, which may be called sectors. Each sector included in the site may be identified based on different identifiers. Each sector 15a, 15b, 15c may be interpreted as a partial area covered by the base station 11.

The base station 11 generally refers to a station communicating with the terminal 12, evolved-NodeB (eNodeB), Base Transceiver System (BTS), access point, femto base station (Femto eNodeB), home Base station (HeNodeB: Home eNodeB), relay (relay), remote radio head (RRH: Remote Radio Head) can be called in other terms.

The terminal 12 may be fixed or mobile, and a mobile station (MS), a mobile terminal (MT), a user terminal (UT), a subscriber station (SS), a wireless device (PDA), a personal digital assistant (PDA) , Wireless modem, and handheld device.

In addition, the base station 11 may be called in various terms such as megacell, macrocell, microcell, picocell, femtocell according to the size of the coverage provided by the base station. The cell may be used as a term indicating a frequency band provided by a base station, coverage of the base station, or base station.

Hereinafter, a downlink (DL) means a communication or communication path from the base station 11 to the terminal 12, and an uplink (UL) communicates from the terminal 12 to the base station 11 or It means the communication path. In the downlink, the transmitter may be part of the base station 11, and the receiver may be part of the terminal 12. In the uplink, the transmitter may be part of the terminal 12 and the receiver may be part of the base station 11.

Meanwhile, there are no restrictions on the multiple access technique applied to the wireless communication system 10. For example, Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiple Access (OFDMA), Single Carrier-FDMA (SC-FDMA), OFDM-FDMA , OFDM-TDMA, OFDM-CDMA can be used in a variety of multiple access techniques. In addition, a time division duplex (TDD) method transmitted using different times or a frequency division duplex (FDD) method transmitted using different frequencies may be used for uplink transmission and downlink transmission.

In the present disclosure, transmitting or receiving a channel includes transmitting or receiving information or a signal through the corresponding channel. For example, transmitting a control channel means transmitting control information or a signal through the control channel. Similarly, transmitting a data channel means transmitting data information or a signal through the data channel.

In the following description, the term NR system is used for the purpose of distinguishing a system to which various examples of the present disclosure are applied from an existing system, but the scope of the present disclosure is not limited by these terms.

For example, the NR system supports various subcarrier spacing (SCS) considering various scenarios, service requirements, and potential system compatibility. In addition, NR systems are designed to overcome poor channel environments such as high path-loss, phase-noise and frequency offset occurring on a high carrier frequency. It can support the transmission of the physical signal / channel through the beam of. Through this, the NR system can support applications such as enhanced Mobile Broadband (eMBB), Massive Machine Type Communications (mMTC) / ultra Machine Type Communications (uMTC), and Ultra Reliable and Low Latency Communications (URLLC). However, although the term NR system in this specification is used as an example of a wireless communication system, the term NR system itself is not limited to the above-described features.

In addition, as an example, 5G mobile communication technology may be defined. In this case, as an example, 5G mobile communication technology may be defined to include not only the above-described NR system, but also an existing Long Term Evolution-Advanced (LTE-A) system. That is, 5G mobile communication may be a technology that operates in consideration of backward compatibility with a previous system as well as a newly defined NR system.

In addition, as another example, in 5G mobile communication, IAB (Integrated Access and Backhaul) technology may be considered and will be described below.

The meanings of the abbreviations used in this specification are shown in Table 1 below.

[Table 1]

Backhaul and IAB

Backhaul means gathering data in one place and passing it to the backbone network. The role of delivering this data to one place is called backhaul equipment, and the entire environment can be defined as a backhaul network.

In the 5G era, as data demand is rapidly increasing, development of backhaul equipment and backhaul network processing technology are required to deliver data collected from users' Internet access devices such as smartphones to the backbone network. In addition, since NR radio access technology will utilize the availability of high frequency spectrum, it is expected that more NR base stations will be needed to achieve the same coverage as the low frequency. Therefore, there is a need for a technology that allows more base stations to be deployed and connected in a simple and cost-effective manner to increase the coverage of the NR.

In order to meet these requirements, IAB (Integrated Access and Backhaul) technology is being researched. IAB refers to a technology for integrating and managing radio resources of a radio backhaul link of a base station and radio resources of an access link for a user terminal device.

Through IAB technology research, more advanced backhaul equipment can be developed, and backhaul processing technology can be developed to efficiently process rapidly increasing data, and NR cells can be flexibly and densely arranged.

For the convenience of description, the following describes the operation and related information for the IAB based on the NR system. However, the following features may not be limited to a specific system, and may be applied to other systems similarly implemented, and are not limited to the above-described embodiments.

IAB structure

2 shows a structure considered in the IAB according to an example.

Referring to FIG. 2, a communication system supporting IAB can be largely composed of a core network, an IAB donor, an IAB node, and a terminal.

Here, the IAB donor means a RAN node that provides a terminal interface to a core network and a wireless backhaul function to an IAB node. The IAB donor can be defined as a base station (gNodeB). The IAB node means a RAN node that supports radio access to the terminal and backhauls access traffic wirelessly.

The IAB donor and the IAB node can deliver packets over a wireless backhaul link, and the IAB node can perform packet transmission and reception over a wireless access link with a terminal.

The IAB node may have a parent or child IAB node. At this time, the parent IAB node may be one or more, and the child IAB node may also be one or more. A parent IAB node connected by a wireless backhaul link can act as a base station to a child IAB node. Advantages of IAB technology can be maximized through proper IAB node placement, and various IAB nodes are currently considered as shown in FIG. 3 below.

3 is a diagram showing various IAB node configurations, and FIG. 4 is a diagram illustrating a structure in which IAB is considered according to another example.

Referring to FIG. 4, the IAB node can support both a Stand Alone (SA) mode and a Non Stand Alone (NSA) mode. However, the IAB node can use only the NR link in the backhaul, and at this time, the NR Uu link may be used. The radio access link between the IAB node and the terminal may also use an NR Uu link. At this time, the Uu link means a link between a base station (gNodeB) and a terminal (UE), or between a radio access network and a terminal, and the Uu link is a path through which a terminal transmits a signal to a base station (Uplink, UL) and a base station. It may include a downlink (DL) that is a path for transmitting a signal to the terminal.

As described above, the IAB node receiving the packet from the terminal through the radio access link may deliver the packet to another IAB node or IAB donor through the backhaul link. That is, the coverage of the base station can be expanded by relaying the packet received by the terminal through the IAB node. In addition, when the terminal and the IAB node perform communication, the terminal transmits data at a relatively short distance, so that the consumption of terminal transmission power and transmission latency can be reduced. In addition, the IAB donor can distribute the load of the base station by transmitting and receiving packets through various IAB nodes. Multiple packets can be received and processed at once. In addition, the IAB donor can reduce the load on the base station by transmitting packets through several IAB nodes.

As described above, in the IAB, a packet may be delivered multiple times through an IAB node, so a study on the packet processing process to support this is necessary. In the IAB environment, a new adaptation layer is considered as a method for packet processing, and multi-hop ARQ is considered to ensure reliability of packet delivery. In addition, research on how to configure bearer mapping to reflect service requirements is needed. Hereinafter, the adaptation layer considered for IAB packet processing will be described.

Adaptation Layer

The Adaptation layer may serve to allow packets to be delivered to an appropriate terminal or an appropriate IAB node or base station to support the backhaul function. More specifically, the Adaptation layer may support the following functions.

-Identification of the terminal bearer for the PDU,

-Routing through wireless backhaul topology,

-QoS enhancement by scheduler for DL and UL on wireless backhaul link,

-Mapping of UE user plane PDUs for backhaul RLC channels

- Etc

To support this function, the Adaptation layer can deliver necessary information through the Adaptation header. The information may be the following information.

-Terminal bearer ID

-Terminal ID

-Route ID, IAB node or IAB donor address

-QoS information

-Other information

The location of the adaptation layer has not been determined yet, and may exist above the RLC layer or above the MAC layer. Or it can be used in combination with the MAC layer.

When the Adaptation layer is present on the RLC layer, the Adaption layer may perform a function of selecting an appropriate IAB node or terminal to deliver a packet. Or, if the Adaptation layer exists above the MAC layer, the Adaptation layer may perform a function of selecting a logical channel to which packets are to be delivered. Alternatively, when the adaptation layer is integrated with the MAC layer, different MAC PDUs may be configured and transmitted to different UE / IAB nodes.

5 shows a communication structure considering an adaptation layer.

According to FIG. 5, the UE may be configured of SDAP, PDCP, RLC, and MAC layers, and the IAB node may be composed of Adapt, RLC, and MAC layers. In addition, the terminal may configure a radio bearer (RB) according to the QoS of the data to be serviced or generated by the terminal.

At this time, the radio bearer may be configured to transmit or receive data packets having a specific QoS. For example, a bearer configured to transmit data among radio bearers may be referred to as a data radio bearer (DRB).

The SDAP layer of the terminal may determine whether to be transmitted through which SLRB according to the QoS of each packet generated from the application layer of the terminal. As an example, a packet for QoS A may be transmitted to DRB A, a packet for QoS B may be transmitted to DRB B, and a packet for QoS C may be transmitted to DRB C.

The PDCP layer may have a plurality of PDCP entities, and the DRB may have a one-to-one mapping relationship with one PDCP entity. The PDCP layer may be a layer that performs a header compression function that reduces unnecessary information, a data packet rearrangement, and a duplicate data packet detection function to efficiently transmit data packets transmitted to the DRB. In addition, the PDCP layer may serve to retransmit data packets that are not properly received at the receiving end when security of the data packets and RRC connection reset.

The RLC layer can divide the data packet to fit the data size requested by the lower layer, and can support three modes to guarantee various QoS required by the DRB. At this time, the three modes may be RLC-TM (Transport Mode), RLC-UM (Unacknowledged Mode), and RLC-AM (Acknowledged Mode). In the case of RLC-TM, the received RLC SDU (ie, PDCP PDU) is transmitted to the MAC layer as it is. In the case of RLC-UM and RLC-AM, the PDCP PDU is divided according to the packet size indicated by the lower layer, and the SN is allocated to add the RLC header, and then the RLC PDU is generated and transmitted to the MAC layer. In addition, the RLC-AM mode supports ARQ function.

In addition, a logical channel (Logical channel) is a channel connecting the MAC and RLC, the logical channel used is different according to the type of data, the data packet is processed in the RLC layer can be delivered to the MAC layer through the logical channel .

The MAC layer may generate a MAC PDU with a data packet received through a logical channel, and the generated MAC PDU may be stored in an HARQ buffer. After the MAC PDU is successfully received, the UE may discard the MAC PDU stored in the HARQ buffer.

As described above, the Adaptation layer is a layer that plays a role of allowing packets to be delivered to an appropriate terminal or an appropriate IAB node or base station to support the backhaul function. It is present on the MAC layer as shown in FIG. 5A, or with FIG. 5B. Likewise, it can exist above the RLC layer.

The terminal, the IAB node, and the IAB donor can transmit and receive information about the backhaul link through the RLC channel. In this case, the RLC channel may be defined as a BH (Back Haul) RLC channel. Packet transmission through a wireless backhaul may be supported through the BH RLC channel and the adaptation layer.

The location of the adaptation layer may be different according to the mapping method of the terminal bearer to the BH RLC channel. In addition, the method of supporting RLC ARQ may be different depending on the location of the adaptation layer.

Hereinafter, a mapping method of a terminal bearer to a BH RLC channel is first described, and then RLC ARQ is described.

Bearer mapping

The IAB node needs to multiplex the terminal DRB to the BH RLC-Channel. There may be a one-to-one mapping mapping each terminal DRB to a different BH RLC-Channel in a bearer mapping method. In addition, there may be a QoS mapping method for mapping to BH RLC-Channel based on the QoS of the tree pack.

6 shows a structure supporting one-to-one bearer mapping.

According to FIG. 6, each terminal may be mapped to a different BH RLC channel. In addition, each BH RLC channel may be mapped to a different BH RLC channel in the next hop. The set number of BH RLC channels is the same as the set number of terminals. In this case, the IAB node does not need to multiplex the terminal DRB or identify the packet because the packet needs only to be transferred between the terminal DRB and the BH RLC channel.

When the terminal bearer and the BH RLC channel have a one-to-one mapping as shown in FIG. 6, the Adaptation layer may be integrated with the MAC layer or disposed over the MAC layer. Since the RLC entity of the IAB node exists for each of the BH RLC channels, the RLC layer can transmit and receive data by mapping to the corresponding RLC entity based on data packet and terminal bearer information transmitted from the Adaptation layer.

7 shows a structure for supporting QoS bearer mapping.

According to FIG. 7, the IAB node can establish a BH RLC channel based on the QoS of the traffic. IAB nodes can be multiplexed into a single BH RLC channel when they have DRBs or QoS flows with similar QoS characteristics, even if they are different UEs. In addition, each BH RLC channel may be mapped to another BH RLC channel according to the QoS of the next hop. The number of BH RLC channels set may be the same as the number of QoS profiles. In this case, since the BH RLC channel is set for each QoS profile, each data block transmitted in the BH RLC channel needs to include identifiers of UEs and DRBs to which it belongs.

When the terminal bearer is aggregated in the BH RLC channel as shown in FIG. 7, the Adaptation layer may be disposed on the RLC layer. The Adaptation layer of the IAB node can play a routing role by classifying to which terminal each data transmitted from the RLC layer should be transmitted.

RLC ARQ

As described above, in IAB, since a packet can be relayed multiple times through an IAB node, multi-hop RLC ARQ can be considered to ensure the reliability of packet transmission and reception.

RLC ARQ is a request for retransmission of a packet that has not been received due to a failure of HARQ in the MAC layer. The RLC layer of the transmitting end receiving the retransmission retransmits the data packet to guarantee the reliability of packet transmission and reception. As described above, RLC ARQ can be supported in RLC AM mode.

The multi-hop RLC ARQ used in the backhaul link may include end-to-end RLC ARQ and hop-by-hop RLC ARQ.

8 is a diagram showing an ARQ mode.

The first in FIG. 8 represents end-to-end RLC ARQ, and the second represents hop-by-hop RLC ARQ. In addition, the third represents a two-hop ARQ mode.

End-to-end RLC ARQ and hop-by-hop RLC ARQ can have different advantages and disadvantages.

For example, the end-to-end RLC ARQ has the advantage of low latency for packet delivery because the packet does not pass through the RLC state system at the intermediate IAB node, but when packet loss occurs, which IAB node has lost Since it is unknown, the higher the number of hops, the longer the delay time for retransmission.

On the other hand, in the case of a hop-by-hop RLC ARQ, since the packet must pass through the RLC state system at each hop, the delay time for packet delivery may be longer. However, when packet loss occurs, the retransmission delay time may be relatively fast because retransmission is performed on only one link.

Whether to support end-to-end RLC ARQ and hop-by-hop RLC ARQ may be determined according to the location of the adaptation layer. When the Adaptation layer is above the RLC layer, at this time, only the hop-by-hop RLC ARQ can be supported. On the other hand, when the Adaptation layer is above the MAC layer, it can support both hop-by-hop RLC ARQ and end-to-end RLC ARQ.

Congestion problem

IAB may be supported based on the above configuration. However, following this configuration, congestion may occur in the intermediate IAB node in a multi-hop backhaul.

For example, even if the IAB node exists in a fixed location, the wireless environment of the wireless backhaul link may be deteriorated due to infrastructure changes or moving objects such as vehicles. In this case, traffic may be disproportionately distributed in the wireless backhaul link, and link or node congestion may occur.

As for the uplink, since the IAB node acts as a base station in the child IAB node, the amount of uplink data transmitted by the child IAB node and the terminal can be controlled by adjusting the UL grant. Therefore, a buffer overflow for uplink data may not occur.

On the other hand, a buffer overflow may occur in the downlink. The link capacity from the IAB node to the child IAB node or terminal may be smaller than the backhaul link capacity from the parent IAB node. Therefore, the downlink data scheduled by the parent IAB node may be larger than the downlink data scheduled by the IAB node to the child IAB node or terminal. In this case, downlink data congestion may occur, and the IAB node in which congestion occurs may discard packets, resulting in a problem of packet loss.

As a solution to this, an end-to-end or hop-by-hop flow control mechanism may be considered.

For example, in end-to-end flow control, the problem of downlink data congestion can be solved by the access IAB node of the terminal reporting the downlink delivery status to the IAB donor. However, since this mechanism does not provide information from the IAB node where the congestion occurred, delays may occur before resolving the congestion.

In the hop-by-hop flow control, the problem of downlink data congestion can be solved by the congested IAB node reporting the downlink delivery status to the parent IAB. Based on the report, the parent IAB or IAB donor can perform flow control and alleviate downlink data congestion.

At this time, the flow control means to prevent the buffer overflow of the receiver by adjusting the processing speed of data, and considers both end-to-end and hop-by-hop flow control mechanisms as a solution to the downlink buffer overflow. Can be. The specific method for performing the flow control mechanism has not yet been discussed.

NR IAB support

As described above, in the wireless communication system in which the IAB is constructed, the terminal may perform direct communication with the base station, or may communicate with the base station through the IAB node. At this time, transmission / reception may be performed through a Uu link, which is a communication interface between the base station and the terminal.

IAB can be performed in an NR system. For example, the NR system supports various subcarrier spacing (SCS) considering various scenarios, service requirements, and potential system compatibility. In addition, NR systems are designed to overcome poor channel environments such as high path-loss, phase-noise and frequency offset occurring on a high carrier frequency. It can support the transmission of the physical signal / channel through the beam of. Through this, the NR system can support applications such as enhanced Mobile Broadband (eMBB), Massive Machine Type Communications (mMTC) / ultra Machine Type Communications (uMTC), and Ultra Reliable and Low Latency Communications (URLLC). However, although the term NR system in this specification is used as an example of a wireless communication system, the term NR system itself is not limited to the above-described features.

In addition, as an example, 5G mobile communication technology may be defined. In this case, as an example, 5G mobile communication technology may be defined to include not only the above-described NR system, but also an existing Long Term Evolution-Advanced (LTE-A) system. That is, 5G mobile communication may be a technology that operates in consideration of backward compatibility with a previous system as well as a newly defined NR system.

For example, the IAB field of 5G may include both backhaul technology in the LTE system and backhaul technology in the NR system. At this time, the IAB field may be an essential field for grafting new and diverse services such as multiple devices being connected.

For the convenience of description, the following describes the operation and related information for the IAB based on the NR system. However, the following features may not be limited to a specific system, and may be applied to other systems similarly implemented, and are not limited to the above-described embodiments.

IAB nodes can report downlink buffer status to the parent IAB node or IAB donor through a hop-by-hop or end-to-end flow control mechanism to prevent downlink data congestion issues, and there are differences in performing each mechanism. You can.

In Example 1 below, an IAB node operation for performing hop-by-hop flow control is proposed, and an IAB node operation for performing end-to-end flow control in Example 2 is described.

Example 1 (hop-by-hop flow control method)

The hop-by-hop flow control is a method of solving the problem of downlink data congestion by reporting the downlink delivery status to the parent IAB node by the congested IAB node. To support this, it is necessary to define a specific IAB node operation, which will be described below.

9 may be a method for performing hop-by-hop flow control.

According to FIG. 9, when a downlink buffer congestion occurs in IAB node 2, the congested IAB node 2 can inform the parent IAB node, IAB node 3, of this fact. The IAB node 3, which has received the above information, can solve this problem by lowering the transmission rate of the downlink packet transmitted to the IAB node 2.

According to this embodiment, the IAB node 2 (IAB node 2) may determine the downlink data congestion and perform hop-by-hop flow control according to the triggering condition of the downlink delivery status report trigger of embodiment 1-1. Thereafter, according to the method of Example 1-2, the IAB node (IAB node 2) may perform a downlink delivery status report to the parent IAB node (IAB node 3).

Example 1-1 (trigger condition for reporting downlink delivery status)

In order to perform hop-by-hop flow control, the IAB node may report the downlink delivery status to the parent IAB node when it is determined that the downlink data is congested according to a certain criterion. However, it is not yet defined what criteria the IAB node determines that the downlink data is congested and performs hop-by-hop flow control, and the following will be proposed.

For example, a criterion for the IAB node to determine that the downlink data is congested may be a case in which data stored in the downlink buffer reaches a threshold.

More specifically, when data stored in the downlink buffer of the IAB node has reached a certain threshold, the parent IAB node can be informed of this situation, and information can be provided to adjust the downlink data throughput / processing speed.

At this time, as an example, the threshold may be set by the IAB node itself, and if data stored in the downlink buffer continues to reach the threshold for a certain period of time, the IAB node may trigger a downlink delivery status report. At this time, the predetermined time may be a timer, and the timer value may be set by an IAB donor.

As another example, the threshold may be set by the IAB node itself. At this time, when data stored in the downlink buffer reaches a threshold and becomes larger by an offset, a downlink buffer status report may be triggered. At this time, the offset may be set by the IAB donor.

As another example, the threshold may be set by the IAB node itself, and the downlink channel environment of the child IAB node and / or the terminal to which the data of the buffer is transmitted while the data stored in the downlink buffer reaches the threshold is not good. If it is determined, the downlink buffer status report can be triggered. Poor downlink channel environment of the child IAB node and / or terminal means that when transmitting downlink data, the IAB node must use more resources, and HARQ retransmission and / or ARQ retransmission may take longer. Therefore, the transmission of downlink data may be slow, and if the share of the downlink buffer is also high, a downlink buffer overflow may occur. Thus, in this case, the downlink buffer status report can be triggered to expect processing from the parent IAB node or IAB donor.

As another example, the threshold may be set by the IAB donor, and when data stored in the downlink buffer continues to reach the threshold for a predetermined period of time, a downlink buffer status report may be triggered. At this time, the predetermined time may be a timer, and the timer value may also be set by an IAB donor.

As another example, the threshold may be set by the IAB donor. At this time, when the data stored in the downlink buffer reaches a threshold and becomes larger by an offset, the downlink buffer status report may be triggered. At this time, the offset value may also be set by the IAB donor.

As another example, the threshold may be set by the IAB node itself, and the downlink channel environment of the child IAB node and / or the terminal to which the data of the buffer is transmitted while the data stored in the downlink buffer reaches the threshold is not good. If it is determined, the downlink buffer status report can be triggered.

Example 1-2 (report of downlink delivery status)

As described above, the IAB node can determine to perform the downlink delivery status report according to a certain condition. At this time, the IAB node may consider the following method to report the downlink delivery status.

For example, the IAB node may use an adaptation header to report the downlink delivery status, and consider the following method to express the downlink delivery status.

The Adaptation layer is a layer that performs routing to deliver packets to an appropriate IAB node, and the Adaptation header may include information required for IAB, such as a terminal bearer ID, a terminal ID, an IAB node to be routed, or an IAB donor address, QoS information. The adaptation layer of the IAB node can add an adaptation header including the above information to an uplink packet to be transmitted to the parent IAB node or IAB donor, through which the uplink packet is mapped to an appropriate bearer and transmitted to the parent IAB or IAB donor. Can be. Therefore, the IAB node can report to the parent IAB node which downlink congestion occurred in which downlink buffer by additionally including downlink delivery status information in the adaptation header. At this time, the configuration of the adaptation header may vary depending on how to express the downlink delivery state, and a description will be given below of a method for expressing the downlink delivery state.

In order to inform the downlink delivery status to the parent IAB node, the adaptation header may include a congestion downlink buffer (backhaul bearer ID), congestion step or congestion information, or information on the amount of downlink data stored. At this time, the adaptation header may be configured based on octets to be aligned with the header structure of another layer, and it may be determined how many octets the adaptation header will use in total according to the number of bits of each information.

For example, the terminal bearer ID and the terminal ID are used by the IAB node and the IAB donor to identify the PDU of the terminal bearer, and the terminal bearer ID may correspond to a logical channel ID (LCID), and the terminal ID is C-RNTI ( Cell-Radio Network Temporary Identify). In the NR system, LCID is defined as 6 bits, and C-RNTI is defined as 16 bits. Therefore, the terminal bearer ID and the terminal ID may also be 6 bits and 16 bits, respectively. In addition, QoS information may correspond to QFI (QoS Flow Indicator), which is QOS flow identification information used in NR. Since QFI is defined as 6 bits in NR, QoS information may be 6 bits. Routing information is used to indicate an IAB node to which a packet is to be relayed, and the number of bits may be determined according to the number of IAB nodes configured. For example, when one IAB donor can have up to seven IAB nodes, each IAB node can be divided into 1 to 7, so 3 bits can be used. In this case, as an example, the IAB donor may be 0. The backhaul bearer ID can also correspond to the LCID, so it can be 6 bits. The number of bits in the DL delivery state may vary according to an expression method described below. For example, when expressing congestion in steps, it may be 2 bits. As another example, when only congestion is expressed, it may be 1 bit. As another example, when expressing the amount of downlink stored, it may be 5 bits or 8 bits.

10 is a diagram showing the configuration of an adaptation header.

10A is an example of expressing a DL delivery state as a stage of congestion.

10B is an example of expressing a DL delivery state as congestion.

10C is an example of expressing a DL delivery state as an amount (5 bits) of stored downlinks.

10D is an example of expressing a DL delivery state as an amount (8 bits) of stored downlinks.

When the above information is included in the adaptation header, the IAB node may include downlink delivery status information in all uplink packets transmitted to the IAB parent. Therefore, since the IAB node determines that congestion has occurred, it can indicate that congestion has occurred in all uplink packets. After reporting the congestion, if the congestion problem is resolved by the processing of the parent IAB node, the IAB node may transmit the indication that congestion does not occur in the adaptation header. At this time, the criterion for determining that the congestion problem has been solved may be when the data stored in the downlink buffer is below a threshold.

As another example, the IAB node may indicate that the downlink data is congested by configuring a STATUS PDU (or control PDU) in the adaptation layer. In general, the STATUS PDU is used to inform the transmitting side of a packet successfully received and a packet detected as lost by the receiving side. However, in the present invention, the STATUS PDU can be used for the purpose of indicating the downlink delivery status. When the STATUS PDU determines that downlink congestion occurs and wants to inform the parent IAB node of the fact, if there is no uplink packet to be transmitted, reporting of downlink delivery status through the above-mentioned adaptation header is not appropriate. Can be Therefore, a STATUS PDU that can be transmitted to the parent IAB node without an uplink packet may be an appropriate method.

The STATUS PDU may include an ID of a bearer where downlink data congestion has occurred and downlink delivery status information of the bearer. In addition, the header of the STATUS PDU may include a D / C (Data / Control) field to indicate whether the PDU is a data PDU or a STATUS PDU. It has a value of 0 or 1 in 1 bit, and if it is 0, it means that it is a Control PDU, and if it is 1, it can mean that it is a Data PDU. In addition, the STATUS PDU may include routing information so that the PDU can be received by the parent IAB node. As mentioned above, the number of bits may be determined according to the number of configured IAB nodes, and 3 bits is assumed in this embodiment. Also, an IAB node ID field may be included to indicate from which IAB node the STATUS PDU is transmitted. The IAB node ID field may also be determined according to the number of IAB nodes configured, and in this embodiment, it is assumed to be 3 bits. In addition, R (Reserved) bits may be added in preparation for future expansion possibilities for other functions of the Control PDU and to maintain an octet structure.

The IAB node may configure a STATUS PDU when the downlink delivery status event is triggered according to the embodiment 1-1, and the STATUS PDU may be transmitted to the parent IAB node.

11 is a diagram showing the configuration of a STATUS PDU.

11A is an example of expressing a DL delivery state as a stage of congestion.

11B is an example of expressing a DL delivery state as congestion.

11C is an example of expressing the DL delivery state as the amount of stored downlink (5 bits).

11D is an example of expressing a DL delivery state as an amount (8 bits) of stored downlinks.

After transmitting the STATUS PDU, the IAB node can expect processing from the parent IAB node for a period of time. If the downlink congestion problem continues to occur even after a certain period of time, the IAB node may configure and transmit the STATUS PDU again. That is, it may be necessary to wait for a certain period of time until the downlink congestion is processed, and at this time, the prohibitTimer may be used. The operation of the timer may be as follows.

-Start: After sending STATUS PDU

-Stop: When the data stored in the downlink buffer is below the threshold

-Expiration: STATUS PDU reconstruction and transmission

As another example, the IAB node may indicate that downlink data is congested through MAC CE.

When the IAB node transmits the MAC CE to the parent IAB node, the MAC CE may be discarded without routing after the parent IAB node confirms. Considering that the hop-by-hop flow control is handled by the parent IAB node, MAC CE transmission may be an appropriate method.

The MAC CE may include ID of a bearer where downlink data congestion has occurred and downlink delivery status information of the bearer. The IAB node may configure MAC CE when the downlink delivery status event is triggered, and the MAC CE may be transmitted to the parent IAB node.

12 is a diagram showing the configuration of MAC CE.

12A is an example of expressing a DL delivery state as a stage of congestion.

12B is an example of expressing a DL delivery state as congestion.

12C is an example of expressing a DL delivery state as an amount (5 bits) of stored downlinks.

12D is an example of expressing a DL delivery state as an amount (8 bits) of stored downlinks.

The IAB node where downlink congestion has occurred may indicate the amount of downlink data stored in the buffer together with the downlink buffer (backhaul bearer ID) where congestion has occurred.

After transmitting the MAC CE, the IAB node can expect processing from the parent IAB node for a period of time. If the downlink congestion problem continues to occur even after a certain period of time, the IAB node may configure and transmit MAC CE again. That is, it may be necessary to wait for a certain period of time until the downlink congestion is processed, and at this time, the prohibitTimer may be used. The operation of the timer may be as follows.

-Start: After MAC CE transmission

-Stop: When the downlink delivery status is below the threshold

-Expiration: MAC CE reconfiguration and transmission

Hereinafter, a method for expressing a downlink delivery state is proposed.

For example, a level for a downlink buffer state may be defined and expressed as a level. At this time, the level may be an N level, and the threshold of N and each N level may be set by the IAB node itself. The IAB node can determine its downlink buffer size and corresponding downlink data throughput. Therefore, the downlink congestion can be expressed by setting a threshold value by the IAB node itself. As an example, the buffer state can be expressed in four steps. The first stage can have a value of 0, the second stage has a value of 1, the third stage has a value of 2, and the fourth stage has a value of 3, which can be expressed in a total of 2 bits. For example, 0 may indicate no congestion and 1 may indicate an initial congestion stage. In addition, 2 may indicate that the downlink congestion is at a critical level, and 3 may indicate that the downlink congestion is a serious level and a downlink buffer overflow occurs. In expressing the downlink delivery status, the IAB node may not need to specifically express the amount of downlink data stored. Therefore, this method is efficient in terms of signaling overhead.

13 is a diagram illustrating a method of expressing a downlink delivery state.

As another example, only the congestion of downlink data may be expressed based on a specific threshold. It can be expressed in a total of 1 bit, for example, 0 can indicate that the downlink transmission is well performed, and 1 can indicate that the downlink data is congested. The hop-by-hop flow control is performed when the IAB node determines congestion of downlink data as described above, where the IAB node can express the downlink buffer status as 1. On the other hand, when performing general data transmission, that is, when the downlink data congestion event is not triggered, the IAB node may express the downlink buffer state as 0. As described above, the threshold can be set by the IAB node itself or by the IAB donor. The method is efficient in terms of signaling overhead by using a small number of bits.

14 is a diagram showing another method of expressing a downlink delivery state.

As another example, the amount of data stored in the downlink buffer may be specifically indicated.

At this time, the table below may be used to indicate the amount of data in the number of bytes. The buffer size can be indicated by 5 bits or 8 bits. The amount of stored data can be defined as BS values in Tables 2 and 3 below, and the BS value can be expressed as an index value. For example, when the amount of stored downlink data is greater than 53 and has a value of 70 that is 74 or less, it may be represented by index 7.

Table 2 is a table showing the amount of data in 5 bits. Table 3 is a table showing the amount of data in 8 bits.

[Table 2]

[Table 3]

The adaptation header information of the uplink packet received from the child IAB node, the parent IAB node receiving the STATUS PDU or MAC CE can determine which downhaul data congestion occurred in which backhaul bearer of which IAB node, and according to the above information. The congestion problem can be solved by slowing down the bearer's downlink packet delivery rate.

15 is a flowchart illustrating an example of an operation of performing a downlink delivery status report of an IAB node according to the present disclosure.

In step S1510, the IAB node may determine that the downlink is congested according to the downlink congestion determination criterion of Example 1-1. At this time, a criterion for determining congestion may be a case where data stored in the downlink buffer exceeds a threshold.

In step S1520, the IAB node may report the downlink delivery status to the parent IAB node according to the reporting method of the embodiment 1-2. At this time, an adaptation header, STATUS PDU, or MAC CE may be used.

The parent IAB node that has grasped downlink congestion of the child IAB node through step S1520 may solve the downlink data congestion problem by lowering the downlink delivery rate in step S1530.

Example 2 (end-to-end flow control method)

End-to-end flow control is a method for the terminal access IAB node to solve the problem of downlink data congestion by reporting the downlink delivery status to the parent IAB node. To support this, it may be necessary to define a specific IAB node operation, which will be described below.

16 may be a method for performing end-to-end flow control.

The terminal access IAB node (IAB node 1) may receive the downlink delivery status information from the intermediate IAB nodes (IAB node 2, IAB node 3), aggregate and report to the IAB donor. The IAB donor receiving the report can adjust the downlink transmission rate / amount so that no downlink congestion occurs.

In order to perform the above operation, in Example 2-1, a downlink delivery status report triggering condition will be described, and in Example 2-2, a downlink delivery status report operation of the IAB node will be described. In the embodiment 2-3, the downlink delivery status reporting operation of the terminal access IAB node will be described.

According to this embodiment, according to the embodiment 2-1, the IAB node (IAB nodes 1, 2, 3) may determine to perform the downlink delivery status report. Thereafter, according to the method of Example 2-2, the IAB node (IAB node 2, 3) may report the downlink delivery status to the terminal access IAB node (IAB node 1). Thereafter, according to the method of Embodiment 2-3, the terminal access IAB node (IAB node 3) may collect the above information and report the overall downlink delivery status to the IAB donor.

Example 2-1 (triggered downlink delivery status reporting event)

In the end-to-end flow control, the congestion is not provided directly by the IAB node, so a delay may occur before resolving the congestion. Therefore, it is possible to perform a role of preventing congestion by performing a report before determining that congestion has occurred.

Therefore, unlike event-based triggering of hop-by-hop flow control, end-to-end flow control can periodically report downlink delivery status for the purpose of preventing downlink congestion problems in advance.

For example, to periodically report the downlink delivery status, the IAB node may operate as follows.

The IAB node periodically reports the current downlink buffer status to the terminal access IAB node, and the terminal access IAB node can report the information to the IAB donor. The IAB donor receiving the information can adjust the downlink data throughput / processing speed according to the downlink buffer status information.

At this time, a timer may be used to periodically trigger the downlink buffer state. For example, the timer may be periodic-Timer, and the timer value may be set by an IAB donor. The operation at the start and end of the timer is as follows.

-Start: A timer can be started when downlink data is available in at least one downlink buffer.

-Upon expiration: A downlink buffer status report can be performed.

In this case, as an example, the IAB node may have one cycle in reporting downlink delivery status. At this time, when the IAB node has multiple terminal access IAB nodes, when the IAB node triggers a downlink delivery status reporting event according to a period, the IAB node provides the same downlink delivery status information to all terminal access IAB nodes. Can deliver.

In case of having one cycle, all terminal access IAB nodes can perform a downlink delivery status report at a similar time. Therefore, there is an advantage that the IAB donor can solve the congestion problem by grasping the entire flow of the downlink delivery status.

At this time, as another example, the IAB node may have a different period for each terminal access IAB node in the downlink delivery status report. That is, when the IAB node has multiple terminal access IAB nodes, the IAB node may deliver different downlink delivery status information according to the triggering period of each terminal access IAB node.

When each terminal access IAB node has a different period, the IAB donor has an advantage of obtaining downlink delivery status information at various points in time.

Example 2-2. Report downlink delivery status of IAB node

As described above, the IAB node can determine to perform the downlink buffer status report according to a certain condition. At this time, how the IAB node reports the downlink delivery status will be described below.

For example, the IAB node may use an adaptation header to report the downlink delivery status, and consider the following method to express the downlink delivery status.

The Adaptation layer is a layer that performs routing to deliver packets to an appropriate IAB node, and the Adaptation header may include information required for IAB, such as a terminal bearer ID, a terminal ID, an IAB node to be routed, or an IAB donor address, QoS information. The adaptation layer of the IAB node may add an adaptation header including the information to a downlink packet to be transmitted to a child IAB node or terminal, through which the downlink packet is mapped to an appropriate bearer and transmitted to a child IAB node or terminal. You can. Therefore, the IAB node can report to the terminal access IAB node which downlink congestion occurred in which downlink buffer by additionally including downlink delivery status information in the adaptation header. At this time, the configuration of the adaptation header may vary depending on how to express the downlink delivery state, and a description will be given below of a method for expressing the downlink delivery state.

The adaptation header may include congestion step or congestion information together with a downlink buffer (backhaul bearer ID) where congestion has occurred. The adaptation header can be configured based on octet to be aligned with the header structure of another layer. Accordingly, it is possible to determine how many octets the adaptation header will use depending on the number of bits of each information.

For example, the terminal bearer ID and the terminal ID are used by the IAB node and the IAB donor to identify the PDU of the terminal bearer, the terminal bearer ID may correspond to a logical channel ID (LCID), and the terminal ID is C-RNTI (Cell-Radio Network Temporary Identify). In the NR system, LCID is defined as 6 bits, and C-RNTI is defined as 16 bits. Therefore, the terminal bearer ID and the terminal ID may also be 6 bits and 16 bits, respectively. In addition, QoS information may correspond to QFI (QoS Flow Indicator) used in NR, and QFI is defined as 6 bits in NR. Therefore, the QoS information can be 6 bits. Routing information is used to indicate an IAB node to which a packet is to be relayed, and the number of bits may be determined according to the number of IAB nodes configured. For example, when one IAB donor can have up to seven IAB nodes, each IAB node can be divided into 1 to 7, so 3 bits can be used. In this case, as an example, the IAB donor may be 0. The backhaul bearer ID can also correspond to the LCID, so it can be 6 bits. The number of bits in the DL delivery state may vary according to an expression method described below. For example, when expressing congestion in steps, it may be 2 bits. As another example, when only congestion is expressed, it may be 1 bit. As another example, when expressing the amount of downlink stored, it may be 5 bits or 8 bits.

17 is a diagram showing the configuration of an adaptation header.

17A is an example of expressing a DL delivery state as a stage of congestion.

17B is an example of expressing a DL delivery state as congestion.

17C is an example of expressing the DL delivery state as the amount of stored downlink (5 bits).

17D is an example of expressing a DL delivery state as an amount (8 bits) of stored downlinks.

When the triggering event period is reached, the IAB node may indicate a downlink delivery state by using the adaptation header in a downlink packet.

As another example, the IAB node may indicate that the downlink data is congested by configuring a STATUS PDU (or control PDU) in the adaptation layer. In general, the STATUS PDU is used to inform the transmitting side of a packet successfully received and a packet detected as lost by the receiving side. However, in the present invention, the STATUS PDU can be used for the purpose of indicating the downlink delivery status. In the end-to-end flow control mechanism, the IAB node needs to report the downlink delivery status to the terminal access IAB node, not the child IAB node, so it sets up a receiver for reporting the downlink delivery status directly to the terminal access IAB through the STATUS PDU. You can.

The STATUS PDU may include an ID of a bearer where downlink data congestion has occurred and downlink delivery status information of the bearer. In addition, the header of the STATUS PDU may include a D / C (Data / Control) field to indicate whether the PDU is a data PDU or a STATUS PDU. It has a value of 0 or 1 in 1 bit, and if it is 0, it means that it is a Control PDU, and if it is 1, it can mean that it is a Data PDU. In addition, the STATUS PDU may include routing information so that the PDU can be received by the parent IAB node. As mentioned above, the number of bits may be determined according to the number of configured IAB nodes, and 3 bits is assumed in this embodiment. Also, an IAB node ID field may be included to indicate from which IAB node the STATUS PDU is transmitted. The IAB node ID field may also be determined according to the number of IAB nodes configured, and in this embodiment, it is assumed to be 3 bits. In addition, R (Reserved) bits may be added in preparation for future expansion possibilities for other functions of the Control PDU and to maintain an octet structure.

The IAB node may configure a STATUS PDU when the downlink delivery status event is triggered according to the embodiment 2-1, and the STATUS PDU may be transmitted to the terminal access IAB node.

18 is a diagram showing the configuration of a STATUS PDU. 18A is an example of expressing a DL delivery state as a congestion level. 18B is an example of expressing a DL delivery state as congestion. 18C is an example of expressing the DL delivery state as the amount of stored downlink (5 bits). 18D is an example of expressing a DL delivery state as an amount of stored downlink (8 bits).

Hereinafter, a method for expressing a downlink delivery state is proposed.

For example, a level for a downlink buffer state may be defined and expressed as a level. At this time, the level may be an N level, and the threshold of N and each N level may be set by the IAB node itself. The IAB node can determine its downlink buffer size and corresponding downlink data throughput. Therefore, the downlink congestion can be expressed by setting a threshold value by the IAB node itself. As an example, the buffer state can be expressed in four steps. The first stage may have a value of 0, the second stage may have a value of 1, the third stage may have a value of 2, and the fourth stage may have a value of 3, which may be expressed in 2 bits. For example, 0 may indicate no congestion and 1 may indicate an initial congestion stage. In addition, 2 may indicate that the downlink congestion is at a critical level, and 3 may indicate that the downlink congestion is a serious level and a downlink buffer overflow occurs. In expressing the downlink delivery status, the IAB node may not need to specifically express the amount of downlink data stored. Therefore, this method is efficient in terms of signaling overhead.

19 is a diagram illustrating a method of expressing a downlink delivery state.

As another example, only the congestion of downlink data may be expressed based on a specific threshold. It can be expressed in a total of 1 bit, for example, 0 can indicate that the downlink transmission is well performed, and 1 can indicate that the downlink data is congested. Therefore, hop-by-hop flow control is performed when the IAB node determines congestion of downlink data as described above, where the IAB node can express the downlink buffer status as 1. On the other hand, when performing general data transmission, that is, when the downlink data congestion event is not triggered, the IAB node may express the downlink buffer state as 0. As described above, the threshold can be set by the IAB node itself or by the IAB donor. The method is efficient in terms of signaling overhead by using a small number of bits.

20 is a diagram showing another method of expressing a downlink delivery state.

As another example, the amount of data stored in the downlink buffer may be specifically indicated. At this time, the table below may be used to indicate the amount of data in the number of bytes. The buffer size can be indicated by 5 bits or 8 bits.

Table 4 is a table showing the amount of data in 5 bits. Table 5 is a table showing the amount of data in 8 bits.

[Table 4]

[Table 5]

Example 2-3 (Reporting the downlink delivery status of the terminal access IAB node)

The access IAB node of the terminal receiving the downlink delivery status information from the IAB node, the access IAB node of the terminal waits for reception of the downlink delivery status information from the parent IAB nodes, and then collects the information and transmits it to the IAB donor have.

21 is a diagram for explaining end-to-end flow control. The operation of the access IAB node of the terminal receiving the downlink delivery status information from the IAB node may be as follows.

In the situation where the IAB donor and the IAB node are configured as shown in FIG. 21, each terminal access IAB node can perform a downlink delivery status report to the IAB donor. According to this embodiment, as an example, one IAB donor may have six IAB nodes, and four terminal access IAB nodes may be used. At this time, the terminal access IAB nodes are IAB nodes 3, 4, 5, and 6.

Each of the IAB nodes may report the downlink delivery status to the terminal access IAB node when the periodic Timer described in the embodiment 2-1 expires.

The terminal access IAB node (IAB node 6) receives downlink delivery status information from at least one parent IAB node (IAB node 1 or 3) or the periodic Timer of the terminal access IAB node (IAB node 6) expires and downlinks If the buffer status reporting event is triggered, the terminal access IAB node (IAB node 6) may start a timer for performing end-to-end flow control. For example, the timer may be a waiting timer. While the waiting Timer is running, the terminal access IAB node (IAB node 6) may wait to receive downlink delivery status information from another parent IAB node (IAB node 1 or 3).

If downlink delivery status information is received from all parent IAB nodes (IAB nodes 1 and 3), the terminal access IAB node (IAB node 6) can stop the waiting timer, and the terminal access IAB node (IAB node 6) The message including the delivery status of all parent IAB nodes (IAB nodes 1 and 3) including the downlink delivery status information of can be configured and transmitted to the IAB donor.

On the other hand, if the waiting Timer has expired, the terminal access IAB node (IAB node 6) reports a report message including downlink delivery status information received from the parent IAB node (IAB node 1 or 3) and its own downlink delivery status information. Once configured, it can be sent to the IAB donor.

At this time, the STATUS PDU described in Example 2-2 may be used as a report message. Considering that the information received should be collected and reported, the STATUS PDU may be an appropriate method. In configuring the STATUS PDU, the IAB donor address may be set in the routing information field, and the backhaul bearer ID and DL delivery status fields may be used as received information from the parent IAB node.

More specifically, when the terminal access IAB node uses a STATUS PDU for reporting the downlink delivery status, the downlink delivery status of the terminal access IAB node and the downlink delivery status received from the parent IAB node in one STATUS PDU. Information may be included. Therefore, the STATUS PDU consists of the routing information field set to the IAB donor address, the IAB node ID set to the terminal access IAB node, and the backhaul bearer ID and DL delivery status fields of the terminal access IAB node, and additionally, IAB, information received from the parent IAB node. Node ID, backhaul bearer ID, and DL delivery status information fields may be added.

The IAB donor, which has received the STATUS PDU from the terminal access IAB node, can determine which backhaul data congestion has occurred in the backhaul bearer, and can solve the congestion problem by slowing down the bearer's downlink packet delivery rate according to the information.

22 is a flowchart illustrating an example of an operation for performing a downlink delivery status report of an IAB node according to the present disclosure.

In step S2210, the parent IAB node 1 may expire the periodic timer for the downlink delivery status report.

In step S2220, the parent IAB node whose period timer has expired may report the downlink delivery status to the terminal access IAB node. At this time, an adaptation header or STATUS PDU may be used.

In step S2230, the terminal access IAB node receiving the downlink delivery status report from the parent IAB node may start a standby timer to report downlink delivery status information from all parent IAB nodes to the IAB donor at once. While the standby timer is running, the terminal access IAB node can expect to receive a downlink delivery status report from the parent IAB node. When receiving a downlink delivery status report from all parent IAB nodes, the terminal access IAB node may stop the waiting timer. If the wait timer has expired, the received information can be collected and reported to the IAB donor.

In step S2240, the parent IAB node 2 may expire a periodic timer for reporting downlink delivery status.

In step S2250, the parent IAB node whose period timer has expired may report the downlink delivery status to the terminal access IAB node. At this time, STATUS PDU may be used.

In step S2260, the terminal access IAB node receiving the downlink delivery status report from all the parent IAB nodes may stop the standby timer and collect information.

In step S2270, the terminal access IAB node may report the downlink delivery status of the terminal access IAB node and the parent IAB nodes to the IAB donor according to the embodiment 2-3.

23 is a view showing the configuration of an IAB donor and an IAB node device according to the present disclosure.

At this time, the IAB donor and the IAB node of Embodiments 1 and 2 described above may operate based on the IAB donor device and the IAB node device disclosed in FIG. 23. That is, FIG. 23 may show the configuration of devices performed in the first and second embodiments.

The base station apparatus 2300 may include a processor 2310 antenna unit 2320, a transceiver 2330, and a memory 2340. The processor 2310 performs baseband-related signal processing, and may include an upper layer processing unit 2311 and a physical layer processing unit 2315. The upper layer processing unit 2311 may process operations of a medium access control (MAC) layer, a radio resource control (RRC) layer, or higher layers. The physical layer processor 2315 may process operations of a physical (PHY) layer (eg, uplink reception signal processing and downlink transmission signal processing). In addition to performing baseband-related signal processing, the processor 2310 may control overall operation of the base station apparatus 2300. The antenna unit 2320 may include one or more physical antennas, and if a plurality of antennas are included, the antenna unit 2320 may support multiple input multiple output (MIMO) transmission and reception. The transceiver 2330 may include a radio frequency (RF) transmitter and an RF receiver. The memory 2340 may store information processed by the processor 2310, software related to the operation of the base station apparatus 2300, an operating system, an application, and may include components such as a buffer.

The processor 2310 of the base station apparatus 2300 may be set to implement the base station operation in the embodiments described in the present invention. For example, the downlink transmission status information transmitted by the IAB node may be received through the physical layer processing unit 2315 of the base station apparatus 2300, and the physical layer processing unit 2315 may receive the received downlink transmission status information. It can be delivered to the upper layer processing unit 2311.

The upper layer processor 2311 may transmit downlink delivery status information received from the IAB node to the downlink delivery controller 2313. The downlink delivery control unit 2313 receiving the information may solve or prevent a congestion problem by adjusting a downlink delivery speed according to a processing state of each node.

The downlink delivery status report configuration unit 2312 may configure a threshold, offset, or timer to determine that the downlink buffer is congested so that the IAB node can perform a downlink delivery status report. In addition, a timer necessary to construct a downlink delivery status report message can be configured.

Meanwhile, the upper layer processing unit 2311, the random access execution unit 2312, the BWP setting unit 2313, and the physical layer processing unit 2315 of the processor 2310 may be software-configured. Accordingly, the above-described components are not essential components in configuring the IAB donor device 2300, but may be optional components. That is, it may be a configuration described in the drawings as a logical configuration for specifically explaining the operation for the above-described embodiments, and may not necessarily include the implementation. However, for convenience of description, a configuration for performing a specific operation has been described, and is not limited to the above-described embodiment.

The IAB node device 2350 may include a processor 2360, an antenna unit 2370, a transceiver 2380, and a memory 2390. The processor 2360 performs baseband-related signal processing, and may include an upper layer processing unit 2361 and a physical layer processing unit 2365. The upper layer processing unit 2361 may process operations of the MAC layer, the RRC layer, or higher layers. The physical layer processing unit 2365 may process operations of the PHY layer (eg, downlink reception signal processing and uplink transmission signal processing). In addition to performing baseband-related signal processing, the processor 2360 may control overall operation of the IAB node device 2350. The antenna unit 2370 may include one or more physical antennas, and if a plurality of antennas are included, MIMO transmission and reception may be supported. The transceiver 2380 may include an RF transmitter and an RF receiver. The memory 2390 may store information processed by the processor 2360 and software, an operating system, and applications related to the operation of the IAB node device 2350, and may include components such as a buffer. The processor 2360 of the IAB node device 2350 may be set to implement the operation of the IAB node in the embodiments described in the present invention.

The processor 2360 of the IAB node device 2350 may include an upper layer processing unit 2361 and a physical layer processing unit 2365. The upper layer processing unit 2361 may include a downlink delivery status reporting event triggering unit 2362 and a downlink delivery status reporting performing unit 2363.

The downlink delivery status report event triggering unit 2362 may be triggered when it is determined that the downlink data is congested or periodically. If the event has been triggered, the downlink delivery status report event triggering unit 2362 can inform the downlink delivery status reporting execution unit 2363.

The downlink delivery status report performing unit 2363 may determine to perform hop-by-hop or end-to-end flow control according to the triggering condition, and may use the adaptation header, STATUS PDU, or MAC CE to transmit the downlink delivery status message. Can be configured. Thereafter, the message may be transmitted to the physical layer processor 2365 to be transmitted to a parent IAB node, a terminal access IAB node, or an IAB donor.

Meanwhile, the upper layer processing unit 2361, the random access execution unit 2362, the BWP setting unit 2363, and the physical layer processing unit 2365 of the processor 2360 may have a software configuration. Accordingly, the above-described components are not essential components in configuring the IAB node device 2350, but may be optional components. That is, it may be a configuration described in the drawings as a logical configuration for specifically explaining the operation for the above-described embodiments, and may not necessarily include the implementation. However, for convenience of description, a configuration for performing a specific operation has been described, and is not limited to the above-described embodiment.

In the operation of the IAB donor device 2300 and the IAB node device 2350, matters described in the examples of the present invention may be applied in the same way, and duplicate descriptions will be omitted.

Exemplary methods of the present disclosure are expressed as a series of operations for clarity of description, but are not intended to limit the order in which the steps are performed, and each step may be performed simultaneously or in a different order if necessary. example

In order to implement the method according to the disclosure, the illustrated steps may include other steps in addition, other steps may be included in addition to the other steps, or other additional steps may be included in addition to some of the steps.

The various embodiments of the present disclosure are not intended to list all possible combinations, but are intended to describe representative aspects of the present disclosure, and the details described in various embodiments may be applied independently or in combination of two or more.

Further, various embodiments of the present disclosure may be implemented by hardware, firmware, software, or a combination thereof. For implementation by hardware, one or more Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), Programmable Logic Devices (PLDs), Field Programmable Gate Arrays (FPGAs), Universal It can be implemented by a processor (general processor), a controller, a microcontroller, a microprocessor.

The scope of the present disclosure includes software or machine-executable instructions (eg, operating systems, applications, firmware, programs, etc.) that cause actions according to the methods of various embodiments to be executed on a device or computer, and such software or Instructions include a non-transitory computer-readable medium that is stored and executable on a device or computer.

Base station: 2300 Processor: 2310
Upper layer processing unit: 2311 Downlink delivery status reporting component: 2312
Downlink transmission control unit: 2312 Physical layer processing unit: 2315
Antenna section: 2320 transceiver: 2330
Memory: 2340 Terminal: 2350
Processor: 2360 upper layer processing unit: 2361
Downlink delivery status report event triggering unit: 2362
Downlink delivery status report execution unit: 2363
Physical layer processing unit: 2365 Antenna unit: 2370
Transceiver: 2380 Memory: 2390

Claims (1)

In a method of performing an IAB (Integrated Access and Backhaul) in the wireless communication system terminal,
Receiving a downlink delivery status report;
Starting a wait timer for collecting information; And
And stopping the waiting timer and collecting information.

Images