Method and device for integrating access link and backhaul link on basis of non-terrestrial network in wireless communication system

Abstract

This method for performing routing on the basis of an NTN environment in a wireless communication system may comprise the steps of: receiving a configuration of a routing table from an IAB donor-CU; identifying a destination node, a path, and a next hop address related to data on the basis of the routing table; and performing routing on the basis of an IAB node satellite having a configurable path.

Description

Method and device for integrating an access link and a backhaul link based on a non-terrestrial network in a wireless communication system

[0001] The present invention relates to a method for integrating an access link and a backhaul link (integrated access and backhaul, IAB) based on non-terrestrial networks (NTN) in a wireless communication system.

[0002]

[0003] The International Telecommunication Union (ITU) is developing the International Mobile Telecommunication (IMT) framework and standards, and is currently discussing fifth-generation (5G) communications through a program called "IMT for 2020 and beyond."

[0004] To meet the requirements presented in "IMT for 2020 and beyond," the 3rd Generation Partnership Project (3GPP) NR (New Radio) system is being discussed to support various numerologies based on time-frequency resource units, taking into account various scenarios, service requirements, and potential system compatibility.

[0005] In addition, in new communication systems, discussions are underway on how to support seamless communication services at the service level for mobile terminals (e.g., vehicle / train / ship-type terminals / personally-carried smartphones) by utilizing non-terrestrial networks (NTNs) as well as terrestrial networks (TNs). Below, a method for measuring neighboring cells and performing cell reselection by considering the mobility of terminals between NTNs and TNs is described.

[0006]

[0007] The present invention can provide a method and device for integrating an access link and a backhaul link in an NTN environment of a wireless communication system.

[0008] The present invention can provide a method and device for performing routing based on an IAB function in an NTN environment of a wireless communication system.

[0009] The present invention can provide a method and device for configuring a routing table for routing based on an IAB function in an NTN environment of a wireless communication system so that the routing table is set to reflect an ISL backhaul link interruption time and a path interruption time.

[0010] The present invention can provide a method and device for configuring a routing table for routing based on an IAB function in an NTN environment of a wireless communication system so that the routing table is set to reflect information based on distance between satellites.

[0011]

[0012] According to one embodiment, a method for performing routing based on a non-terrestrial networks (NTN) environment in a wireless communication system may include: receiving a routing table from an integrated access backhaul (IAB) donor-CU (central unit); identifying a destination node, a path, and a next hop address related to data based on the routing table; and performing routing based on an IAB node satellite capable of setting a path.

[0013] Additionally, according to one embodiment, the routing table includes at least one entry including a destination node, a path, and a next hop address, wherein each of the at least one entry may further include an interruption time.

[0014] Additionally, according to one embodiment, the downtime may include at least one of a backhaul link downtime and a path downtime, and routing may be performed based on entries that are capable of being routed by the downtime.

[0015] Additionally, according to one embodiment, a distance threshold parameter may be received from an IAB donor CU, and the routing table may include at least one entry including a destination node, a path, and a next hop address, wherein routing may be performed based on an entry in which the distance between the IAB node satellites is less than the distance threshold among the at least one entry.

[0016] Additionally, according to one embodiment, the distance threshold parameter may be included in the Backhaul adaptation protocol (BAP)-config and received from the IAB donor CU.

[0017] Additionally, according to one embodiment, when the backhaul link is unavailable based on a distance threshold, backhaul link unavailability information may be transmitted to the neighboring IAB node satellite.

[0018] Additionally, according to one embodiment, backhaul link unavailability information may be indicated based on a BAP control protocol data unit (PDU).

[0019] The features briefly summarized above regarding the present disclosure are merely exemplary aspects of the detailed description of the present disclosure that follows and do not limit the scope of the present disclosure.

[0020]

[0021] According to the present disclosure, a method for integrating an access link and a backhaul link in an NTN environment of a wireless communication system can be provided.

[0022] According to the present disclosure, a method for performing routing based on an IAB function in an NTN environment of a wireless communication system can be provided.

[0023] According to the present disclosure, when configuring a routing table for routing based on an IAB function in an NTN environment of a wireless communication system, a method can be provided for setting the routing table to reflect an ISL backhaul link outage time and a path outage time.

[0024] According to the present disclosure, when configuring a routing table for routing based on an IAB function in an NTN environment of a wireless communication system, a method can be provided for setting the routing table to reflect distance-based information between satellites.

[0025] The present disclosure is not limited to the effects described above, and other effects not mentioned will be clearly understood by those skilled in the art to which the present disclosure pertains from the description below.

[0026]

[0027] FIG. 1 is a drawing for explaining an NR frame structure to which the present disclosure can be applied.

[0028] FIG. 2 is a diagram showing an NR resource structure to which the present disclosure can be applied.

[0029] FIG. 3 is a diagram illustrating an NTN including a transparent satellite to which the present disclosure can be applied.

[0030] FIG. 4 is a diagram illustrating an NTN including a regenerative satellite without inter-satellite links (ISLs) to which the present disclosure may be applied.

[0031] FIG. 5 is a diagram illustrating an NTN including a regenerative satellite having an ISL to which the present disclosure can be applied.

[0032] FIG. 6 is a diagram illustrating a user plane (UP) protocol stack structure in an NTN including a transparent satellite to which the present disclosure can be applied.

[0033] FIG. 7 is a diagram illustrating a control plane (CP) protocol stack structure in an NTN including a transparent satellite to which the present disclosure can be applied.

[0034] FIG. 8 is a diagram illustrating a timing advance calculation method to which the present disclosure can be applied.

[0035] FIG. 9 is a diagram illustrating an earth fixed cell scenario to which the present disclosure can be applied.

[0036] FIG. 10 is a diagram illustrating an earth moving cell scenario to which the present disclosure can be applied.

[0037] FIG. 11 is a diagram illustrating a method for mapping PCI to satellite beams to which the present disclosure can be applied.

[0038] FIG. 12 is a diagram for explaining an integrated access and backhaul (IAB) operation to which the present disclosure can be applied.

[0039] FIG. 13 is a diagram for explaining the structure of a backhaul adaptation protocol (BAP) to which the present disclosure can be applied.

[0040] FIG. 14 is a diagram for explaining the operation of a backhaul adaptation protocol (BAP) to which the present disclosure can be applied.

[0041] FIG. 15 is a diagram for explaining a radio bearer and RLC channel mapping operation to which the present disclosure can be applied.

[0042] FIG. 16 is a diagram for explaining a radio bearer and RLC channel mapping operation to which the present disclosure can be applied.

[0043] FIG. 17 is a diagram for explaining the operation of an IAB node to which the present disclosure can be applied.

[0044] FIG. 18 is a diagram for explaining the routing operation of an IAB node in a regenerative satellite environment to which the present disclosure can be applied.

[0045] FIG. 19 is a diagram for explaining the routing operation of an IAB node in a regenerative satellite environment to which the present disclosure can be applied.

[0046] FIG. 20 is a diagram for explaining the routing operation of an IAB node in a regenerative satellite environment to which the present disclosure can be applied.

[0047] FIG. 21 is a diagram for explaining the routing operation of an IAB node in a regenerative satellite environment to which the present disclosure can be applied.

[0048] FIG. 22 is a diagram for explaining the motion of a satellite moving over time to which the present disclosure can be applied.

[0049] FIG. 23 is a diagram for explaining the routing operation of an IAB node in a regenerative satellite environment to which the present disclosure can be applied.

[0050] Figure 24 is a diagram showing a BAP Control PDU to which the present disclosure can be applied.

[0051] Figure 25 is a drawing showing a block diagram to which the present disclosure can be applied.

[0052] Figure 26 is a drawing showing a block diagram to which the present disclosure can be applied.

[0053] Figure 27 is a drawing showing a device configuration to which the present disclosure can be applied.

[0054]

[0055] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the attached drawings so that those skilled in the art can easily implement the present disclosure. However, the present disclosure may be implemented in various different forms and is not limited to the embodiments described herein.

[0056] In describing embodiments of the present disclosure, detailed descriptions of known configurations or functions will be omitted if they are deemed to obscure the gist of the present disclosure. Furthermore, portions of the drawings that are irrelevant to the description of the present disclosure have been omitted, and similar portions are designated with similar reference numerals.

[0057] In the present disclosure, when a component is said to be "connected," "coupled," or "connected" to another component, this may include not only a direct connection, but also an indirect connection in which another component exists in between. Furthermore, when a component is said to "include" or "have" another component, unless otherwise specifically stated, this does not exclude the other component, but rather implies that the other component may be included.

[0058] In this disclosure, terms such as first, second, etc. are used solely to distinguish one component from another, and do not limit the order or importance of components unless specifically stated otherwise. Accordingly, within the scope of this disclosure, a first component in one embodiment may be referred to as a second component in another embodiment, and similarly, a second component in one embodiment may be referred to as a first component in another embodiment.

[0059] In this disclosure, distinct components are used to clearly illustrate their respective characteristics, and do not necessarily imply that the components are separated. That is, multiple components may be integrated into a single hardware or software unit, or a single component may be distributed into multiple hardware or software units. Therefore, even if not specifically mentioned, such integrated or distributed embodiments are also included within the scope of this disclosure.

[0060] In the present disclosure, the components described in various embodiments are not necessarily essential components, and some may be optional components. Therefore, embodiments comprising a subset of the components described in one embodiment are also within the scope of the present disclosure. Furthermore, embodiments including other components in addition to the components described in various embodiments are also within the scope of the present disclosure.

[0061] The present disclosure describes a wireless communication network, and operations performed in the wireless communication network may be performed in a process of controlling the network and transmitting or receiving a signal in a system (e.g., a base station) that manages the wireless communication network, or in a process of transmitting or receiving a signal in a terminal connected to the wireless network.

[0062] It is self-evident that various operations performed for communication with terminals in a network consisting of multiple network nodes including a base station can be performed by the base station or other network nodes other than the base station. 'Base station (BS)' can be replaced by terms such as fixed station, Node B, eNodeB (eNB), ng-eNB, gNodeB (gNB), and access point (AP). In addition, 'terminal' can be replaced by terms such as UE (User Equipment), MS (Mobile Station), MSS (Mobile Subscriber Station), SS (Subscriber Station), and non-AP station (non-AP STA).

[0063] In the present disclosure, transmitting or receiving a channel means transmitting or receiving information or a signal through the 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.

[0064] In the following description, the term NR (New Radio) system is used for the purpose of distinguishing the system to which various examples of the present disclosure are applied from existing systems; however, the scope of the present disclosure is not limited by this term.

[0065] NR systems support a variety of subcarrier spacings (SCS) to accommodate diverse scenarios, service requirements, and potential system compatibility. Furthermore, NR systems can support the transmission of physical signals / channels across multiple beams to overcome challenging channel conditions, such as high path loss, phase noise, and frequency offsets that occur at high carrier frequencies. This enables NR systems to 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).

[0066] Hereinafter, 5G mobile communication technology can be defined to include not only the NR system, but also the existing LTE-A (Long Term Evolution-Advanced) system and LTE (Long Term Evolution) system. 5G mobile communication may include technology that operates in consideration of backward compatibility with previous systems as well as the newly defined NR system. Therefore, the 5G mobile communication below may include technology that operates based on the NR system and technology that operates based on previous systems (e.g., LTE-A, LTE), and is not limited to a specific system.

[0067] First, we would like to briefly explain the physical resource structure of the NR system to which the present invention is applied.

[0068] FIG. 1 is a drawing for explaining an NR frame structure to which the present disclosure can be applied.

[0069] In NR, the basic unit of time domain is It can be, , and N can be 4096. Meanwhile, in LTE, the basic unit of the time domain is It can be, And, =2048. The constant for the multiplication relationship between the NR time base unit and the LTE time base unit is k= can be defined as

