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

Abstract

This wireless device may include a wireless transceiver, one or more processors, and a memory for storing instructions for the wireless device, when executed by the one or more processors. Here, operations of the wireless device comprise: performing a random access procedure with a satellite IAB node on the basis of NTN IAB topology integration; performing an RRC connection establishment procedure with the satellite IAB node on the basis of the random access procedure; acquiring an NTN IAB-related parameter in the RRC connection establishment procedure; and selecting an AMF on the basis of the NTN IAB-related parameter, wherein the NTN IAB-related parameter may be configured on the basis of at least one of an NTN IAB operation indicator, a satellite orbit, and a cell type.

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 access links and backhaul links (integrated access and backhaul, IAB) based on non-terrestrial networks (NTN) in a wireless communication system. Specifically, the present invention relates to a method for integrating new satellite IAB nodes based on an NTN IAB topology adaptation procedure.

[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 integrating a new satellite IAB node in an NTN IAB environment of a wireless communication system.

[0009] The present invention can provide a method and device for instructing NTN IAB operation in an NTN IAB environment of a wireless communication system.

[0010] The present invention can provide a method and device for setting NTN IAB operation function related parameters in an NTN IAB environment of a wireless communication system.

[0011]

[0012] According to one embodiment, a wireless device may include a wireless transceiver, one or more processors, and a memory that stores instructions for the wireless device when executed by the one or more processors. Here, the operation of the wireless device may include: performing a random access procedure with a satellite IAB node based on integration of a non-terrestrial networks (NTN) integrated access backhaul (IAB) topology; performing an RRC (radio resource control) connection establishment procedure with the satellite IAB node based on the random access procedure, obtaining NTN IAB-related parameters in the RRC connection establishment procedure; and selecting an access management function (AMF) based on the NTN IAB-related parameters, wherein the NTN IAB-related parameters may be set based on at least one of an NTN IAB operation indicator, a satellite orbit, and a cell type.

[0013] Also, according to one embodiment, a wireless device may include a wireless transceiver, one or more processors, and a memory that stores instructions for the wireless device when executed by the one or more processes, wherein the operation of the wireless device includes: obtaining NTN IAB-related parameters from at least one potential parent IAB node, and selecting a parent IAB node based on the NTN IAB-related parameters, wherein the NTN IAB-related parameters may be set based on at least one of a gateway connectivity validity time, a hop count, and whether or not a satellite is in geostationary orbit.

[0014] Also, according to one embodiment, a wireless device may include a wireless transceiver, one or more processors, and a memory that stores instructions for the wireless device when executed by the one or more processors. Here, the operation of the wireless device is to: obtain measurement configuration information for a measurement report, obtain NTN IAB related parameters from at least one satellite IAB node, and perform the measurement report by determining whether to perform the measurement report, wherein the NTN IAB related parameters may be set based on at least one of a gateway connectivity validity time, a hop count, and whether the satellite is in a geostationary orbit.

[0015] 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.

[0016]

[0017] According to the present disclosure, there is an effect of providing a method for integrating an access link and a backhaul link in an NTN environment of a wireless communication system.

[0018] According to the present disclosure, there is an effect of providing a method for integrating a new satellite IAB node in an NTN IAB environment of a wireless communication system.

[0019] According to the present disclosure, there is an effect of providing a method for instructing NTN IAB operation in an NTN IAB environment of a wireless communication system.

[0020] According to the present disclosure, there is an effect of providing a method for setting parameters related to NTN IAB operation functions in an NTN IAB environment of a wireless communication system.

[0021] 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.

[0022]

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

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

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

[0026] 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.

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

[0028] 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.

[0029] 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.

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

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

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

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

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

[0035] FIG. 13 is a diagram illustrating an intra CU topology adaptation procedure to which the present disclosure is applied.

[0036] FIG. 14 is a diagram illustrating a method for performing an inter CU topology redundancy procedure to which the present disclosure applies.

[0037] FIG. 15 is a diagram illustrating an IAB inter CU topology adaptation procedure to which the present disclosure is applied.

[0038] FIG. 16 is a diagram illustrating an IAB inter CU topology adaptation procedure to which the present disclosure is applied.

[0039] FIG. 17 is a diagram illustrating how an IAB inter CU topology adaptation procedure is performed based on a descendant IAB node to which the present disclosure applies.

[0040] Figure 18 is a diagram illustrating an IAB inter CU backhaul RLF recovery procedure to which the present disclosure applies.

[0041] FIG. 19 is a diagram illustrating an IAB inter CU backhaul RLF recovery procedure to which the present disclosure applies.

[0042] Figure 20 is a diagram illustrating an IAB integration method to which the present disclosure is applied.

[0043] Figure 21 is a diagram showing an NTN IAB parameter indication method to which the present disclosure is applied.

[0044] Figure 22 is a diagram showing the NTN IAB operation to which the present disclosure is applied.

[0045] Figure 23 is a diagram illustrating a method for selecting a parent node in an IAB MT setup process to which the present disclosure applies.

[0046] Figure 24 is a diagram illustrating an NTN IAB topology adaptation procedure to which the present disclosure applies.

[0047] FIG. 25 is a diagram illustrating a method for performing a measurement report in an NTN IAB to which the present disclosure applies.

[0048] FIG. 26 is a diagram illustrating a parameter reporting method for inter / intra CU NTN IAB topology adaptation to which the present disclosure is applied.

[0049] Figure 27 is a flowchart showing the operation method of an IAB donor to which the present disclosure is applied.

[0050] Figure 28 is a flowchart showing a satellite IAB node operation method to which the present disclosure is applied.

[0051] Figure 29 is a flowchart showing a satellite IAB node operation method to which the present disclosure is applied.

[0052] Figure 30 is a drawing showing a device configuration to which the present disclosure is applied.

[0053]

[0054] 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.

[0055] 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.

[0056] 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.

[0057] 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.

[0058] 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.

[0059] 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.

[0060] 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.

[0061] 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).

[0062] 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.

[0063] 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.

[0064] 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).

[0065] 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.

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

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

[0068] 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

[0069] 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.

[0070] 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.

[0071] [Mathematical Formula 1]

[0072]

[0073] 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.

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

[0075] 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.

[0076] 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.

[0077] [Equation 2]

[0078]

[0079]

[0080] 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.

[0081] 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.

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

[0083] [Table 1]

[0084]

[0085] 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.

[0086] 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.

[0087] 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.

[0088] 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).

[0089] 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.

[0090] 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).

[0091] [Table 2]

[0092]

[0093] 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.

[0094] [Table 3]

[0095]

[0096] 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).

[0097] 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.

[0098] [Table 4]

[0099]

[0100]

[0101] 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.

[0102] 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.

[0103] 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.

[0104] 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.

[0105] 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.

[0106]

[0107] Non-terrestrial networks (NTN):

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

[0109]

[0110] NTN Gateway (NTN-gateway):

[0111] 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).

[0112]

[0113] Feeder link:

[0114] Wireless link between NTN gateway and satellite

[0115]

[0116] Geostationary Earth orbit (GEO):

[0117] 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.

[0118]

[0119] Low Earth Orbit (LEO):

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

[0121]

[0122] Medium Earth Orbit (MEO):

[0123] Orbits that exist between LEO and GEO

[0124]

[0125] Unmanned Aircraft Systems (UAS):

[0126] 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).

[0127]

[0128] Minimum Elevation angle:

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

[0130]

[0131] Mobile Services:

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

[0133]

[0134] Mobile Satellite Services:

[0135] 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.

[0136]

[0137] Non-Geostationary Satellites:

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

[0139]

[0140] On Board Processing:

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

[0142]

[0143] Transparent payload:

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

[0145]

[0146] Regenerative payload:

[0147] 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.

[0148]

[0149] Onboard NTN gNB:

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

[0151]

[0152] On ground NTN gNB:

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

[0154]

[0155] One-way latency:

[0156] 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.

[0157]

[0158] Round Trip Delay (RTD):

[0159] 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.

[0160]

[0161] Satellite:

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

[0163]

[0164] Satellite beam:

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

[0166]

[0167] Service link:

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

[0169]

[0170] User Connectivity:

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

[0172]

[0173] User Throughput:

[0174] Data transmission rate provided to the terminal

[0175]

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

[0177] 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.

[0178] 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.

[0179] 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.

[0180] 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.

[0181] 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.

[0182] 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.

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

[0184] 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.

[0185] 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.

[0186] 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.

[0187] 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.

[0188] 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.

[0189] 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.

[0190] 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.

[0191] 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.

[0192] 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).

[0193] For example, referring to Fig. 8(a), if the satellite payload type is a regenerative 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 the common TA value ( ) and TA value by terminal ( ) can be calculated. For example, the common TA value ( ) may be the TA value required for all terminals due to the large cell coverage and long round-trip time (RTT) of NTN. That is, since NTN is located in the air and is a relatively long distance compared to the distance between terminals, a common TA value ( ) may be required. Additionally, terminal-specific TA values ​​( ) may be a value that occurs due to the different locations of each terminal within the cell coverage. If the terminal knows the location of the satellite at a specific time in advance through the satellite ephemeris that it has stored in advance or received from the NTN, and knows the location of the terminal through a function such as GNSS, the terminal can calculate the distance between the satellite and the terminal at a specific time, and can obtain the TA value by itself and then correct the TA value, thereby determining the TA value.

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

[0195] 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, it is necessary to additionally consider the case where the TA value caused by the feeder link is not compensated by the overall TA compensation method. In addition, each terminal may have a different TA value ( ) can only be calculated, the terminal needs to identify one reference point for each beam or cell, and needs to transmit information about it to other terminals. When the network sets an offset between the downlink frame timing and the uplink frame timing, the network needs to manage the offset information regardless of the satellite payload type. Here, as an example, the network may provide each terminal with a value for TA correction, and is not limited to the above-described embodiment.

[0196] 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 of a satellite beam or cell. The network can transmit the common TA value to the terminals for each satellite beam or cell based on a broadcast method. The common TA value can be calculated in the network assuming at least one reference position for each satellite beam or cell. In addition, the terminal-specific TA value ( ) 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, when the network provides a timing change rate to the terminal, the terminal can support TA value correction based on this.

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