[0070] Referring to Figure 1, the time structure of a frame for downlink / uplink (DL / UL) transmission is can have. Here, one frame is It consists of 10 subframes corresponding to time. The number of consecutive OFDM symbols in each subframe is = It can be. In addition, each frame is divided into two half frames of the same size, half frame 1 can be composed of sub frames 0-4, and half frame 2 can be composed of sub frames 5-9.

[0071] represents the timing advance (TA) between the downlink (DL) and uplink (UL). Here, the transmission timing of the uplink transmission frame i is determined based on the downlink reception timing at the terminal, based on the following mathematical expression 1.

[0072] [Mathematical Formula 1]

[0073]

[0074] Here, It may be a TA offset value that occurs due to differences in duplex mode, etc. In FDD (Frequency Division Duplex), has a value of 0, but in TDD (Time Division Duplex), it takes into account the margin for DL-UL switching time. It can be defined as a fixed value. For example, in TDD (Time Division Duplex) of FR1 (Frequency Range 1), which is a frequency below 6 GHz, is 39936 or 25600 It could be 39936 is 20.327μs, and 25600 is 13.030μs. Also, at FR2 (Frequency Range 2), which is a millimeter wave (mmWave) frequency, is 13792 It could be. At this time, 13792 is 7.020 μs.

[0075] FIG. 2 is a diagram showing an NR resource structure to which the present disclosure can be applied.

[0076] Resource elements (REs) within a resource grid can be indexed according to each subcarrier spacing. Here, one resource grid can be created for each antenna port and each subcarrier spacing. Uplink and downlink transmission and reception can be performed based on the corresponding resource grid.

[0077] In the frequency domain, one Resource Block (RB) consists of 12 REs, and each of the 12 REs can be configured with an index (nPRB) for one RB. The index for an RB can be utilized within a specific frequency band or system bandwidth. The index for an RB can be defined as in the following mathematical expression 2. Here, represents the number of subcarriers per RB, and k represents the subcarrier index.

[0078] [Equation 2]

[0079]

[0080]

[0081] Different numerologies can be configured to meet the diverse services and requirements of NR systems. For example, while LTE / LTE-A systems can support a single subcarrier spacing (SCS), NR systems can support multiple SCSs.

[0082] A new numerology for NR systems supporting multiple SCSs can operate in frequency ranges or carriers such as below 3GHz, 3GHz-6GHz, 6GHZ-52.6GHz or above 52.6GHz to address the issue of not being able to use wide bandwidth in frequency ranges or carriers such as 700MHz or 2GHz.

[0083] Table 1 below shows examples of numerologies supported by the NR system.

[0084] [Table 1]

[0085]

[0086] Referring to Table 1 above, the numeral can be defined based on the subcarrier spacing (SCS), cyclic prefix (CP) length, and number of OFDM symbols per slot used in the Orthogonal Frequency Division Multiplexing (OFDM) system. The above values ​​can be provided to the terminal through the upper layer parameters DL-BWP-mu and DL-BWP-cp for the downlink, and through the upper layer parameters UL-BWP-mu and UL-BWP-cp for the uplink.

[0087] In Table 1 above, when the subcarrier spacing setting index (u) is 2, the subcarrier spacing (Δf) is 60 kHz, and normal CP and extended CP can be applied. For other numerology indices, only normal CP can be applied.

[0088] A normal slot can be defined as the basic time unit used to transmit a single piece of data and control information in an NR system. The length of a normal slot can be set to the number of OFDM symbols, which is 14 by default. Furthermore, unlike slots, a subframe has an absolute time length equivalent to 1 ms in an NR system and can be used as a reference time for the length of other time intervals. Here, for coexistence or backward compatibility between LTE and NR systems, a time interval similar to an LTE subframe may be required in the NR standard.

[0089] For example, in LTE, data can be transmitted based on a unit of time called a Transmission Time Interval (TTI), which can be set to one or more subframes. Here, one subframe can be set to 1ms and can contain 14 OFDM symbols (or 12 OFDM symbols).

[0090] In addition, a non-slot can be defined in NR. A non-slot can mean a slot having a number that is at least one symbol smaller than a normal slot. For example, in the case of providing low latency such as URLLC service, latency can be reduced through a non-slot having a number of symbols smaller than a normal slot. Here, the number of OFDM symbols included in a non-slot can be determined by considering the frequency range. For example, a non-slot with a length of 1 OFDM symbol can be considered in a frequency range of 6 GHz or higher. As an additional example, the number of OFDM symbols defining a non-slot can include at least 2 OFDM symbols. Here, the range of the number of OFDM symbols included in a non-slot can be set as the length of a mini-slot up to a predetermined length (e.g., the normal slot length - 1). However, as a specification of a non-slot, the number of OFDM symbols may be limited to 2, 4, or 7 symbols, but is not limited thereto.

[0091] Additionally, for example, in unlicensed bands below 6 GHz, subcarrier spacing where u equals 1 and 2 may be used, and in unlicensed bands above 6 GHz, subcarrier spacing where u equals 3 and 4 may be used. For example, when u equals 4, it may be used for SSB (Synchronization Signal Block).

[0092] [Table 2]

[0093]

[0094] Table 2 shows the number of OFDM symbols per slot for normal CP, by subcarrier spacing setting (u). ), number of slots per frame ( ), number of slots per subframe ( ) is shown. Table 2 shows the above-described values ​​based on a normal slot having 14 OFDM symbols.

[0095] [Table 3]

[0096]

[0097] Table 3 shows the number of slots per frame and the number of slots per subframe based on normal slots with 12 OFDM symbols per slot when extended CP is applied (i.e., when u is 2 and the subcarrier spacing is 60 kHz).

[0098] As mentioned above, one subframe may correspond to 1ms on the time axis. Additionally, one slot may correspond to 14 symbols on the time axis. For example, one slot may correspond to 7 symbols on the time axis. Accordingly, the number of slots and symbols that can be considered within 10ms corresponding to one radio frame may be set differently. Table 4 may show the number of slots and symbols according to each SCS. In Table 4, the 480kHz SCS may not be considered, but is not limited to these examples.

[0099] [Table 4]

[0100]

[0101]

[0102] Furthermore, for example, in existing wireless communication systems, communication could be performed based on a terrestrial network comprised of ground-based terminals and ground-based base stations. Terminals could access the network wirelessly. Here, when moving, the terminal could continuously receive the same service through other base stations within the terrestrial network. After connecting to the network, the terminal could access a specific service server through other wired or Internet networks. Furthermore, the terminal could receive services that connected it to other terminals through wired or wireless communication via the network.

[0103] However, new wireless communication systems can support terminal communication not only through terrestrial networks but also through non-terrestrial networks (NTN). Here, NTN can refer to a network or a part of a network that utilizes a mobile device floating in the air or space equipped with a base station or relay equipment. For example, NTN can support terminal-to-terminal communication services based on satellites equipped with communication capabilities in LEO (Low Earth Orbit) and GEO (Geostationary Earth orbit). As another example, NTN can support terminal-to-terminal communication services based on aircraft equipped with communication capabilities within Unmanned Aircraft Systems (UAS), but is not limited thereto.

[0104] Below, we distinguish between terrestrial networks (TN) and non-terrestrial networks (NTN). In existing communication systems, only terrestrial networks existed, so this distinction was not necessary. In contrast, below, we distinguish between NTN and TN as communication systems that enable terminal-to-terminal communication based on NTN, and describe methods for supporting terminal-to-terminal communication services based on these distinctions.

[0105] For example, wireless communication services between ground base stations and wireless terminals or between mobile base stations are described as mobile services, but are not limited thereto. Furthermore, communications between mobile ground base stations and at least one space base station may be considered mobile satellite services. Furthermore, wireless communication services between mobile ground base stations and space base stations, or between mobile ground base stations via at least one space base station, may also be considered mobile satellite services, but are not limited thereto.

[0106] The following describes a method for performing communication based on a wireless communication system that supports both mobile services and mobile satellite services. For example, while NTN technologies have been introduced specifically for satellite communications, NTN can also be introduced in TN communication systems (e.g., 5G systems) to operate alongside TN. Here, a terminal can support both NTN and TN simultaneously. For a terminal that supports both NTN and TN simultaneously, a wireless communication system may require specific NTN technologies in addition to long-term evolution (LTE) and new radio (NR) systems, which are radio access technologies (RATs). The following describes a method for achieving this. For example, the following may be definitions of each term related to NTN and TN.

[0107]

[0108] Non-terrestrial networks (NTN):

[0109] A network or part of a network that utilizes airborne or space-based mobile devices carrying base stations or relay equipment for communications.

[0110]

[0111] NTN Gateway (NTN-gateway):

[0112] A ground station or gateway located on the Earth's surface and equipped with sufficient wireless access equipment to connect to satellites. Typically, an NTN gateway may be a transport network layer node (TNL).

[0113]

[0114] Feeder link:

[0115] Wireless link between NTN gateway and satellite

[0116]

[0117] Geostationary Earth orbit (GEO):

[0118] A circular orbit 35,786 km above the Earth's equator, aligned with the direction of Earth's rotation. Objects or satellites in this orbit revolve with the same period as the Earth's rotation. Therefore, when observed from Earth, they appear to be stationary and motionless.

[0119]

[0120] Low Earth Orbit (LEO):

[0121] Orbits between 300 and 1500 km above the Earth

[0122]

[0123] Medium Earth Orbit (MEO):

[0124] Orbits that exist between LEO and GEO

[0125]

[0126] Unmanned Aircraft Systems (UAS):

[0127] Systems typically operate between 8 and 50 km above ground level and may include high-altitude platforms (HAPs). Unmanned aerial systems may include at least one of the following systems: Tethered UAS (TUA), Lighter Than Air UAS (LTA), and Heavier Than Air UAS (HTA).

[0128]

[0129] Minimum Elevation angle:

[0130] Minimum angle required for a ground terminal to face a satellite or UAS base station in the air

[0131]

[0132] Mobile Services:

[0133] Wireless communication services between ground base stations and wireless terminals or between mobile base stations

[0134]

[0135] Mobile Satellite Services:

[0136] It may be a wireless communication service between mobile ground base stations and one or more space base stations, or between mobile ground base stations and space base stations, or between mobile ground base stations via one or more space base stations.

[0137]

[0138] Non-Geostationary Satellites:

[0139] Satellites in LEO and MEO orbits may be satellites that orbit the Earth with a period of approximately 1.5 to 10 hours.

[0140]

[0141] On Board Processing:

[0142] Digital processing of uplink RF signals mounted on satellite or non-terrestrial equipment

[0143]

[0144] Transparent payload:

[0145] This may mean changing the carrier frequency of the uplink RF signal and filtering and amplifying it before transmitting it via the downlink.

[0146]

[0147] Regenerative payload:

[0148] Modification and amplification of an uplink RF signal before transmission via the downlink. The signal modification may include digital processing such as decoding, demodulation, re-modulation, re-encoding, and filtering.

[0149]

[0150] Onboard NTN gNB:

[0151] It may refer to an onboard satellite with a base station (gNB) implemented in a regenerative payload structure.

[0152]

[0153] On ground NTN gNB:

[0154] A ground base station (GNB) implemented in a transparent payload structure.

[0155]

[0156] One-way latency:

[0157] The time it takes for a wireless terminal to reach a public data network or from a public data network to a wireless terminal in a wireless communication system.

[0158]

[0159] Round Trip Delay (RTD):

[0160] The time it takes for any signal to reach a wireless terminal from an NTN gateway or from an NTN gateway to a wireless terminal and then return back. At this time, the returning signal may be a signal having a different form or message than the above-mentioned arbitrary signal.

[0161]

[0162] Satellite:

[0163] It can be a space vehicle equipped with a radio communication transceiver capable of supporting transparent payloads or regenerative payloads, and can typically be located in LEO, MEO, or GEO orbits.

[0164]

[0165] Satellite beam:

[0166] The beam generated by the antenna of the onboard satellite

[0167]

[0168] Service link:

[0169] Wireless link between satellite and terminal (UE)

[0170]

[0171] User Connectivity:

[0172] The ability to establish and maintain data / voice / video transmission between the network and the terminal.

[0173]

[0174] User Throughput:

[0175] Data transmission rate provided to the terminal

[0176]

[0177] FIG. 3 is a diagram illustrating an NTN including a transparent satellite to which the present disclosure can be applied.

[0178] Referring to FIG. 3, terminals included in the NTN may include terrestrial network terminals. For example, terminals in the NTN and TN may include manned or unmanned vehicles, such as ships, trains, buses, or airplanes, and may not be limited to a specific form. Referring to FIG. 3, a transparent satellite payload generated through a network including transparent satellites may be implemented in a manner corresponding to an RF repeater.

[0179] More specifically, a network including transparent satellites can perform frequency conversion and amplification for radio signals received in both uplink and downlink directions, and transmit the radio signals. Accordingly, the satellites can relay the NR-Uu radio interface, which includes both feeder links and service links, as described below.

[0180] As another example, referring to FIG. 3, a Satellite Radio Interface (SRI) over a feeder link may be included in the NR-Uu interface. That is, the satellite may not be the end point of the NR-Uu interface. Here, the NTN gateway may support all functions necessary to transmit signals defined in the NR-Uu interface. For example, other transparent satellites may be connected to the same base station on the ground. That is, a configuration in which multiple transparent satellites are connected to a single ground base station may also be possible. The base station may be an eNB or a gNB, but may not be limited to a specific form.

[0181] FIG. 4 is a diagram illustrating an NTN including a regenerative satellite without inter-satellite links (ISLs) to which the present disclosure may be applied.

[0182] Referring to Figure 4, the NTN may include a regenerative satellite. Here, a regenerative satellite may mean a satellite that includes a base station function. For example, a regenerative satellite payload generated through a network including a regenerative satellite may be implemented by regenerating a signal received from the ground.

[0183] More specifically, the regenerative satellite can receive signals from the ground based on the NR-Uu radio interface on the service link between the terminal and the satellite. As another example, the regenerative satellite can receive signals from the ground through the SRI (Satellite Radio Interface) on the feeder link between the NTN gateways. Here, the SRI (Satellite Radio Interface) can be defined in the transport layer between the satellite and the NTN gateway. The transport layer can mean the transport layer among the layers defined by the OSI 7 layer. That is, based on the regenerative satellite, the signal from the ground can be transformed based on digital processing such as decoding, demodulation, re-modulation, re-encoding, and filtering, but is not limited thereto.

[0184] FIG. 5 is a diagram illustrating an NTN including a regenerative satellite having an ISL to which the present disclosure can be applied.

[0185] Referring to Figure 5, ISL can be defined at the transport layer. Alternatively, ISL can be defined as a wireless interface or a visible light interface, and is not limited to a specific embodiment. Here, the NTN gateway can support all functions of the transport protocol. Furthermore, each regeneration satellite can serve as a base station, and multiple regeneration satellites can be connected to the same 5G core network on the ground.

[0186] FIG. 6 is a diagram illustrating a user plane (UP) protocol stack structure in an NTN including a transparent satellite to which the present disclosure may be applied. FIG. 7 is a diagram illustrating a control plane (CP) protocol stack structure in an NTN including a transparent satellite to which the present disclosure may be applied.

[0187] The NR Uu interface may be an interface defined by protocols for wireless connection between a terminal and a base station in an NR system. At this time, the NR Uu interface may include a user plane defined by protocols for transmitting user data, including NTN. In addition, the NR Uu interface may include a control plane defined by protocols for transmitting signaling including radio resource control information, including NTN. For example, the Medium Access Control (MAC) layer is set based on Radio Link Control (RLC), Packet Data Convergence Protocol (PDCP), Service Data Adaptation Protocol (SDAP), and Radio Resource Control (RRC), and the protocols for each layer may be defined based on NR among 3GPP RAN-related standards, but may not be limited thereto.

[0188] For example, FIG. 6 may be a UP protocol stack structure based on a transparent satellite. That is, only frequency conversion and amplification of transparently received wireless signals may be performed and transmitted at the satellite and NTN gateway. Furthermore, FIG. 7 may be a CP protocol stack structure based on a transparent satellite. That is, only frequency conversion and amplification of transparently received wireless signals may be performed at the satellite and NTN gateway.

[0189] Based on the above, a wireless communication system supporting terminal-to-terminal communication using NTN and TN can be considered. For example, NTN may have a longer roundtrip time (RTT) between the terminal and the base station than conventional TN. Therefore, from a UP perspective, the terminal needs to buffer data to be transmitted via both uplink and downlink for a longer period of time due to the increased RTT. In other words, the terminal needs to store more data in the buffer. Consequently, the terminal may require a larger memory capacity than conventional systems, which will be discussed later.

[0190] Figure 8 is a diagram illustrating a timing advance calculation method applicable to the present disclosure. As described above, satellites included in NTNs are located in the sky, which can result in longer signal round-trip times (RTTs). For example, LEO satellites are located 300 to 1,200 km above the Earth's surface, while GEO satellites are located more than 36,000 km above the equator. Therefore, propagation delays in NTNs can be significantly greater than in TNs. On the other hand, because NTNs are located in the sky, they can offer greater cell coverage than terrestrial networks.

[0191] That is, since NTN may have different RTT and cell coverage compared to TN, there is a need to redefine the method for obtaining time synchronization for uplink transmission in NTN. As an example, FIG. 8 may be a method for calculating TA values ​​that occur depending on the satellite payload type.

[0192] More specifically, FIG. 8(a) may be a method for calculating a TA value when the satellite payload type is a playback payload. Additionally, FIG. 8(b) may be a method for calculating a TA value when the satellite payload type is a transparent payload.

[0193] Here, we consider a case where the terminal knows the satellite ephemeris and its position to ensure initial access and ongoing maintenance of the timing advance (TA) value. Here, the satellite ephemeris can refer to the distance between each satellite and the receiver and the position of each satellite. For example, the terminal can acquire the TA value on its own and then apply it (Option 1). Alternatively, the terminal can receive instructions for TA compensation and correction from the network (Option 2).

[0194] For example, referring to Fig. 8(a), if the satellite payload type is a replay payload, the satellite can directly perform the role of a base station. At this time, the terminal can calculate the TA value required for uplink transmission including the PRACH (physical random access channel). The terminal can calculate a common TA value (Tcom) and a terminal-specific TA value (TUEx). For example, the common TA value (Tcom) may be a TA value required for all terminals due to the large cell coverage and long round trip time (RTT) of the NTN. That is, since the NTN is located in the sky and is a relatively long distance compared to the distance between terminals, a common TA value (Tcom) that takes into account the long round trip time (RTT) in cell coverage may be required. In addition, the terminal-specific TA value (TUEx) may be a value generated due to the different locations of each terminal within the cell coverage. If the terminal knows the position of the satellite at a specific time in advance through the satellite ephemeris stored in advance or received from NTN, and the position of the terminal is known through a function such as GNSS, the terminal can calculate the distance between the satellite and the terminal at a specific time, and can then obtain the TA value on its own and correct the TA value, thereby determining the TA value.

[0195] Through the above, the terminal can perform uplink timing alignment between terminals received from the base station with full TA compensation.

[0196] As another example, the terminal can perform downlink and uplink frame timing alignment on the network side. As shown in Fig. 8(b), if the satellite payload type is a transparent payload, the satellite can perform filtering and amplification of the radio signal and transmit the signal to the NTN gateway. In other words, the satellite can act as an RF repeater. At this time, there may be cases where the NTN gateway needs to be changed based on the continuous movement of the satellite. In Fig. 8(b), the common TA value (Tcom) can be determined based on the sum of the distance D01 between the reference point and the satellite and the distance D02 between the satellite and the NTN gateway. At this time, the feeder link can be changed as the NTN gateway changes based on the movement of the satellite. In other words, the distance between the satellite and the NTN gateway can be changed based on the changed feeder link. Therefore, the common TA value that occurs may be changed, and there is a need to perform an update at the corresponding terminal. In addition, when setting an offset between the downlink frame timing and the uplink frame timing in the network, there is a need to additionally consider the case where the TA value generated by the feeder link is not compensated by the overall TA compensation method. In addition, when the terminal can only calculate a different TA value (TUEx) for each terminal, the terminal needs to confirm one reference point for each beam or cell and needs to transmit information about it to other terminals. When setting an offset between the downlink frame timing and the uplink frame timing in the network, the network needs to manage the offset information regardless of the satellite payload type. Here, as an example, the network may provide a value for TA compensation to each terminal, and is not limited to the above-described embodiment.

[0197] As another example, a method for directing TA compensation and correction in the network (Option 2) can be considered. In this case, a common TA value can be generated based on common factors for propagation delay shared by all terminals located within the coverage area of ​​a satellite beam or cell. The network can broadcast the common TA value to the terminals for each satellite beam or cell. The common TA value can be calculated by the network assuming at least one reference position for each satellite beam or cell. In addition, the terminal-specific TA value (TUEx) can be determined based on the random access procedure defined in the existing communication system (e.g., Release 15 or Release 16 of the existing NR system). In this case, for example, when applying long TA values ​​and negative TA values, a new field may be required in the random access message. For example, if the network provides a timing change rate to the terminal, the terminal can support TA value correction based on this.

[0198] FIG. 9 is a diagram illustrating an earth fixed cell scenario to which the present disclosure can be applied.

[0199] Referring to FIG. 9, a fixed cell may be a cell with a fixed location from which a signal is transmitted from a satellite. For example, since a satellite moves over time, the antenna and beam must be varied so that the service coverage is fixed to a specific location in order to maintain a fixed cell. At this time, as an example, satellite 1 (910) in FIG. 9 can maintain a fixed cell by varying the antenna and beam during T1 to T3. Here, when a specific time (T4) elapses, satellite 1 can no longer service the corresponding location, so satellite 2 (920) provides service at the corresponding location to maintain service continuity. At this time, the beam or cell of satellite 2 (920), which services the same location as the location serviced by satellite 1 (910) in the previous time (T1 to T3) after time T4, may maintain the characteristics of the beam or cell of satellite 1 (910), and is not limited to the above-described embodiment.

[0200] For a more specific example, when a service is provided by satellite 1 (910) and satellite 2 (920), at least one of the physical cell ID (PCI) value and system information may remain the same. That is, as a cell with fixed service coverage, it may be generally set based on satellites in LEO and MEO orbits excluding GEO, which can vary the angles of their antennas and beams.

[0201] In contrast, FIG. 10 is a diagram illustrating an earth moving cell scenario to which the present disclosure may be applied. For example, a cell with a moving service coverage may be an earth moving cell.

[0202] For example, referring to FIG. 10, satellite 1 (1010), satellite 2 (1020), and satellite 3 (1030) can each provide services to cells having different PCIs. At this time, the antenna and beam through which the satellite transmits signals to the ground are fixed, and the type in which the service coverage moves as the satellite moves over time can be referred to as an Earth moving cell. The Earth moving cell can be established based on satellites in LEO and MEO orbits excluding GEO, among which the antenna and beam angles are fixed. Here, the satellites can have the advantages of being cheaper and having a lower failure rate compared to satellites that can adjust the angles of the antenna and beam.

[0203] Additionally, FIG. 11 is a diagram illustrating a method of mapping PCI to satellite beams to which the present disclosure can be applied.