[0198] 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.

[0199] 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.

[0200] 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.

[0201] 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.

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

[0203] 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.

[0204] 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.

[0205] 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.

[0206] 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.

[0207] 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.

[0208] 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.

[0209] 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.

[0210] 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 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.

[0211] 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 providing IoT services in terms of wireless resource utilization and power control, 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.

[0212] 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).

[0213] 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.

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

[0215] Referring to Figure 12, integrated access and backhaul (IAB) can be applied to a wireless communication system. IAB may be required in a cellular network scenario that is not connected to the network by wires and is composed of densely deployed cells (e.g., NR cells). 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 that 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.

[0216] 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.

[0217] 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.

[0218] 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.

[0219] In addition, as an example, a backhaul adaptation protocol (BAP) layer may be required for IAB operation. The BAP layer may be required to support routing of an IAB-based wireless backhaul. The BAP layer may exist above the radio link control (RLC) 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 the base station function, and the MT of the IAB node may be responsible for the terminal function. In addition, as an example, the BAP layer of the IAB node may have one BAP entity in the MT function and a BAP entity collocated separately from the DU function. Here, each BAP entity may have a transmitting part and a receiving part. 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. In contrast, the transmitting part of a collocated BAP entity can add a BAP header. In addition, a BAP entity can generate, forward, and receive BAP control PDU(s).The transmitting part of the BAP entity can perform routing, mapping of BH RLC channels to BH RLC channels, and BAP header rewriting. For example, routing can be performed based on a routing table. The IAB donor-CU (centralized unit) can configure a routing table for each IAB node via radio resource control (RRC) / F1 application protocol (F1AP) messages. The routing table can consist of one or more entries.

[0220] FIG. 13 is a diagram illustrating an intra-CU topology adaptation procedure to which the present disclosure is applied. Referring to FIG. 13, a standalone (SA) operation-based intra-CU topology adaptation procedure may be performed. The SA operation-based intra-CU topology adaptation procedure may mean that a source parent IAB node (1331) in a source path (1330) and a target parent IAB node (1341) in a target path (1340) are connected to the same IAB donor-CU (IAB donor-CU) 1350, and each has a different IAB donor DU (IAB donor-DU) 1332, 1342. For example, in FIG. 13, the source parent IAB node and the target parent IAB node are each connected to the same IAB donor CU (1350), and the source parent IAB node can be connected to the source IAB donor DU (1332), and the target parent IAB node can be connected to the target IAB donor DU (1342). That is, in FIG. 13, the source parent IAB node (1332) and the target parent IAB node (1342) are connected to the same IAB donor CU (1350), and can be connected to different IAB donor DUs.

[0221] In FIG. 13, a terminal (1310) can receive downlink (DL) data and transmit uplink (UL) data through an IAB node (1320). Here, the IAB node (1320) connected to the terminal (1310) may be a migrating IAB node (1320) that is being migrated from a source path (1330) to a target path (1340). The migrating IAB node (1320) may include an IAB distributed unit (DU) that performs a base station function and an IAB mobile terminal (MT) that performs a terminal function. The IAB MT of the migrating IAB node (1320) may transmit a measurement report (MR) to the IAB DU of the source parent IAB node (1331). Here, the measurement report can be performed based on the measurement configuration previously set by the IAB donor CU (1350). Thereafter, the source parent IAB node (1331) can transmit the received measurement report to the IAB donor CU (1350) via a UL RRC message transfer.

[0222] The IAB donor CU (1350) may transmit a UE context setup request message to the IAB DU of the target parent IAB node (1341) to create one or more bearers and UE contexts. Here, the UE context may be a context for the IAB MT of the previous IAB node (1320) connected to the UE (1310). Thereafter, the IAB DU of the target parent IAB node (1341) may forward a UE context setup response message to the IAB donor CU (1350). Thereafter, the IAB donor CU (1350) may transmit a UE context modification request message to the IAB DU of the source parent node (1331). Here, the context modification request message may include an RRC reconfiguration message. For example, the context modification request message may include the configuration information of Table 5 below. Specifically, the context change request message may include the default BH RLC channel and base BAP routing ID configuration information for UL F1-C / non-F1 traffic, as well as the BH RLC channel and BAP routing ID for F1-C / non-F1 traffic. In addition, the context change request message may include additional BH RLC channel configuration information.

[0223] The context change request message may include transport network layer (TNL) address assignment information. The TNL address assignment information may be an address routable to the target IAB donor DU (1342), and the new TNL address may replace the address routable to the previous source IAB donor DU (1332). Additionally, when IPsec tunnel mode is used to protect F1 and non-F1 traffic, the assigned TNL address may exist outside the IP address. For example, in FIG. 13, if the source route (1330) and the target route (1340) have the same IAB donor DU, the TNL address may not be changed.

[0224] Additionally, as an example, a context change request message may include a transmission action indicator, which may instruct the source parent IAB node (1331) to stop transmitting data to the previous IAB node (1320) connected to the terminal (1310).

[0225] [Table 5]

[0226]

[0227]

[0228] Thereafter, the IAB DU of the source parent IAB node (1331) can transmit the received RRC reconfiguration message to the IAB MT of the previous IAB node (1320) connected to the terminal (1310). In addition, the IAB DU of the source parent IAB node (1331) can transmit a UE context modification response message to the IAB donor CU (1350) in response to the received RRC reconfiguration message. Thereafter, the IAB DU of the target parent IAB node (1341) can perform a random access procedure with the previous IAB node (1320). Thereafter, the IAB MT of the previous IAB node (1320) can transmit an RRC reconfiguration complete message to the IAB DU of the target parent IAB node (1341) in response. The IAB DU of the target parent IAB node (1341) can transmit the received RRC reconfiguration complete message to the IAB donor CU (1350) via an uplink RRC transfer message (UL RRC MESSAGE TRANSFER). In addition, the IAB MT of the previous IAB node (1320) can transmit signaling and data of the IAB MT to the IAB donor CU (1350).

[0229] Thereafter, the IAB donor CU (1350) can configure a BH RLC channel and a BAP sublayer routing entry between the target parent IAB node (1341) and the target IAB donor DU (1342). In addition, downlink mapping can be performed to the target IAB donor DU (1342) for data on a path toward the previous IAB node (1320) connected to the terminal (1310). For example, the downlink mapping of the target IAB donor DU (1342) can be performed in the previous step, but is not limited thereto. That is, the IAB donor CU (1350) can configure an additional BH RLC channel to the previous IAB node (1320) via an RRC message.

[0230] After that, the F1-C connection may be switched to use the new TNL address of the previous IAB node (1320). The IAB donor CU (1350) may update the UL BH information associated with each GTP tunnel for the previous IAB node (1320). In addition, the IAB donor CU (1350) may transmit a UE context release command message to the IAB DU of the source parent IAB node (1331). The IAB DU of the source parent IAB node (1331) may release the context of the previous IAB node (1320) and transmit a UE context release complete message to the IAB donor CU (1350). Thereafter, the IAB donor CU (1350) may release the BH RLC channel and BAP sublayer routing entry between the source parent IAB node (1331) and the source IAB donor DU (1332) within the source path (1330). For example, if the source path (1330) and the target path (1340) include the same node, the IAB donor CU (1350) may not release the BH RLC channel and BAP sublayer routing entry for the corresponding node.

[0231] As another example, an inter-CU topology management procedure may be performed. For example, an IAB donor DU may support inter-donor DU rerouting. Here, the IAB donor DU may identify a rerouted uplink packet based on the source IP address of the uplink packet. That is, the IAB donor DU may forward the uplink packet to an adjacent donor DU that may have the source IP address. Here, as an example, the IAB donor DU and the inter-IAB donor DU may be controlled by the same IAB donor CU. As another example, the IAB donor DU and the inter-IAB donor DU may be controlled by different IAB donor CUs, and the present invention is not limited to a specific embodiment. The IAB donor CU may configure a prefix for indicating whether to transmit a list of reroutable TNL addresses and tunnel-related information to the IAB donor DU.

[0232] As another example, an inter-CU topological redundancy procedure may be performed in a dual connectivity (DC) environment. The inter-CU topological redundancy procedure may be a method for establishing, modifying, and releasing redundant paths in an IAB topology between different IAB donor CUs.

[0233] FIG. 14 is a diagram illustrating a method for performing an inter-CU topology redundancy procedure to which the present disclosure applies. Referring to FIG. 14, a dual-connecting IAB node (1420) is not controlled by an IAB donor CU (1440) having an F1 interface, and a second backhaul path may be established for the dual-connecting IAB node (1420). Here, the dual-connecting IAB node (1420) may be an IAB node located at the edge of the coverage area. The dual-connecting IAB node (1420) may maintain a connection with the IAB donor CU (1440) based on the F1 interface, and may maintain an RRC connection with an IAB donor CU (1460) that does not have an F1 interface.

[0234] Referring to FIG. 14, a dual connection establishment procedure for an IAB MT of a dual-connected IAB node (1420) may be performed. The dual connection establishment procedure for the IAB MT of the dual-connected IAB node (1420) may be performed before or after an F1 interface between an IAB donor DU and an IAB donor CU is established. For example, an F1 terminating IAB donor CU (F1 terminating IAB-donor-CU, 1440) may transmit an IAB transport migration management request message to a non-F1 terminating IAB donor CU (1460). A downlink RRC message transfer transmitted by the non-F1 terminating IAB donor CU (1460) may include an RRC reconfiguration message for the IAB MT of the dual-connected IAB node (1420). The IAB DU of the second parent IAB node (1451) may transmit the received RRC reconfiguration message to the IAB MT of the dual-connected IAB node (1420). The IAB MT of the dual-connected IAB node (1420) may transmit an RRC reconfiguration complete message to the IAB DU of the second parent IAB node (1451). In addition, the IAB DU of the second parent IAB node (1451) may transmit an uplink RRC message transfer (UL RRC MESSAGE TRANSFER) including the RRC reconfiguration complete message to the non-F1 terminating IAB donor CU (1460). In addition, the non-F1 terminating IAB donor CU (1460) may modify or configure the BAP sublayer routing and BH RLC channel for the second path based on the IAB DU of the dual-connected IAB node (1420) and the second parent IAB node (1451).