[0204] For example, a PCI may refer to an index that can logically distinguish one cell. That is, beams having the same PCI value may be included in the same cell. For example, referring to FIG. 11(a), a PCI may be assigned to multiple satellite beams. On the other hand, referring to FIG. 11(b), one PCI may be assigned to each satellite beam in one satellite. For example, a satellite beam may be composed of one or more SSB (Synchronization Signal Block, SS / PBCH block) beams. One cell (or PCI) may be composed of up to L SSB beams. Here, L may be 4, 8, 64, or 256 depending on the size of the frequency band and / or subcarrier band, but is not limited to the above-described embodiment. That is, L may be similar to a terrestrial network (TN), which is an existing communication system (NR system), in which one or more SSB indices may be used for each PCI. Through this, SSBs transmitted through different beams can be distinguished, and SSB indices can be mapped to logically defined antenna ports or physically distinct beams.

[0205] For example, a terminal that can access NTN may be a terminal that supports GNSS (Global Navigation Satellite System) functionality. However, terminals that can access NTN may also include terminals that do not support GNSS. As another example, NTN may also support terminals that support GNSS functionality but are unable to obtain location information via GNSS, and the present invention is not limited to the above-described embodiment.

[0206] As described above, terminals can communicate via NTN. For example, terminals can receive non-terrestrial network-based services based on 5G / B5G NTN. This allows terminals to avoid the regional, environmental, spatial, and economic constraints of wireless access services (e.g., LTE, NR, WiFi, etc.) that rely on terrestrial network equipment. For example, based on the aforementioned approach, advanced wireless access technologies provided on terrestrial networks can be applied to non-terrestrial network platforms (e.g., satellites and UAVs). This allows for the provision of various wireless access service products and technologies alongside advanced network technologies.

[0207] NTN platforms can operate as a sort of mirror, relaying NR signals in space or at high altitudes, or by embedding base station (gNB, eNB) functionality. For example, NG-RAN-based NTN architectures can be implemented with "Transparent payload-based NTN" and "Regenerative payload-based NTN" structures, as previously mentioned.

[0208] Furthermore, as an example, NTN technology can be utilized as an extended network structure and technology for the 5G Integrated Access and Backhaul (IAB) architecture, enabling wider coverage and more wireless access services. The integration of NTN and terrestrial networks can ensure service continuity and scalability of 5G systems.

[0209] For example, integrated NTN and TN networks can offer significant benefits in terms of 5G target performance (e.g., user experience, data transmission rate, and reliability) in urban and suburban areas. Furthermore, integrated NTN and TN networks can ensure connectivity not only in highly dense areas (e.g., concert halls, sports stadiums, shopping centers, etc.), but also for fast-moving objects such as airplanes, high-speed trains, vehicles, and ships. Furthermore, integrated NTN and TN networks can utilize multi-connection capabilities to simultaneously access data transmission services from both NTN and TN networks. This allows for selective utilization of a better network depending on traffic characteristics and load levels, achieving both efficiency and cost-effectiveness for 5G wireless transmission services.

[0210] A terminal on a flat surface can simultaneously connect to both the NTN network and the TN network to utilize wireless data services. Furthermore, the terminal can simultaneously connect to one or more NTN platforms (e.g., two or more LEO / GEO satellites) to provide wireless data access services for harsh environments or regions where the TN network is difficult to support. This allows the terminal to be utilized in conjunction with various services. In particular, the integrated NTN and TN networks can enhance the reliability of autonomous driving services and facilitate efficient network operation, and are not limited to the above-described embodiments.

[0211] Here, for example, V2X technology based on LTE mobile communication or standard technology based on the IEEE 802.11p standard may have similar limitations in the services that can be provided. The LTE V2X standard can be provided to meet the requirements defined in C-ITS (e.g., time delay of about 100ms, reliability of about 90%, and generation of messages of tens to hundreds of bytes 10 times per second, etc.). Therefore, new V2X services that require low latency, high reliability, high-capacity data traffic, and improved positioning may be needed. At this time, for example, the standardization of 5G wireless access technology (e.g., NR (New Radio)) is in progress based on the above-mentioned. In addition, for example, standardization of various numerologies, frame structures, and corresponding L2 / L3 protocol structures is in progress to be able to respond more flexibly to the requirements of new services than LTE. Based on the above, it may be possible to support enhanced V2X services such as autonomous driving and remote driving by introducing sidelink wireless access technology based on 5G mobile communication technology, and the NTN network may be utilized for this purpose.

[0212] As another example, NTN networks can be utilized to support IoT services in harsh environments and areas not covered by terrestrial networks. For example, IoT devices often require wireless communication with minimal power consumption in harsh channel environments (e.g., mountains, deserts, or oceans), depending on their intended use. Existing cellular-based technologies may primarily be targeted at mobile broadband (MBB) services. Therefore, they may be inefficient in terms of wireless resource utilization and power control when providing IoT services, and may not support flexible operation. Furthermore, existing non-cellular IoT technologies may have limitations in providing diverse IoT services due to limited mobility support and coverage. Considering the aforementioned issues, NTN networks can be applied, thereby improving services.

[0213] Furthermore, for example, if 5G mobile communication-based sidelink technology were applied to the NTN network, it could provide users with wider coverage and mobility through a more efficient wireless communication method than the current Bluetooth / Wi-Fi-based wearable devices. Furthermore, it could differentiate itself from existing communication standards in applications requiring high data rates and mobility support using wearable devices (e.g., wearable multimedia services).

[0214] Another example is that NTN networks can improve public safety communications networks and expand disaster communications coverage. For example, the high reliability and low latency of 5G mobile communication systems can be leveraged through NTN networks to provide public services such as disaster response. For example, mobile base stations, such as drones supporting 5G mobile communications, can be used to support mobile broadband services even in deserts and high mountainous areas. In other words, applying NTN networks to public services can expand disaster communications coverage by covering a wider range of areas.

[0215] FIG. 12 is a diagram illustrating a method for integrating an access link and a backhaul link to which the present disclosure is applicable.

[0216] Referring to Figure 12, integrated access and backhaul (IAB) can be applied to a wireless communication system. In a cellular network scenario consisting of densely deployed cells (e.g., NR cells), a wireless backhaul function may be required where the cells are not connected to the network by wires. For example, in a wireless communication system (e.g., NR), a wider bandwidth can be used than in previous wireless communication systems (e.g., LTE) through massive MIMO (multi-input, multi-output) and multiple beams. Therefore, IAB technology, which integrates access links and backhaul links, can be flexibly supported in wireless communication systems, and additionally developed technologies can be applied to wireless communication systems in the future.

[0217] As an example, FIG. 12 is a diagram illustrating an IAB network. However, this is merely an example and may not be limiting. Referring to FIG. 12, IAB nodes (IAB nodes) (1210, 1220, 1230) can perform multiplexing in terms of time, frequency, and space. IAB nodes (1210, 1220, 1230) can communicate based on the same frequency (in-band) or different frequency (out-of-band) bands in the access link and backhaul link. For example, when the access link and backhaul link use different frequency bands, the placement of IAB nodes (1210, 1220, 1230) can be relatively easy, and the impact of interference can be reduced. On the other hand, when the access link and backhaul link use the same frequency band, the IAB nodes (1210, 1220, 1230) need to perform actions to avoid or mitigate interference.

[0218] For example, a base station may be connected to the core network via a wired connection. Here, the base station may function as an IAB donor and be connected to one or more IAB nodes via a backhaul link. Conversely, a base station without a wired connection can receive data from a terminal via an access link and transmit the data to a base station with a wired connection via a backhaul link.

[0219] IAB operation can be supported to address the short radio range issues in mmWave. Here, IAB operation can be supported to address the short radio range issues as described above by utilizing one or more multi-hop wireless backhauling operations. Specifically, IAB nodes can have one or more backhaul links. Accordingly, multi-hop backhauling can perform adaptive path selection to select the IAB node to transmit data.

[0220] FIG. 13 is a diagram illustrating a BAP sublayer to which the present disclosure is applicable. FIG. 13 is a diagram illustrating a backhaul adaptation protocol (BAP) layer required for IAB operation. Referring to FIG. 13, the BAP layer may be required to support routing of an IAB-based wireless backhaul. The BAP layer may exist above the RLC (radio link control) layer based on a radio interface structure. The BAP layer may exist in the distributed unit (DU) of the IAB donor and the DU and mobile terminal (MT) of the IAB node, and may be responsible for routing and RLC channel mapping functions for multi-hop-based relay transmission. The DU of the IAB node may be responsible for a base station function, and the MT of the IAB node may be responsible for a terminal function.

[0221] Figure 14 is a diagram illustrating the functions of a BAP sublayer to which the present disclosure is applicable. The BAP layer of an IAB node may have one BAP entity in the MT function and may have BAP entities collocated separately in the DU function. Here, each BAP entity may have a transmitting part and a receiving part.

[0222] Figure 14 illustrates the functions of a BAP entity. The receiving part of a BAP entity can forward BAP protocol data units (PDUs) to the transmitting part of a collocated BAP entity. In addition, the receiving part of a BAP entity can forward BAP service data units (SDUs) to the transmitting part of a collocated BAP entity. When BAP SDUs are forwarded, the receiving part of a BAP entity can remove a BAP header. On the other hand, the transmitting part of a collocated BAP entity can add a BAP header. In addition, the BAP entity can generate, forward, and receive BAP control PDU(s). The transmitting part of the BAP entity can perform routing, BH RLC channel mapping, and BAP header rewriting functions.

[0223] For example, routing can be performed based on a routing table. An IAB donor-CU (centralized unit) can configure a routing table for each IAB node via RRC (radio resource control) / F1AP (F1 application protocol) messages. The routing table can be composed of one or more entries. Table 5 below is an example of a routing table, but is not limited thereto. An entry in the routing table can include a destination address (BAP address), a BAP routing ID (BAP Routing ID) including a BAP path identifier (BAP path ID), and a next-hop BAP address, as shown in Table 5.

[0224] [Table 5]

[0225]

[0226]

[0227] FIG. 15 is a diagram illustrating a method for mapping a terminal bearer and a BH RLC channel to which the present disclosure is applicable. Referring to FIG. 15, terminals (1510, 1520), an IAB node (1530), and an IAB donor (1540) may establish a backhaul link (BH link) and a BH RLC link. However, FIG. 15 is merely an example for convenience of explanation and may not be limited thereto. For example, the data radio bearer (DRB) of each terminal (1510, 1520) may be mapped to a respective BH RLC channel. Here, each BH RLC channel may be separated and transmitted in the next hop. The number of BH RLC channels may be equal to the number of DRBs configured in the terminal. Then, when multiple BH RLC channels are multiplexed into one logical channel, the BAP header may include an identifier set for each BH RLC channel.

[0228] As a specific example, in FIG. 15, terminal 1 (1510) may be configured with DRB 1 for VoIP, DRB 2 for streaming, and DRB 3 for web browsing. Terminal 2 (1520) may be configured with DRB 1 for VoIP and DRB 2 for streaming. Here, DRB 1 of terminal 1 may be mapped to BH RLC channel 1, and DRB 1 of terminal 2 may be mapped to BH RLC channel 4. In addition, DRB 2 of terminal 1 may be mapped to BH RLC channel 2, and DRB 2 of terminal 2 may be mapped to BH RLC channel 5. In addition, DRB 3 of terminal 1 may be mapped to BH RLC channel 3. That is, each of the DBRs of multiple terminals may be mapped to one BH RLC channel.

[0229] FIG. 16 is a diagram illustrating a method for mapping terminal bearers and BH RLC channels to which the present disclosure is applicable. Referring to FIG. 16, terminals (1610, 1620), an IAB node (1630), and an IAB donor (1640) can establish a BH link and a BH RLC link. However, FIG. 16 is merely an example for convenience of explanation and may not be limited thereto. For example, bearers of multiple terminals (1610, 1620) can be mapped to a single BH RLC channel based on parameters (e.g., bearer quality of service (QoS)). The IAB node (1630) can multiplex DRBs of the same type from multiple terminals (1610, 1620) onto a single BH RLC channel.