[0235] Thereafter, the non-F1 terminating IAB donor CU (1460) may transmit an IAB transport migration management response message including mapping information of traffic that should be offloaded to the F1 terminating IAB donor CU (1440). Thereafter, the F1 terminating IAB donor CU (1440) may update the UL BH information of the dual-connected IAB node (1420). Here, the updated information may include a UL fully qualified tunnel endpoint identifier (FTEID) and a DL FTEID associated with an individual GTP tunnel. In addition, the updated information may include information that is changed to use a new TNL address of the dual-connected IAB node (1420). In addition, the updated information may include E1 / F1 signaling to provide an updated user plane configuration (UP configuration) for the F1-U tunnel of the IAB MT of multiple terminals or child nodes.

[0236] Additionally, the F1 terminating IAB donor CU (1440) may also provide UL BH information associated with non-UP traffic. If a new TNL address is configured for F1-C traffic as described above, the new TNL address may be added to the F1-C of the IAB donor DU (1432) associated with the F1 terminating IAB donor CU (1440). Additionally, if a new TNL address is configured for F1-C traffic, a new SCTP (stream control transmission protocol) between the dual-connected IAB node (1420) and the F1 terminating IAB donor CU (1440) may be established using the new TNL information of the dual-connected IAB node (1420). Additionally, the F1 terminating IAB donor CU (1440) may transmit an IAB transport migration management request message to the non-F1 terminating IAB donor CU (1460) to change information about offloaded traffic of the dual-connection IAB node (1420). Additionally, the non-F1 terminating IAB donor CU (1460) may transmit an IAB transport migration management response message to the F1 terminating IAB donor CU (1440). Thereafter, the F1 terminating IAB donor CU (1440) may repeat the procedure for requesting addition, modification, and release of offloaded traffic. Additionally, a non-F1 terminating IAB donor CU (1460) can request L2 transport modification for offloaded traffic via an IAB transport migration modification request message.Here, the F1 terminating IAB donor CU (1440) can reconfigure the UL BH mapping and transmit a positive response to the change via an IAB transport migration modification response message. Furthermore, the non-F1 terminating IAB donor CU (1460) can reconfigure the TNL address of the dual-connected IAB node (1420) via an RRC message.

[0237] FIG. 15 and FIG. 16 are diagrams illustrating an IAB inter CU topology adaptation procedure to which the present disclosure is applied.

[0238] For example, an inter-CU topology adaptation operation may be performed on an IAB node connected to an IAB donor CU. Here, an IAB MT of the IAB node may change its connection from an old parent IAB node to a new parent IAB node. For example, the old parent IAB node and the new parent IAB node may have different IAB donor CUs. For example, the old parent IAB node may be a source parent IAB node, and the new parent IAB node may be a target parent IAB node, but is not limited thereto.

[0239] As a specific example, referring to FIG. 15, the IAB-MT of a migrating IAB node 1520 connected to a terminal (1510) can change the connection from a source IAB donor CU (1540) to a target IAB donor CU (1560). As an example, the IAB DU of the migrating IAB node (1520) can maintain an F1AP connection with the source IAB donor CU (1540), and the IAB MT of the migrating IAB node (1520) can be a boundary IAB node that acquires an RRC connection with the target IAB donor CU (1560).

[0240] Referring to FIG. 15, a source IAB donor CU (1540) may generate an Xn handover request message and transmit it to a target IAB donor CU (1560). Here, the Xn handover request message may include tunnel (TNL) address information of a previous IAB node (1520) in the form of an RRC container. The target IAB donor CU (1560) may generate a UE context and UE context setup request message for the IAB MT of the previous IAB node (1520) and transmit them to a target parent IAB node (1551) within a target path (1550). Thereafter, the target parent IAB node (1551) may generate a UE context setup response message in response to the received request and transmit the message to the target IAB donor CU (1560). Thereafter, the target IAB donor CU (1560) may perform admission control and transmit a handover request acknowledge to the source IAB donor CU (1540). Here, the handover request acknowledge may include a new RRC configuration. The source IAB donor CU (1540) may generate a UE context modification request message including the RRC configuration received from the target IAB donor CU (1560) and transmit the message to the source parent IAB node (1531) of the source path (1531).

[0241] Thereafter, the source parent IAB node (1531) can forward the received RRC reconfiguration message to the IAB MT of the previous IAB node (1520). In addition, the source parent IAB node (1531) can generate a UE context modification response and forward it to the source IAB donor CU (1540).

[0242] Thereafter, the IAB MT of the previous IAB node (1520) can perform a random access procedure with the target parent IAB node (1551) of the target path (1550). The previous IAB node (1520) can transmit an RRC reconfiguration complete message to the target parent node (1551) after completing the random access procedure. The target parent node (1551) can transmit a UL RRC MESSAGE TRANSFER including the received RRC reconfiguration complete message to the target IAB donor CU (1560). Thereafter, the target IAB donor CU (1560) can perform a path switching procedure for the IAB MT of the previous IAB node (1520). The target IAB donor CU (1560) can transmit a UE context release message to the source IAB donor CU (1540). Afterwards, the source IAB donor CU (1540) may release the BH RLC channel and BAP sublayer routing entry for the source path between the source parent IAB node (1531) of the previous IAB node (1520) and the source IAB donor DU (1532).

[0243] Also, referring to FIG. 16, after releasing the BH RLC channel and BAP sublayer routing entry for the source route between the source parent IAB node of the previous IAB node and the source IAB donor DU in FIG. 15, the target IAB donor CU (1660) may configure the BH RLC channel and BAP sublayer routing entry for the target route (1650) between the previous IAB node (1620) and the target IAB donor DU (1652). In addition, the target IAB donor CU (1660) may configure DL mapping of the target IAB donor DU (1652) for the target route (1650) of the previous IAB node (1620). As an example, the DL mapping may be a setting to support F1-C traffic transmission for the target route (1650). Additionally, the F1-C connection between the previous IAB node (1620) and the source IAB donor CU (1640) may be changed to the target path (1650) using the new TNL address information of the previous IAB node (1520). For example, the previous IAB node (1620) may report the new TNL address information it wishes to use for F1-U traffic to the source IAB donor CU (1640) via a gNB-DU configuration update message.

[0244] Thereafter, the source IAB donor CU (1640) may transmit an IAB transport migration management request message to the target IAB donor CU (1660) to provide information about traffic that needs to be offloaded. The target IAB donor CU (1660) may modify or configure BAP sublayer routing entries and BH RLC channels for the target path (1650) between the previous IAB node (1620) and the target IAB donor CU (1660). In addition, the target IAB donor CU (1660) may forward an IAB transport migration management response message to the source IAB donor CU (1640) to provide mapping information about traffic that needs to be offloaded. Thereafter, the F1-U connection between the previous IAB node (1620) and the source IAB donor CU (1640) may be changed to use the new TNL addresses of the previous IAB node (1620). The source IAB donor CU (1640) may provide updated UL BH information based on the traffic information that needs to be offloaded to the IAB-DU of the previous IAB node (1620). Here, the source IAB donor CU (1640) may also update UL BH information associated with non-UP traffic. In addition, for example, terminal-related or non-terminal-related signaling associated with E1 / F1 interface signaling may be used. In addition, if the source IAB donor CU (1640) requests additional traffic offload or modifies or releases the offloaded traffic during the above-described process, the source IAB donor CU (1640) may repeat the above-described operation when modifying or releasing the traffic.For example, the target IAB donor DU (1660) may, but is not limited to, reject all or part of an addition or modification request by the source IAB donor CU (1640).

[0245] FIG. 17 is a diagram illustrating a method for performing an IAB inter-CU topology adaptation procedure based on a descendant IAB node to which the present disclosure applies. Referring to FIG. 17, a migrating IAB node 1730 may include lower-level IAB node(s). For example, the lower-level IAB node(s) may have F1 and RRC connections with a source IAB donor CU (1750). In FIG. 17, a descendant IAB node 1720 exists as a descendant node of the migrating IAB node (1730), and a terminal (1710) may be connected to the descendant IAB node (1720), but this is merely an example and is not limited to the embodiment. In FIG. 17, a previous IAB node (1720) having a lower IAB node can perform a topology change from a source IAB donor DU (1742) within a source path (1740) to a target IAB donor DU (1762) within a target path (1760).

[0246] Referring to FIG. 17, a previous IAB node (1720) may perform an IAB inter-CU topology change procedure. Referring to FIG. 17, a source IAB donor CU (1750) may transmit an IAB transport migration management request message to a target IAB donor CU (1770) to provide traffic information that needs to be offloaded from lower-level IAB node(s). The IAB transport migration management request message may include a request for new TNL address(es) for lower-level IAB node(s) anchored at the target IAB donor CU (1770). Here, the source IAB donor CU (1750) may include an identifier for the previous IAB node (1730) in the IAB transport migration management request message.

[0247] Thereafter, the target IAB donor CU (1770) can determine the IAB donor DU based on the identifier of the previous IAB node (1730). The target IAB donor CU (1770) can configure or modify the BAP sublayer routing entry and BH RLC channel corresponding to the target path (1760) between the previous IAB node (1730) and the target IAB donor DU (1762). In addition, the target IAB donor CU (1770) can also perform DL mapping for the target path (1760) to the target IAB donor DU (1762). Thereafter, the target IAB donor CU (1770) can obtain new TNL address(es) from the target IAB donor DU (1762) based on the TNL address requested as described above.

[0248] Thereafter, the target IAB donor CU (1770) may transmit mapping information for traffic to be offloaded to the source IAB donor CU (1750) via an IAB transport migration management response message. Here, the IAB transport migration management response message may include L2 information of the target IAB donor CU (1770). The L2 information may be information for configuring header rewriting and BH RLC channel mapping of the traffic as indicated above in the migration IAB node (1730). In addition, the IAB transport migration management response message may include DSCP / IPv6 Flow Label values ​​used for the DL traffic to be offloaded as indicated above. In addition, the IAB transport migration management response message may include the TNL address(es) as described above. Additionally, the target IAB donor CU (1770) may choose to have the same IAB donor DU within the IAB topology for all traffic that needs to be offloaded with the same BAP address as the UL BH mapping received from the source IAB donor CU (1750). Additionally, the target IAB donor CU (1770) may provide the same egress BAP routing ID for all traffic that needs to be offloaded with the same ingress BAP routing ID as the UL BH mapping received from the source IAB donor CU (1750). Thereafter, the source IAB donor CU (1750) may configure BAP sublayer routing and header rewrite in the IAB DU of the previous IAB node (1730), and configure the BH RLC channel mapping entry of the previous IAB node (1730).Additionally, the source IAB donor CU (1750) may forward a DL RRC message transfer including an RRC reconfiguration message for an IAB MT of a child node of the previous IAB node (1730) to the previous IAB node (1730). Here, the previous IAB node (1730) may transmit the received RRC message to the IAB MT of the child IAB node (1720). The IAB MT of the child IAB node (1720) may forward an RRC reconfiguration complete message to the IAB DU of the previous IAB node (1730). Thereafter, the IAB-DU of the previous IAB node (1730) may forward an UL RRC message transfer including an RRC reconfiguration complete message to the source IAB donor CU (1750). For example, a source IAB donor CU (1750) may configure a BAP sublayer routing entry and a UL BH mapping between a child IAB node (1720) and a previous IAB node (1730) in the child IAB node (1720), but may not be limited thereto.

[0249] Thereafter, the F1-C connection and the F1-U tunnel may be changed to use the new TNL address(es) of the child IAB node (1720). The source IAB donor CU (1750) may send an IAB transport migration management request message to the target IAB donor CU (1770) to change the information of the offloaded traffic of the child IAB node (1720). Thereafter, the target IAB donor CU (1770) may forward an IAB transport migration management response message to the source IAB donor CU (1750). Here, if the source IAB donor CU (1750) requests to release, modify, and add the offloaded traffic for the child IAB node (1720), the source IAB donor CU (1750) may repeat the above-described procedure. For example, the target IAB donor DU (1762) may, but is not limited to, reject all or part of an addition or modification request by the source IAB donor CU (1742).

[0250] FIG. 18 and FIG. 19 are diagrams illustrating an IAB inter CU backhaul RLF recovery procedure to which the present disclosure applies.

[0251] Referring to FIG. 18, the IAB MT of the IAB node (1820) can detect a backhaul RLF (radio link failure). Here, the IAB MT of the IAB node (1820) can attempt to recover the RLF by performing random access with the IAB DU of the new parent IAB node (1851). Specifically, the IAB MT of the IAB node (1820) can transmit an RRC reestablishment request message to the IAB DU of the new parent node (1851). The IAB DU of the new parent node (1851) can transmit an initial UL RRC message including the received RRC reestablishment request message to the new IAB donor CU (1860). A new IAB donor CU (1860) can obtain a terminal context for the IAB-MT of the IAB node (1820) performing RLF recovery through an XnAP retrieve UE context procedure. Here, the initial IAB donor CU (1840) can include the TNL address information of the IAB node (1820) performing RLF recovery in the RRC container of a retrieve UE context response message. The new IAB donor CU (1860) can transmit a DL RRC MESSAGE TRANSFER to transfer the RRC re-establishment message generated by the IAB DU of the new parent IAB node (1851). Thereafter, the IAB DU of the new parent IAB node (1851) can transmit the RRC re-establishment message to the IAB MT of the IAB node (1820) performing RLF recovery.Here, the IAB-MT of the IAB node (1820) performing RLC recovery may transmit an RRC reestablishment complete message to the IAB DU of the new parent IAB node (1851). Thereafter, the IAB DU of the new parent IAB node (1851) may forward a UL RRC MESSAGE TRANSFER including the received RRC reestablishment complete message to the new IAB-donor-CU (1860). The new IAB donor CU (1860) may set up one or more bearers and trigger a UE context setup procedure to the IAB DU of the new parent IAB node (1851) to create a UE context for the IAB MT of the IAB node (1820) performing RLC recovery. Here, the bearers can be used for self-signaling and data traffic by the IAB MT of the IAB node (1820) performing RLF recovery. Thereafter, the new IAB donor CU (1860) can trigger a path switching procedure of the IAB MT of the IAB node (1820) performing RLF recovery. The new IAB donor CU (1860) can send a UE context release message to the initial IAB donor CU (1840), and the initial IAB donor CU (1840) can release the BAP sublayer routing entry and the BH RLC channel on the initial path (1830) between the initial parent IAB node (1831) and the initial IAB donor DU (1832).

[0252] Thereafter, referring to FIG. 19, the new IAB donor CU (1960) may forward a DL RRC message transfer including an RRC reconfiguration message for IAB-MT of the IAB node (1920) performing RLF recovery to the IAB DU of the new parent IAB node (1951). For example, the RRC reconfiguration message may include new TNL addresses that anchor the new IAB donor DU (1952). In addition, the RRC reconfiguration message may further include a BAP address for the IAB node (1920) performing RLF recovery in the topology of the new IAB donor CU (1960). In addition, the RRC reconfiguration message may further include a default BAP routing ID configuration and a default BH RLC channel for mapping UL F1-C / non-F1 traffic to the recovery path (1950).

[0253] Thereafter, the IAB DU of the new IAB parent node (1951) can transmit the received RRC reconfiguration message to the IAB MT of the IAB node (1920) performing RLF recovery. Thereafter, the IAB MT of the IAB node (1920) performing RLF recovery can transmit an RRC reconfiguration complete message to the IAB DU of the new parent IAB node (1851). Thereafter, the IAB DU of the new parent node (1951) can transmit a UL RRC message transfer including the received RRC reconfiguration complete message to the new IAB donor CU (1960).

[0254] For example, the IAB topology adaptation operation of FIGS. 13 to 19 may be an operation based on channel conditions in a fixed state of the IAB nodes. That is, the IAB nodes may perform a topology adaptation procedure based on the channel conditions to transmit and receive data through a better path. However, the IAB topology adaptation procedure in an NTN environment needs to be performed based on IAB nodes that are not fixed, and a method for this is described below.

[0255] For example, satellites within a regenerative-based satellite environment can support an integrated access and backhaul (IAB) network architecture and protocol architecture. That is, satellites within a regenerative-based satellite environment can perform forwarding-based data transmission in a CU (Central Unit) / DU (Distributed Unit) split radio access network architecture. Here, forwarding-based data transmission can be performed based on a method of establishing a packet transmission path using an address and routing identifier assigned from an IAB donor based on the destination address of the packet.

[0256] The protocol of the IAB network can be segmented at the RLC (radio link control) layer to enable multi-hop relay transmission. Furthermore, the protocol of the IAB network includes a backhaul adaptation protocol (BAP) for routing and RLC channel mapping, as described above.

[0257] For example, an IAB network can be configured based on a relay scheme with multiple hops having one or more wireless links. However, the relay scheme may have a high probability of poor signal quality on the links, and thus, service coverage and service continuity along the path may not be guaranteed. Considering the above, topology adaptation can be performed considering wireless link quality and traffic load. Below, a method for performing topology adaptation considering NTN IAB operation is described. As an example, a satellite performing the MT and DU roles of the IAB node described above is referred to as a satellite IAB node (Sat. IAB-node), but this name may not be limited to this.

[0258] FIG. 20 is a diagram illustrating an IAB integration method to which the present disclosure is applied. IAB nodes can establish a connection with an IAB donor through the F1 interface. Here, the IAB nodes can broadcast SIB 1 (system information block 1) including an "IAB-Support" indicator. That is, the IAB nodes can broadcast information on whether they support IAB by including it in the system information block. IAB nodes that have not established a connection to the IAB donor can establish a connection with the IAB donor through IAB nodes that broadcast SIB 1 including the "IAB-Support" indicator. For example, referring to FIG. 20, IAB node 2 (2020), a new IAB node, can establish a network connection through IAB node 1 (2010). That is, IAB node 2 (2020) is not connected to the core network through the existing IAB donor (2030) and may attempt to establish a network connection through another IAB node.

[0259] For example, IAB node 2 (2020) can perform IAB MT setup (phase 1). The IAB MT of IAB node 2 (2020) can perform RRC connection with IAB donor CU (2032) similar to a terminal. In addition, the IAB MT of IAB node 2 (2020) can perform core network authentication, IAB node 2 related information management, and radio bearer setup (SRBs, DRBs) procedures related to traffic of IAB node 2 through IAB donor CU (2032). Here, IAB node 2 (2020) can select a parent IAB node through an IAB capability indicator included in SIB 1 transmitted by IAB DUs of potential parent IAB nodes. Additionally, the IAB node 2 (2020) may include an IAB node indicator indicating its IAB capabilities in the RRC setup complete message transmitted to the IAB donor (2030). The IAB donor (2030) may select an access management function (AMF) that supports the IAB node 2 (2020) based on the IAB node indicator information.

[0260] After that, IAB node 2 (2020) can establish a BH RLC channel. (phase 2-1) Specifically, one default BH RLC channel can be established during the bootstrapping procedure. Here, one default BH RLC channel can be established to transmit and receive non-UP traffic, such as F1-C traffic / non-F1 traffic, to and from IAB node 2 (2020). In the above-described process, the BH RLC channel between IAB node 1 (2010) and IAB donor DU (2031) can be changed. As another example, a new BH RLC channel can be established in the above-described process. In addition, as an example, the IAB donor CU (2032) can establish a non-default BH RLC channel. For example, when an IAB donor CU (2032) establishes a non-default BH RLC channel, the BAP address of IAB node 2 (202) and the default BAP routing ID for the upstream direction may be set.