[0230] As a specific example, when the QoS of all traffic in the DBRs of multiple terminals is the same, the DBRs of the multiple terminals may be mapped to a single BH RLC channel and transmitted. For example, in FIG. 16, terminal 1 (1610) may be configured with DRB 1 for VoIP, DRB 2 for streaming, and DRB 3 for web browsing. Terminal 2 (1620) may be configured with DRB 1 for VoIP and DRB 2 for streaming. Here, DRB 1 of terminal 1 and DRB 1 of terminal 2 may be mapped to BH RLC channel 1 as a single BH RLC channel. Similarly, DRB 2 of terminal 1 and DRB 2 of terminal 2 may be mapped to BH RLC channel 2 as a single BH RLC channel. Since DRB 3 is configured only in terminal 1, DRB 3 may be mapped to RLC channel 3 as a single BH RLC channel. That is, the DBRs of multiple terminals can be mapped to one BH RLC channel.

[0231] The terminal bearer and the BH RLC channel can be mapped 1:1 or N:1, as shown in FIGS. 15 and 16. Here, each mapping method differs in terms of data transmission overhead, IAB node complexity, and scheduling. Specifically, the 1:1 mapping method may not require the inclusion of a terminal identifier and a DRB identifier. On the other hand, the N:1 mapping method may require a terminal identifier and a DRB identifier. Therefore, the 1:1 mapping method may have lower data transmission overhead than the N:1 mapping method.

[0232] Additionally, the DRB information of a terminal can be derived by the LCID (Logical Channel ID). Therefore, when applying the 1:1 mapping method, the LCID needs to be extended. In addition, the N:1 mapping method needs to operate by including DRB information in the header and transmitting it. In addition, since the N:1 mapping method maps multiple terminal DRBs to a single BH RLC channel, it is necessary for all terminals to successfully transmit DRBs. In other words, if the DRB transmission of one terminal continuously fails, the DRBs of other terminals cannot be transmitted, which may block transmission opportunities.

[0233] FIG. 17 is a diagram illustrating ingress / egress of BH links and BH RLC channels to which the present disclosure is applicable. FIG. 17 illustrates ingress / egress BH links and BH RLC channels through which BAP data packets are transmitted from IAB nodes (1710, 1720, 1730, 1740). Referring to FIG. 17, an ingress BH link may be a BH link transmitted from a previous hop IAB node. In addition, an ingress BH RLC channel may refer to one or more BH RLC channels configured within a BH link of a previous hop IAB node. For example, in FIG. 17, an ingress BH link may be configured from a previous hop IAB node 1 (1710) to an IAB node 2 (1720). In addition, multiple ingress BH RLC channels may be configured within the ingress BH link. However, this is merely an example for the convenience of explanation and may not be limited thereto. An egress BH link may refer to a BH link to be transmitted to the next hop IAB node. In addition, an egress BH RLC channel may refer to one or more BH RLC channels configured within the BH link to be transmitted to the next hop IAB node. In FIG. 17, an egress BH link may be configured from IAB node 2 (1720) to the next hop IAB node 3 (1730) or IAB node 4 (1740). In addition, multiple egress BH RLC channels may be configured within the egress BH link. However, this is merely an example for the convenience of explanation and may not be limited thereto.

[0234] For example, Table 6 may be a BH RLC channel mapping configuration. Specifically, Table 6 may be a BH RLC channel mapping configuration that the network sets (or configures) in the IAB node. When the IAB node receives data from the previous hop and forwards it to the next hop, the IAB node may determine the next BH RLC channel ID (Egress BH RLC Channel ID) through the BH link ID (Ingress link ID), BH RLC channel ID (Ingress BH RLC Channel ID) from the previous hop, and the determined next hop BAP address (Egress link ID). As a specific example, referring to FIG. 17, the previous hop IAB node 1 (1710) may transmit data to IAB node 2 (1720). The IAB node 2 (1720) may check whether the destination address of the BAP header in the data from the IAB node 1 (1710) is its own address. IAB node 2 (1720) can forward BAP SDUs to upper layers if the destination address is its own address. Conversely, IAB node 2 (1720) can forward data to the transmission part of the BAP entity if the destination address is not its own address.

[0235] For example, in FIG. 17, we can consider a case where an IAB node transmits data of a previous hop as data of a next hop. Here, the BAP address of IAB node 1 (1710), which is a previous hop of IAB node 2 (1720), may be 1, and the BAP addresses of IAB node 3 (1730) and IAB node 4 (1740), which are next hops of IAB node 2 (1720), may be 2 and 3, respectively. In addition, the BH RLC channel ID (BH RLC channel ID) may be set to BIT STRING (SIZE (16)). The BH RLC channel ID may be included in a BH link between IAB nodes. For example, in IAB node 2 (1720), the egress BH RLC channel IDs may be distinguished as 1, 2, 3, 4, 5, and 6. Here, referring to Table 6, IAB node 2 (1720) may select egress RLC channel ID 6 when the BAP address of the previous hop IAB node 1 (1710) is 1, the ingress BH RLC channel ID is 2, and the BAP address of the selected next hop is 3. However, this is only one example for convenience of explanation and is not limited to the above-described embodiment.

[0236] [Table 6]

[0237]

[0238]

[0239] As described above, communication can be performed in an NTN environment. Here, IAB functionality can be applied to NTN environments, thereby resolving issues arising there. As an example, the following describes solutions to newly emerging issues arising when IAB functionality is applied to NTN environments.

[0240] For example, a satellite used in an NTN environment may be a regenerative-payload satellite or a transparent-payload satellite, although this may not be limited thereto. A regenerative-payload satellite may refer to a satellite equipped with a base station (BS) function, either a DU function or all functions. A transparent-payload satellite may refer to a satellite that relays signal transmission by performing filtering and amplification before transmitting the signal.

[0241] As an example, the following describes a case where the IAB function is applied to an NTN environment based on a regenerative-payload type satellite equipped with the full functionality of a base station or DU functionality, but is not limited thereto and may also be applied in the same or similar form to a transparent-payload satellite.

[0242] An NTN environment may be one in which communications are performed based on satellites. Satellites may continuously move around the Earth. Links may be established for communication. Satellite-based links may include, but are not limited to, feeder links and intersatellite links (ISLs). A feeder link may be a link between an IAB donor satellite and an NTN gateway. As another example, if the NTN gateway is an IAB donor, a feeder link may be a link between the IAB donor and an IAB node satellite. An ISL may be a link between an IAB donor satellite and an IAB node satellite, or between two IAB node satellites. Here, feeder links and ISLs may be interrupted due to satellite movement. A link interruption may refer to an environment in which communication is impossible due to the distance between satellites and the distance between satellites and the gateway. In other words, a link interruption may refer to a state in which communication is impossible due to a decrease in communication quality caused by an increase in the distance between satellites.

[0243] IAB functionality can be applied in an NTN environment, and routing can be performed between IAB node satellites based on IAB functionality. For example, IAB node satellite-based routing can successfully transmit data only when it avoids paths with expected link outages or paths with link outages. Therefore, IAB node satellite-based routing must consider ISL link outage information, and a method for achieving this is described below.

[0244] For example, IAB node satellite-based routing can be performed to select the next-hop IAB node satellite while considering ISL link outages. Here, IAB node satellite-based routing can be performed so that the next-hop IAB node satellite is determined based on time. IAB node satellite-based routing can configure the IAB node satellite by including ISL outage time information in the routing table, as will be described later.

[0245] As another example, IAB node satellite-based routing can be performed by determining backhaul link unavailability based on distance. For example, the above-described routing may be performed based on the distance between an IAB node and the next-hop IAB node, but is not limited thereto.

[0246] As another example, IAB node satellite-based routing can be performed by indicating backhaul link unavailability based on distance. For example, the above-described indication can be performed based on at least one of a BAP control PDU and a medium access control (MAC) control element (CE), but is not limited thereto.

[0247] FIG. 18 is a diagram illustrating a method for selecting a next-hop IAB node satellite and performing a route selection operation when performing IAB node satellite-based routing applicable to the present disclosure. Referring to FIG. 18, IAB donor satellite (IAB donor satellite, 1820), IAB node satellite 1 (1830), and IAB node satellite 2 (1840) may be satellites moving along the same orbit. On the other hand, IAB node satellite 3 (1850) may be a satellite moving along a different orbit from the above-described orbit. However, FIG. 18 is merely an example for convenience of explanation and may not be limited thereto.

[0248] Referring to FIG. 18, routing based on the IAB function may be performed based on IAB node satellites (1820, 1830, 1840, 1850). As a specific example, routing may be determined to perform communication to a terminal (1860) through an IAB donor satellite (1820), an IAB node satellite 1 (1830), and an IAB node satellite 2 (1840) as path 1. As another example, routing may be determined to perform communication to a terminal (1860) through an IAB donor satellite (1820), an IAB node satellite 3 (1850), an IAB node satellite 1 (1830), and an IAB node satellite 2 (1840) as path 2, but may not be limited thereto. Here, routing may be set in consideration of the ISL validity time between satellites.

[0249] For example, referring to FIG. 18(a), routing can be performed based on path 1 or path 2 at time T1. The ISL between the IAB donor satellite (1820) and the IAB node satellite 1 (1830) and the ISL between the IAB node satellite 1 (1830) and the IAB node satellite 2 (1840) can be valid regardless of time because they are satellites in the same orbit. In addition, the ISL between the IAB donor satellite (1820) and the IAB node satellite 3 (1850) and the ISL between the IAB node satellite 3 (1850) and the IAB node satellite 1 (1830) can be valid at time T1. Therefore, routing can be performed based on path 1 or path 2 at time T1, and IAB node satellite 1 (1830) can transmit upstream data directly to IAB donor satellite (1820) (path 1) or through IAB node satellite 3 (1850). (path 2) For example, IAB node satellite 1 (1830) can perform local routing to select the path of IAB node satellite 3 (1850) when it is determined that the ISL backhaul link between IAB node satellite 1 (1830) and IAB donor satellite (1820) is unavailable due to radio link failure (RLF) or flow control.

[0250] On the other hand, referring to Fig. 18(b), routing can be performed only by path 1 at time T2. The ISL between the IAB donor satellite (1820) and IAB node satellite 1 (1830) and the ISL between the IAB node satellite 1 (1830) and IAB node satellite 2 (1840) can be valid regardless of time since they are satellites in the same orbit. On the other hand, the ISL between the IAB donor satellite (1820) and IAB node satellite 3 (1850) may not be valid at time T2. Therefore, routing may not be performed based on path 2 at time T2, and IAB node satellite 1 (1830) can transmit upstream data only through IAB donor satellite (1820). (Path 1) That is, path 2 cannot be used because the ISL backhaul link between IAB node satellite 3 (1850) and IAB donor satellite (1820) is unavailable due to satellite mobility. Here, if IAB node satellite 3 (1850) and IAB donor satellite (1820) determine that the ISL backhaul link between IAB node satellite 3 (1850) and IAB donor satellite (1820) is unavailable due to RLF (radio link failure) or flow control, they may instruct IAB node satellite 1 (1830), which is a lower IAB node satellite, not to use the backhaul link.

[0251] FIG. 19 is a diagram illustrating a method for selecting a next-hop IAB node satellite and performing a route selection operation when performing IAB node satellite-based routing applicable to the present disclosure. Referring to FIG. 19, an IAB donor (1910) may be located on the ground. For example, the IAB donor (1910) may be an NTN gateway, but may not be limited thereto. Here, IAB node satellite 4 (1920), IAB node satellite 1 (1930), and IAB node satellite 2 (1940) may be satellites that move along the same orbit. On the other hand, IAB node satellite 3 (1950) may be a satellite that moves along a different orbit from the above-described orbit. However, FIG. 19 is merely an example for convenience of explanation and may not be limited thereto.