[0261] Afterwards, the BAP sublayer may be updated to support routing between the IAB node 2 (2020) and the IAB donor DU (2031) (phase 2-2). In addition, for the downstream direction, the IAB donor CU (2032) may initiate an F1AP procedure to set the BAP routing ID and IP header field mapping associated with the IAB node 2 (2020) to the IAB donor DU (2031). Afterwards, all upper nodes (e.g., IAB-node 1) of the IAB node 2 (2020) and the IAB donor DU (2031) may update the routing entries and routing tables for the new BAP routing ID(s). In addition, as an example, when performing the above-described update, an IP address allocation procedure for the IAB node 2 (2020) may be performed. The IAB node 2 (2020) may request one or more IP addresses from the IAB donor CU (2032) via RRC. The IAB donor CU (2032) may transmit one or more IP address(es) for the IAB node 2 (2020) via RRC. The IAB donor CU (2032) may obtain the IP address(es) from the IAB donor DU (2031) via F1-AP or OAM / DHCP. For example, the IP address allocation procedure may be performed after the RRC connection is established.

[0262] After that, IAB DU setup can be performed. (Phase 3) IAB DU of IAB node 2 (2020) can be configured through OAM (operation administration and maintenance). For example, IAB DU of IAB node 2 (2020) can initiate F1 setup with IAB donor CU (2032) through TNL establishment and assigned IP address(es). IAB donor CU (2032) can check the connection relationship between IAB MT and IAB DU from BAP address of IAB node included in F1 setup request message. After F1 setup is completed, IAB node 2 (2020) can provide service to terminals.

[0263] For example, an IAB node needs to obtain approval from the core network during the initial registration procedure to operate as a mobile IAB (mIAB). An mIAB can allow the deployment of mobile cells and can be an IAB node that performs communications while deployed on board trains, buses, and aircraft. For example, an IAB node can operate based on a pre-configured configuration as a fixed IAB node. In contrast, an mIAB can perform communications while in motion. As a specific example, an mIAB can provide services to users within a moving object (e.g., a train). Here, an mIAB needs to obtain approval from the core network during the initial registration procedure to perform the operation of providing services to terminals.

[0264] Specifically, the AMF can determine whether to approve mIAB operation based on subscription information and transmit information indicating approval to the radio access network (RAN). The IAB node can transmit an mIAB operation indicator to the IAB donor. The IAB donor can select an appropriate AMF based on the mIAB operation indicator received from the IAB node. Considering the above, there is a need to include an mIAB operation indicator in the RRC setup complete message transmitted from the IAB node to the IAB donor.

[0265] Here, for example, in an NTN IAB environment, an IAB node is a satellite IAB node and thus can be continuously mobile. Therefore, the IAB topology may not be continuously maintained in an NTN environment. Furthermore, in an NTN environment, satellite IAB nodes within an IAB topology may operate similarly to the mIAB operation described above, and thus may require approval from the core network. Therefore, satellite IAB nodes with a specific orbit can obtain approval from the core network to configure an IAB topology. The core network needs to configure a specific AMF to manage the satellite IAB nodes in an NTN IAB environment. The IAB donor can select the specific AMF to obtain approval for IAB operations from the core network. Here, when the IAB donor obtains approval for the IAB topology in an NTN IAB environment or selects a suitable AMF, the IAB donor may obtain, but is not limited to, the information in Table 6 below from each satellite IAB node that may be included in the IAB topology. Specifically, each satellite IAB node can transmit information about NTN IAB operation, satellite orbit information (ephemeris), and cell type information to the IAB donor. Here, the cell type information may indicate whether the cell is a moving cell or a fixed cell. Additionally, each satellite IAB node can transmit other information to the IAB donor, and is not limited to a specific embodiment.

[0266] [Table 6]

[0267]

[0268]

[0269] FIG. 21 is a diagram illustrating a NTN IAB parameter indication method to which the present disclosure is applied. Referring to FIG. 21, in an NTN IAB environment, a satellite IAB node may transmit an NTN IAB operation indicator to an IAB donor. The NTN IAB operation indicator may be an indicator indicating whether the corresponding satellite IAB node performs an NTN IAB function. The IAB donor may select an appropriate AMF that supports the NTN IAB function based on the NTN IAB operation indicator received from the satellite IAB node. As another example, in an NTN IAB environment, a satellite IAB node may transmit information related to the NTN IAB operation to the IAB donor together with the NTN IAB operation indicator. Here, the information related to the NTN IAB operation may be as in Table 6 described above, but is not limited thereto. As a specific example, in FIG. 21, satellite IAB node 1 (2110) may be connected to an IAB donor (2120) as a new satellite IAB node. Satellite IAB node 1 (2110) can perform RRC connection setup with IAB donor (2120) based on a random access procedure.

[0270] More specifically, satellite IAB node 1 (2110) may transmit a preamble (msg 1) to IAB donor (2120). Satellite IAB node 1 (2110) may configure random access channel (RACH) resources based on the received system information, and may randomly select one of the contention-based preambles associated with the beam according to the RACH resource configuration and transmit the selected one to IAB donor (2120). Thereafter, satellite IAB node 1 (2110) may receive a random access response (RAR, msg 2) from IAB donor (2120). The RAR may include, but is not limited to, a UL grant, a timing advance command (TA command), a temporary radio network temporary identifier (C-RNTI), and other information. Thereafter, the satellite IAB node 1 (2110) may transmit an RRC setup request message to the IAB donor (2120) to establish an RRC connection with the IAB node 1 (2120). For example, the RRC setup request message may include, but is not limited to, a terminal identifier (e.g., ng-GS-TMSI-Part1 or randomValue), an establishment cause (e.g., emergency, highPriorityAccess, mt-Access, mo-Signalling, mo-Data, mo-VoiceCall, mo-VideoCall, mo-SMS, mps-PriorityAccess, mcs-PriorityAccess, etc.), and other information. Thereafter, the IAB donor (2120) may establish an RRC connection with the satellite IAB node 1 (2110) and transmit an RRC setup message to the satellite IAB node 1 (2110).Here, the RRC configuration message may include, but is not limited to, radio bearer configuration (Radiobearerconfig), cell group configuration (Cellgroupconfig) and other information.

[0271] Thereafter, the satellite IAB node 1 (2110) may transmit an RRC setup complete message to the IAB donor (2120). For example, the RRC setup complete message may include, but is not limited to, a selected public land mobile network (PLMN) identifier, a registered AMF (registered AMF), an AMF identifier type (guami-Type), a network slice selection assistance information (s-NSSAI) list (s-NSSAI-List), a designated non access stratum (NAS) message (dedicatedNAS-message), a ng-5G-S-TMSI (temporary mobile subscriber identity) value (ng-5G-S-TMSI-Value), an IAB node indicator (iab-NodeIndication), idle measurements (idleMeasAvailable), terminal measurements (ue-MeasurementsAvailable), mobility history (mobilityHistoryAvail), mobility state (mobilityState), and other information.

[0272] For example, the RRC setup complete message may additionally include NTN IAB function related parameters. As a specific example, the NTN function related parameters may be configured as shown in Table 7 below with an NTN IAB node operation indicator (ntn-iab-NodeIndication), orbit information (ephemeris), and cell type information (moving or fixed), but may not be limited thereto. As another example, the information in Table 7 below may be transmitted from satellite IAB node 1 (2110) to the IAB donor (2120) through a message other than the RRC setup complete message, and is not limited to a specific embodiment.

[0273] More specifically, the NTN IAB node operation indicator (ntn-iab-NodeIndication) can indicate whether the NTN IAB node can be operated through a 1-bit value of true or false. In addition, the satellite orbit information (ephemeris) is satellite ephemeris information, and the cell type information (moving or fixed) can indicate whether the cell is a moving cell or a fixed cell through a 1-bit value. As another example, the 1-bit value can be expressed as BOOLEAN and is not limited to a specific embodiment. However, this is just one example and may not be limited thereto. As another example, the orbit information (ephemeris) can be indicated by an index of one or more orbit information lists (ephemeris lists) that can be confirmed in the IAB donor (2120).

[0274] As another example, the RRC setup completion message may be as shown in Table 8 below. The NTN IAB node operation indicator (ntn-iab-NodeIndication) may be a 1-bit value that indicates whether the NTN IAB node can be operated. In addition, the RRC setup completion message may include an NTN IAB identifier-related parameter (ntn-iab-identity). The NTN IAB identifier-related parameter may mean an identifier of NTN-related information preset by the network. For example, the NTN IAB identifier-related parameter may include information on a moving cell or a fixed cell as satellite orbit information. However, this is only one example and may not be limited thereto. As another example, one identifier may be indicated by an integer or may be expressed in the form of a sequence indicating multiple integers. That is, the NTN-related information preset by the network may be information related to the NTN IAB topology with which a satellite attempting IAB integration can be integrated.

[0275] Thereafter, the IAB donor (2120) may perform AMF selection based on the information obtained from the satellite IAB node 1 (2110). Specifically, the IAB donor (2120) may select an AMF based on NTN IAB function related parameters (e.g., ntn-iab-NodeIndication, ephemeris, moving or fixed) received from the satellite IAB node 1 (2110). In addition, as an example, the IAB donor (2120) may transmit the NTN IAB function related parameters (e.g., ntn-iab-NodeIndication, ephemeris, moving or fixed) to the selected AMF for authentication in the AMF, but is not limited to a specific embodiment.

[0276] [Table 7]

[0277]

[0278] [Table 8]

[0279]

[0280]

[0281] As another example, NTN IAB integration may be implemented with NTN IAB instructions. More specifically, a new IAB node may select a parent node through an IAB capability indicator transmitted via SIB 1, which is broadcast by at least one potential parent node during the IAB integration procedure. For example, in an NTN environment, satellite nodes may be connected to a ground-based NTN gateway, thereby enabling data transmission and reception between the terminal and the core network. In other words, in the NTN IAB topology, at least one satellite IAB node must be connected to a ground-based NTN gateway. Here, for example, a satellite may continuously move and may not be able to establish a connection with the NTN gateway as it moves. In other words, a satellite may be able to communicate with the NTN gateway for a certain period of time, but as it moves away from the NTN gateway, signal quality may deteriorate and communication may become impossible.

[0282] Considering the above, there is a need to configure parameters that indicate connectivity with the NTN gateway. Specifically, parameters for a gateway connectivity indication may be configured. For example, a satellite may orbit the Earth at a preset period. Accordingly, whether a satellite can connect to a gateway may also vary based on a preset periodic service time. Considering the above, the gateway connectivity indication parameters may be configured based on the service time, but may not be limited thereto.

[0283] Here, for example, when a new satellite IAB node selects a parent IAB node within an NTN IAB topology, it may be efficient for the new satellite IAB node to select a parent IAB node that can maintain NTN gateway connectivity for a long time in order to provide service continuity. For example, the IAB or mIAB of existing TN (terrestrial networks) may not consider the maintenance time because the parent IAB nodes are fixed. On the other hand, in an NTN IAB environment, the NTN gateway connectivity of the satellite IAB node may be lost. Therefore, when a new satellite IAB node selects a parent node in an IAB topology, it is necessary to consider the gateway maintenance time of the parent node, thereby increasing the maintenance time of the IAB topology.

[0284] As another example, a parameter indicating a hop count may be configured in an NTN IAB environment. In an NTN IAB environment, the distance between satellite IAB nodes may be large, resulting in long propagation delays. Therefore, when a new satellite IAB node selects a parent node within an IAB topology, the new satellite IAB node needs to consider the hop count when selecting the parent node, thereby reducing delays in transmitting and receiving data to the core network. Considering the above, a parameter indicating a hop count may be configured.

[0285] As another example, parameters indicating GSO / NGSO (Geostationary orbit / non-geostationary orbit) can be set in the IAB environment. More specifically, satellites can be divided into geostationary satellites, in which the Earth's rotation speed and the satellite's orbital speed are set to be the same and exist at the same location on the Earth, and non-geostationary satellites (NGSO satellites), which are satellites that orbit faster than the Earth's rotation speed at a lower altitude than the geostationary satellites. For example, when a new satellite IAB node selects a parent node within the IAB topology and receives the above-described GSO / NGSO information, the new satellite IAB node can efficiently select a parent node in the IAB integration procedure. Considering the above, parameters indicating GSO / NGSO can be set.

[0286] That is, based on the above, when a new satellite IAB node performs an IAB integration procedure, the satellite IAB node can obtain information of Table 9 below related to the NTN IAB, and use the information to select a parent node in the IAB integration procedure.

[0287] [Table 9]

[0288]

[0289]

[0290] FIG. 22 is a diagram illustrating an NTN IAB operation to which the present disclosure is applied. Referring to FIG. 22, satellite IAB donor 1 (2221), satellite node 1 (2231), satellite node 2 (2232), and satellite node 3 (2234) may form one IAB topology, and satellite IAB donor 2 (2222) may form one IAB topology. However, this is only an example for the convenience of explanation and may not be limited thereto. Here, the NTN gateway distance of satellite IAB donor 1 (2221) may be relatively closer than the NTN gateway distance of satellite IAB donor 2 (2222), and thus the IAB topology may be maintained for a long time. In addition, the IAB topology in FIG. 22 may include the same IAB donor CU located on the ground and connected to the NTN gateway. However, this is a configuration for the convenience of explanation and is not limited thereto.

[0291] In the above situation, satellite IAB node 3 (2233) may be a satellite IAB node that newly desires NTN IAB operation. That is, satellite IAB node 3 (2233) may be a new satellite IAB node. Satellite IAB node 3 (2233) may receive system information broadcast from satellite IAB donor 2 (2222), satellite IAB node 2 (2232), and satellite IAB node 4 (2234) among adjacent satellites capable of NTN IAB. Here, when only the IAB operation capability indicator is transmitted as in the existing IAB operation, satellite IAB node 3 (2233) may select satellite donor 2 (2222) with a relatively short maintenance time with the NTN gateway. That is, satellite IAB node 3 (2233) may select an IAB node without considering the gateway connectivity maintenance time. In the above-described case, if the NTN gateway connection of Satellite IAB Donor 2 (2222) is lost, a new NTN IAB procedure may be required. Therefore, Satellite IAB Node 3 (2233) needs to select a parent node with a long NTN gateway maintenance time, and for this purpose, it may receive the above-described connectivity information parameters as connectivity information with the NTN gateway.

[0292] As another example, satellite IAB node 3 (2233) can receive system information broadcast from satellite IAB donor 2 (2222), satellite IAB node 2 (2232), and satellite IAB node 4 (2234) among neighboring satellites capable of NTN IAB. Here, in a case where only the IAB operation capability indicator is transmitted as in the existing IAB operation, it can be considered that satellite IAB node 3 (2233) selects satellite IAB node 2 (2232) with the largest hop count as a parent node to perform the IAB integration procedure. In the above case, satellite IAB node 3 (2233) can select satellite IAB node 2 (2232) with a relatively large hop count compared to satellite IAB node 4 (2234), which may increase the delay time. Considering the above, satellite IAB nodes within the NTN IAB topology need to provide their hop count information to new satellite IAB nodes. To this end, the hop count-related parameters described above can be set and transmitted. This allows a new satellite IAB node to select a parent node while taking delay time into account when performing the NTN IAB integration procedure.

[0293] As another example, a new satellite IAB node can acquire additional GSO / NGSO-related parameters. Specifically, a GSO satellite can continuously provide connectivity to the NTN gateway, allowing it to perform NTN IAB operations for a longer period of time than an NGSO satellite. However, since a GSO may be located at a higher altitude than an NGSO, delays may increase. Considering the above, a new satellite IAB node may acquire GSO / NGSO-related information and select a parent node with an environment suited to its traffic characteristics, but this embodiment is not limited thereto.

[0294] FIG. 23 is a diagram illustrating a method for selecting a parent node in an IAB MT setup process to which the present disclosure is applied. Referring to FIG. 23, NTN IAB function-related parameters may be included in system information and transmitted in the IAB integration process. For example, a satellite IAB node may need to instruct a new satellite IAB node on the above-described parameter information. The new satellite IAB node may select an appropriate parent node based on the above-described information. For example, in FIG. 23, satellite IAB node 3 (2323) may receive system information from an adjacent satellite IAB node capable of NTN IAB operation and then select a parent IAB node through parameters associated with the NTN IAB. Specifically, satellite IAB node 3 (2323) may select a parent IAB node in the IAB MT setup process based on the IAB integration process as a new satellite IAB node. For example, in FIG. 23, satellite IAB node 3 (2323) can obtain system information broadcast from satellite IAB donor 2 (2312), satellite IAB node 2 (2322), and satellite IAB node 4 (2324) as neighboring satellite IAB nodes. For example, the system information transmitted by the satellite IAB node and satellite IAB donor performing the NTN IAB operation may include the parameter information of Table 9 described above. That is, the system information may include one or more of NTN gateway connectivity indication information, hop count information, and NGSO / GSO information. Satellite IAB node 3 (2323) can select a parent IAB node based on the above-described information. That is, satellite IAB node 3 (2323) can select a parent IAB node based on one or more of connectivity indication information, hop count information, and NGSO / GSO information as NTN IAB-related parameters within the received system information. For example, system information may be as shown in Table 10 below under SIB 1, but may not be limited thereto.

[0295] As a specific example, SIB 1 of Table 10 below may include NTN IAB function-related parameters. For example, the gateway connectivity indication may indicate the time at which the connection between the satellite IAB node, which is the first hop within the IAB topology, and the NTN gateway is interrupted. The gateway connectivity indication parameter may be an integer value and may indicate a unit of 10ms after 1900. 01. 01 00:00:00, but may not be limited thereto.

[0296] Additionally, as an example, the hop counter may represent the number of hops of a satellite IAB node performing the NTN IAB function, and may represent up to five hops as an integer value, but is not limited thereto. As an example, the hop counter may be represented as a bit string or as a higher integer value, and is not limited to a specific embodiment.

[0297] Additionally, as an example, NGSO / GSO may indicate GSO or NGSO with a 1-bit value, but is not limited thereto. As an example, NGSO / GSO may be indicated as BOOLEAN, and is not limited to a specific embodiment.

[0298] [Table 10]

[0299]

[0300]

[0301] As another example, NTN IAB topology adaptation can be considered as an intra-CU or inter-CU-based NTN IAB topology adaptation procedure. For example, in an NTN environment, a satellite connected to a ground-based NTN gateway must maintain connectivity to enable data transmission and reception between the terminal and the core network, as described above.

[0302] In other words, in an IAB topology, at least one satellite IAB node must have connectivity with a ground-based NTN gateway. However, because satellites are constantly moving, connectivity may not be maintained. In other words, a satellite IAB node connects to the NTN gateway for a specific period of time to communicate, and if the distance from the NTN gateway increases and signal quality degrades, communication becomes impossible.

[0303] Considering the above, it may be efficient for a new satellite IAB node to change to a target path that can maintain NTN gateway connectivity for a long time. More specifically, in existing TN IAB or mIAB, the parent IAB nodes are fixed, so the maintenance time may not be considered. On the other hand, in NTN IAB, the IAB topology may be maintained for a limited time, and the IAB topology may not be maintained after a certain period of time. Therefore, a satellite IAB node needs to consider the maintenance time of the target path and report it to the satellite IAB donor. Based on this, the target path can be changed to increase the time for which the IAB topology can be maintained. Gateway connectivity indication parameters can be configured for the above-described operation. As another example, in an NTN IAB environment, hop counts can be considered when changing the target path based on the propagation delay based on the distance between satellites, thereby reducing the delay in transmitting and receiving data to the core network.