[0252] Referring to FIG. 19, routing based on the IAB function may be performed based on IAB node satellites (1920, 1930, 1940, 1950). As a specific example, routing may be determined to perform communication to a terminal (1960) through IAB node satellite 4 (1920), IAB node satellite 1 (1930), and IAB node satellite 2 (1940) as path 1. As another example, routing may be determined to perform communication to a terminal (1960) through IAB node satellite 4 (1920), IAB node satellite 3 (1950), IAB node satellite 1 (1930), and IAB node satellite 2 (1940) as path 2, but may not be limited thereto. Here, routing may be set in consideration of the ISL validity time between satellites.

[0253] For example, referring to FIG. 19(a), routing can be performed based on path 1 or path 2 at time T1. The ISL between IAB node satellite 4 (1920) and IAB node satellite 1 (1930) and the ISL between IAB node satellite 1 (1930) and IAB node satellite 2 (1940) can be valid regardless of time because they are satellites in the same orbit. In addition, the ISL between IAB node satellite 4 (1920) and IAB node satellite 3 (1950) and the ISL between IAB node satellite 3 (1950) and IAB node satellite 1 (1930) can be valid at time T1. Therefore, routing can be performed based on path 1 or path 2 at time T1, and IAB node satellite 1 (1930) can forward data to IAB node satellite 4 (1920), and the data can be forwarded to IAB donor (1910). (Path 1) In addition, IAB node satellite 1 (1930) can forward upstream data to IAB node satellite 4 (1920) via IAB node satellite 3 (1950), and finally the upstream data can be forwarded to IAB donor (1910). (Path 2) For example, IAB node satellite 1 (1930) may perform local routing to select a path to IAB node satellite 3 (1950) if it determines that the ISL backhaul link between IAB node satellite 1 (1930) and IAB node satellite 4 (1920) is unavailable due to radio link failure (RLF) or flow control.

[0254] On the other hand, referring to Fig. 19(b), routing can be performed based on path 1 at time T2. The ISL between IAB node satellite 4 (1920) and IAB node satellite 1 (1930) and the ISL between IAB node satellite 1 (1930) and IAB node satellite 2 (1940) can be valid regardless of time since they are satellites in the same orbit. On the other hand, the ISL between IAB node satellite 4 (1920) and IAB node satellite 3 (1950) may not be valid at time T2. Therefore, routing may not be performed based on path 2 at time T2, and IAB node satellite 1 (1930) can transmit upstream data to IAB donor (1910) only via IAB node satellite 4 (1920) (path 1). That is, path 2 cannot be used because the ISL backhaul link between IAB node satellite 3 (1950) and IAB node satellite 4 (1920) is unavailable due to satellite mobility. Here, if IAB node satellite 3 (1950) and IAB node satellite 4 (1920) determine that the ISL backhaul link between IAB node satellite 3 (1950) and IAB node satellite 4 (1920) is unavailable due to RLF (radio link failure) or flow control, they may instruct the lower IAB node satellite, IAB node satellite 1 (1930), not to use the backhaul link.

[0255] FIG. 20 is a diagram illustrating a method for selecting a next-hop IAB node satellite and performing a route selection operation when performing IAB node satellite-based routing applicable to the present disclosure. Referring to FIG. 20, an IAB donor satellite (IAB donor satellite, 2020) and an IAB node satellite 2 (2040) may move along satellite orbit 1 (satellite movement direction). On the other hand, IAB node satellite 1 (2030) and IAB node satellite 3 (2050) may move along satellite orbit 2. However, FIG. 20 is merely an example for convenience of explanation and may not be limited thereto.

[0256] Referring to FIG. 20, routing based on the IAB function may be performed based on IAB node satellites (2020, 2030, 2040, 2050). As a specific example, routing may be determined to perform communication to a terminal (2060) through an IAB donor satellite (2020), an IAB node satellite 1 (2030), and an IAB node satellite 2 (2040) as path 1. As another example, routing may be determined to perform communication to a terminal (2060) through an IAB donor satellite (2020), an IAB node satellite 3 (2050), and an IAB node satellite 2 (2040) as path 2, but may not be limited thereto. Here, routing may be performed in consideration of the ISL validity time between satellites.

[0257] For example, referring to FIG. 20(a), routing may be performed based on path 1 or path 2 at time T1. IAB node satellite 2 (2040) may transmit data to IAB donor satellite (2020) via either IAB node satellite 1 (2030) on path 1 or IAB node satellite 3 (2050) on path 2 at time T1. Accordingly, routing may be performed based on path 1 or path 2 at time T1.

[0258] On the other hand, referring to FIG. 20(b), routing can be performed based on path 1 at time T2. IAB node satellite 2 (2040) can transmit data to IAB donor satellite (2020) via IAB node satellite 1 (2030) of path 1 at time T2, but cannot transmit data to IAB donor satellite (2020) via IAB node satellite 3 (2050) of path 2. That is, IAB node satellite 2 (2040) cannot use the ISL backhaul link between IAB node satellite 2 (2040) and IAB node satellite 3 (2050) at time T2 due to satellite mobility, and therefore cannot use path 2, and can only use path 1.

[0259] FIG. 21 is a diagram illustrating a method for selecting a next-hop IAB node satellite and performing a route selection operation when performing IAB node satellite-based routing applicable to the present disclosure. Referring to FIG. 21, an IAB donor (2110) may be located on the ground. For example, the IAB donor (2110) may be an NTN gateway, but may not be limited thereto. In addition, IAB node satellite 2 (2140) and IAB node satellite 4 (2120) may move along satellite orbit 1 (satellite movement direction). On the other hand, IAB node satellite 1 (2130) and IAB node satellite 3 (2150) may move along satellite orbit 2. However, FIG. 21 is merely an example for convenience of explanation and may not be limited thereto.

[0260] Referring to FIG. 21, routing based on the IAB function may be performed based on IAB node satellites (2120, 2130, 2140, 2150). As a specific example, routing may be determined to perform communication to a terminal (2160) through IAB node satellite 4 (2120), IAB node satellite 1 (2130), and IAB node satellite 2 (2140) as path 1. As another example, routing may be determined to perform communication to a terminal (2160) through IAB node satellite 4 (2120), IAB node satellite 3 (2150), and IAB node satellite 2 (2140) as path 2, but may not be limited thereto. Here, routing may be performed in consideration of the ISL validity time between satellites.

[0261] For example, referring to FIG. 21(a), routing may be performed based on path 1 or path 2 at time T1. IAB node satellite 2 (2140) may transmit upstream data to IAB node satellite 4 (2120) via either IAB node satellite 1 (2130) of path 1 or IAB node satellite 3 (2150) of path 2 at time T1, so that it may be delivered to the IAB donor (2110). Accordingly, routing may be performed based on path 1 or path 2 at time T1.

[0262] On the other hand, referring to FIG. 21(b), routing can be performed based on path 1 at time T2. IAB node satellite 2 (2140) can transmit upstream data to IAB node satellite 4 (2120) via IAB node satellite 1 (2130) of path 1 at time T2 so that it can be delivered to IAB donor (2110), but cannot transmit upstream data to IAB node satellite 4 (2120) via IAB node satellite 3 (2150) of path 2 so that it can be delivered to IAB donor (2110). That is, IAB node satellite 2 (2140) cannot use the ISL backhaul link between IAB node satellite 2 (2140) and IAB node satellite 3 (2150) at time T2 due to satellite mobility, and therefore cannot use path 2, and can only use path 1.

[0263] That is, the above-described Figures 18 to 21 may be cases where the ISL backhaul link is interrupted due to satellite mobility in an NTN environment. Routing based on the IAB function needs to be configured to take the above-described link interruption into account, and this will be described below.

[0264] Routing can be performed based on a routing table. The IAB donor CU can establish a routing table for each IAB node via RRC / F1AP messages. The routing table can consist of one or more entries, as shown in Table 5 above.

[0265] For example, the routing table (or routing table configuration) may further include the ISL backhaul link outage time or the path outage time. Specifically, the IAB donor-CU may configure the routing table based on at least one of the ISL backhaul link outage time and the path outage time, and transmit an RRC / F1AP message including the routing table information to the IAB node satellite. That is, the routing table may include information regarding at least one of the path outage time and the backhaul link outage time. The IAB node satellite may recognize at least one of the path outage time and the backhaul link outage time information through the routing table, and may use the information during routing.

[0266] As a specific example, Table 7 below may be an uplink backhaul routing configuration or a routing table. Table 7 may include at least one of ISL backhaul link interruption time and path interruption time information, but may not be limited thereto. In addition, the routing table of Table 7 may be a parameter configured for each IAB node satellite when performing RRC and F1 establishment. Referring to Table 7, the routing table may include a BAP routing ID including a destination node address (BAP Address (DESTINATION)) and a path identifier (BAP path ID). Here, the destination node address (BAP Address (DESTINATION)) and the path identifier (BAP path ID) may each be set to a BIT STRING SIZE (10)), but are not limited thereto. In addition, the routing table may include a next-hop BAP address (Next-hop BAP Address). Here, the next hop BAP address can be configured as the egress BH link ID on the IAB node, and the next hop BAP address can be set to BIT STRING SIZE (10), but is not limited thereto. Here, the routing table can further include a stop time. The stop time can mean an integer value expressed in units of 10ms after 1900 / 01 / 01 in epoch time (e.g. INTEGER (0..549755813887)).

[0267] For example, the outage time may include at least one of the ISL backhaul link outage time and the route outage time information. That is, when the IAB node satellite receives the routing table configuration, it can recognize the time when the link of the corresponding route is out of order based on the outage time information. As a more specific example, the IAB node satellite can recognize the time when the link of the corresponding route is out of order based on the BAP route ID of the route corresponding to the entry. As another example, the IAB node satellite can recognize the time when the link with the next IAB node satellite is out of order based on the egress BH link ID of the route corresponding to the entry.

[0268] As another example, the interruption time may have a preset periodic value. For example, each IAB node satellite may move along a satellite orbit, and based on this, link interruption times may occur periodically. The interruption time information may indicate the time at which the link is interrupted based on the preset periodic value described above.

[0269] As another example, the interruption time may have a timer value. For example, the timer may be set to have units of seconds, minutes, or hours, and the time at which the link is interrupted may be determined based on this. More specifically, if a timer corresponding to an entry is set, the IAB node satellite may recognize the time at which the link with the next IAB node satellite is interrupted based on the BAP path ID and the egress BH link ID.

[0270] [Table 7]

[0271]

[0272]

[0273] As a specific example, Table 8 may be a method for including downtime information in a routing table considering an IAB node satellite. For example, Table 8 may include at least one of ISL backhaul link downtime and path downtime information in a routing table configured in the IAB node satellite 1 of FIG. 18 or FIG. 19 described above. IAB node satellite 1 may receive a routing table configured for uplink transmission from an IAB donor-CU located on the ground. A1 may refer to a BAP address of the IAB donor satellite in Table 8. In addition, when multiple paths exist, paths (path 1, path 2) may refer to identifiers for each path. In addition, the next-hop BAP address may refer to the next hop of uplink transmission in the routing table. Accordingly, the next-hop BAP address may be the IAB donor satellite or IAB node satellite 3, and the next-hop BAP address may be set differently for each path. In addition, the downtime may be configured as an absolute time in the routing table. More specifically, the outage time may mean at least one of the ISL backhaul link outage time and the path outage time. The outage time may be configured for each entry. For example, in FIG. 18 or FIG. 19, IAB node satellite 1 may be able to use both entries 1 and 2 of Table 8 at time T1. On the other hand, IAB node satellite 1 may determine that information corresponding to entry 2 of Table 8 is not available at time T2. IAB node satellite 1 may recognize the outage time information of entry 2 and thus recognize that entry 2 is not available at time T2. That is, IAB node satellite 1 may recognize that communication via the ISL backhaul link between the IAB donor satellite and IAB node satellite 3 cannot be performed at time T2. Therefore, IAB node satellite 1 may determine that entry 2, whose next hop address is IAB node satellite 3, is not available.For example, the downtime may be determined by the network based on, but not limited to, satellite orbit information held by each satellite.