[0304] Here, for example, in the case of the existing TN IAB and mIAB, in the IAB topology adaptation procedure, the IAB node can transmit a measurement report (MR) on signal quality to the IAB donor in the same manner as in the existing wireless communication system. The IAB donor can perform a procedure to change the IAB topology-based path based on the received measurement report. Here, since the IAB topology is fixed, unlike the NTN IAB environment, path validity determination for the parent IAB node may not be required. In addition, even when the final stage of the IAB topology moves to the mIAB environment, path validity determination for the parent nodes may not be required because the parent nodes are fixed.

[0305] For example, the intra-CU IAB topology adaptation procedure may be a procedure for changing an IAB donor DU in an IAB donor CU, as described above. Specifically, when one IAB donor CU, IAB donor CU A, and two IAB donor DUs, IAB donor DU A and IAB donor B, are connected based on the F1 interface, the IAB node may perform data transmission and reception through the IAB donor CU A and IAB donor DU A, and then, based on the signal quality result, change the path to another IAB donor DU, IAB donor DU B, within the same IAB donor CU A to perform data transmission and reception.

[0306] Also, as an example, the inter-CU IAB topology adaptation procedure may be a procedure for changing paths in different IAB donor CUs, as described above. Specifically, each of different IAB donor CUs A and B may be connected to one IAB donor DU X and one IAB donor DU Y via an F1 interface. Here, an IAB node may transmit and receive data through the IAB donor CU A and the IAB donor DU X, and then change the path to another IAB donor CU B and the IAB donor DU Y based on a signal quality result to transmit and receive data.

[0307] Here, as an example, in an NTN IAB environment, measurement reporting conditions can be set by considering NTN gateway connectivity (parent node or path validity time) and hop count. Specifically, if measurement report (MR) conditions are set by considering NTN gateway connectivity and hop count information, unnecessary measurement report transmission can be reduced. Furthermore, the satellite IAB donor can direct the NTN IAB topology adaptation procedure to an appropriate path based on the above-described information.

[0308] As a specific example, Table 11 below may be conditions for the occurrence of a measurement report event or conditional handover in an existing wireless communication system. For example, if the conditions expressed as events in Table 11 below are satisfied, the terminal may perform a measurement report (MR) on the measurement results to the network. As another example, if the conditions expressed as "CondEvent" in Table 11 below are satisfied, the terminal may perform a conditional handover (CHO) to the target cell.

[0309] [Table 11]

[0310]

[0311]

[0312] Here, as an example, a new event may be defined based on parameters related to the NTN IAB function described above. As a specific example, Table 12 below may be a new event based on the parameters described above, but may not be limited thereto. Referring to Table 12, an event may be set when the NTN gateway validity time is greater than a preset threshold, considering the NTN gateway connectivity maintenance time of a neighboring cell. (Event T1) As another example, an event may be set when the hop count of a neighboring cell is lower than a preset threshold, but may not be limited thereto. (Event H1)

[0313] [Table 12]

[0314]

[0315]

[0316] FIG. 24 is a diagram illustrating an NTN IAB topology adaptation procedure to which the present disclosure applies. Referring to FIG. 24, satellite IAB donor 1 (2421), satellite IAB node 1 (2431), and satellite IAB node 2 (2432) can form one IAB topology. In addition, satellite IAB donor 2 (2422) and satellite IAB node 3 (2433) can form one IAB topology. In addition, satellite IAB donor 3 (2423) and satellite IAB node 4 (2434) can form one IAB topology. Here, satellite IAB donor 1 (2421) and satellite IAB donor 2 (2422) can be connected to the same IAB donor CU and F1 interface through the same NTN gateway (2411). On the other hand, satellite IAB donor 3 (2423) can be connected to another IAB donor CU via another NTN gateway (2412) via the F1 interface. However, this is only an example for convenience of explanation and is not limited thereto.

[0317] For example, the same applies to cases where the satellite donor DU is not located on a satellite but on the ground, and is not limited to a specific form. If the IAB donor DU is located on the ground, similar to the IAB donor CU, the satellite IAB donor in FIG. 24 can operate as a satellite IAB node, and is not limited to a specific embodiment.

[0318] Here, as an example, satellite IAB node 3 (2433) may measure a specific event through a measurement configuration set via an RRC message transmitted by the satellite IAB donor CU based on NTN IAB topology adaptation operation. As an example, the specific event may include Tables 11 and 12 described above, but is not limited to a specific embodiment.

[0319] As a specific example, Table 12 described above as a specific event can be considered. For example, if the NTN gateway validity time of a neighboring cell is greater than a preset threshold (Event T1), satellite IAB node 3 (2433) may determine that the event condition is met and report the measurement result to the satellite IAB donor CU. As a more specific example, a case may be considered where the preset threshold for the event (Event T1) of Table 12 in the measurement configuration transmitted by the satellite IAB donor CU is 120m (minute), the NTN gateway validity time of satellite IAB node 2 is 100m, and the NTN gateway validity time of satellite IAB node 4 is 2000m. However, this is just one example for convenience of explanation and is not limited thereto. Here, satellite IAB node 3 (2433) can receive reference signals (e.g., SSB, synchronization signal block) from satellite IAB node 2 (2432) and satellite IAB node 4 (2434) and perform measurements. Satellite IAB node 3 (2433) can receive reference signals from adjacent satellite IAB nodes and acquire system information based on the signals. Here, when satellite IAB node 3 (2433) can perform measurements by receiving reference signals from satellite IAB node 2 (2432) and satellite IAB node 4 (2434), satellite IAB node 3 (2433) can check the NTN gateway validity time based on the system information received from each satellite. That is, each system information may include a parameter for the NTN gateway connectivity maintenance time as described above. Here, satellite IAB node 3 (2433) can transmit a measurement result report for satellite IAB node 4 (2434) having an NTN gateway validity time greater than 120 m as a preset threshold value to the satellite IAB donor CU.

[0320] As another example, a case where the hop count of a neighboring cell is lower than a preset threshold value may be considered. In FIG. 24, satellite IAB node 3 (2433) may report the measurement result to the IAB donor CU when the hop count is lower than the threshold value. More specifically, a hop count-based event (Event H1) of Table 12 may be set within the measurement configuration transmitted by the satellite IAB donor CU. Here, a case where the threshold value for the hop count is 3, the hop count of satellite IAB node 2 (2432) is 3, and the hop count of satellite IAB node 4 (2434) is 2 may be considered. However, this is only one example for the convenience of explanation and is not limited to the above-described embodiment. Here, satellite IAB node 3 (2433) may perform measurement by receiving a reference signal (e.g., SSB) from satellite IAB node 2 (2432) and satellite IAB node 4 (2434). Satellite IAB node 3 (2433) can receive reference signals from adjacent satellite IAB nodes and acquire system information based on the reference signals. Here, when satellite IAB node 3 (2433) performs measurements by receiving reference signals from satellite IAB node 2 (2432) and satellite IAB node 4 (2434), satellite IAB node 3 (2433) can check the hop count based on the system information received from each satellite. That is, each system information can include a parameter for the hop count as described above. Here, satellite IAB node 3 (2433) can report the result of satellite IAB node 4 (2434) having a hop count less than 3 as a threshold value.

[0321] As another example, the NTN gateway connectivity maintenance-based event (Event T1) and the hop count-based event (Event H1) in Table 12 can be configured in parallel with existing signal quality events. That is, the events can be configured in parallel, and the terminal can report measurement results by checking two conditions.

[0322] As a specific example, Event A3 of Table 11 and Event T1 of Table 12 may be associated with the terminal and set. The terminal may transmit a measurement report to the satellite IAB donor CU when the signal quality of the reference signal of the neighboring cell is better than the signal quality of the serving cell plus an offset value (Event A3) and the NTN gateway validity time condition is satisfied (Event T1).

[0323] As another example, Event A3 of Table 11 and Event H1 of Table 12 may be associated with the terminal. The terminal may transmit a measurement report to the satellite IAB donor CU when the signal quality of the reference signal of the neighboring cell is better than the signal quality of the serving cell plus an offset value (Event A3) and the NTN hop count condition is satisfied (Event H1).

[0324] FIG. 25 is a diagram illustrating a method for performing measurement reporting in an NTN IAB to which the present disclosure is applied. Referring to FIG. 25, the above-described satellite IAB node 3 can perform a measurement reporting procedure for NTN IAB topology adaptation operation. As a specific example, satellite IAB node 3 (2523) can receive system information from an adjacent satellite IAB node capable of NTN IAB operation and then determine a measurement report based on parameters associated with the NTN IAB. For example, a measurement configuration for satellite IAB donor 2 (2512) connected to satellite IAB node 3 (2523) can be set by transmitting reporting conditions, measurement methods, and other information for a specific frequency via an RRC message of an IAB donor CU of a serving cell of satellite IAB node 3 (2523). In addition, satellite IAB node 4 (2524) and satellite IAB node 2 (2522), which are neighboring satellite IAB nodes of satellite IAB node 3 (2523), can broadcast system information, and satellite IAB node 3 (2523) can receive the system information. That is, the satellite IAB node and satellite IAB donor performing NTN IAB operation can broadcast system information. Here, the system information can include at least one of the NTN gateway connectivity indication and hop counter parameter described above. Satellite IAB node 3 (2523) can receive system information transmitted by neighboring satellites and perform measurements on SSB. Satellite IAB node 3 (2523) can check whether a reporting condition is satisfied based on at least one of the parameters associated with NTN IAB within the system information received from neighboring satellites capable of NTN IAB. Satellite IAB node 3 (2523) can report measurement results to satellite IAB donor CU for measurement identifiers that satisfy reporting conditions.

[0325] As another example, FIG. 26 is a diagram illustrating a parameter reporting method for inter / intra CU NTN IAB topology adaptation to which the present disclosure applies.

[0326] Referring to FIG. 26, a condition for triggering an event is not determined based on at least one of the NTN gateway validity time and the hop count, and at least one of the NTN gateway validity time and the hop count may be included in the measurement report.

[0327] For example, when configuring a measurement with a satellite IAB node, the network may be configured to transmit at least one of the NTN gateway validity time and hop count in the measurement report. Accordingly, based on Table 11 described above, if the signal quality is satisfied according to an event, the satellite IAB node may transmit the measurement report while including at least one of the NTN gateway validity time and hop count in the measurement configuration. Here, at least one of the NTN gateway validity time and hop count may be activated.

[0328] As a specific example, referring to FIG. 26, satellite IAB node 3 (2623) can receive system information from an adjacent satellite IAB node capable of NTN IAB operation. Thereafter, when satellite IAB node 3 (2623) triggers a measurement report, satellite IAB node 3 (2623) can transmit parameters associated with NTN IAB by including them in the measurement report.

[0329] For example, the measurement configuration for a satellite IAB donor 2 (2612) connected to a satellite IAB node 3 (2623) can be set by transmitting the reporting conditions, measurement method, and other information for a specific frequency via an RRC message of the IAB donor CU of the serving cell of the satellite IAB node 3 (2623). Here, the measurement configuration can be set to be transmitted including at least one of the NTN gateway validity time and the hop count.

[0330] In addition, satellite IAB node 4 (2624) and satellite IAB node 2 (2622) can broadcast system information to the surrounding satellite IAB nodes of satellite IAB node 3 (2623), and satellite IAB node 3 (2623) can receive the system information. That is, the satellite IAB node and satellite IAB donor performing NTN IAB operation can broadcast system information. Here, the system information can include at least one of the NTN gateway connectivity indication and hop counter parameter described above. Satellite IAB node 3 (2623) can receive system information transmitted by neighboring satellites and perform measurement for SSB. Thereafter, satellite IAB node 3 (2623) can decide to report the measurement. For example, satellite IAB node 3 (2623) can check the SSB signal quality of a neighboring satellite capable of NTN IAB and check whether the reporting conditions of Table 11 are satisfied. Satellite IAB node 3 (2623) may decide to issue a measurement report if the reporting conditions are met. Here, the measurement report may include at least one of an NTN gateway connectivity indication and a hop counter parameter.

[0331] Fig. 27 is a flowchart illustrating an operation method of an IAB donor to which the present disclosure is applied. Referring to Fig. 27, the IAB donor can perform a random access procedure with a satellite IAB node based on NTN IAB topology integration (S2710). Here, the satellite IAB node may be a satellite IAB node newly integrated into the NTN IAB topology. The IAB donor can perform an RRC connection establishment procedure with the satellite IAB node based on the random access procedure (S2720). Here, as an example, the IAB donor can obtain NTN IAB-related parameters in the RRC connection establishment procedure. As a more specific example, the IAB donor can obtain NTN IAB-related parameters included in an RRC setup complete message. Thereafter, the IAB donor can select an AMF based on NTN IAB related parameters. (S2730) Here, as an example, the NTN IAB related parameters can be set based on at least one of the NTN IAB operation indicator, satellite orbit, and cell type, and can be as shown in Table 6 described above.

[0332] Fig. 28 is a flowchart illustrating a method of operating a satellite IAB node to which the present disclosure is applied. Referring to Fig. 28, a satellite IAB node may obtain NTN IAB-related parameters from at least one potential parent IAB node. (S2810) Here, the satellite IAB node may be a satellite IAB node newly integrated into the NTN IAB topology. Thereafter, the satellite IAB node may select a parent IAB node based on the NTN IAB-related parameters. (S2820) Here, as an example, the NTN IAB-related parameters may be set based on at least one of a gateway connectivity validity time, a hop count, and whether or not the satellite is in a geostationary orbit, and may be as shown in Table 9 described above.

[0333] Figure 29 is a flowchart showing a satellite IAB node operation method to which the present disclosure is applied.

[0334] Referring to FIG. 29, a satellite IAB node can obtain measurement configuration information for a measurement report. (S2910) For example, the measurement configuration information can be configured by a satellite IAB donor, and the reporting conditions for frequencies, measurement methods, and other information can be transmitted and set. Thereafter, the satellite IAB node can obtain NTN IAB-related parameters from at least one adjacent satellite IAB node. (S2920) Thereafter, the satellite IAB node can determine whether to perform a measurement report and perform the measurement report. (S2930) For example, the NTN IAB-related parameters can be set based on at least one of the gateway connectivity validity time, the hop count, and whether the satellite is in a geostationary orbit, and can be as shown in Table 9 described above. Here, as an example, an event for a measurement report can be configured as a separate event based on the NTN IAB-related parameters, as shown in Table 12 described above. As another example, an event for a measurement report is an event based on Table 11 described above, and the measurement report may include NTN IAB related parameters, and is not limited to a specific embodiment.

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

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

[0337] The first device (3000) may include a processor (3020), an antenna unit (3012), a transceiver (3014), and a memory (3016). The processor (3020) performs baseband-related signal processing and may include a higher layer processing unit (3030) and a physical layer processing unit (3040). The higher layer processing unit (3030) may process operations of a medium access control (MAC) layer, a radio resource control (RRC) layer, or higher layers. The physical layer processing unit (3040) 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 (3020) may also control the overall operation of the first device (3000). The antenna unit (3012) 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 (3016) may store information processed by the processor (3020), software related to the operation of the first device (3000), an operating system, applications, etc., and may include components such as a buffer. The processor (3020) of the first device (3000) may be configured to implement the operation of the first device in the embodiments described in the present invention.

[0338] The second device (3050) may include a processor (3070), an antenna unit (3062), a transceiver (3064), and a memory (3066). For example, in the present invention, the second device (3050) may communicate with the first device (3000). The processor (3070) may perform baseband-related signal processing and may include a higher layer processing unit (3080) and a physical layer processing unit (3090). The higher layer processing unit (3080) may process operations of a MAC layer, an RRC layer, or higher layers. The physical layer processing unit (3090) 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 (3070) may also control operations of the overall terminal device (3050). The antenna unit (3062) 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 (3066) may store information processed by the processor (3070), software related to the operation of the second device (3050), an operating system, applications, etc., and may include components such as a buffer. The second device (3050) according to an example of the present invention may be associated with a vehicle. For example, the second device (3050) may be integrated into the vehicle, located in the vehicle, or located on the vehicle. In addition, the second device (3050) according to the present invention may be the vehicle itself. In addition, the second device (3050) 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 (3050) 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.

[0339] 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 (3050) 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 (3050) 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. That is, the second device (3050) may not only directly support interactive services utilizing sidelink, but may also be utilized as a cooperation device to support interactive services utilizing sidelink.

[0340] For example, the first device (3000) may be an IAB donor, and the second device (3050) may be a satellite IAB node. Here, the second device (3050) may be a satellite IAB node newly integrated into the NTN IAB topology. The first device (3000) may perform an RRC connection establishment procedure with the second device (3050) based on a random access procedure. Here, as an example, the first device (3000) may obtain NTN IAB-related parameters in the RRC connection establishment procedure. As a more specific example, the first device (3000) may obtain NTN IAB-related parameters included in an RRC setup complete message. Thereafter, the first device (3000) may select an AMF based on the NTN IAB-related parameters. Here, as an example, the NTN IAB related parameters may be set based on at least one of the NTN IAB operation indicator, satellite orbit, and cell type, and may be as shown in Table 6 described above.

[0341] As another example, the second device (3050) may obtain NTN IAB-related parameters from at least one potential parent IAB node. Here, the second device (3050) may be a satellite IAB node newly integrated into the NTN IAB topology. Thereafter, the second device (3050) may select a parent IAB node based on the NTN IAB-related parameters. Here, as an example, the NTN IAB-related parameters may be set based on at least one of gateway connectivity validity time, hop count, and whether the satellite is in geostationary orbit, and may be as shown in Table 9 described above.

[0342] As another example, the second device (3050) can obtain measurement configuration information for a measurement report. For example, the measurement configuration information can be configured by the first device (3000), and the reporting conditions for the frequency, the measurement method, and other information can be transmitted and set. Thereafter, the second device (3050) can obtain NTN IAB-related parameters from at least one adjacent satellite IAB node. Thereafter, the second device (3050) can determine whether to perform a measurement report and perform the measurement report. For example, the NTN IAB-related parameters can be set based on at least one of the gateway connectivity validity time, the hop count, and whether the satellite is in geostationary orbit, and can be as shown in Table 9 described above. Here, as an example, the event for the measurement report can be configured as a separate event based on the NTN IAB-related parameters, as shown in Table 12 described above. As another example, an event for a measurement report is an event based on Table 11 described above, and the measurement report may include NTN IAB related parameters, and is not limited to a specific embodiment.

[0343] 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.

[0344] 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.

[0345] 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.

[0346]

[0347] The following may also apply to other systems.

Claims

1. In wireless devices, wireless transceiver; one or more processors; and A memory that stores instructions for the wireless device when executed by one or more of the above processes; The operation of the above wireless device is: Performs a random access procedure with satellite IAB nodes based on integration of non-terrestrial networks (NTN) integrated access backhaul (IAB) topology, Based on the random access procedure, a radio resource control (RRC) connection establishment procedure is performed with the satellite IAB node, and NTN IAB related parameters are acquired in the RRC connection establishment procedure, and Select AMF (access management function) based on the above NTN IAB related parameters, A wireless device, wherein the above NTN IAB related parameters are set based on at least one of an NTN IAB operating indicator, a satellite orbit, and a cell type.

2. In wireless devices, wireless transceiver; one or more processors; and A memory that stores instructions for the wireless device when executed by one or more of the above processes; The operation of the above wireless device is: Obtain NTN IAB related parameters from at least one potential parent IAB node, and Select a parent IAB node based on the above NTN IAB related parameters, A wireless device wherein the above NTN IAB related parameters are set based on at least one of gateway connectivity validity time, hop count, and geostationary satellite.

3. In wireless devices, wireless transceiver; one or more processors; and A memory that stores instructions for the wireless device when executed by one or more of the above processes; The operation of the above wireless device is: Obtain measurement configuration information for measurement reports, Obtain NTN IAB related parameters from at least one satellite IAB node, and A wireless device that determines whether to perform the above measurement report and performs the above measurement report, wherein the NTN IAB related parameters are set based on at least one of the gateway connectivity validity time, hop count, and whether or not it is a geostationary satellite.

Images