[0274] [Table 8]

[0275]

[0276]

[0277] As another example, Table 9 may include at least one of the ISB backhaul link interruption time and path interruption time information configured in IAB node satellite 2 of FIG. 20 or FIG. 21 described above. In FIG. 20 or FIG. 21, IAB node satellite 2 may receive a routing table for uplink transmission from an IAB donor CU located on the ground. For example, in Table 9, A1 may denote a BAP address of the IAB donor satellite. In addition, when multiple paths exist, paths (path 1, path 2) may denote identifiers for each path. In addition, the next-hop BAP address may denote the next hop of uplink transmission in the routing table. Accordingly, the next-hop BAP address may be IAB node satellite 1 or IAB node satellite 3, and the next-hop BAP address may be set differently for each path. In addition, the interruption time may be configured as an absolute time within the routing table. The downtime may refer to at least one of the ISL backhaul link downtime and the path downtime. The downtime may be configured for each entry.

[0278] More specifically, the outage time may mean at least one of the ISL backhaul link outage time and the path outage time. The outage time may be configured for each entry. For example, in FIG. 20 or FIG. 21, IAB node satellite 2 may be able to use both entries 1 and 2 of Table 9 at time T1. On the other hand, IAB node satellite 2 may determine that information corresponding to entry 2 of Table 9 is not available at time T2. IAB node satellite 2 may recognize the outage time information of entry 2 and thus recognize that entry 2 is not available at time T2. That is, IAB node satellite 2 may recognize that communication via the ISL backhaul link between IAB node satellite 2 and IAB node satellite 3 cannot be performed at time T2. Therefore, IAB node satellite 2 may determine that entry 2, whose next hop address is IAB node satellite 3, is not available. For example, the downtime may be determined by the network based on, but not limited to, satellite orbit information held by each satellite.

[0279] [Table 9]

[0280]

[0281]

[0282] For example, the above-described operation can be applied to all of FIGS. 18 to 21. That is, it can be applied to both scenarios where the IAB donor is located on the ground or on a satellite. Furthermore, the above-described operation is not limited to the earth-fixed cell scenarios of FIGS. 18 to 21, where a satellite serves a specific area at a specific time, but can also be applied to an earth-moving cell, and is not limited to a specific form. Furthermore, although the above-described operation is described based on the number of IAB hops being two, it is not limited thereto and can be equally applied to cases where there is one hop or more than two hops.

[0283] As another example, the next hop IAB node satellite in routing can be determined based on distance. FIG. 22 is a diagram showing ECEF (Earth-Centered, Earth-Fixed) coordinates and Ellipsoid-Point of satellite orbit information (ephemeris) to which the present disclosure is applicable. As an example, satellite orbit information (ephemeris) can be expressed based on ECEF coordinate information. ECEF coordinate information can indicate x, y, z values ​​with respect to the center of the earth and the movement speed in each axis in km / s. Ellipsoid-point information can indicate latitude ( , longitude), longitude ( , latitude) and longitude can indicate whether the satellite is located in the northern or southern hemisphere based on the equator. For example, Tables 10 and 11 can be examples of satellite coordinates and velocities according to absolute time (epoch time). Referring to Tables 10 and 11, the valid starting position of the satellite coordinates and velocities can be indicated through a specific SFN and subframe. For example, the network can transmit one absolute time (epoch time, SFN & Subframe) and the corresponding satellite coordinates and velocities to the terminal through system information (e.g. SIB19). Thereafter, the network can update the system information to modify the absolute time (epoch time) and the satellite coordinates and velocities.

[0284] As a specific example, the terminal can acquire system information. Here, the system information may include parameters for absolute time (epoch time), and the valid starting point may be indicated through the SFN and subframe. For example, if the terminal confirms the absolute time (epoch time) corresponding to SFN 100 and subframe 2 and the corresponding satellite coordinates and velocity, the terminal can determine that the satellite coordinates and velocity are valid from the time of SFN 100 and subframe 2. Thereafter, if the terminal acquires system information and confirms the absolute time (epoch time) corresponding to SFN 200 and subframe 2 and the corresponding satellite coordinates and velocity, the terminal can update the absolute time (epoch time) and the corresponding satellite coordinates and velocity.

[0285] [Table 10]

[0286]

[0287] [Table 11]

[0288]

[0289]

[0290] For example, a satellite can move at a specific speed in a specific orbit. Therefore, the distance between adjacent satellites can be determined based on satellite orbital information. The IAB node satellite can utilize the distance information between satellites during routing, thereby recognizing when a link is interrupted. As a specific example, the IAB node satellite can determine the distance from the next-hop IAB node satellite or IAB donor satellite during routing. The IAB node satellite can determine that the link is unusable if the distance between satellites exceeds a preset threshold. For example, the preset threshold may be a distance threshold, which can be configured by the network during RRC or F1 setup. As a more specific example, when the network performs initial RRC setup with the IAB node satellite, the network can include the distance threshold information between satellites in the RRC reconfiguration message and transmit it. The distance threshold between satellites may be the DistanceThresh parameter, but may not be limited to that name.

[0291] Table 12 below may be a BAP-config configuration within an RRC reconfiguration message. For example, BAP-config may include bap-Adress as a BAP address to be used by the IAB node. Additionally, BAP-config may include defaultUL-BAP-RoutingID indicating a default uplink routing identifier. defaultUL-BAP-RoutingID may be used for F1-C and non-F1 traffic transmission during IAB-MT RRC re-establishment, IAB-MT RRC Resume, migration, and IAB node bootstrapping procedures of the IAB node.

[0292] Additionally, BAP-config may include defaultUL-BH-RLC-Channel. defaultUL-BH-RLC-Channel may indicate the default backhaul RLC channel. defaultUL-BH-RLC-Channel may be used for F1-C and non-F1 traffic transmission during IAB-MT RRC re-establishment, IAB-MT RRC resume, migration, and IAB node bootstrapping procedures of the IAB node.

[0293] Additionally, BAP-config may include flowControlFeedbackType. FlowControlFeedbackType may instruct the IAB node to perform flow control for each hop for each Routing ID. Furthermore, FlowControlFeedbackType may instruct the IAB node to perform flow control for each hop for each BH RLC channel. Furthermore, FlowControlFeedbackType may instruct the IAB node to perform flow control for each hop for each Routing ID and BH RLC channel, and is not limited to a specific form.

[0294] Here, as an example, BAP-config may further include the DistanceThresh parameter described above. DistanceThresh may indicate a distance threshold from the next hop node during routing from the IAB node. The IAB node may only use IAB node satellites within the distance threshold as its next hop.

[0295] [Table 12]

[0296]

[0297]

[0298] As a specific example, Table 13 may be a routing table configured based on distance. For example, Table 13 may be a routing table of IAB node satellite 2 of FIG. 20 or FIG. 21, but this is merely a configuration for convenience of explanation and may not be limited thereto. IAB node satellite 2 may receive a routing table for uplink transmission from an IAB donor CU located on the ground, as described above. Referring to Table 13, A1 may refer to a BAP address of the IAB donor satellite. In addition, when multiple paths exist, paths (path 1, path 2) may refer to identifiers for each path. In addition, the next-hop BAP address may refer to the next hop of uplink transmission in the routing table. Accordingly, the next-hop BAP address may be IAB node satellite 1 or IAB node satellite 3, and the next-hop BAP address may be configured differently for each path.

[0299] Here, the routing table for determining the next hop may not include downtime, unlike the time-based next hop IAB node satellite determination method described above. For example, the IAB node satellite may apply a distance threshold configured by the network to all entries in common. That is, when routing is performed on the IAB node satellite, the IAB node satellite may select a backhaul link in the configured routing table where the distance from the next hop IAB node satellite is less than the distance threshold as the next hop IAB node satellite.

[0300] More specifically, the distance threshold may be a parameter used by the IAB node satellite to determine the next hop IAB node satellite. The distance threshold may be used to calculate the distance from the satellite corresponding to the next hop BAP address in the IAB node satellite and to determine whether the backhaul link is available. For example, in FIG. 20 or FIG. 21, IAB node satellite 2 may have both entries 1 and 2, which are composed of IAB node satellite 1 and IAB node satellite 3, as next hops, available at time T1. On the other hand, IAB node satellite 2 may determine that the information corresponding to entry 2 is not available at time T2. When performing routing at time T2, IAB node satellite 2 may recognize that the distance to IAB node satellite 3 is greater than the configured distance threshold. In other words, IAB node satellite 2 may determine that the backhaul link of IAB node satellite 3 is not available at time T2.

[0301] [Table 13]

[0302]

[0303]

[0304] As another example, an IAB node satellite can indicate to an adjacent IAB node satellite that an IAB-based backhaul link is unavailable when performing routing. In an NTN environment, the IAB node satellite can recognize the locations of each adjacent IAB node satellite. Therefore, the IAB node satellite can determine the availability of the backhaul link by checking the distance from the adjacent IAB node satellite or IAB donor satellite to which the backhaul link is connected. The IAB node satellite can determine the availability of the backhaul link in the downstream and upstream directions in the same way. For example, in a conventional IAB operation, the IAB node can measure the signal strength of the parent node and generate an RLF if the signal quality is lower than a threshold value a large number of times over a preset period of time. The IAB node can then indicate an RLF for the backhaul link of the parent node to the child node. Since the IAB node satellite determines the availability of the backhaul link in the downstream and upstream directions in the same way, it can operate faster than the method described above.

[0305] FIG. 23 is a diagram illustrating a method for selecting a next-hop IAB node satellite and performing a route selection operation when performing IAB node satellite-based routing applicable to the present disclosure. Referring to FIG. 23, IAB donor satellite (IAB donor satellite) 2320, IAB node satellite 1 (2330), and IAB node satellite 2 (2340) may be satellites moving along the same orbit. On the other hand, IAB node satellite 3 (2350) may be a satellite moving along a different orbit from the above-described orbit. However, FIG. 23 is merely an example for convenience of explanation and may not be limited thereto.

[0306] For example, the IAB node satellite of FIG. 23 may indicate whether a distance-based backhaul link is unavailable. Specifically, referring to FIG. 23(b), the distance between IAB node satellite 3 (2350) and IAB donor satellite (2320) may be greater than a distance threshold. Here, the IAB node satellite may determine that the backhaul link between IAB node satellite 3 (2350) and IAB donor satellite (2320) is unavailable. For example, IAB node satellite 2 (2340) and IAB node satellite 1 (2330) may perform routing to perform uplink transmission of a terminal. Here, IAB node satellite 2 (2340) and IAB node satellite 1 (2330) may determine not to select a path to IAB node satellite 3 (2350) at time T2. Therefore, IAB node satellite 3 (2350) needs to instruct its child node satellite, IAB node satellite 1 (2330), that the path through IAB node satellite 3 (2350) is not possible.

[0307] Here, the IAB node satellite can transmit a BAP Control PDU (BAP Control PDU) to indicate the backhaul link unavailability (BH Unavailable) to neighboring nodes in both upstream and downstream directions. Furthermore, as an example, FIG. 23 can be applied equally to a case where the IAB donor is located on the ground and operates based on an IAB node satellite, as in FIG. 19, and is not limited to a specific form.

[0308] FIG. 24 is a diagram illustrating a BAP control PDU to which the present disclosure is applicable. Referring to FIG. 24, an IAB node satellite may transmit a BAP control PDU to indicate that a backhaul link is unavailable in the upstream and downstream directions. The BAP control PDU may include a 1-bit D / C (2410). The 1-bit D / C may be a field indicating whether it is a BAP data PDU (BAP Data PDU) or a BAP control PDU. In addition, the 1-bit R may be a reserved bit that may be reserved for other functions and purposes in the future. In addition, the 4-bit PDU type (2420) may be a field indicating each of various types of BAP control PDUs based on Table 14. For example, the BAP control PDU may include a value for the BAP control field indicating that the backhaul link is unavailable. The BAP control field value indicating that the backhaul link is unavailable may be '0110' in Table 14, but this is only one example and may have other values. For example, the BAP control field value indicating that the backhaul link is unavailable may be set to a single value between 0110 and 1111 and is not limited to a specific format.

[0309] [Table 14]

[0310]

[0311]

[0312] FIG. 25 is a flowchart illustrating an IAB node satellite operation to which the present disclosure is applicable. Referring to FIG. 25, an IAB node satellite may receive a routing table configuration from an IAB donor-CU (S2510). Thereafter, the IAB node satellite may identify destination node, path, and next-hop address information related to data (S2520) and perform routing based thereon. For example, the routing table may include at least one entry including a destination node, path, and next-hop address. In addition, each of the at least one entry may further include an interruption time. The interruption time may include at least one of a backhaul link interruption time and a path interruption time, as described above. Here, if route setting is possible based on the downtime of the routing table (S2530), the IAB node satellite can perform routing based on the IAB node satellite for which route setting is possible (S2540). On the other hand, if route setting is not possible based on the downtime of the routing table (S2530), the IAB node satellite can perform routing by excluding the IAB node satellite for which route setting is not possible, as described above (S2550). Routing can be performed based on the entry for which route setting is possible by the downtime.

[0313] FIG. 26 is a flowchart illustrating an IAB node satellite operation applicable to the present disclosure. Referring to FIG. 26, the IAB node satellite may receive a routing table configuration from the IAB donor CU (S2610). Thereafter, the IAB node satellite may identify destination node, path, and next-hop address information related to data (S2620) and perform routing based thereon. For example, the routing table may include at least one entry including a destination node, a path, and a next-hop address. In addition, the IAB node satellite may receive a distance threshold parameter from the IAB donor CU. For example, the distance threshold parameter may be included in BAP-config and received from the IAB donor CU, but may not be limited thereto. In addition, the routing table may include at least one entry including a destination node, a path, and a next-hop address. Here, the IAB node satellite may perform routing based on an entry in which the distance between the IAB node satellites is less than a distance threshold among at least one entry. That is, if the distance between satellites is greater than the distance threshold (S2630), the IAB node satellite determines that the backhaul link is unavailable and can perform routing by excluding the satellite (S2640). On the other hand, if the distance between satellites is less than the distance threshold (S2630), the IAB node satellite determines that the backhaul link is available and can perform routing based on the satellite (S2660).

[0314] Additionally, the IAB node satellite may transmit backhaul link unavailability information to neighboring IAB node satellites when the backhaul link is unavailable. For example, the backhaul link unavailability information may be indicated based on the BAP control PDU, as described above. The features briefly summarized above regarding the present disclosure are merely exemplary aspects of the detailed description of the present disclosure described below and do not limit the scope of the present disclosure.

[0315] Figure 27 is a drawing showing a device configuration to which the present disclosure can be applied.

[0316] Referring to FIG. 27, a first device (2700) and a second device (2750) can communicate with each other. In this case, as an example, the first device (2700) may be a base station device and the second device (2750) may be a terminal device. As another example, both the first device (2700) and the second device (2750) may be terminal devices. As another example, the first device (2700) may be an IAB donor-CU and the second device (2750) may be an IAB node satellite. In other words, the first device (2700) and the second device (2750) may be devices that communicate with each other based on NR-based communication, and are not limited to a specific form.

[0317] The first device (2700) may include a processor (2720), an antenna unit (2712), a transceiver (2714), and a memory (2716). The processor (2720) performs baseband-related signal processing and may include a higher layer processing unit (2730) and a physical layer processing unit (2740). The higher layer processing unit (2730) may process operations of a medium access control (MAC) layer, a radio resource control (RRC) layer, or higher layers. The physical layer processing unit (2740) may process operations of a physical (PHY) layer (e.g., uplink reception signal processing, downlink transmission signal processing). In addition to performing baseband-related signal processing, the processor (2720) may also control the overall operation of the first device (2700). The antenna unit (2712) may include one or more physical antennas, and when it includes multiple antennas, it may support MIMO (Multiple Input Multiple Output) transmission and reception. In addition, beamforming may be supported. The memory (2716) may store information processed by the processor (2720), software related to the operation of the first device (2700), an operating system, applications, etc., and may include components such as a buffer. The processor (2720) of the first device (2700) may be configured to implement the operation of the first device in the embodiments described in the present invention.

[0318] The second device (2750) may include a processor (2770), an antenna unit (2762), a transceiver (2764), and a memory (2766). For example, in the present invention, the second device (2750) may communicate with the first device (2700). The processor (2770) may perform baseband-related signal processing and may include a higher layer processing unit (2780) and a physical layer processing unit (2790). The higher layer processing unit (2780) may process operations of a MAC layer, an RRC layer, or higher layers. The physical layer processing unit (2790) may process operations of a PHY layer (e.g., downlink reception signal processing, uplink transmission signal processing, sidelink signal processing). In addition to performing baseband-related signal processing, the processor (2770) may also control operations of the overall terminal device (2750). The antenna unit (2762) may include one or more physical antennas, and when it includes multiple antennas, it may support MIMO transmission and reception. In addition, it may support beamforming. The memory (2766) may store information processed by the processor (2770), software related to the operation of the second device (2750), an operating system, applications, etc., and may include components such as a buffer. The second device (2750) according to an example of the present invention may be associated with a vehicle. For example, the second device (2750) may be integrated into the vehicle, located in the vehicle, or located on the vehicle. In addition, the second device (2750) according to the present invention may be the vehicle itself. In addition, the second device (2750) according to the present invention may be at least one of a wearable terminal, an AV / VR, an IoT terminal, a robot terminal, and a public safety terminal.The terminal device (2750) to which the present invention is applicable may include any type of communication device that supports interactive services utilizing sidelink for services such as Internet access, service execution, navigation, real-time information, autonomous driving, and safety and risk diagnosis. Furthermore, any type of communication device capable of sidelink operation, such as an AR / VR device or sensor that performs relay operations, may be included.

[0319] Here, the vehicles / terminals to which the present invention is applied may include autonomous vehicles / driving terminals, semi-autonomous vehicles / driving terminals, non-autonomous vehicles / driving terminals, etc. Meanwhile, although the second device (2750) according to an example of the present invention is described as being associated with a vehicle, one or more of the UEs may not be associated with a vehicle. This is merely an example, and should not be construed as limiting the application of the present invention to the described example. In addition, the second device (2750) according to an example of the present invention may also include various types of communication devices capable of performing cooperation to support interactive services utilizing sidelink. In other words, the second device (2750) may not only directly support interactive services utilizing sidelink, but may also be utilized as a cooperation device to support interactive services utilizing sidelink.

[0320] For example, the second device (2750) may be an IAB node satellite. Here, the IAB node satellite (2750) may receive a routing table configuration from the IAB donor-CU, which is the first device (2700). Thereafter, the IAB node satellite (2750) may identify destination node, path, and next-hop address information related to the data and perform routing based thereon. For example, the routing table may include at least one entry including the destination node, path, and next-hop address. In addition, each of the at least one entry may further include an outage time. The outage time may include at least one of a backhaul link outage time and a path outage time, as described above. Here, if route configuration is possible based on the outage time of the routing table, the IAB node satellite (2750) may perform routing based on an IAB node satellite capable of route configuration. On the other hand, if route setting is not possible based on the downtime of the routing table, the IAB node satellite (2750) can perform routing while excluding the IAB node satellite for which route setting is not possible, as described above. Routing can be performed based on entries for which route setting is possible based on the downtime.

[0321] As another example, the IAB node satellite (2750) may receive a routing table configuration from the IAB donor-CU (2700). Thereafter, the IAB node satellite (2750) may identify destination node, path, and next-hop address information related to data and perform routing based thereon. For example, the routing table may include at least one entry including the destination node, path, and next-hop address. In addition, the IAB node satellite (2750) may receive a distance threshold parameter from the IAB donor-CU (2700). For example, the distance threshold parameter may be included in BAP-config and received from the IAB donor CU (2700), but may not be limited thereto. In addition, the routing table may include at least one entry including the destination node, path, and next-hop address. Here, the IAB node satellite (2750) may perform routing based on an entry in which the distance between the IAB node satellites is less than the distance threshold among the at least one entry. That is, if the distance between satellites is greater than the distance threshold, the IAB node satellite (2750) determines that the backhaul link is unavailable and can perform routing by excluding the satellite. On the other hand, if the distance between satellites is less than the distance threshold, the IAB node satellite (2750) determines that the backhaul link is available and can perform routing based on the satellite.

[0322] Additionally, the IAB node satellite (2750) may transmit backhaul link unavailability information to an adjacent IAB node satellite when the backhaul link is unavailable. For example, the backhaul link unavailability information may be indicated based on the BAP control PDU, as described above. The features briefly summarized above for the present disclosure are merely exemplary aspects of the detailed description of the present disclosure described below and do not limit the scope of the present disclosure.

[0323] Additionally, various embodiments of the present disclosure may be implemented by hardware, firmware, software, or a combination thereof. In the case of hardware implementation, the embodiments may be implemented by 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), general processors, controllers, microcontrollers, microprocessors, etc.

[0324] The scope of the present disclosure includes software or machine-executable instructions (e.g., operating systems, applications, firmware, programs, etc.) that cause operations according to the methods of various embodiments to be executed on a device or a computer, and a non-transitory computer-readable medium having such software or instructions stored thereon and executable on the device or computer.

[0325] The various embodiments of the present disclosure are not intended to list all possible combinations but rather to illustrate representative aspects of the present disclosure, and the matters described in the various embodiments may be applied independently or in combination of two or more.

[0326]

[0327] The following may also apply to other systems:

Claims

1. A method for performing routing based on a non-terrestrial networks (NTN) environment in a wireless communication system, A step of configuring a routing table from an IAB (integrated access backhaul) donor-CU (central unit); A step of identifying a destination node, a path, and a next hop address related to the data based on the above routing table; and A method for performing routing, comprising the step of performing routing based on an IAB node satellite capable of setting a route.

2. In paragraph 1, The routing table includes at least one entry including the destination node, the route, and the next hop address, A method of performing routing, wherein each of said at least one entry further includes a downtime.

3. In paragraph 2, The above downtime includes at least one of a backhaul link downtime and a path downtime, A routing method, wherein the above routing is performed based on an entry capable of setting a route by the above interruption time.

4. In paragraph 1, Receive a distance threshold parameter from the above IAB donor CU, The routing table includes at least one entry including the destination node, the route, and the next hop address, A routing method, wherein the routing is performed based on an entry among at least one entry in which the distance between IAB node satellites is less than a distance threshold value.

5. In paragraph 4, A routing method wherein the above distance threshold parameter is included in the BAP (Backhaul adaptation protocol)-config and received from the IAB donor CU.

6. In paragraph 5, A routing method, wherein when the backhaul link is unavailable based on the above distance threshold, information on the unavailability of the backhaul link is transmitted to an adjacent IAB node satellite.

7. In paragraph 6, A routing method in which the above backhaul link unavailability information is indicated based on a BAP control PDU (protocol data unit).

Images